| Summary: | [HSW/BYT Bisected]igt/drv_module_reload causes WARNING "Memory manager not clean during takedown." + slab not clean | ||||||
|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Guo Jinxian <jinxianx.guo> | ||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Severity: | normal | ||||||
| Priority: | high | CC: | intel-gfx-bugs | ||||
| Version: | XOrg git | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Guo Jinxian
2014-11-21 03:48:27 UTC
Hm, I've noticed similar "Memory manager not clean" issues when reloading i915.ko on my snb just this week. Do you see this on other platforms, too? Btw for WARNING there's often a 2nd line with some explanation, that should be the bug summary according to bug filing BKM. I've fixed it. Bisect should definitely help here since it looks like a leak somewhere. dcb4c12a687710ab745c2cdee8298c3e97f6f707 is the first bad commit Author: Oscar Mateo <oscar.mateo@intel.com> AuthorDate: Thu Nov 13 10:28:10 2014 +0000 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Wed Nov 19 19:32:58 2014 +0100 drm/i915/bdw: Pin the context backing objects to GGTT on-demand Up until now, we have pinned every logical ring context backing object during creation, and left it pinned until destruction. This made my life easier, but it's a harmful thing to do, because we cause fragmentation of the GGTT (and, eventually, we would run out of space). This patch makes the pinning on-demand: the backing objects of the two contexts that are written to the ELSP are pinned right before submission and unpinned once the hardware is done with them. The only context that is still pinned regardless is the global default one, so that the HWS can still be accessed in the same way (ring->status_page). v2: In the early version of this patch, we were pinning the context as we put it into the ELSP: on the one hand, this is very efficient because only a maximum two contexts are pinned at any given time, but on the other hand, we cannot really pin in interrupt time :( v3: Use a mutex rather than atomic_t to protect pin count to avoid races. Do not unpin default context in free_request. v4: Break out pin and unpin into functions. Fix style problems reported by checkpatch v5: Remove unpin_lock as all pinning and unpinning is done with the struct mutex already locked. Add WARN_ONs to make sure this is the case in future. Issue: VIZ-4277 Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> :040000 040000 b99fffd2ff94e9c66c4797886726deb6cdf9d502 d3501260bc640ac87a2a95d13ecfc379caaf4d41 M drivers On it's parents commit(c86ee3a9f8cddcf2e637da19d6e7c05bdea11a96), another dmseg warning reproduced. [root@x-hsw24 tests]# ./drv_module_reload unbinding /sys/class/vtconsole/vtcon0/: (M) frame buffer device module successfully unloaded [root@x-hsw24 tests]# dmesg -r|egrep "<[1-4]>"|grep drm <4>[ 48.255113] WARNING: CPU: 5 PID: 3981 at drivers/gpu/drm/i915/intel_pm.c:6207 intel_disable_gt_powersave+0x33/0x37a [i915]() <4>[ 48.255117] dm_mod snd_hda_codec_realtek snd_hda_codec_generic iTCO_wdt iTCO_vendor_support snd_hda_codec_hdmi dcdbas serio_raw pcspkr i2c_i801 snd_hda_controller snd_hda_codec snd_hwdep lpc_ich shpchp mfd_core snd_pcm snd_timer snd soundcore battery acpi_cpufreq i915(-) button video drm_kms_helper drm [last unloaded: snd_hda_intel] <4>[ 48.255165] [<ffffffffa0004dd3>] ? vblank_disable_and_save+0x170/0x17f [drm] <4>[ 48.255197] [<ffffffffa0007527>] ? drm_dev_unregister+0x1e/0x8b [drm] <4>[ 48.255202] [<ffffffffa0007757>] ? drm_put_dev+0x3e/0x47 [drm] <4>[ 48.255222] [<ffffffffa000917a>] ? drm_pci_exit+0x38/0x98 [drm] (In reply to Daniel Vetter from comment #1) > Hm, I've noticed similar "Memory manager not clean" issues when reloading > i915.ko on my snb just this week. Do you see this on other platforms, too? > > Btw for WARNING there's often a 2nd line with some explanation, that should > be the bug summary according to bug filing BKM. I've fixed it. > > Bisect should definitely help here since it looks like a leak somewhere. I checked on ILK SNB and BYT platforms, and only reproduce this on BYT platform. (In reply to Guo Jinxian from comment #3) > (In reply to Daniel Vetter from comment #1) > > Hm, I've noticed similar "Memory manager not clean" issues when reloading > > i915.ko on my snb just this week. Do you see this on other platforms, too? > > > > Btw for WARNING there's often a 2nd line with some explanation, that should > > be the bug summary according to bug filing BKM. I've fixed it. > > > > Bisect should definitely help here since it looks like a leak somewhere. > > I checked on ILK SNB and BYT platforms, and only reproduce this on BYT > platform. Hm, BYT is likely a different bug since the bisected commit is for gen8+ (bdw/bsw) only. Can you please file a new bug report for BYT? Also please check whether it's a regression and bisect if so. commit 958f8cd96f979b20c45c55cba14bf8d8fbeca64f Author: Thomas Daniel <thomas.daniel@intel.com> Date: Tue Nov 25 10:39:25 2014 +0000 drm/i915: Fix context object leak for legacy contexts Verified on latest -nightly(0db9cf7742874ee2c09a35b640c1bb04cb379eb6) [root@x-hsw24 tests]# ./drv_module_reload unbinding /sys/class/vtconsole/vtcon0/: (M) frame buffer device module successfully unloaded [root@x-hsw24 tests]# dmesg -r|egrep "<[1-4]>"|grep drm Closing old verified. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.