| Summary: | [GT2 2D] Video rendering freezes in certain apps after C3 suspend-resume | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | dave | ||||||||||||
| Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | medium | ||||||||||||||
| Version: | unspecified | ||||||||||||||
| Hardware: | Other | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||
| Attachments: |
|
||||||||||||||
Created attachment 48756 [details]
Xorg log
Created attachment 48757 [details]
xrandr --verbose output
Created attachment 48758 [details]
VBIOS dump
Created attachment 48759 [details]
intel_reg_dumper output
From the description and lack of the usual hangchecks in dmesg, I suspect this is a FBC issue. Can you please try a 3.0 kernel which has FBC disabled by default? Or set i915.enable_fbc=0 (though I think that only came in during 2.6.39+). Updated to 3.0-rc6 from the kernel PPA. With the combination of 3.0-rc6 and bleeding edge Xorg drivers, I'm unable to reproduce the bug. While I have my X220 in a configuration amenable to sacrifice, is there any further data I can collect (in any configuration of kernel+X drivers) to help development? About the only thing useful to check is whether the bug comes back with i915.enable_fbc=1 (append to your kernel boot parameters in grub). With my kernel version, the argument to grub is i915.i915_enable_fbc=1 (otherwise the driver fails to modprobe). Booting with FBC enabled brings back the bug. |
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 48755 [details] dmesg output Note that I am not using Compiz or other accelerated/fancy window managers, just an old-fashioned xmonad. The issue is not a hard lockup of the entire machine, rather frequent multi-second lockups of video output in certain kind of 2d apps. I've noted this so far while trying to play videos with Adobe Flash Player in a browser, and the game Battle for Wesnoth. Upon starting these programs, video rendering is normal and smooth for 1-2s, then video rendering freezes. The rest of the system works normally (audio, cpu work, disk I/O...), and video outside the windows of these apps continues to render normally. 3-10s, the frozen app resumes rendering, with the expected content, for another 1-2s, and the cycle repeats. While investigating, I upgraded to the xorg-edgers Ubuntu PPA (those are the versions I'm reporting below). With those X drivers, the lockup bug does not seem to occur after a cold boot or reboot, but appears after the first C3 (ram) suspend-resume cycle, and persists until the next full reboot. With the stable Ubuntu drivers, this behavior starts even before the first suspend cycle. Environment: - Chipset: Intel(R) Sandybridge Mobile (GT2) - Architecture: i686 - libdrm version: 2.4.26 - mesa version: 2.1 Mesa 7.10.2 - intel driver version: 2.15.0 - xorg version: X.Org X Server 1.10.2.901 (1.10.3 RC 1) - kernel version: 2.6.38-8-generic - Distribution: Ubuntu 11.04 - Machine: Lenovo Thinkpad X220 i5 - Display: LVDS Reproduction: - On the above hardware, install Ubuntu 11.04. Install the xorg-edgers PPA to get bleeding edge video drivers. - Reboot. - Run Battle for Wesnoth. Muck around in the UI for ~1min, notice rendering does not freeze. - C3 suspend and resume. - Run Battle for Wesnoth. Muck around in the UI, notice rendering is now choppy and freezy. Notice the surrounding stuff doesn't seem affected. - Reboot the machine. - Run Battle for Wesnoth. Notice rendering works again. All logs attached per the guide