| Summary: | [GM965 regression] Kernel WARNING + stack trace and display lock-up on lid open | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Ari Entlich <lmage11> | ||||||||||||||||||
| Component: | DRM/Intel | Assignee: | Daniel Vetter <daniel> | ||||||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||||||
| Severity: | normal | ||||||||||||||||||||
| Priority: | medium | CC: | ben, chris, daniel, florian, jbarnes, lmage11 | ||||||||||||||||||
| Version: | XOrg git | ||||||||||||||||||||
| Hardware: | Other | ||||||||||||||||||||
| OS: | All | ||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
Created attachment 66856 [details]
intel_error_decode output
Created attachment 66857 [details]
intel_reg_dumper output
Try this patch: https://patchwork.kernel.org/patch/1426961/ Ari, can you add your reproduction method to the older bug? *** This bug has been marked as a duplicate of bug 53379 *** (In reply to comment #3) > Try this patch: https://patchwork.kernel.org/patch/1426961/ This patch is for gen3 and earlier only, your machine is gen4 so this doesn't apply. The other thing is that the gpu hang and the WARN are two different bugs, e.g. in the attached dmesg there's no sign of a gpu hang afaict. We should concentrate this bug report here on the WARN, if the gpu hang is still reproducible with the latest userspace components, please file a new bug for that (and attaching the undecoded error_state is usually better, in case we take the opportunity to improve the error state decoder). Chris marked the gpu hang in this bug as duplicate, but since I've decided to track the WARN in this one here we can reopen ;-) The WARN looks pretty sweet, but can be avoided with https://bugs.freedesktop.org/attachment.cgi?id=62701 Created attachment 66883 [details]
Un-decoded i915_error_state
Daniel, do you want the patch to avoid the WARN or respin an equivalent for modeset-rework? Created attachment 68879 [details]
Kernel log for Oct 14 kernel
Hey guys, here's some more logs. This is with a kernel built from drm-intel-nightly on October 14th. For the kernel log, I filtered out the "drm:drm_ioctl" lines, because they were making the file very big and they don't seem to have a whole lot of information in them.
Created attachment 68880 [details]
intel_reg_dumper output for Oct 14 kernel
Created attachment 68881 [details]
i915_error_state for Oct 14 kernel
Oh, and this kernel did not have any other patches applied. It looked to me like the patch in comment #7 was no longer relevant, because of this: http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightly&id=3b7a89fce3e3dc96b549d6d829387b4439044d0d patch. Created attachment 68883 [details] [review] force restore on lid open The attached patch (only compile tested) should shut up the warnings and restore the display on lid open. Ari, do you mind confirming that Daniel's patch does exactly what it says on the tin? commit a3443c5e7be8831ae634ed0738232452a11f3739 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 23 18:16:34 2012 +0100 drm/i915: force restore on lid open There seem to be indeed some awkwards machines around, mostly those without OpRegion support, where the firmware changes the display hw state behind our backs when closing the lid. A patch referencing this bug report has been merged in Linux v3.8-rc1: commit 45e2b5f640b3766da3eda48f6c35f088155c06f3 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 23 18:16:34 2012 +0100 drm/i915: force restore on lid open |
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.
Created attachment 66855 [details] Kernel log Sometimes when I open my laptop lid, the screen goes black and refuses to show anything else. The laptop is not completely frozen, since I can ssh in and I also appear to be able to switch VTs. Once, I was only able to get the driver to fill in the i915_error_state file after I switched away from and back to my X VT (though that time I did it with chvt). I have experienced this with 3.4.4 and 3.5.3, but not with 2.6.31 (so it is probably, hopefully not a hardware issue). It also happens with both libdrm 2.4.33 and 2.4.39. Attached are: 1. A log of kernel messages that shows an assertion failure in the drm code, and also includes a lot of debug logging (I used drm.debug=0xf even though I was told to use 0xe.... I hope that's alright). 2. The output of the intel_error_decode utility from intel-gpu-tools. 3. The output of the intel_reg_dumper utility from intel-gpu-tools. Note that the intel-gpu-tools output and the kernel log are actually from different instances of the problem, because I didn't have the drm.debug option set when I was running those tools. I can get it all from one instance if that is necessary. I also have some more information if you need it, and can do whatever else is necessary to figure this out. Thanks!