I tried RC3 or X server and intel driver. When X enters DPMS mode (either from xscreensaver or by hand with xset s activate), the machine hangs shortly.
Created attachment 9371 [details] my xorg.conf
Created attachment 9372 [details] Typical Xorg log just before complete box hang
(In reply to comment #0) > When X enters DPMS mode (either from xscreensaver or by hand with xset s > activate), the machine hangs shortly. Hangs as in not pingable? Are you sure xset s activate goes to DPMS directly? Is anything 3D running in your session? Which version of libgl1-mesa-dri is installed?
not pingable indeed. xset q reports Standby: 1800 Suspend: 1800 Off: 1800, so I guess it directly enters "off" mode yes. I'll try to set different values for determining if one particular level breaks. I indeed usually have a 3D application running (simply because there is a xscreensaver). It looks like it's only some GL savers that poses problem, because the hang is not systematic (even after seeing several GL savers running). I have libgl1-mesa-{dri,glx} 6.5.2-3
I found a reproducable way to trigger it: I start xinit /usr/bin/fvwm, then run xscreensaver-demo, let it start the daemon, ask for Preview of the "providence" saver, and then via ssh run xset s activate. Note: xscrensaver's standby/suspend/off times are all the same.
Note: the hang is not immediate, it usually takes a few dozens of seconds (during which the GL saver is still active I guess?).
Actually, standby/suspend/off times don't need to be the same. Even when set to 10/20/30 minutes I get the crash.
Does this also happen with an older kernel, say 2.6.18?
I tried the debian 2.6.18-4-686 kernel with same result. I also tried the git version, same result but I get some debugging message when starting the Providence saver: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset. In case it might be helpful, I'll attach dmesg + /proc/interrupts
Created attachment 9439 [details] my dmesg
Created attachment 9440 [details] my /proc/interrupts
Actually, the debugging message only shows up with a 2.6.18 kernel, not with the 2.6.20 kernel
(In reply to comment #9) > do_wait: drmWaitVBlank returned -1, IRQs don't seem to be > working correctly. Try running with LIBGL_THROTTLE_REFRESH and > LIBL_SYNC_REFRESH unset. Hmm. Does this and/or the hang also happen if you set the driconf setting vblank_mode ('Synchronization with vertical refresh (swap intervals)') to 0 ('Never synchronize with vertical refresh, ignore application's choice')?
When doing this the warning goes away and I can't reproduce the hang indeed.
Oops, sorry, I spoke too fast. I still have the warning and the hang.
Would the patch attached to bug 10546 happen to help?
Unfortunately it doesn't. I'm still getting the warning and the hang.
On my end, I'm encountering DPMS problems too, but this doesn't involve any 3D applications nor DRI. DRI is disabled (I have a too-large Virtual screen size). Unfortunately, I haven't been able to save any Xorg logs yet.
xserver RC5 fixed the issue for me, whatever the version of xf86-video-intel (RC3 or current git). Would you like me to to bisect the git for discovering which commit fixed it?
This bug seems to still hit me.
JM: how do you reproduce the bug?
Mmm, I also got a hang yesterday. That was during a long noon break during which I left xscreensaver running. I'm now trying without it, just to check whether it's related.
Samuel: I'm seeing the problem occur sporadically. Hard to reproduce. However: - It seems that when I have an external monitor connected, it occurs more readily. - If when I run xrandr I'm told that there's an output connected to the VGA (even if there isn't), I'm also more susceptible to it. I'll see if I can try isolating it. Also: running 'xset dpms force off' doesn't hit me with the bug; however, lid closure does. (it could be a fluke though -- I'll investigate further).
I believe that I may be experiencing the same bug on my system (Dell Inspiron 510m laptop, 855GM graphics running Ubuntu Feisty and the 2.0.0 intel driver from git). My system tends to hang both when I switch from X to a VT or run an application that changes the screen resolution, e.g. ppracer (DRI functions perfectly, that's not the issue). When the hang occurs, the screen blanks and the system becomes unresponsive and only a hard reset works. Is this is the same issue (with DPMS), or will I open another bug?
I get the same lockup with my 855GM on a HP nx5000 running debian unstable Kernel is 2.6.20.3 I _think_ the problem appeared when doing this upgrade 2007-04-20 12:57:41: - C xserver-xorg-video-i810 2:1.7.2-4 2007-04-20 12:58:04: U libxrandr2 2:1.1.0.2-5 2:1.2.1-1 2007-04-20 12:58:11: U libdrm2 2.3.0-2 2.3.0-4 2007-04-20 12:58:11: U libgl1-mesa-dri 6.5.1-0.6 6.5.2-4 2007-04-20 12:58:15: U libgl1-mesa-glx 6.5.1-0.6 6.5.2-4 2007-04-20 12:58:41: U libglu1-mesa 6.5.1-0.6 6.5.2-4 2007-04-20 12:58:43: U mesa-utils 6.3.2-2.1 6.5.2-4 2007-04-20 12:58:44: U xserver-xorg-core 2:1.1.1-21 2:1.3.0.0.dfsg-1 2007-04-20 12:58:45: + I xserver-xorg-video-intel 2:2.0.0-1 I will try the 2.6.21-rc7 and report if it make any difference and also try to downgrade some of the above packages. Thank you for the work so far.
Using 2.6.21-rc7 makes no difference Pushing the laptop lid freezes the computer after 2 seconds (less than this, it comes back) The regression appears when going from xserver-xorg-video-i810 1.9.94-1 -> 2.0.0-1 Adding acpi=off to the kernel inhibits the problem Section "Module" Load "bitmap" Load "dbe" Load "ddc" Load "extmod" Load "freetype" Disable "glx" Disable "dri" Load "int10" Load "vbe" EndSection
(In reply to comment #26) > The regression appears when going from xserver-xorg-video-i810 1.9.94-1 -> > 2.0.0-1 This bug was originally reported against 1.9.93 though... Still, it would be great if you could isolate the guilty change with git-bisect.
(In reply to comment #27) > This bug was originally reported against 1.9.93 though... Still, it would be > great if you could isolate the guilty change with git-bisect. > I tried running version 1.9.94 on my system (also with ACPI disabled), but I can still reproduce the hang with that version of the driver. This bug is quite frustrating to isolate, because it's hard to anticipate when a lockup will occur and because it's a hard freeze no logs are recoverable. Observations on my system (Dell Inspiron 510m, 855GM, Ubuntu Feisty): Driver 1.7.4: Everything works perfectly - DRI, DPMS, XV output, switching to VT, closing lid, etc. I don't recall ever experiencing a system lockup with this driver (except perhaps from playing around with DRI on rare occasions, but it's not related to this). Driver 1.9.94: Switching between VTs, deliberately killing/respawning X seems stable for a while, but after some time a hang will occur. DPMS function by pressing the close lid button briefly, but system hangs if pressed for several seconds or pressed repeatedly. XV playback will crash or lockup X (but fixable with temporary patches in bug #10645). Changing screen resolution will sometimes cause the server to restart. Running ppracer (fullscreen 800x600) will sometimes work initially, but then you can guarantee a hard freeze if you try to relaunch ppracer, switch to a VT or kill X afterwards. Driver 2.0.0: This driver is quite erratic on my system. Sometimes when launched, GDM tries to set a virtual mode rather than the intended 1024x768, and crashes with an .xsession-errors message (will post logs). If this behaviour doesn't occur, once logged into GNOME I experience virtually the same behaviour as the 1.9.94 driver. I can't ssh into the laptop when the freezes occur, and the logs aren't written to disk in time, so I'm unsure how I can provide good logs for troubleshooting. In the meantime I'm attaching logs from my system when the 2.0.0 driver is active and exhibiting the strange GDM bug, maybe it'll give some clues.
Created attachment 9727 [details] xorg.conf (driver 2.0.0)
Created attachment 9728 [details] Xorg.0.log (driver 2.0.0, after GDM bug, but no hang)
Created attachment 9729 [details] dmesg (driver 2.0.0)
Created attachment 9730 [details] .xsession-errors relating to strange GDM behaviour (driver 2.0.0)
(In reply to comment #28) > Driver 2.0.0: This driver is quite erratic on my system. Sometimes when > launched, GDM tries to set a virtual mode rather than the intended 1024x768, > and crashes with an .xsession-errors message (will post logs). Please don't mix up several issues in a single report but file a new one if this hasn't been reported yet (it sounds like this could be related to intermittent detection of a non-existant external display reported elsewhere). > I can't ssh into the laptop when the freezes occur, and the logs aren't written > to disk in time, so I'm unsure how I can provide good logs for troubleshooting. Remounting the filesystem containing the logs with the sync option might help.
(In reply to comment #27) > (In reply to comment #26) > > The regression appears when going from xserver-xorg-video-i810 1.9.94-1 -> > > 2.0.0-1 > > This bug was originally reported against 1.9.93 though... Still, it would be > great if you could isolate the guilty change with git-bisect. > Short comment (because I lack time..): While bisecting from freedesktop git (thanks for the http-export btw), I discovered that 1.9.94 is indeed bad for me. No time to check why the same debian version didn't show the problem. I tried to bisect between 1.9.93 and 1.9.94 but the compilation failed due to changes in libxrandr. I hope to get today again on the problem as soon as I have more time.
I have the same problem here. X.org from Debian Unstable. Going back to xserver-xorg-video-i810 from Etch solves the problem. I do not use 3D (but DRI is enabled). I may give more details on thursday.
Some news... Since a few days I'm fighting with this lockup and my last discovery: Building xf86-video-intel 1.9.91 against xserver 1.2.99.902 already shows the problem (no dri, no mesa, not loading module dri and glx). Can somebody confirm? Building xf86-video-intel 1.7.4 against the same internal xserver does not show this lockup. At the moment when I build an intermediate version (300 commits between the 1.7.4 and 1.9.91..) I get a signal 11 after entering the preinit of i810_drv.so, and this for several versions of xf86-video-intel.. ?? I will try some "manual bisect",meanwhile, if somebody has at least two commit-ids for xserver and xf86-video-input that I should try, that would help me.
Created attachment 10373 [details] Crash log (actually probably not related to this bug) I don't seem to have hangs any more, but I have experienced a server crash when leaving xscreensaver with DPMS enabled (I don't seem to have any problem with DPMS but no xscreensaver or xscreensaver without DPMS). Here is the log file.
I'm seeing something like this with 2.1.0 on my thinkpad r31 (i830). DRI is disabled. This is the first -intel driver I could use b/c of #10389 in 2.0.0. The locks have happened twice since upgrading to 2.1.0 last night. Both times I left my laptop for sometime and returned to find it locked up (as above, not replying to pings even sysrq is unresponsive). I have reduced my gnome-screensaver times to 1 min til blanking and 2 mins to dpms off (in gnome-power-manager) but have not yet seen it. I haven't not yet tracked down how exactly to reproduce it but will post once/if I have something more definite.
Hi, I took the time to pull the latest git and until now, I haven't experienced any freeze when putting down the lid button of my laptop (855GM) As a recall, the xorg.conf is a default one with only these modules: Section "Module" Disable "dri" Disable "glx" EndSection I guess it's maybe the BIOS timing problem that Keith corrected but haven't verified (yet). That's really cool! I'm very happy to be using this driver!
lkislaire the lid locking issue you mention is a different problem of the reported here. The problem that Conn has (and myself) is also different and reported as https://bugs.freedesktop.org/show_bug.cgi?id=11432. This seems to be related with the Dell laptops BIOS. The lid issue lkislaire is reporting to be fixed maybe the one solved with commit http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commit;h=d957c6b8e1dde8e11c1db3431e0ff58c5d984880 I'm not a perfect bug reporter, but as I've been told is better to create a new bug report and merge afterwards than mess several issues on the same bug report. Let's help developers! ;)
there are too many reports in this bug. As the original bug reporter said this bug has been fixed (no hang). I will mark this bug as fixed and please open new bug if you experience other error.
Just in case anyone is looking at, my issue in comment #38 seems to be related to the Pipe A quirk and is reported in bug #14960
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.