Total lockup when I'm trying to play a movie with xine. It usually happens when I get the laptop from the standby mode. (II) I810(0): [drm] removed 1 reserved context for kernel (II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xf8d6f000 at 0xb7eed000 Fatal server error: lockup Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. Error in I830WaitLpRing(), now is 94500478, start is 94498477 pgetbl_ctl: 0x3fee0001 pgetbl_err: 0x19 ipeir: 0 iphdr: 1810000 LP ring tail: cbc0 head: ca84 len: 1f001 start 0 eir: 0 esr: 10 emr: ffff instdone: ffc0 instpm: 0 memmode: 108 instps: 0 hwstam: ffff ier: 0 imr: ffff iir: 2a0 space: 130748 wanted 131064 FatalError re-entered, aborting lockup
Created attachment 3169 [details] Full Xorg.log file Here is my log file.
Can you explain a little bit more about the events leading up to the crash ? Did you suspend/resume or VT switch ? I've also uploaded 1.5.154 if you can try that.
(In reply to comment #2) > Can you explain a little bit more about the events leading up to the crash ? > > Did you suspend/resume or VT switch ? > > I've also uploaded 1.5.154 if you can try that. I've tried your latest driver and it worked fine for a couple of days. But today I got complete lockup again. It happens only when I at least one suspend or hibernate my laptop. When I do hard reboot of the laptop, it works fine. These are relevent lines from the log file: Error in I830WaitLpRing(), now is 10026, start is 8025 pgetbl_ctl: 0x3fee0001 pgetbl_err: 0xffb9f019 ipeir: 0 iphdr: 1810000 LP ring tail: b0 head: 0 len: 1f001 start 0 eir: 0 esr: 10 emr: ffff instdone: ffc0 instpm: 0 memmode: 108 instps: 0 hwstam: ffff ier: 2 imr: 9 iir: 2a0 space: 130888 wanted 131064 (II) I810(0): [drm] removed 1 reserved context for kernel (II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xf8ca3000 at 0xb7ee4000 Fatal server error: lockup Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. Error in I830WaitLpRing(), now is 12030, start is 10029 pgetbl_ctl: 0x3fee0001 pgetbl_err: 0xffb9f019 ipeir: 0 iphdr: 1810000 LP ring tail: b8 head: 0 len: 1f001 start 0 eir: 0 esr: 10 emr: ffff instdone: ffc0 instpm: 0 memmode: 108 instps: 0 hwstam: ffff ier: 0 imr: ffff iir: 2a0 space: 130880 wanted 131064 FatalError re-entered, aborting lockup
I'm seeing pretty much exactly the same thing, both with 1.4.0 and 1.5.154. The crashes only occur when launching xine or totem-xine, and only after at least one suspend-resume cycle. I haven't been able to discern any other pattern: sometimes it goes weeks without crashing, sometimes it crashes all the time... Here's the crash part of the log for 1.4.0 (from Ubuntu Breezy): Error in I830WaitLpRing(), now is 12328, start is 10327 pgetbl_ctl: 0x1fee0001 pgetbl_err: 0x0 ipeir: 0 iphdr: 1810000 LP ring tail: b0 head: 0 len: 1f001 start 0 eir: 0 esr: 0 emr: ffff instdone: ffc0 instpm: 0 memmode: 108 instps: 0 hwstam: ffff ier: 2 imr: 9 iir: 2a0 space: 130888 wanted 131064 (II) I810(0): [drm] removed 1 reserved context for kernel (II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xe03ff000 at 0xb7cdf000 Fatal server error: lockup And here's what 1.5.154 has to say: Error in I830WaitLpRing(), now is 2779, start is 778 pgetbl_ctl: 0x1fee0001 pgetbl_err: 0x0 ipeir: 0 iphdr: 1810000 LP ring tail: 8 head: 0 len: 1f001 start 0 eir: 0 esr: 0 emr: ffff instdone: ffc0 instpm: 0 memmode: 108 instps: 0 hwstam: ffff ier: 0 imr: ffff iir: 0 space: 131056 wanted 131064 Fatal server error: lockup Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. (WW) I810(0): Successfully set original devices Set640x480 (0xc050) Succeeded (WW) I810(0): Setting the original video mode instead of restoring the saved state (WW) I810(0): Extended BIOS function 0x5f05 failed. (II) I810(0): BIOS call 0x5f05 not supported, setting refresh with VBE 3 method. (II) I810(0): xf86UnbindGARTMemory: unbind key 4 (II) I810(0): xf86UnbindGARTMemory: unbind key 0 (II) I810(0): xf86UnbindGARTMemory: unbind key 1 (II) I810(0): xf86UnbindGARTMemory: unbind key 3 (II) I810(0): xf86UnbindGARTMemory: unbind key 2 (WW) I810(0): Successfully set original devices (2)
I've just uploaded 1.5.155 - try that. If it still fails, complete logs again will be useful
Created attachment 3327 [details] Crash log for 1.5.155 Still crashes, I'm afraid (log attached), quite quickly this time... Also, 1.5.155 breaks DRI on Ubuntu Breezy's 6.8.2.
(In reply to comment #6) > Created an attachment (id=3327) [edit] > Crash log for 1.5.155 > > Still crashes, I'm afraid (log attached), quite quickly this time... > > Also, 1.5.155 breaks DRI on Ubuntu Breezy's 6.8.2. Can you explain what you did ? And I can't see in the log file that it's broken DRI either. From the log you are not suspending or resuming, or even playing a video so some detail would be good.
Well, I *did* resume/suspend, then launched totem-xine - followed by instant crash. This is what glxinfo has to say on the DRI matter: name of display: :0.0 ERROR! sizeof(I830DRIRec) does not match passed size from device driver libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering display: :0 screen: 0 direct rendering: No
I've uploaded 1.5.156, but the DRI problems seems to be related to you using a DRI snapshot or Ubuntu is using a more recent version of Mesa.
Oh, and how are you suspending/resuming ??
(In reply to comment #10) > Oh, and how are you suspending/resuming ?? I'm just using ubuntu's scripts, that essentially does echo -n mem > /sys/power/state They also use something called vbetool to "post" and restore something called "vbestate". I have no idea what that means... I'll try 1.5.156 asap. Thanks for looking into this!
1.5.156 seems better! I've suspended/resumed/played video quite frantically, and still no crash. No DRI in this one either though, with the stock Ubuntu Breezy kernel/xorg combo. I'll continue to use 1.5.156 for a while - as I said earlier, sometimes it's been weeks between crashes.
(In reply to comment #9) > I've uploaded 1.5.156, but the DRI problems seems to be related to you using a > DRI snapshot or Ubuntu is using a more recent version of Mesa. 1.5.156 is much better. No lockups so far. Thank you.
I'm also still completely crash-free with 1.5.156 - I'd say this bug is fixed. Is there a diff between 1.5.155 and 1.5.156 somewhere? It would be great to get the fix into Breezy. And to have DRI *and* xv at the same time...
I think I've found a workaround: If the suspend/resume mechanism in Ubuntu is set to call "vbetool dpms off" on suspend, and "vbetool dpms on" on resume, I don't get any crashes (i.e. USE_DPMS is set to true in /etc/defaults/acpi-support). This workaround works with the default driver in Ubuntu Breezy (1.4.0).
Fix committed to CVS. Closing.
(In reply to comment #16) > Fix committed to CVS. Closing. Assuming you mean this one: http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c?r1=1.35&r2=1.36 I don't think this is fixed. Ubuntu Breezy's xorg now contains the fix (and as far as I can tell, the i810 driver in Breezy is pretty much identical to xorg cvs), but X still crashes the same way as before. The only difference is that I now don't get any error messages in the log file. And the workaround I thought I found doesn't seem to work all the time... Anything else I can do to help track this down?
I'm not sure what you mean by no error messages in the log file. So how does it crash if no messages are produced ?
(In reply to comment #18) > I'm not sure what you mean by no error messages in the log file. > > So how does it crash if no messages are produced ? Exactly the same pattern as before: X quits abruptly seconds after launching totem-xine, before totem manages to show a single frame of the video launched. After that I get a black screen, with a "busy cursor" that comes and goes (as if X is restarting, crashing, restarting, etc.). Nothing works at that point (i.e. ctrl-alt-backspace, switching to vt, etc.). By "no error messages in log file" I simply mean that /var/log/Xorg.0.log no longer mentions neither I830WaitLpRing, nor "error" of any kind. It might of course be that the log file gets overwritten, if it's gdm that restarts X repeatedly, though. This is what the syslog said: Oct 11 14:25:29 danlifebook gdm[24291]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Oct 11 14:25:32 danlifebook kernel: [4369740.926000] mtrr: base(0xd8020000) is not aligned on a size(0x600000) boundary Oct 11 14:25:52 danlifebook kernel: [4369760.284000] mtrr: base(0xd8020000) is not aligned on a size(0x600000) boundary Oct 11 14:26:09 danlifebook kernel: [4369777.244000] mtrr: base(0xd8020000) is not aligned on a size(0x600000) boundary Oct 11 14:26:26 danlifebook kernel: [4369794.174000] mtrr: base(0xd8020000) is not aligned on a size(0x600000) boundary Oct 11 14:26:43 danlifebook kernel: [4369811.106000] mtrr: base(0xd8020000) is not aligned on a size(0x600000) boundary Oct 11 14:27:00 danlifebook kernel: [4369828.134000] mtrr: base(0xd8020000) is not aligned on a size(0x600000) boundary Oct 11 14:27:08 danlifebook gdm[25084]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Oct 11 14:27:18 danlifebook kernel: [4369846.281000] mtrr: base(0xd8020000) is not aligned on a size(0x600000) boundary Oct 11 14:27:35 danlifebook kernel: [4369863.581000] mtrr: base(0xd8020000) is not aligned on a size(0x600000) boundary Anyway, I'm trying 1.5.157 now, to see if I just got lucky for a while with 1.5.156. Sigh...
O.k. I'll be interested if 1.5.157 continues to work for you.
Is 1.5.157 still going ?
(In reply to comment #21) > Is 1.5.157 still going ? Yes it is! I haven't had a single crash with 1.5.157 (nor with 1.5.156), despite lots of suspending/resuming/video-playing. 1.5.157 works perfectly (modulo non-DRI-ness and the, ahum, liberal logging...).
(In reply to comment #21) > Is 1.5.157 still going ? I've lost your URL to the driver. 156 works fine for me on Ubuntu Breezy. What are the changes between 156 and 157?
I just tried the driver from http://www.fairlite.demon.co.uk/intel.html (is this the correct url?) and I still got the problem described above (hangup after suspend - playing video) Xorg log: ... (II) LoadModule: "i810" (II) Loading /usr/lib/modules/drivers/i810_drv.o (II) Module i810: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.5.164 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 0.7 ... (WW) I810(0): Extended BIOS function 0x5f05 failed. Set640x480 (0xc050) Succeeded (II) I810(0): xf86BindGARTMemory: bind key 4 at 0x007bf000 (pgoffset 1983) (II) I810(0): xf86BindGARTMemory: bind key 0 at 0x0ffff000 (pgoffset 65535) (II) I810(0): xf86BindGARTMemory: bind key 1 at 0x0fffb000 (pgoffset 65531) (II) I810(0): xf86BindGARTMemory: bind key 3 at 0x0ffea000 (pgoffset 65514) (II) I810(0): xf86BindGARTMemory: bind key 2 at 0x0fffa000 (pgoffset 65530) (WW) I810(0): PRB0_HEAD (0x0001e63c) and PRB0_TAIL (0x0001e668) indicate ring buffer not fl ushed (II) I810(0): Display plane A is disabled and connected to Pipe A. (II) I810(0): Display plane B is enabled and connected to Pipe B. (II) I810(0): Enabling plane B. (II) I810(0): Display plane A is now disabled and connected to Pipe A. (II) I810(0): Display plane B is now enabled and connected to Pipe B. (II) I810(0): PIPEACONF is 0x00000000 (II) I810(0): PIPEBCONF is 0x80000000 (II) I810(0): Mode bandwidth is 47 Mpixel/s (II) I810(0): maxBandwidth is 1152 Mbyte/s, pipe bandwidths are 252 Mbyte/s, 0 Mbyte/s Error in I830WaitLpRing(), now is 2347, start is 346 pgetbl_ctl: 0x2ffc0001 pgetbl_err: 0x0 ipeir: 0 iphdr: 1810000 LP ring tail: 8 head: 0 len: 1f801 start 0 eir: 0 esr: 0 emr: ffff instdone: ffc0 instpm: 0 memmode: 108 instps: f0000 hwstam: ffff ier: 0 imr: ffff iir: 0 space: 131056 wanted 131064 Fatal server error: lockup Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. (WW) I810(0): Successfully set original devices Set640x480 (0xc050) Succeeded (II) I810(0): xf86UnbindGARTMemory: unbind key 4 (II) I810(0): xf86UnbindGARTMemory: unbind key 0 (II) I810(0): xf86UnbindGARTMemory: unbind key 1 (II) I810(0): xf86UnbindGARTMemory: unbind key 3 (II) I810(0): xf86UnbindGARTMemory: unbind key 2 (WW) I810(0): Successfully set original devices (2) HW: is a compaq nx6110 with i915 (In reply to comment #23) > (In reply to comment #21) > > Is 1.5.157 still going ? > > I've lost your URL to the driver. 156 works fine for me on Ubuntu Breezy. What > are the changes between 156 and 157? >
Can you post or attach a full log and not just excerpts - thanks!
Created attachment 3602 [details] Xorg crashlog
Mmm. This log looks very strange. I can't see anywhere where it's initializing XAA or configuring the extensions that usually appear at the end of the log. It looks as though it's been cut & pasted. Are you sure this is the right log ?
Or maybe - is this a log when you've tried to restart X after the first crash happened ?? If so, that's not good enought. I'll need a log of the original crash.
Yes - you are right - I didn't think about that (sorry). I added the log from a working sleep-resume-play video cycle and one where it crashed. (In reply to comment #28) > Or maybe - is this a log when you've tried to restart X after the first crash > happened ?? > > If so, that's not good enought. I'll need a log of the original crash.
Created attachment 3605 [details] Working suspend-resume-play cycle
Created attachment 3606 [details] Crashing suspend-resume-play cycle
O.k. You've uploaded a log which works and which doesn't. Can you explain in a bit more detail of anything different you are doing between the two setups ??
Ah I noticed you are suspending and sleeping. Presumably doing echo 3 > /proc/acpi/sleep and echo 4 > /proc/acpi/sleep ??
Oh, and does it work fine if you are not playing videos in suspend and sleep ?
Does it make any difference if you remove the VBERestore option ??
- I don't do anything different at all. After a suspend-resume cycle X sometimes crashes - sometimes not. To reproduce the crash: I just send it to sleep, woke it up, played video a couple of times. It actually took 5-6 cycles to crash. - I use the hibernate skript from gentoo to suspend. But I guess it doesn't do anything different then unloading some critical modules and do an echo "mem" > /sys/power/state - Without the VBERestore option the display does not come up again.
Oh - and yes - it works perfectly as long as I don't try to play any video. I also tried playing a video and suspend during playing. Gives the same results - sometimes crashes - sometimes not. (In reply to comment #36) > - I don't do anything different at all. After a suspend-resume cycle X > sometimes crashes - sometimes not. > To reproduce the crash: I just send it to sleep, woke it up, played video a > couple of times. It actually took 5-6 cycles to crash. > > - I use the hibernate skript from gentoo to suspend. But I guess it doesn't do > anything different then unloading some critical modules and do an echo "mem" > > /sys/power/state > > - Without the VBERestore option the display does not come up again.
I've uploaded 1.5.165. Can you try it and see if it cures the problem. If not, can you upload another log.
I tried about 10 times or so without a problem (what does not say much since the problem does appear randomly). However at the last suspend I let the video running what resulted in a crash. The logs are quite big - just say something if you only need certain bits. (In reply to comment #38) > I've uploaded 1.5.165. Can you try it and see if it cures the problem. If not, > can you upload another log.
Created attachment 3613 [details] Another crashlog with video running during suspend
I can't see any crash in that last log.
Me neither - sorry for that. I hate mondays.... Here comes the correct one (In reply to comment #41) > I can't see any crash in that last log.
Created attachment 3614 [details] Now the real other crashlog with video running during suspend
O.k. The overlay looks as though it's failing to switch on after the resume. I've uploaded 1.5.166 to try and remedy this - give it a try and let me know.
OK - this time it took about 20-40 (I didn't count) times to crash it - log is attached (In reply to comment #44) > O.k. The overlay looks as though it's failing to switch on after the resume. > > I've uploaded 1.5.166 to try and remedy this - give it a try and let me know.
Created attachment 3616 [details] Crashlog to 1.5.166
O.k. I counted 17 times. Damn. I've uploaded another one (1.5.167), but if this doesn't work, I'm gonna have to defer it for a little while.
Ok - new crash log (sorry man). I really appreciate your work on this. Defer it till you have time. Cheers Dom (In reply to comment #47) > O.k. I counted 17 times. Damn. > > I've uploaded another one (1.5.167), but if this doesn't work, I'm gonna have to > defer it for a little while.
Created attachment 3617 [details] Crashlog to 1.5.167
1.5.168 is up (last one for today).
Same story .... (In reply to comment #50) > 1.5.168 is up (last one for today).
Created attachment 3627 [details] Crashlog to 1.5.169
1.5.170 is up.
Are your sure? Log says: (II) Module i810: vendor="X.Org Foundation" compiled for 6.8.2, module version = 1.5.169 (In reply to comment #53) > 1.5.170 is up.
Positive, might be cached though.
Hm ... Anyway - new crashlog (In reply to comment #55) > Positive, might be cached though.
Created attachment 3629 [details] Crashlog to 1.5.170
1.5.171 is up
Created attachment 3632 [details] Crashlog to 1.5.171
1.5.172 is up. last one for today.
Will test it tomorrow - its late (In reply to comment #60) > 1.5.172 is up. last one for today.
Created attachment 3641 [details] Crashlog to 1.5.172
1.5.173 is up with some extra debugging information.
Useful if you could try this Dom as soon as you can. I'm interested in the additional debug output.
I will try to test it today - unfortunately the laptop was in use for the last two days. I'm on it. (In reply to comment #64) > Useful if you could try this Dom as soon as you can. I'm interested in the > additional debug output.
Created attachment 3660 [details] Crashlog to 1.5.173
Btw. it crashed without suspending (In reply to comment #66) > Created an attachment (id=3660) [edit] > Crashlog to 1.5.173 >
Thanks for this, can you try 1.5.173 again. Does it always crash straight away ? If not, If you can get another log that'd be great.
1.5.174 is up and might help the initial crash situation.
New log in a few minutes (In reply to comment #69) > 1.5.174 is up and might help the initial crash situation. It always crashes straight away (In reply to comment #68) > Thanks for this, can you try 1.5.173 again. Does it always crash straight away ? > > If not, If you can get another log that'd be great.
Created attachment 3661 [details] Crashlog to 1.5.174
Ugh. O.k. nothing really out of the ordinary there. 1.5.175 is up with more debug.
> 1.5.175 is up with more debug. lol - I´ll give it a shot tomorrow
Created attachment 3664 [details] Crashlog to 1.5.175
Ok something happened - the X server crashed, however the display is not dead any more. X ist just restarting and shows the login screen again. I will crash it one more time to verify. (In reply to comment #74) > Created an attachment (id=3664) [edit] > Crashlog to 1.5.174 >
Ok - seemed to be a single incident. Now it crashed like before. (In reply to comment #75) > Ok something happened - the X server crashed, however the display is not dead > any more. X ist just restarting and shows the login screen again. > I will crash it one more time to verify. > > (In reply to comment #74) > > Created an attachment (id=3664) [edit] [edit] > > Crashlog to 1.5.174 > > > >
You probably recognized that I accidently wrote 1.5.174 in the last few posts - it is in fact 1.5.175 (In reply to comment #76) > Ok - seemed to be a single incident. Now it crashed like before. > > (In reply to comment #75) > > Ok something happened - the X server crashed, however the display is not dead > > any more. X ist just restarting and shows the login screen again. > > I will crash it one more time to verify. > > > > (In reply to comment #74) > > > Created an attachment (id=3664) [edit] [edit] [edit] > > > Crashlog to 1.5.174 > > > > > > > > >
O.k. that helps a little. Can I ask you to try something else ? Rather than do suspend/resume. Can you try VT switching to see if you can get it to happen ?
(In reply to comment #78) > O.k. that helps a little. > > Can I ask you to try something else ? > > Rather than do suspend/resume. Can you try VT switching to see if you can get it > to happen ? hi, guys! I am experiencing exactly the same problem with an nx6110 laptop. If the laptop hasn't been put into suspend to ram (via echo 3 > /proc/acpi/sleep) there are no problems. Sometimes, after a wake up from suspend it will crash when trying to watch a video file. The player doesn't matter, what I've noticed is that the crash occurs only when trying to use Xvideo output mode. If I set Mplayer to use x11 output (and so no acceleration) there are no crashes. Xvideo output works fine if the laptrop hasn't been suspended previuosly. To sum it up my uneducated guess is that somehow the Xvideo part is not reinitialized correctly during resume, so there's a crash when use of Xvideo is attempted. The strange thing is it happens randomly.
If you want to contribute - Alan's dev driver is available at http://www.fairlite.demon.co.uk/intel.html. Try to crash the X server with vt switching and upload the log here. It would speed things up enormously since I have only eventually access to the nx6110 of my gf. > hi, guys! > > I am experiencing exactly the same problem with an nx6110 laptop. If the laptop > hasn't been put into suspend to ram (via echo 3 > /proc/acpi/sleep) there are no > problems. Sometimes, after a wake up from suspend it will crash when trying to > watch a video file. The player doesn't matter, what I've noticed is that the > crash occurs only when trying to use Xvideo output mode. If I set Mplayer to use > x11 output (and so no acceleration) there are no crashes. Xvideo output works > fine if the laptrop hasn't been suspended previuosly. > > To sum it up my uneducated guess is that somehow the Xvideo part is not > reinitialized correctly during resume, so there's a crash when use of Xvideo is > attempted. The strange thing is it happens randomly. (In reply to comment #79) > (In reply to comment #78) > > O.k. that helps a little. > > > > Can I ask you to try something else ? > > > > Rather than do suspend/resume. Can you try VT switching to see if you can get it > > to happen ? > hi, guys! > > I am experiencing exactly the same problem with an nx6110 laptop. If the laptop > hasn't been put into suspend to ram (via echo 3 > /proc/acpi/sleep) there are no > problems. Sometimes, after a wake up from suspend it will crash when trying to > watch a video file. The player doesn't matter, what I've noticed is that the > crash occurs only when trying to use Xvideo output mode. If I set Mplayer to use > x11 output (and so no acceleration) there are no crashes. Xvideo output works > fine if the laptrop hasn't been suspended previuosly. > > To sum it up my uneducated guess is that somehow the Xvideo part is not > reinitialized correctly during resume, so there's a crash when use of Xvideo is > attempted. The strange thing is it happens randomly.
Luckily I have the machine right now. Following setup: video is playing and I keep switching to console via ctrl+alt+F1 and back via crtl+F1. No crashes so far - log is attached (In reply to comment #79) > (In reply to comment #78) > > O.k. that helps a little. > > > > Can I ask you to try something else ? > > > > Rather than do suspend/resume. Can you try VT switching to see if you can get it > > to happen ? > hi, guys! > > I am experiencing exactly the same problem with an nx6110 laptop. If the laptop > hasn't been put into suspend to ram (via echo 3 > /proc/acpi/sleep) there are no > problems. Sometimes, after a wake up from suspend it will crash when trying to > watch a video file. The player doesn't matter, what I've noticed is that the > crash occurs only when trying to use Xvideo output mode. If I set Mplayer to use > x11 output (and so no acceleration) there are no crashes. Xvideo output works > fine if the laptrop hasn't been suspended previuosly. > > To sum it up my uneducated guess is that somehow the Xvideo part is not > reinitialized correctly during resume, so there's a crash when use of Xvideo is > attempted. The strange thing is it happens randomly.
Created attachment 3684 [details] vt switching 1.5.175
o.k. if VT switching is o.k. Can you try changing the suspend option to "disk" instead of "mem" and see if that makes it crash as well. I'm suspecting it won't crash and if that's the case I think I can work up a fix.
1.5.176 is up to test with even more debug.
(In reply to comment #84) > 1.5.176 is up to test with even more debug. I downloaded the file from http://www.fairlite.demon.co.uk/i810_drv.o I suppose this is 1.5.176. Replaced my i810_drv.o with it, but unfortunately the crash is still here. I'm attaching the log file.
Created attachment 3739 [details] crashlog 1.5.176
I've uploaded another with more debug, can you try ?
One other test people might want to try is attaching a CRT and trying with that connected instead of the LCD. See if you can crash it that way.
(In reply to comment #87) > I've uploaded another with more debug, can you try ? I've tried the newest module, still locks up, uploading last 1000 lines of the X.org log file. (In reply to comment #88) > One other test people might want to try is attaching a CRT and trying with that > connected instead of the LCD. See if you can crash it that way. Tried with a CRT connected, no much difference. If there's anything else I can do I'd be glad to help.
Created attachment 3741 [details] crash log with more debug - see comment #87
Full logs are always better than partial ones, even if you bzip2 them. I've uploaded 1.5.185 to try.
(In reply to comment #91) > Full logs are always better than partial ones, even if you bzip2 them. > > I've uploaded 1.5.185 to try. With this one it always locks up. Evry time, from the first try, even before the machine has been suspended. I don't know if that's good, but I hope it might help locate the cause of the problem :). Attaching log.
Created attachment 3758 [details] 1.5.185 crash log, on a fresh start, without suspend to ram
It's certainly helping me narrow down what's causing things. I've uploaded 1.5.186.
(In reply to comment #94) > It's certainly helping me narrow down what's causing things. > > I've uploaded 1.5.186. Same as previous version, locks up even without suspending. See log.
Created attachment 3764 [details] 1.5.186 crash log, on a fresh start, without suspend to ram
o.k. 1.5.187 is up.
(In reply to comment #97) > o.k. 1.5.187 is up. No change, again crashes even without suspend, totally unable to play a movie using XV. Do you get enough info from the log file? Is there an easier way, like running the X server through a debuger or something?
Created attachment 3767 [details] 1.5.187 crash without suspend, on first attempt to use XV
I don't have access to an nx6110, and the lockup doesn't occur on the hardware I have access to.
Hello, I have the same laptop HP nx6110, with suspend problems. I'm using xorg 7.0 RC2 (Gentoo), but I have driver called i810_drv.so, not i810_drv.o (/usr/lib/xorg/modules/drivers/i810_drv.so). So, how can I help you to test the driver?
Any idea how he proceed futher? (In reply to comment #100) > I don't have access to an nx6110, and the lockup doesn't occur on the hardware I > have access to.
Created attachment 3790 [details] 1.5.191 Hi, I installed 6.8.2 and download the newest driver (1.5.191). I suspend to RAM, then resume. It gave me only black screen, if I tried to switch into console, display shut down.
(In reply to comment #21) > Is 1.5.157 still going ? Still going for me. I haven't had a crash since 1.5.156 (I upgraded to 1.5.164 ages ago, and this has been rock solid for me). I still can't find the sources for this, though. I'd really like to get rid of the enormous amounts of logging, and try to get DRI working. Where should I look?
1.5.192 is up to try.
It's worth upgrading the Xorg 7.0 now, and trying my latest test driver or compile the current Xorg CVS yourselves as all the latest code is there now.
I've uploaded 1.5.193 which has the Xvideo fixes from the Xorg 7.0 driver backported to the Xorg 6.8.2 driver. Those who can't upgrade to 7.0 may want to try 1.5.193 now.
(In reply to comment #107) > I've uploaded 1.5.193 which has the Xvideo fixes from the Xorg 7.0 driver > backported to the Xorg 6.8.2 driver. Thanks! Unfortunately it is quite broken for me. Totally garbled output from xine, vlc and mplayer (alternating flashing pink and green stripes).
Whoops, I know what I forget. Just uploaded 1.5.194 which should fix that.
Created attachment 4555 [details] crash log after a few suspend-resume cycles
Honza, this is a bad log because it's of a server restart through xdm (or equivalent). You need to make sure the server doesn't restart automatically otherwise it will overwrite the log file. I've also uploaded 1.6.5 because I forgot to enable the Xvideo debug output. So, can you download and try again, and explain in a little detail of what you did to cause the crash - i.e. what video player and possibly a pointer to a sample video file ?
well, there is a bug while using driver 1.6.5. It's without suspend-resume cycle - playing movie using xine player. For the first time playing it looks normal, but after second (and next) play (using xine or mplayer) it has corrupted colors (Foto: www.stud.fit.vutbr.cz/~xstodo00/i810/2x_xine.jpg). If I play it using mplayer only, it seems well. After suspend and resume it works fine for the first time in xine and then corrupted colors again. Mplayer without problems. This behaviour I noticed also in driver 1.6.4. Log file is there: http://www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log.tar.bz2 Log file seems to enlarge quite fast - 140 MB after 40 min uptime :-( Would it be possible to show version of current driver on the site with this test driver (http://www.fairlite.demon.co.uk/intel.html)? Thanks Honza
Crash using driver 1.6.5 This crash is without suspend-resume cycles, using Real Player plug-in in Firefox. Site caused crash is http://www.ceskatelevize.cz/vysilani/index.php?streamtype=RH&progid=18997. Version of Real Player is 10.0.6.776, Firefox 1.5. Log file is there: www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log_RealPlayer.tar.bz2
Try 1.6.6 which I've just uploaded.
I tried 1.6.6 - there are still corrupted colors after playing in xine. Log file after second play using xine: http://www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log_xine.tar.bz2). Playing in RealPlayer plug-in crashed after cca 10th run (1.6.5 crashed twice in two attempts). This crash log is after playing in Real Player plug-in and one suspend-resume cycle: www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log_RealPlayer_2.tar.bz2
Honza, these are good logs. Keep 'em coming. I've uploaded 1.6.7 which will probably be the last for today, but it'll give me some good stuff to read. Thanks.
Driver 1.6.7: There is a log with corrupted colors in xine - still the same behaviour as described above. Log is after second playing with xine. www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log_xine_2.tar.bz2 Crash after using Real Player plug-in. It's after cca 4 suspend-resume cycles and about 25 minutes intesive testing. www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log_RealPlayer_3.tar.bz2 Mplayer, xine and VLC didn't cause any crash while todays testing.
Honza, I've uploaded 1.6.8 to try. Let me know how it goes.
Hi, 1.6.8 has still corrupted colors after play in xine, but this time it doesn't help to suspend and resume - colors are still corrupted. There is log after second play using xine: http://www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log_xine_3.tar.bz2.
Honza, the color problems look like xine is using gamma adjustment which may not be what it's expecting. I'll need to look at xine to find out how they are configuring gamma values. So for now, ignore the color problems. I'm more interested in the lockups for this bug. Let me know if it locks up with 1.6.8.
Hi guys, > So for now, ignore the color problems. I'm more interested in the lockups for > this bug. I don't have the nx6110 with me right now, but I haven't had lockups with the last version of the module I installed (it was quite some time ago). I have more than 30 days uptime with numerous suspend/resume cycles and watching movies with Xv output. The question is how can I identify which release is the module I have? I'll have the computer next week, and may be post an md5sum of the .o file?
There are two logs from lockup. I tried to suspend and resume while a video is running. Sometimes it works well, sometimes it lockups. The first log is from real player plug-in and the second from mplayer. http://www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log_RealPlayer_4.tar.bz2 http://www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log_mplayer_1.tar.bz2
Honza, 1.6.9 is up to try.
(In reply to comment #121) > Hi guys, > > So for now, ignore the color problems. I'm more interested in the lockups for > > this bug. > > I don't have the nx6110 with me right now, but I haven't had lockups with the > last version of the module I installed (it was quite some time ago). I have more > than 30 days uptime with numerous suspend/resume cycles and watching movies with > Xv output. > > The question is how can I identify which release is the module I have? > > I'll have the computer next week, and may be post an md5sum of the .o file? Rado, if you look in the Xorg log file the version of the i810_drv is displayed when it's loaded.
1.6.9 Crashed after cca 20 suspend-resume cycles. Suspending while video is playing in mplayer. http://www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log_mplayer_2.tar.bz2
Honza, Do you use vbetool when suspending and resuming ?? If so, does it happen when you don't use vbetool ??
> if you look in the Xorg log file the version of the i810_drv is displayed when > it's loaded. Thanks, I checked it. I'm using Fedora Core 4, X.org 6.8.2 and version 1.5.191 of i810_drv and haven't had the lockup for a long time. I don't use vbetool, rely on the module itself to restore the video. I think I have seen this version to freeze once (more than a month ago), but can't reproduce it - may have been something completely unrelated. I think the problem is fixed in this release, at least it looks like so on my machine. I only use mplayer for video though, haven't tried other players. Honza, if you want try if this version works so good for you too. Regards, RAdo
Yes, I'm using vbetool, so I disabled it and tried about 40 suspend and resume cycles with real player and mplayer and no lockup.
(In reply to comment #128) > Yes, I'm using vbetool, so I disabled it and tried about 40 suspend and resume > cycles with real player and mplayer and no lockup. O.k. If you just did vbetool vbestate save hibernate.... vbetool vbestate restore Can you try going back to vbetool and doing this... vbetool vbestate save hibernate vbetool post vbetool vbestate restore Does that work ??
Well, I tried to set up using "vbetool post" in configuration file (hibernate.conf), suspend-resume, play video and then it crashed. There is crash log and some configuration files. http://www.stud.fit.vutbr.cz/~xstodo00/i810/Xorg.0.log_RealPlayer_5.tar.bz2 http://www.stud.fit.vutbr.cz/~xstodo00/i810/xorg.conf http://www.stud.fit.vutbr.cz/~xstodo00/i810/hibernate.conf
*** Bug 3054 has been marked as a duplicate of this bug. ***
I've been waiting (from bug #3054) for the 2.6.16 kernel. In the couple of weeks I've been waiting there hasn't been a single i810 crash. I'm not sure if this is as good as it sounds since the new i810 driver needs i915 1.4.1 for drm, and so was running without DRI. That's why I've been waiting for the 2.6.16 kernel (the mesa source itself is too complicated to me). I now really need hardware acceleration (I have some VRLM images I need to view), so I jumped ahead and installed 2.6.16-rc4. i810 accepts the i915 version it contains, but fails on a different point: drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) I810(0): [drm] loaded kernel module for "i915" driver (II) I810(0): [drm] DRM interface version 1.2 (II) I810(0): [drm] created "i915" driver at busid "pci:0000:00:02.0" (II) I810(0): [drm] added 8192 byte SAREA at 0xf8b37000 (II) I810(0): [drm] mapped SAREA 0xf8b37000 to 0xb7f96000 (II) I810(0): [drm] drmAddMap failed (EE) I810(0): [dri] DRIScreenInit failed. Disabling DRI. So DRI is still not operating for me. This is with i810 1.6.4 compiled for X.org 7.0.0 but run on 6.9.0. Let me know if you need the full log. Drew
You should probably get the latest test driver from http://www.fairlite.demon.co.uk/intel.html which is current to the CVS of X.org.
Oh yeah, I should have thought of that first. I've got it now, though, v 1.6.10, and it's still failing at drmAddMap in exactly the same manner.
Ok uploaded a new one that should fix that.
OK i810 now seems happy. v1.6.11 Seems to be switching on i915 successfully now: drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) I810(0): [drm] DRM interface version 1.2 (II) I810(0): [drm] created "i915" driver at busid "pci:0000:00:02.0" (II) I810(0): [drm] added 8192 byte SAREA at 0xf8a09000 (II) I810(0): [drm] mapped SAREA 0xf8a09000 to 0xb7f41000 (II) I810(0): [drm] framebuffer handle = 0xe0020000 (II) I810(0): [drm] added 1 reserved context for kernel (II) I810(0): Allocated 32 kB for the logical context at 0x7fe2000. Unfortunately there's still some problem running glx. glxinfo reports: name of display: :0.0 ERROR! sizeof(I830DRIRec) does not match passed size from device driver libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 Likewise glxgears runs slow (8 FPS).
Because you need to be running the i915_dri.so driver from Mesa CVS, which I suspect you've not done.
No, I'm using 2.6.16-rc4.
You misunderstand. Mesa CVS is where the 3D driver lives i.e. i915_drv.so (not the kernel module i915.ko) So you need to check out Mesa CVS and build that to get the new i915_drv.so and install that in the modules/dri directory.
Where I said i915_drv.so above - substitute i915_dri.so (it's early - coffee)
My that's horrible confusing have two different drivers with the same name. While I wait till I can get my hands on the new mesa i915 driver (distinct from the kernel i915 driver), I've got i810 1.6.11 running on linux 2.6.16-rc4. Unfortunately the lockup has just occurred again. It never occurred with i810 1.6.10 on linux 2.6.15, running for several weeks. Since i810 1.6.10 rejected kernel 2.6.15's version of i915, whereas 2.6.16-rc4's version of i915 is being used, I gather the bug is somewhere in i915. Do you expect adding mesa's new version of i915 will make any difference to this? Is the Xserver log useful at this point?
There aren't two drivers with the same name. Let me explain... i810_drv.so is the Xserver's 2D driver i915_dri.so is the 3D DRI Driver i915.ko is the kernel driver. And yes, the log would be useful with the steps you did leading up to the crash.
Created attachment 4755 [details] lockup log from i810 1.6.11 on linux 2.6.16-rc4 Hmm, i915_dri.so and i915.ko sound pretty much like recompilations of the same driver to me, but anyway... Here is a log containing a recent lockup under i810 1.6.11 and kernel 2.6.16-rc4 (i915 v1.4). Mesa (i915_dri) is from Debian's xlibmesa-dri v6.9.0.dfsg.1-4. For me the problem is related to S3 suspend-to-ram, and occurs upon resuming. When I resume, I typically see one of two effects: either the lockup (which the attachment here refers to), or else window integrity is lost (windows not painted correctly, fixed only by rebooting, not by restarting X). In the first case of lockup, the screen remains blank after resume and I never get back to X at all. The attached log refers to this case. I should mention at this point that I need to use the following script to resume, taken previously from http://www.faime.demon.co.uk/linux/scripts.html (no longer available), referring to http://bugme.osdl.org/show_bug.cgi?id=4455 ########################################### curcons=`fgconsole` chvt 1 logger "acpi/sleep: entering sleep state" sync echo -n mem > /sys/power/state logger "acpi/sleep: back from sleep state" logger "acpi/sleep: clearing video S3 state ..." /usr/X11R6/bin/pcitweak -w 00:02:00 212 0 chvt $curcons ##################################### If I do not use it then the computer does not get anywhere resuming at all, and the end of the X log looks like: ... Warning: font renderer for ".bdf.gz" already registered at priority 0 Warning: font renderer for ".pmf" already registered at priority 0 (WW) I810(0): Successfully set original devices (WW) I810(0): Setting the original video mode instead of restoring the saved state (WW) I810(0): Extended BIOS function 0x5f05 failed. (II) I810(0): BIOS call 0x5f05 not supported, setting refresh with VBE 3 method.(II) I810(0): xf86UnbindGARTMemory: unbind key 7 (II) I810(0): xf86UnbindGARTMemory: unbind key 0 (II) I810(0): xf86UnbindGARTMemory: unbind key 1 (II) I810(0): xf86UnbindGARTMemory: unbind key 3 (II) I810(0): xf86UnbindGARTMemory: unbind key 2 (II) I810(0): xf86UnbindGARTMemory: unbind key 4 (II) I810(0): xf86UnbindGARTMemory: unbind key 5 (II) I810(0): xf86UnbindGARTMemory: unbind key 6 (WW) I810(0): Successfully set original devices (2) (II) Open ACPI successful (/var/run/acpid.socket) (II) I810(0): Detected resume, re-POSTing. (WW) I810(0): Bad V_BIOS checksum (II) I810(0): Primary V_BIOS segment is: 0xc000
Created attachment 4756 [details] windows not repainting after resume As a variation I tried the shorter S3 suspend/resume script from http://bugme.osdl.org/show_bug.cgi?id=4455, namely: #### cat /proc/bus/pci/00/02.0 > /var/cache/vidpci.config echo -n mem > /sys/power/state cat /var/cache/vidpci.config > /proc/bus/pci/00/02.0 #### (the suspend/resume problem appears to belong to IBM R51 Thinkpad laptops) This gave me an example of the bug where the windows do not get repainted correctly after resume. As far as I can tell it's the same behaviour obtained when using the other suspend/resume script. In more detail, lockup has not occured but the problem is that while the mouse and keyboard work fine, the windows are not repainted successfully. I can see only parts of their contents, and if I move a window about then the contents do not follow, instead a ghost box is left where the original window was. The frame of the window, on the other hand, is drawn correctly, and if I make the window full screen using the maximise button then I can see its contents. If I access the Gnome->Desktop->Logout dialog box, then it appears but I can't read the entries. But but hovering the mouse over them I can see the buttons (e.g. Restart or Logout) appear. Logging out and restarting X does not help, the windows are still broken after logging back in again. All I can do is reboot the computer. The attached log represents /var/log/Xorg.0.log at the point after resume (before rebooting).
Drew, you might want to check the Thinkpad's BIOS and see if there is an option to repost on S3.
I had a look at the BIOS options but I couldn't see anything that seemed relevant. POST was mentioned but only in regards to booting, I couldn't see anything referring to suspend/resume, or linking POST directly to video. The Video section referred to brightness and video port settings, not suspend settings. I couldn't see any reference to S3 suspend or to ACPI.
I can also confirm this bug. I have a Toshiba Satellite Laptop and I am using Ubuntu Dapper on it. The lockup happened after I once did a suspend to RAM. After that X never started and it went into an infinite loop. I am attaching the full log with this.
Created attachment 4964 [details] Crash log Attached crash log
I've got a different error message now with i810 1.6.13. This time the freeze after suspend/resume occurred with the screen being displayed (not blank), and with a blue glow overlaying over the top 3 or 4 cm of the screen. The error this time was: (II) I810(0): [drm] dma control initialized, using IRQ 11 ADVANCE_LP_RING: outring (0x21) isn't on a QWord boundary(II) Configured Mouse: ps2EnableDataReporting: succeeded ADVANCE_LP_RING: outring (0x29) isn't on a QWord boundaryError in I830WaitLpRing(), now is 121174101, start is 121172100 pgetbl_ctl: 0x5fee0001 pgetbl_err: 0x0 ipeir: 0 iphdr: c000000 LP ring tail: 28 head: 8 len: 1f001 start 0 eir: 0 esr: 1 emr: ffff instdone: ffc1 instpm: 40 memmode: 108 instps: 20 hwstam: ffff ier: 82 imr: 9 iir: 20 space: 131031 wanted 131064 (II) I810(0): [drm] removed 1 reserved context for kernel (II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xf8b45000 at 0xb7fcd000 Fatal server error: lockup Please consult the The X.Org Foundation support at http://wiki.X.Org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. ADVANCE_LP_RING: outring (0x31) isn't on a QWord boundaryError in I830WaitLpRing(), now is 121176121, start is 121174120 pgetbl_ctl: 0x5fee0001 pgetbl_err: 0x0 ipeir: 0 iphdr: c000000 LP ring tail: 30 head: 8 len: 1f001 start 0 eir: 0 esr: 1 emr: ffff instdone: ffc1 instpm: 40 memmode: 108 instps: 20 hwstam: ffff ier: 0 imr: ffff iir: 0 space: 131023 wanted 131064 FatalError re-entered, aborting lockup Let me know if you want the rest of the log.
Everyone who's getting "ghost" windows after resuming from S3: I used to see this too, and I fixed it by removing all the vbetool statements from my suspend script. My suspend script now only does the equivalent of "chvt 1; echo mem > /sys/power state" on suspend. On resume, it only does "chvt 7" and relies on the X driver to restore state. I *do*, however, still have the problem with xv causing lockups on resume. But I'm using an old version of i810_drv.so (the one that comes with debian unstable, don't know which version it is).
No, Lorenzo, your suggestion is no good, sorry. I never had any vbetool statements in my script in the first place. And the Xserver is unable to restore video on its own, that's the whole problem. It needs extra commands to try to fix it. I've been using cat /proc/bus/pci/00/02.0 > /var/cache/vidpci.config echo -n mem > /sys/power/state cat /var/cache/vidpci.config > /proc/bus/pci/00/02.0 in line with http://bugme.osdl.org/show_bug.cgi?id=4455
I think the problem that you're seeing is the same though: the X server tries to restore video by re-POSTing, but at the same time you're writing to the video card registers, so X server and card state get out of sync. As I said, I fixed this by not writing to the card registers at all and having the X server re-POST on its own. If this doesn't work for you, maybe you can try to stop the graphics driver from attempting to re-POST and just doing it by catting the registers back.
> If this doesn't work for you, maybe you can try > to stop the graphics driver from attempting to re-POST umm ... how?
(In reply to comment #153) > > If this doesn't work for you, maybe you can try > > to stop the graphics driver from attempting to re-POST > > umm ... how? By commenting out the code that does it, perhaps?
Alan, did the code for this fix ever get added to CVS?
I get this error on ubuntu dapper with both the 1.4.1.3 version of the driver shipped with dapper, and with the 1.6.0 version checked out with git. Allthough: My X session locks up regardless of any suspend stuff. If I start the computer, log in to X and try to use xv, it crashes and hangs.
Created attachment 5729 [details] Xorg log from i810 1.6.0 Xorg log from i810 1.6.0 Linux version 2.6.15-23-686 (buildd@rothera) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 SMP PREEMPT Tue May 23 14:03:07 UTC 2006
I see similar behavior here; I get intermittent lockups (with the complaint "Error in I830WaitLpRing()") when viewing movies with mythtv or xine. I'm not doing any suspending or fancy power management that I'm aware of. This is with the driver out of git, as of 2006-05-30, and the X server from Debian sid (xserver-xorg-core 1.0.2-8).
Altough are reported for different xorg versions, I think this is a duplicate of #5774. *** This bug has been marked as a duplicate of 5774 ***
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.