xorg-server segfaults with intel (i810) driver and looses itself in infinite respawn

Bug #147597 reported by gmud
2
Affects Status Importance Assigned to Milestone
xf86-video-intel
Won't Fix
High
xserver-xorg-video-intel (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Steps to reproduce:

There are no specific steps required such as suspend/resume or using video overlay apps. It happens without being reproducible with certain steps required to make X crash.

The server crashes with signal 11 and then looses itself in an infinite respawn, the machine has to be rebooted for normal operation.

Error messages in Xorg log:

Error in I830WaitLpRing(), timeout for 2 seconds
pgetbl_ctl: 0x3ffe0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 0
LP ring tail: 408 head: 0 len: 1f001 start 0
eir: 0 esr: 1 emr: ffff
instdone: ffc1 instpm: 0
memmode: 108 instps: 20
hwstam: ffff ier: 0 imr: ffff iir: 0

(see attached xorg log for more details)

Revision history for this message
gmud (gmud) wrote :
Revision history for this message
gmud (gmud) wrote :

Just for the records: the crash happens on gutsy (kubuntu) beta, xorg-server version is 1.3.0.0.dfsg-12ubuntu8

Revision history for this message
In , gmud (gmud) wrote :

- Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
- Xorg version 7.2 (xorg-server 1.3.0.0), Intel driver version 2.1.1 (ubuntu gutsy packages)

When using the xorg server with the intel driver and loading a lot of pixmaps in short intervals the server segfaults with the following error:

Error in I830WaitLpRing(), timeout for 2 seconds

(see attached log for full details)

The notebook has to be restarted after lockup, no way to get to a readable console (screen is garbled), server respawns infinitely.

This bug is relatively serious, because I already had data loss because of the lockup.

I am trying to find a more presize way to reproduce this bug, as soon as I have more info I'll post it here.

Revision history for this message
In , gmud (gmud) wrote :

Created an attachment (id=11977)
log for xorg segfaulting with I830WaitLpRing() error.

Revision history for this message
Bryce Harrington (bryce) wrote :

The infinite respawn (if it's what I suspect) should be resolved now. (Please confirm against Gutsy-final).

If the crash also still occurs, please attach the output of lspci -vvnn.

Changed in xorg-server:
status: New → Incomplete
Revision history for this message
In , Gordon Jin (gordon-jin) wrote :

Can you describe in a more reproducible way?

Revision history for this message
In , gmud (gmud) wrote :

Hello,

after the latest update I cannot reproduce anymore, so it seems fixed now.
If I encounter the problem again I will reopen and post more info.

Revision history for this message
In , gmud (gmud) wrote :

Reopen. Today I had 20 crashes of the same type. And now I know why it is sometimes gone: When enabling framebuffer with kernel parameter "vga" I can almost all times reproduce the error with the following steps:

1. High resolution (1650w) on external device (flatpanel on pipe b and lcd on pipe a)
2. Load a lot of pixmaps at once or simply load a webpage in a browser and scroll up and down fast
The server will crash then.

When disabling framebuffer I cannot reproduce anymore!

Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

You mean using the intelfb kernel driver? That's generally incompatible with the X driver, so we may have to mark this one WONTFIX.

On the plus side, we're looking to replace the intelfb driver with something much more featureful--DRM based kernel mode setting. You can see more info about that at http://dri.freedesktop.org/wiki/DrmModesetting.

Revision history for this message
In , gmud (gmud) wrote :

The problem is, if I want to have a splash theme while booting... I have seen this a lot of times. Is this an intelfb only problem?

kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=blabla ro quiet splash

kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=blabla ro quiet vga=791 splash

Revision history for this message
In , Jesse Barnes (jbarnes-virtuousgeek) wrote :

Yes, I think intelfb is the only fb driver that's this incompatible with the X driver (though there have definitely been conflicts between other fb & X drivers in the past). On top of that, the intelfb driver can't drive very many types of outputs, so it's not generally very useful.

So sorry, this configuration won't be supported. But like I said before, we're working towards something much better; keep your eye on the kernel mode setting work.

Revision history for this message
In , gmud (gmud) wrote :

Thanks for the feedback and I'll keep watching the drmmodesetting thing :)

Revision history for this message
In , Michel-tungstengraphics (michel-tungstengraphics) wrote :

In the meantime, vesafb might be better.

Revision history for this message
gmud (gmud) wrote :

Perhaps this is related to the following bug:
http://bugs.freedesktop.org/show_bug.cgi?id=12772

It's about intelfb and X driver incompatibility (won't fix).

Revision history for this message
Bryce Harrington (bryce) wrote :

Thanks for checking upstream on this. Since they're marking it won't fix, we're doing the same. This probably means you'll need to run without the intelfb for the time being, until the new DRM modesetting work is released.

Changed in xserver-xorg-video-intel:
status: Incomplete → Won't Fix
Changed in xserver-xorg-video-intel:
status: Unknown → Won't Fix
Revision history for this message
Ronald Verbeek (n-launchpad-anrosil-nl) wrote :

I am confronted with this bug in Intrepid. It didn't had it in previous Ubuntu releases. I have had it at least twice while playing AisleRiot (Freecell) while dragging a card with the mouse.

Revision history for this message
gmud (gmud) wrote :

Yes, I had this yesterday, too. Seems to be a problem with intrepid, it didn't occur with hardy.

This is the bt:
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x79) [0x80c3009]
1: [0xb7fdb400]
2: /usr/lib/xorg/modules/drivers//intel_drv.so(I830WaitLpRing+0x1dc) [0xb7a411ac]
3: /usr/lib/xorg/modules/drivers//intel_drv.so(I830Sync+0x1c3) [0xb7a415e3]
4: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7a4c8d0]
5: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7a4ca30]
6: /usr/bin/X [0x80d6b0a]
7: /usr/lib/xorg/modules/extensions//libglx.so [0xb7b05be9]
8: /usr/bin/X(AbortDDX+0x79) [0x80a8b09]
9: /usr/bin/X(AbortServer+0x28) [0x813c498]
10: /usr/bin/X(FatalError+0x63) [0x813caa3]
11: /usr/lib/xorg/modules/drivers//intel_drv.so(I830WaitLpRing+0x201) [0xb7a411d1]
12: /usr/lib/xorg/modules/drivers//intel_drv.so(I830Sync+0x1c3) [0xb7a415e3]
13: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7a697ea]
14: /usr/lib/xorg/modules//libexa.so(exaWaitSync+0x65) [0xb791b045]
15: /usr/lib/xorg/modules//libexa.so(ExaDoPrepareAccess+0x7e) [0xb791c23e]
16: /usr/lib/xorg/modules//libexa.so(ExaCheckPutImage+0x103) [0xb7923e03]
17: /usr/lib/xorg/modules//libexa.so [0xb791d585]
18: /usr/bin/X [0x817948d]
19: /usr/bin/X(ProcPutImage+0x15e) [0x808951e]
20: /usr/bin/X(Dispatch+0x34f) [0x808c89f]
21: /usr/bin/X(main+0x47d) [0x8071d1d]
22: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7bdd685]
23: /usr/bin/X [0x8071101]
Saw signal 11. Server aborting.
(II) AIGLX: Suspending AIGLX clients for VT switch
Error in I830WaitLpRing(), timeout for 2 seconds
pgetbl_ctl: 0x3ffc0001 getbl_err: 0x00000000
ipeir: 0x00000000 iphdr: 0x02000011
LP ring tail: 0x000001d0 head: 0x00011774 len: 0x0001f001 start 0x00000000
eir: 0x0000 esr: 0x0000 emr: 0xffff
instdone: 0xfa41 instpm: 0x0000
memmode: 0x00000306 instps: 0x800f04c4
hwstam: 0xfffe ier: 0x0002 imr: 0x0000 iir: 0x0070
Ring at virtual 0xa77fc000 head 0x11774 tail 0x1d0 count 14999
Ring at virtual 0xa77fc000 head 0x11774 tail 0x1d0 count 14999
[...]
Ring end
space: 71068 wanted 131064

Changed in xserver-xorg-video-intel:
importance: Unknown → High
Changed in xserver-xorg-video-intel:
importance: High → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.