Bug#272060: i810: Unexplained server lockup
> Error in I830WaitLpRing(), now is 1418444325, start is 1418442324
> pgetbl_ctl: 0x3ffe0001 pgetbl_err: 0x29
> ipeir: 0 iphdr: 1810000
> LP ring tail: ff48 head: f4c4 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: 0
> space: 128372 wanted 131064
>
> FatalError re-entered, aborting
> lockup
Although this bug is way old, I get something with a similar signature
in xserver-xorg-video-i810 2:1.7.2-3, even *after* applying the lockup
patches 10-overlay_fix_lockup.patch and 11-xv_lockup.patch.
In my case the problem seems to be quite reliably reproducible (though
still random - you have to wait for it): it only occurs after S3 suspend.
My video card is "Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)".
After S3 suspend (from script):
cat /proc/bus/pci/00/02.0 > /var/cache/vidpci.config
sync
sleep 2
echo -n mem > /sys/power/state
cat /var/cache/vidpci.config > /proc/bus/pci/00/02.0
the computer restores to a correctly drawn screen with an invisible
mouse pointer, which is restored after going to console and returning
back to X (see bug #390913).
Also after S3 resume, glx programs such as glxgears, penguin racer,
show a blank screen, though no error is given.
These seems to be associated symptoms. At some after this resume, the
lockup will inevitably occur (I think an xscreensaver screensaver
triggers it).
Annoying that S3 suspend/resume is so close to fully operational, yet
is still essentially unusable! My workaround is to use S4
suspend-to-disk instead (e.g. Gnome's power management applet with
hibernation, or use s2disk from uswsusp).
Drew
Reply to: