Ever since KMS was enabled in Fedora rawhide I've been experiencing random lockups on my HP Compaq nc6400 laptop with this graphics controller: 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) I've filed a bug against fedora with more details here: https://bugzilla.redhat.com/show_bug.cgi?id=492686 There's dmesg output and xorg logs etc there.
Changing this to critical
Last kernel I reproduced this on was Linux localhost.localdomain 2.6.31-0.204.rc9.fc12.i686.PAE #1 SMP Sat Sep 5 20:45:47 EDT 2009 i686 i686 i386 GNU/Linux
Sorry for all the spam. This is the driver version: xorg-x11-drv-intel-2.8.0-13.20090909.fc12.i686
We can't reproduce this with upstream code.
Well, something is triggering this for me at least. It could be hardware or some app doing the wrong thing, but the fact is still that this started as soon as KMS was enabled in fedora. I spoke briefly to warren togami on irc yesterday and he indicated that he'd seen freezes with 945GM too, but thought they had been fixed very recently. In fact I thought so too, but after a suspend / resume cycle coming home from work yesterday it hung on me while working in gnome-terminal. I have firefox, evolution, xchat-gnome running most of the time and do compilation/editing etc. Some in vi in gnome-terminal and some in emacs. Is there anything I can do to get more debugging from the driver itself or maybe Xorg somewhere? Thanks a lot for following up on this.
Got another lockup just now. Newer packages than last time: 2.6.31-33.fc12.i686.PAE xorg-x11-drv-intel-2.8.0-15.20090909.fc12.i686 xorg-x11-server-Xorg-1.6.99.902-1.fc12.i686
So this is relate with suspend/resume? I think we've got some reports on that, could you still get dmesg kernel log in failure case? I'll try to see if this's also on my side.
I had another one now without suspend / resume in between so it's definitely not related to that (at least not only that). Attaching syslog output for all of Sep 23 so far and here I had a hang at 09.59 which was just after resuming after going to work. Later I had a hang around 13.25 after trying to connect to a projector at work to display a presentation. I see some messages there that look like it didn't like the projector at least :-)
Created attachment 29795 [details] syslog output
I still see these hangs several times a day. Is there nothing I can do to get more data here?
Still seeing this with the 2.9.0 release of the driver and a very recent kernel. One "datapoint" is that I see these hangs most often when running on battery. I had the machine running for several days without problems this weekend but shortly after unplugging the power I had a hang... Not very quantifiable but still worth mentioning I think.
So, going with the assumption that this is related to deeper C-states when running on battery I'm going to attach output from intel_gpu_dump in both cases just in case that is helpful to anyone.
Created attachment 30096 [details] output from intel_gpu_dump on battery
Created attachment 30097 [details] dump when plugged in
Interesting, we have new CxSR feature in KMS that will try to downclock PLL in C state, that might be possible trigger this? Have you tried with 'i915.powersave=0' option for drm/i915 module?
Tried this and got a new lockup about two minutes after logging in... Anything else we can try?
(In reply to comment #0) > https://bugzilla.redhat.com/show_bug.cgi?id=492686 > > There's dmesg output and xorg logs etc there. That's wrong bug number ... https://bugzilla.redhat.com/show_bug.cgi?id=492686 is "Evolution hangs in uninterruptible sleep state and grinds the machine to a halt", which is now kernel bug.
Didn't you just paste a link to the very same bug I linked to in comment #0? :-)
Does this still happen with upstreams?
(In reply to comment #12) > So, going with the assumption that this is related to deeper C-states when > running on battery I'm going to attach output from intel_gpu_dump in both cases > just in case that is helpful to anyone. Yes! Apparently there was a debugging bit that needed to be set in order to stop the machine killing itself when using the blitter with deep C-states. GAH! commit 944001201ca0196bcdb088129e5866a9f379d08c Author: Dave Airlie <airlied@redhat.com> Date: Tue Jul 20 13:15:31 2010 +1000 drm/i915: enable low power render writes on GEN3 hardware.
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.