X hangs and gives "illegal extended x86 opcode" after Gutsy upgrade

[Gard Spreemann]

Binary package hint: xserver-xorg-core

The problems started taking place after upgrading from Feisty to Gutsy on a Toshiba Tecra A2 laptop with an Intel 855GM graphics card. Every hour or so, X will gobble up 99% CPU time, and be completely frozen, and the computer must be rebooted remotely. The X log file contains
f000:5503: 01 ILLEGAL EXTENDED X86 OPCODE!
every time the lockup occurs.

I use i810 as the X module and i915 as the kernel module for the card. Everything worked perfectly fine in Feisty. No special program needs to be running for the lockup to occur, although it seems that stopping and starting the screensaver (non-3D, plain screensaver) can have some effect on bringing out the lockup.

Some Googling turned up similar bug reports, [1] and [2], which also describe a patch to hw/xfree86/int10.c in source package xorg-server. I've tried out the patch, but the lockup persists.

Version information:
Package xserver-xorg-core: 2:1.3.0.0.dfsg-12ubuntu8
Kernel: 2.6.22-14-generic

[1] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/146643
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404885#46

[indigo (indigo-sunrise)]

I have the same issue, on a Toshiba Satellite A55 laptop with an Intel 855GM graphics card. Also using i810 as the X module, and i915 for the kernel. I also have the same "f000:5503: 01 ILLEGAL EXTENDED X86 OPCODE!" line in the X log file. xserver-xorg-core and kernel are the same versions as above, too, 2:1.3.0.0.dfsg-12ubuntu8 and 2.6.22-14-generic. Upgraded to Gutsy (Xubuntu) two days ago.

I did a test this afternoon to see exactly how the screensaver brings it about. I turned it on, logged into Fluxbox, then let it sit. After 10 minutes, my plain black screensaver came up, then the screen appears to power down after another 10 minutes, like it has always done. I waited for about two hours after that, without giving it any input, and the screen remained off with no changes. After that, I moved the mouse around to get the screen back. 10 minutes went by, and it went to the screensaver. However, after another 10 minutes, instead of the screen shutting down, the screensaver deactivates and the lockup occurs.

So basically, it happens when it tries to power down the screen from the screensaver for the second time.

[Gard Spreemann (gspreemann)]

I have an strace of the event now. The whole strace is huge, but at one point this happens:

gettimeofday({1193220908, 897516}, NULL) = 0
gettimeofday({1193220908, 897569}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [IO])
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [IO])

Then the SIGALARM and sigreturn as above alternate with nothing inbetween them (about 20k times) until I kill X. Nowhere else does such a tight loop appear to occur in the strace log, so I reckon this is the point from which X gobbles 99% CPU and freezes.

[Gard Spreemann (gspreemann)]

Just as a note, this seems similar also to bug #61250 reported[1] on Dapper (but apparently solved in Edgy or Feisty).

[1] https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/61250

[Gard Spreemann (gspreemann)]

I have switched to the newer driver (simply called "intel", contained in xserver-xorg-video-intel), and this appears to have fixed the problem for me.

As a note to any 855GM users (and possibly others) switching to the intel driver, I recommend checking bug #157213 for a note on a problem one may encounter with this card and driver.

[Bryce Harrington (bryce)]

Thanks for reporting this bug. Since it sounds like it was with -i810 and resolved when switching to -intel, I'm moving it to the xserver-xorg-video-i810 package.

Since i810 is legacy and will go away in Hardy, the issue is extremely unlikely to be fixed, but this bug report may be of use to other -i810 users running into the problem. It's good to know switching to -intel will solve it.

[Timo Aaltonen (tjaalton)]

Fixed with the new driver, marking as such. People bumping into this issue will see this bug when reporting a new one, so it's safe to close it as fixed.