I have been trying releases of the xf96-intel driver since 2.4.x when I got my laptop fresh off the first assembly runs of Montevina chipsets in September. Since 2.5.x and all versions since then up to and including git master built this past weekend, using the UXA method works fine as long as I do not leave the laptop idle. If I leave the laptop for a long period--greater than 30 minutes usually--idle, it will be completely hard-locked when I return. No keyboard status lights. No ping response. No wired or wireless activity lights. Completely frozen. However it's not consistent. It might freeze while I'm on my hour lunch break. If I leave it overnight, however, there's a 100% chance it will be locked up when I get up in the morning. It has never hard-locked this way while I am using it and I use the laptop >10 hours daily. The display may or may not be in a DPMS state depending on whether enough time expires before the freeze occurs. It doesn't matter if close the lid. It doesn't matter if I am using an external display. It doesn't matter if I'm on a dock or not. I even had the motherboard replaced with an entirely new revision in this laptop after I discovered and reported an issue to Lenovo regarding the specifications of the resistors along the DVI link paths. So, it's not the hardware. EXA is 100% stable. I have never seen a freeze of any kind, idle or not, while using the EXA method. I began using this laptop with 2.6.26 and have worked my way up to 2.6.29; no kernel is more or less likely to freeze. I have tried X.org versions starting at 7.2 all the way through git master (built everything by hand). Nothing helps except disabling UXA. I even tried disabling some of the Montevina power saving features like PCIe link sleeping: no affect. I'm completely at a loss for what the cause is other than a bad interaction between some kind of idle behavior and the UXA method. (Obviously no backtrace is possible with this kind of issue.)
Both my hand-built 2.6.29 and drm-next kernels and--at the time--the newly uploaded official Debian 2.6.29 kernel exhibited the same behavior. Two weeks ago, after filing this bug, I decided to install Fedora Rawhide whose kernel was roughly at the same patch level as the drm-next I built by hand and whose Xorg stack was fairly close to the built-from-git copy I built myself. It hasn't locked up a single time after this switch. At this point, I suspect some bad interaction between Debian userspace power management and something else. I really cannot say with certainty. It would be interesting if anyone reports this same behaviour on slightly older userspace environments. Perhaps some laptop mode script can be blamed.
Adjusting severity: crashes & hangs should be marked critical.
Narrowed it down to bluetooth input. Closing NOTOURBUG. :\
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.