Re: DRM-related kmalloc-32 memory leak in 2.6.35
On Mon, 27 Sep 2010, Andrew Morton wrote: > > Still present in 2.6.35. Appears to be DRM: > > > > 845 drm_vm_open_locked+0x72/0x109 age=43/37572/59269 pid=2089 > > cpus=0-1 > > > > That's after about a minute of uptime. Grows to 100k in about a day. > > > > dmesg bits: > > [0.834653] [drm] Initialized drm 1.1.0 20060810 > > [0.834986] pci :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > > [0.834995] pci :00:02.0: setting latency timer to 64 > > [1.002572] mtrr: type mismatch for e000,1000 old: write-back > > new: write-combining > > [1.002580] [drm] MTRR allocation failed. Graphics performance may > > suffer. > > [1.019880] acpi device:03: registered as cooling_device2 > > [1.021520] input: Video Bus as > > /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 > > [1.021543] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: > > no) > > [1.021855] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > > minor 0 > > > > This is with: > > > > 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 > > Integrated Graphics Controller (rev 03) > > 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 > > Integrated Graphics Controller (rev 03) > > > > Matt tells me that this (drop-dead box-killing!) bug is still present > in current kernels. Could someone take a look please? > > The code seems very simple, and I couldn't spot a problem. Probably > this means that I'm even simpler. > I'm wondering what reading /sys/kernel/debug/dri/.../vma says when DRM_DEBUG_CODE is enabled, it seems to have been written for this type of debugging. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
DRM-related kmalloc-32 memory leak in 2.6.35
On Mon, 27 Sep 2010, Andrew Morton wrote: > > Still present in 2.6.35. Appears to be DRM: > > > > 845 drm_vm_open_locked+0x72/0x109 age=43/37572/59269 pid=2089 > > cpus=0-1 > > > > That's after about a minute of uptime. Grows to 100k in about a day. > > > > dmesg bits: > > [0.834653] [drm] Initialized drm 1.1.0 20060810 > > [0.834986] pci :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > > [0.834995] pci :00:02.0: setting latency timer to 64 > > [1.002572] mtrr: type mismatch for e000,1000 old: write-back > > new: write-combining > > [1.002580] [drm] MTRR allocation failed. Graphics performance may > > suffer. > > [1.019880] acpi device:03: registered as cooling_device2 > > [1.021520] input: Video Bus as > > /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 > > [1.021543] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: > > no) > > [1.021855] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > > minor 0 > > > > This is with: > > > > 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 > > Integrated Graphics Controller (rev 03) > > 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 > > Integrated Graphics Controller (rev 03) > > > > Matt tells me that this (drop-dead box-killing!) bug is still present > in current kernels. Could someone take a look please? > > The code seems very simple, and I couldn't spot a problem. Probably > this means that I'm even simpler. > I'm wondering what reading /sys/kernel/debug/dri/.../vma says when DRM_DEBUG_CODE is enabled, it seems to have been written for this type of debugging.
Re: DRM-related kmalloc-32 memory leak in 2.6.35
On Wed, 25 Aug 2010 15:59:09 -0500 Matt Mackall wrote: > On Tue, 2010-08-24 at 10:37 -0500, Christoph Lameter wrote: > > On Tue, 24 Aug 2010, Matt Mackall wrote: > > > > > kmalloc-321113344 1113344 32 1281 : tunables00 > > > 0 : slabdata 8698 8698 0 > > > > > > That's /proc/slabinfo on my laptop with SLUB. It looks like my last > > > reboot popped me back to 2.6.33 so it may also be old news, but I > > > couldn't spot any reports with Google. > > > > Boot with "slub_debug" as a kernel parameter > > > > and then do a > > > > cat /sys/kernel/slab/kmalloc-32/alloc_calls > > > > to find the caller allocating the objets. > > Still present in 2.6.35. Appears to be DRM: > > 845 drm_vm_open_locked+0x72/0x109 age=43/37572/59269 pid=2089 > cpus=0-1 > > That's after about a minute of uptime. Grows to 100k in about a day. > > dmesg bits: > [0.834653] [drm] Initialized drm 1.1.0 20060810 > [0.834986] pci :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > [0.834995] pci :00:02.0: setting latency timer to 64 > [1.002572] mtrr: type mismatch for e000,1000 old: write-back new: > write-combining > [1.002580] [drm] MTRR allocation failed. Graphics performance may suffer. > [1.019880] acpi device:03: registered as cooling_device2 > [1.021520] input: Video Bus as > /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 > [1.021543] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) > [1.021855] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > minor 0 > > This is with: > > 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 > Integrated Graphics Controller (rev 03) > 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 > Integrated Graphics Controller (rev 03) > Matt tells me that this (drop-dead box-killing!) bug is still present in current kernels. Could someone take a look please? The code seems very simple, and I couldn't spot a problem. Probably this means that I'm even simpler. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
DRM-related kmalloc-32 memory leak in 2.6.35
On Wed, 25 Aug 2010 15:59:09 -0500 Matt Mackall wrote: > On Tue, 2010-08-24 at 10:37 -0500, Christoph Lameter wrote: > > On Tue, 24 Aug 2010, Matt Mackall wrote: > > > > > kmalloc-321113344 1113344 32 1281 : tunables00 > > > 0 : slabdata 8698 8698 0 > > > > > > That's /proc/slabinfo on my laptop with SLUB. It looks like my last > > > reboot popped me back to 2.6.33 so it may also be old news, but I > > > couldn't spot any reports with Google. > > > > Boot with "slub_debug" as a kernel parameter > > > > and then do a > > > > cat /sys/kernel/slab/kmalloc-32/alloc_calls > > > > to find the caller allocating the objets. > > Still present in 2.6.35. Appears to be DRM: > > 845 drm_vm_open_locked+0x72/0x109 age=43/37572/59269 pid=2089 > cpus=0-1 > > That's after about a minute of uptime. Grows to 100k in about a day. > > dmesg bits: > [0.834653] [drm] Initialized drm 1.1.0 20060810 > [0.834986] pci :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > [0.834995] pci :00:02.0: setting latency timer to 64 > [1.002572] mtrr: type mismatch for e000,1000 old: write-back new: > write-combining > [1.002580] [drm] MTRR allocation failed. Graphics performance may suffer. > [1.019880] acpi device:03: registered as cooling_device2 > [1.021520] input: Video Bus as > /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 > [1.021543] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) > [1.021855] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > minor 0 > > This is with: > > 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 > Integrated Graphics Controller (rev 03) > 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 > Integrated Graphics Controller (rev 03) > Matt tells me that this (drop-dead box-killing!) bug is still present in current kernels. Could someone take a look please? The code seems very simple, and I couldn't spot a problem. Probably this means that I'm even simpler.
