Bug 5774

Created attachment 4518 [details]
Log file containing Error in I830WaitLpRing()

Created attachment 4519 [details]
Xdpyinfo output

Created attachment 4520 [details]
xvinfo output

Created attachment 4521 [details]
Xorg configuration file

The log you've provided is bogus, because it's of an Xserver that's been
respawned by your display manager and thus overwrote the original log.

Having said that, I'd be more interested in a log with the driver from 
http://www.fairlite.demon.co.uk/intel.html

Created attachment 4522 [details]
Xorg.log with new driver loaded

When X starts, i can see nothing but a black screen and i cannot switch to any
vitual console.

While opening a bug on ubuntu bugzilla, i find this: 
https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-i810/+bug/28326 
Same behaviour as me! 
 
 

Mmm. A couple of users have reported this now, in that the last line comes back
with "Module called abort()"

Can you ssh in and do this for me....

gdb Xorg

once in gdb, do this

break xf86abort
run

This will start X and stop at the point it calls the abort function. Then do this..

backtrace

and attach the output of the backtrace.

Thanks.

Surely! Thanks! 

My hardware: IBM/Lenovo Thinkpad X41 Tablet

lspci -vvv
0000:00:02.0 VGA compatible controller: Intel Corporation Mobile
915GM/GMS/910GML Express Graphics Controller (rev 03) (prog-if 00 [VGA])
        Subsystem: IBM: Unknown device 0582

This is a backtrace from the experimental driver at:
http://www.fairlite.demon.co.uk/intel.html

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7da19a1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7da32b9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x080e13e0 in xf86abort ()
#4  0xb7909164 in shadowDamageRegion () from /usr/lib/xorg/modules/libshadow.so
#5  0x0818d842 in compPaintWindowBackground ()
#6  0x080ff01f in miWindowExposures ()
#7  0x080c4ee9 in xf86XVScreenInit ()
#8  0x080738d9 in MapWindow ()
#9  0x08073b7f in InitRootWindow ()
#10 0x0806e2c7 in main ()

O.k. I've found the problem. The i810 driver uses some of a newer interface in
the shadow library.

So, I've uploaded a new libshadow.so that also needs to be installed with the
i810_drv.so.

Please try this and report back.

It works (at least for me). Now I only need to work on the wacom-driver to
respect these settings.

Sorry for the delay...i've been very busy here at work! :-)    
This is my backtrace using the experimental driver:   
   
#0  0x080e13bf in xf86abort ()   
#1  0xb7886164 in shadowDamageRegion ()   
from /usr/lib/xorg/modules/libshadow.so   
#2  0x080ff01f in miWindowExposures ()   
#3  0x080c4ee9 in xf86XVScreenInit ()   
#4  0x080738d9 in MapWindow ()   
#5  0x08073b7f in InitRootWindow ()   
#6  0x0806e2c7 in main ()   
   
It's the same as Sven's backtrace!   
Now trying with the new libshadow.so...i'll give you feedback within few days. 
 
Thank you so much!!! 
    

Hey...Xorg is working now!  
Maybe it's too soon to say that but...i think the bug is gone away: i cannot 
reproduce the crash anymore! 
Let's see if i find some regression in this days... 

Closing. Re-open if something crops up.

I'm using FC5 and I recently did a yum update to xorg-x11-drv-i810-1.4.1.3-3.1
and xorg-x11-server-Xorg-1.0.1-9.fc5.5 and now I get the problem.
It happens with perfect reproducability every time I suspend to RAM and
come back, I'm using "/bin/echo -n mem > /sys/power/state" which always worked
in the past and now it kills X after resuming from suspend. 
I also added more RAM to my system recently (from 256M to 512M) which might
be related. The yum update also updated a heap of other stuff but I get this
problem with almost no applications running (just xterm and ratpoison).

Created attachment 6449 [details]
Xorg log from a server "lockup" error

You will notice that I have a bunch of Wacom stuff enabled but the test in
question did not have the Wacom tablet plugged in. I can repeat the test
without
Wacom enabled if you think that makes a difference. There never has been a 
problem with the Wacom stuff in the last few versions.

I just tried the http://www.fairlite.demon.co.uk/intel.html driver and
it seems to be incompatible with Redhat's build...

(EE) module ABI major version (1) doesn't match the server's version (0)
(II) UnloadModule: "i810"
(II) Unloading /usr/lib/xorg/modules/drivers/i810_drv.so
(EE) Failed to load module "i810" (module requirement mismatch, 0)


Guess I'll have to find an SRPM from somewhere and roll my own...

