Created attachment 63150 [details] dmesg file after running module_reload System Environment: -------------------------- Platform: Ivbridge(chief river) Kernel: (drm-intel-next-queued)33ee6d190ce8e4c33a7caf7d75618feb97936517 Bug detailed description: ------------------------- Running the i-g-t tool module_reload costs more time than normal, and after running module_reload, hangcheck dump GPU hung. This is a regression issue, this case passed on kernel: Kernel: (drm-intel-next-queued)1523c310b3ed964b71a8db16f70c3bc21cc0642e Some additional commit info: Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri May 25 12:34:54 2012 -0700 drm/i915: add min freq control to debugfs
In my testing on snb, this has been introduced somewhere in Ben's context patches.
*** Bug 51214 has been marked as a duplicate of this bug. ***
Should be fixed in -queued with commit 55a6662837a5efe48c836bfc3570ace348f3db09 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jun 19 21:55:32 2012 +0200 drm/i915: fix module unload after context merge
(In reply to comment #3) > Should be fixed in -queued with > > commit 55a6662837a5efe48c836bfc3570ace348f3db09 > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > Date: Tue Jun 19 21:55:32 2012 +0200 > > drm/i915: fix module unload after context merge Did you push it? I didn't find it on -queued branch....
Now also pushed, you people are simply too fast ;-)
Created attachment 63277 [details] dmesg file after running module_reload I re-test module_reload. The issues still there. The dmesg is attatched.
Hm, I've just checked again and it works like a charm on my ivb. Can you describe more clearly what's going wrong? Looking at dmesg I don't see any indication that module unload started. Also note that yesterday I've pushed out a totally broken -queued version for a while that drops all register writes on ivb/snb. Locking at dmesg this could be the problem. So can you please retest on the latest -queued branch? Also, if you have other testcases/machines that hang, please check the -queued version you have. The broken commit is commit 3008bb11d1ea4cd2c70f08e92dfe1caf6adf55b8 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Jun 15 11:55:17 2012 -0700 drm/i915: access VLV regs through read/write switch it should be replaced by the good version commit f7dff0c9cbb89e9c406c0ca47f32129b61721174 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Jun 15 11:55:17 2012 -0700 drm/i915: access VLV regs through read/write switch Sorry for any problems this has caused for you.
Looking again at the dmesg, I'm pretty sure this is due to the broken Valleyview commit from Jesse. I'll close this again as fixed, please confirm.
Created attachment 63424 [details] running modulereload's demsg info (In reply to comment #8) > Looking again at the dmesg, I'm pretty sure this is due to the broken > Valleyview commit from Jesse. I'll close this again as fixed, please confirm. I try with the kernel Kernel: (drm-intel-next-queued)ff049b6ce21d2814451afd4a116d001712e0116b which including the patch: commit f7dff0c9cbb89e9c406c0ca47f32129b61721174 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Jun 15 11:55:17 2012 -0700 drm/i915: access VLV regs through read/write switch but I still can find hangcheck dump GPU hung in dmesg
Hm, this is really strange, and I'm running out of ideas. Can you please try to bisect this issue?
(In reply to comment #10) > Hm, this is really strange, and I'm running out of ideas. Can you please try to > bisect this issue? Daniel, I try with the latest -next , and can't reproduce this issue.
Well, I guess we'll then just close this. Please reopen (or file a new bug) if this shows up again.
(In reply to comment #12) > Well, I guess we'll then just close this. Please reopen (or file a new bug) if > this shows up again. Ok, we don't reproduce this on IVB platform. Closing it.
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.