Is this still an issue on drm-intel-testing (that combines -fixes and -queued)? I have a feeling this is another case of the hw context stuff blowing up.

It also happens on (drm-intel-testing)ef6113ad0f406db4fbe2bcf3359dd938a6046d75.

In that case it sounds like a normal regression introduce in -queued. Can you please bisect this? Just looking at the dmesg&backtrace I have no idea what's going wrong here :(

Just to confirm: Does this happen even if you run the module reload test right after boot, i.e. with nothing else having run?

After boot, Run(only run) the module reload, This issue happens.

I tried to bisect it.Selected good commit:20d5a540e55a29daeef12706f9ee73baf5641c16   and bad commit:83358c85866ebd2af1229fc9870b93e126690671.

Bisect shows:
The merge base 6b16351acbd415e66ba16bf7d473ece1574cf0bc is bad.
This means the bug has been fixed between 6b16351acbd415e66ba16bf7d473ece1574cf0bc and [20d5a540e55a29daeef12706f9ee73baf5641c16]

Can you please double-check that 6b16351acbd415e66ba16bf7d473ece1574cf0bc is really bad. Also, please attach the bisect log:

$ git bisect log

For checking Bug 53526, add slub_debug on the cmdline causes this issue.
Remove this slub_debug, It doesn't happen.

It's not a regression, caused by slub_debug.

Can you please retest now that the other mysterious slub_debug issue resolved itself.

It still happens on commit 2fc764a311ca1e51c69ac3ff2872ae49617f9b46(Merge: 1a9a08f 3d840a1)

[   42.362225] Call Trace:
[   42.362330]  [<ffffffffa01c4e11>] sandybridge_update_wm+0x61/0x414 [i915]
[   42.362434]  [<ffffffff810f8f16>] ? kfree+0xd2/0x12e
[   42.362542]  [<ffffffffa01ac56c>] ? intel_crtc_destroy+0x62/0x6b [i915]
[   42.362652]  [<ffffffffa01c6251>] intel_update_watermarks+0x19/0x1b [i915]
[   42.362766]  [<ffffffffa01d00a5>] ivb_disable_plane+0x95/0x9e [i915]
[   42.362877]  [<ffffffffa01cfa7e>] intel_disable_plane+0x24/0x62 [i915]
[   42.362987]  [<ffffffffa01cfacb>] intel_destroy_plane+0xf/0x24 [i915]
[   42.363097]  [<ffffffffa0053bf3>] drm_mode_config_cleanup+0x147/0x17c [drm]
[   42.363208]  [<ffffffffa01b698b>] intel_modeset_cleanup+0xf9/0x105 [i915]
[   42.363315]  [<ffffffffa0192282>] i915_driver_unload+0xee/0x24f [i915]
[   42.363424]  [<ffffffffa004e413>] drm_put_dev+0xd2/0x1af [drm]
[   42.363529]  [<ffffffffa018e1eb>] i915_pci_remove+0x18/0x1a [i915]
[   42.363631]  [<ffffffff8122a5f9>] pci_device_remove+0x28/0x4c
[   42.363732]  [<ffffffff812a9b23>] __device_release_driver+0x67/0xba
[   42.363834]  [<ffffffff812aa247>] driver_detach+0x8f/0xb8
[   42.363936]  [<ffffffff812a9986>] bus_remove_driver+0x8c/0xae
[   42.364036]  [<ffffffff812aa7cb>] driver_unregister+0x64/0x6d
[   42.364137]  [<ffffffff8122a88d>] pci_unregister_driver+0x3f/0x88
[   42.364245]  [<ffffffffa00504e2>] drm_pci_exit+0x3f/0x78 [drm]
[   42.364356]  [<ffffffffa01d4897>] i915_exit+0x17/0x19 [i915]
[   42.364458]  [<ffffffff81081532>] sys_delete_module+0x1a6/0x204
[   42.364559]  [<ffffffff81079400>] ? trace_hardirqs_on_caller+0x11e/0x155
[   42.364662]  [<ffffffff81095e68>] ? __audit_syscall_entry+0x191/0x1bd
[   42.364766]  [<ffffffff813de062>] system_call_fastpath+0x16/0x1b
[   42.364866] Code: 48 8b bc f0 78 36 00 00 48 8b 47 28 48 85 c0 74 06 80 7f 30 00 75 14 49 8b 40 18 41 89 03 49 8b 42 18 89 03 31 c0 e9 ca 00 00 00 <44> 8b 68 5c be 08 00 00 00 44 8b a7 80 00 00 00 4d 8b 72 20 44
[   42.367978] RIP  [<ffffffffa01c296b>] g4x_compute_wm0+0x4d/0x122 [i915]
[   42.368132]  RSP <ffff880225125bb0>
[   42.368236] ---[ end trace 6eaebf99d70dd4de ]---

Created attachment 67268 [details]
dmesg

Created attachment 67271 [details] [review]
Destroy CRTCs after planes.

(In reply to comment #12)
> Created attachment 67271 [details] [review] [review]
> Destroy CRTCs after planes.

Add this patch into -queued kernel(commit:cd9a8c405d532bb74c6e243),This issue goes away.

commit 3184009c36da413724f283e3c7ac9cc60c623bc4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Sep 17 09:38:03 2012 +0000

    drm: Destroy the planes prior to destroying the associated CRTC
    
    As during the plane cleanup, we wish to disable the hardware and
    so may modify state on the associated CRTC, that CRTC must continue to
    exist until we are finished.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
    Cc: stable@vger.kernel.org
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Tested-by: lu hua <huax.lu@intel.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

(In reply to comment #14)
> commit 3184009c36da413724f283e3c7ac9cc60c623bc4
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Mon Sep 17 09:38:03 2012 +0000
> 
>     drm: Destroy the planes prior to destroying the associated CRTC
>     
>     As during the plane cleanup, we wish to disable the hardware and
>     so may modify state on the associated CRTC, that CRTC must continue to
>     exist until we are finished.
>     
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54101
>     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>     Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
>     Cc: stable@vger.kernel.org
>     Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
>     Tested-by: lu hua <huax.lu@intel.com>
>     Signed-off-by: Dave Airlie <airlied@redhat.com>

Did you cherry pick to -queued/fixed branch?

The patch has been merged through the drm-next tree and is included in 3.7-rc1. Until I roll the intel trees forward, you can test Linus' upstream tree to confirm the fix.

Fixed on upstream tree. Tested on commit 6f0c0580b70
commit 6f0c0580b70c89094b3422ba81118c7b959c7556
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Oct 20 12:11:32 2012 -0700
  
  Linux 3.7-rc2

Verified.Fixed on -nightly branch commit b5a833707960154164cf450647c76547be43a167.

Closing old verified+fixed.