The log you provide is useless because it's from an Xserver that's being started
with xdm (or gdm or equivalent) so you must turn that off first and get a new log.

Created attachment 6529 [details]
I830WaitLpRing lockup in 1.6.5

The lockup occured under i810 1.6.5.
Linux 2.6.17, Xorg 7.1.1 (1.1.1),  mesa Version: 6.5.0.cvs.20060524.

Should this mesa version be recent enough for i810 1.6.5 to work correctly?

*** Bug 4353 has been marked as a duplicate of this bug. ***

It's not enough to provide a log. Please indicate what you did to cause the
crash at that time in detail.

For those who are playing video's and suspend/resuming you'll have to grab the
current git repository and change the first line in i830_video.c to a '1' and
recompile.

Reinstall the new driver and try to reproduce the crash.

There's been some fixes today for Xv issues, I really suggest doing what I said
in the last comment if people still have issues with the latest git code.

I've uploaded a binary snapshot of the 1.7.0 driver to my homepage at
http://www.fairlite.demon.co.uk/intel.html for those people here to try.

You'll need to use the -ignoreABI flag for older than Xorg 7.1 servers.

Hi Alan

Can you please also post the source code of your new driver snapshot or at 
least also binary for amd64/X86_64.

I am trying to get an intel core 2 duo with an intel i945GM card to work, but
every now and then the XServer crashes with the "I830WaitLpRing()... Fatal 
server error: lockup" message. By the way I do not use any fancy video or 
graphic tasks when the server crashes just browsing, coding, writing, mouse 
movements, ...

Alex, why don't you just do what I said in comment #24 ?

Hi Alan
Although I have installed the latest i830 driver from the git repostory
I still experience the "I830WaitLpRing" problem:

Error in I830WaitLpRing(), now is 238436401, start is 238434296
pgetbl_ctl: 0x7ffc0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 0
LP ring tail: c310 head: c310 len: 1f001 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 0
memmode: 306 instps: f0000
hwstam: ffff ier: 0 imr: ffff iir: 0
space: 131060 wanted 131064

Fatal server error:
lockup

(WW) I810(0): Successfully set original devices
(WW) I810(0): Setting the original video mode instead of restoring
        the saved state
(--) I810(0): A non-CRT device is attached to pipe B.
        No refresh rate overrides will be attempted.
(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 13
(II) I810(0): xf86UnbindGARTMemory: unbind key 9
(II) I810(0): xf86UnbindGARTMemory: unbind key 10
(II) I810(0): xf86UnbindGARTMemory: unbind key 12
(II) I810(0): xf86UnbindGARTMemory: unbind key 11
(WW) I810(0): Successfully set original devices (2)

 

What would be extremely useful Alex is that you actually give some description
about what exactly you do to cause it and a complete and full log file as it may
bear absolutely no resemblence to the initially reported behaviour. In which
case a new bug should be opened.

As of today I have not seen any common pattern which might have caused any of 
the crashes. I guess that it might be linked to activity on the input devices 
(mouse or keyboard), but I have no proof for that. Fact is that it only crashes 
while I am working (moving the mouse or pressing keys), it does not crash if 
the desktop is idle or the screensaver is running. However, there are not 
obvious signsfor that in the log files the only thing I see is the 
beforementioned "I830WaitLpRing ... Server lockup" message.

I have to few knowledge about the X-system to deceide if this problem is 
distinct from this bug, if it is, I will of course open a new one. For the mean 
time I'll post a complete Xorg logfile of a crashed session.

Created attachment 7399 [details]
Xorg.log with I830WaitLpRing message and lockup

Does the Xserver start successfully again once it's crashed, or do you need to
reboot ?

(In reply to comment #32)
> Does the Xserver start successfully again once it's crashed, or do you need to
> reboot ?

I have the same problem on a MacBook (non-pro) with Debian, xorg 7.1.0 and i810
1.6.5 or 1.7.2. When I downgrade to i810 1.5.1 (which requires xorg 7.0.23), it
works. That is, it is a regression in either xorg 7.1 or the i810 driver 1.6.

And to answer your question: the server can not restart, but I usually need a
cold reboot to fix it.

(In reply to comment #33)
> That is, it is a regression in either xorg 7.1 or the i810 driver 1.6.

Update: it seems to be a problem with xorg 7.1. I just recompiled the Debian 
xserver-xorg-video-i810 1.5.1.0-2 package with xorg 7.1.0 and see the same 
problem. Downgrading the xorg-server and xorg-xserver-core packages to 7.0 
solves the problem again. I can provide log files if that would help.

I had the same problem as #16, with the suspend to ram. After reading in another
bug that vbetool was bad, I disabled it. Then I experienced the bug that was
fixed in version 1.7.1. After upgrading to 1.7.2, everything worked. Maybe this
would also resolve the problem for #16, in which case this bug is one step
closer to being closed.

Someone should checkout the current git repo for the upcoming 7.2 Xorg release
just to make sure it's fixed in that then.

Personally, I did not encounter this bug with 1.6.x but it started happening when I installed 
1.7.2.

Joonas, if you have a 965 chipset and are running Xv apps, you are hitting a
different problem.

I'm going to close this now - as I believe it's fixed.

If someone can actually replicate the problem with the current Xorg upcoming 7.2
release and the current git i810 driver then we can reopen it. Until then this
is closed as fixed.

Please reopen this bug, it still crashes with Xorg 7.1.99.2 and latest xf86-
video-intel from GIT (checked out 4th Nov). Happens sometimes when running xine 
after resuming from suspend to disk. This happens too, if opengl is selected as 
video output mode in xine! While my kdm is in the crashing-starting loop, I can 
run suspend to disk again, and after resuming, my X starts up fine and I have 
no problems with xv or opengl then, until the next resume. Are you sure, this 
is not kernel related? I use an Intel 855GM chipset.


I configured xf86-video-intel with --enable-video-debug. My Xorg.0.log (after 
the first crash) states:
------- SNIP -------
(**) Keyboard1: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD)
(II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE)
(II) Mouse1: ps2EnableDataReporting: succeeded
(II) AIGLX: Suspending AIGLX clients for VT switch
Error in I830WaitLpRing(), now is -1291190234, start is -1291192235
pgetbl_ctl: 0x1ffe0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 1810000
LP ring tail: 160 head: 0 len: 1f001 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 1
memmode: 108 instps: 0
hwstam: ffff ier: 22 imr: 9 iir: 280
space: 130712 wanted 131064
(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xdf876000 at 0xb7b50000

Fatal server error:
lockup

(II) AIGLX: Suspending AIGLX clients for VT switch
Error in I830WaitLpRing(), now is -1291187226, start is -1291189227
pgetbl_ctl: 0x1ffe0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 1810000
LP ring tail: 168 head: 0 len: 1f001 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 1
memmode: 108 instps: 0
hwstam: ffff ier: 22 imr: 9 iir: 200
space: 130704 wanted 131064

FatalError re-entered, aborting
lockup
------- SNAP -------

And in my kdm.log I got (this is a sane X before a suspend, showing a video, 
mixed with the insane X after the resume):

------- SNIP -------
SPIN 997639
SPIN 997638
SPIN 997637
SPIN 997636
SPIN 997635
SPIN 997634
OVERLAY_OFF
COLORKEY
Overlay goes from off to on
OVERLAY_UPDATE
BRIGHTNESS
OVERLAY_UPDATE
CONTRAST
OVERLAY_UPDATE
I830StopVideo
I830StopVideo
I830StopVideo
I830StopVideo
I830StopVideo
I830StopVideo
I830StopVideo
I830StopVideo
COLORKEY
OVERLAY_UPDATE
pitch 0 is 100, pitch 1 is 52, pitch 2 is 52
offset 1 is 10000, offset 2 is 12600
size is 15200
Error in I830WaitLpRing(), now is -1291219736, start is -1291221737
pgetbl_ctl: 0x1ffe0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 1810000
LP ring tail: 158b0 head: 158a4 len: 1f001 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 1
memmode: 108 instps: 0
hwstam: ffff ier: 22 imr: 9 iir: 200
space: 131052 wanted 131064

Fatal server error:
lockup

Error in I830WaitLpRing(), now is -1291217732, start is -1291219733
pgetbl_ctl: 0x1ffe0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 1810000
LP ring tail: 158b8 head: 158a4 len: 1f001 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 1
memmode: 108 instps: 0
hwstam: ffff ier: 22 imr: 9 iir: 200
space: 131044 wanted 131064

FatalError re-entered, aborting
lockup


This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation CVS repository.
See http://wiki.x.org/wiki/CvsPage for CVS access instructions.

X Window System Version 7.1.99.2
------- SNAP -------

Alan: I'm using 945GM chipset.

Created attachment 7654 [details] [review]
video patch

Can you try applying the following patch to the driver and see if it makes a
difference.

Applied the patch and tested a lot. 
I was unable to reproduce the crash again after applying the patch, and 
everything works fine as expected. It seems to be a lot more stable now.

Created attachment 7727 [details] [review]
Alternative fix

Can you try this alternative fix and let me know the results.

Applied the alternative fix and after some tests, it seems to be stable, too. 
Is this patch worthy to be applied upstream? If you need further testings, I'm 
your man. I'll let you know, if it happens to crash again.

Thank you very much.

Fixed in the git repo now. It'll be in the next release.

(In reply to comment #40)
> no problems with xv or opengl then, until the next resume. Are you sure, this 
> is not kernel related? I use an Intel 855GM chipset.
> 
I know this bug is marked as solved, but I would like to explain my experience 
just in case. I get to recover the system after this situation. X server was 
trying to start and crash infinitely till I went to a console, stopped the kdm 
service (also X) and then unloading the i915 module and then starting again kdm 
works.

I'm on debian unstable, card i855GM, linux 2.6.18.3, xorg-i810 1.7.2, xorg 
1.7.1. The problem is reproduced randomly after some suspend to ram or 
hibernate cycle and xine playing by Xv.

I've uploaded the latest git driver to my homepage at
http://www.fairlite.demon.co.uk/intel.html.

If you can try that it has additional debug output if Xv causes the Xserver to
crash.

Back again (after 6 months)...

I just installed FC6 and now X11 does *NOT* die after return from suspend to
RAM. Seems that the problem has been fixed. Absolutely nothing else in the
hardware has changed. The new package versions are:
xorg-x11-drv-i810-1.6.5-9.fc6 and xorg-x11-server-Xorg-1.1.1-47.fc6 plus the
kernel version was also moved forward in the upgrade (now is at Linux version
2.6.18-1.2798.fc6).

Looking at the patch regarding xv, I strongly suspect that my problem had
nothing to do with this because for me it happened without playing video, just
running very simple apps.

Seems strange to me that xdm would break the logfiles because just about
everyone uses xdm or gdm. I would expect that a good design would be for the
standard system logfile to contain all the relevant information thus, you have a
fighting chance of getting hold of useful data.

Reopen. :-( Just crashed on my notebook again.

Background: Did a lot of suspend2ram cycles with my notebook and when opening xine now, X crashed. Usually after suspend2ram everything works fine. Sometimes after suspend2ram all OpenGL output is black (this is a bug too). After suspend2disk, OpenGL output is fine again. X crashes much less often than before, but still it's not reliable.

System (Gentoo):
xorg-server-1.2.0
xf86-video-i810-1.7.4
suspend2-sources-2.6.19


Relevant part in Xorg.0.log:
------ SNIP ------
(**) Keyboard1: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD)
(II) XINPUT: Adding extended input device "touchpad" (type: MOUSE)
(II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE)
Synaptics DeviceInit called
SynapticsCtrl called.
(II) Mouse1: ps2EnableDataReporting: succeeded
Synaptics DeviceOn called
(--) touchpad touchpad found
Synaptics DeviceOff called
(II) AIGLX: Suspending AIGLX clients for VT switch
Error in I830WaitLpRing(), now is 216775073, start is 216773072
pgetbl_ctl: 0x1ffe0001 pgetbl_err: 0x19
ipeir: 0 iphdr: 1810000
LP ring tail: 160 head: 0 len: 1f001 start 0
eir: 0 esr: 10 emr: ffff
instdone: ffc0 instpm: 15
memmode: 108 instps: 0
hwstam: ffff ier: 22 imr: 9 iir: 280
space: 130712 wanted 131064
(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xdff8f000 at 0xb7b89000

Fatal server error:
lockup

(II) AIGLX: Suspending AIGLX clients for VT switch
Error in I830WaitLpRing(), now is 216778081, start is 216776080
pgetbl_ctl: 0x1ffe0001 pgetbl_err: 0x19
ipeir: 0 iphdr: 1810000
LP ring tail: 168 head: 0 len: 1f001 start 0
eir: 0 esr: 10 emr: ffff
instdone: ffc0 instpm: 15
memmode: 108 instps: 0
hwstam: ffff ier: 22 imr: 9 iir: 280
space: 130704 wanted 131064

FatalError re-entered, aborting
lockup
------ SNAP ------

Oh, it's an Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

Thanks,
Sascha

This is closed. And you are not using the same xorg version or driver of the original bug.

Please open a new report. And additional information such as the full log, and building the driver with the --enable-video-debug flag before posting the log would be useful. 

As certainly looking at that crash information it doesn't look like Xvideo is causing your crash.