[Bug 86507] [HSW Bisected]igt/drv_module_reload causes WARNING "Memory manager not clean during takedown." + slab not clean

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=86507

Guo Jinxian <jinxianx.guo at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|bisect_pending              |
            Summary|[HSW                        |[HSW
                   |Regression]igt/drv_module_r |Bisected]igt/drv_module_rel
                   |eload causes WARNING        |oad causes WARNING "Memory
                   |"Memory manager not clean   |manager not clean during
                   |during takedown." + slab    |takedown." + slab not clean
                   |not clean                   |

--- Comment #2 from Guo Jinxian <jinxianx.guo at intel.com> ---
dcb4c12a687710ab745c2cdee8298c3e97f6f707 is the first bad commit
Author:     Oscar Mateo <oscar.mateo at intel.com>
AuthorDate: Thu Nov 13 10:28:10 2014 +0000
Commit:     Daniel Vetter <daniel.vetter at 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 at intel.com>
    Signed-off-by: Thomas Daniel <thomas.daniel at intel.com>
    Reviewed-by: Akash Goel <akash.goels at gmail.com>
    Reviewed-by: Deepak S<deepak.s at linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>

:040000 040000 b99fffd2ff94e9c66c4797886726deb6cdf9d502
d3501260bc640ac87a2a95d13ecfc379caaf4d41 M      drivers

On it's parents commit(c86ee3a9f8cddcf2e637da19d6e7c05bdea11a96), another dmseg
warning reproduced.

[root at x-hsw24 tests]# ./drv_module_reload
unbinding /sys/class/vtconsole/vtcon0/: (M) frame buffer device
module successfully unloaded
[root at 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]

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20141124/4b29cdc9/attachment.html>