| Summary: | [snb uxa] Frequent hard lockups when using icedove (thunderbird) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Michael Biebl <mbiebl> | ||||||||
| Component: | DRM/Intel | Assignee: | Daniel Vetter <daniel> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | medium | CC: | ben, chris, daniel, jbarnes | ||||||||
| Version: | unspecified | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
Can you also attach your dmesg, and probably /sys/kernel/debug/dri/0/i915_error_state? (In reply to comment #1) > Can you also attach your dmesg, and probably > /sys/kernel/debug/dri/0/i915_error_state? Atm it just prints "no error state collected". I assume you want me to run that when the lockup happens? As the machine is basically dead when that happens, i.e. I can't even switch to the console anymore, which makes this a bit more complicated. Ok, we shall just have to try the shotgun approach. Can you please install a 3.4 kernel? There were a number of SNB workarounds. The other approach would be to enable SNA. Created attachment 62217 [details]
dmesg
Created attachment 62219 [details]
i915_error_state
I was able to gather the requested information via SSH after the system had locked up again. A very interesting thing happened: While gathering the information, the screensaver on the system had kicked in (after 10 min) and I was able to type again. The desktop session was back to normal. I'm not sure if it was the screensaver which "unfroze" the hung system or if it was caused by something else. Can you please 'cat /sys/kernel/debug/dri/0/i915_fbc_status'? (In reply to comment #7) > Can you please 'cat /sys/kernel/debug/dri/0/i915_fbc_status'? # cat /sys/kernel/debug/dri/0/i915_fbc_status FBC enabled Until debian update their kernel, you will need to append i915.i915_enable_fbc=0 to your command-line. (In reply to comment #9) > Until debian update their kernel, you will need to append > i915.i915_enable_fbc=0 to your command-line. With 2:2.18.0-2 I also had FBC enabled, but I didn't have the lockups. What changed between 2.18 and 2.19 in that regard that this makes a difference now? I'll try to run 2.19 with FBC disabled to verify if the hangs are gone. Thanks for your quick help so far! The FBC/BLT hang is principally a timing bug, it just requires the right sequence of commands to trigger. Likely that some of the bug fixes in 2.19.0 just altered your common workload sufficiently to trigger it. Though others have reported the FBC hang with earlier ddx. (In reply to comment #11) > The FBC/BLT hang is principally a timing bug, it just requires the right > sequence of commands to trigger. Likely that some of the bug fixes in 2.19.0 > just altered your common workload sufficiently to trigger it. Though others > have reported the FBC hang with earlier ddx. Just wanted to add, that disabling FBC did indeed avoid the GPU hangs for me. |
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 62204 [details] Xorg log Distro: Debian/sid xserver-xorg-core: 2:1.12.1.902-1 xserver-xorg: 1:7.6+13 xserver-xorg-video-intel: 2:2.19.0-1 linux-image-3.2.0-2-amd64: 3.2.18-1 Since upgrading xserver-xorg-video-intel from 2:2.18.0-2 to 2:2.19.0-1 I get frequent lookups of X. So far this always happened when opening a large email folder in icedove(thunderbird). At this point the desktop is completely frozen and the system no longer reacts on keyboard input. I can still move the mouse, but X no longer reacts on clicks. This both happened in a composited DE (gnome-shell) and a non-composited DE (gnome-fallback/metacity). Downgrading to 2:2.18.0-2 reliably fixes the problem for me. My system is a X220 sandy bridge laptop, i.e a HD 3000 integrated graphics card. When the lockup happens I get a Xorg backtrace in Xorg.0.log (attached)