Xorg (i810) freezes randomly when using hardware accel

[Markus Hoenicka]

Oliver Fromme writes:
 >  > Section "Device"
 >  >     Identifier  "truei810"
 >  >     Driver      "i810"
 >  >     VideoRam    131072
 >  >     # Insert Clocks lines here if appropriate
 >  > EndSection
 > 
 > I think you should _not_ override the VideoRam.  Let it
 > autodetect the amount of video RAM. 
 > 

I was under the impression that there is no autodetection in the case
of shared video ram. In any case, using a different VideoRam setting
or none at all does not change the problem.

Googling for the Xorg error message gave a few hits, e.g.

https://launchpad.net/distros/ubuntu/+source/xserver-xorg-video-i810/+bug/22741

which makes me think this is not a FreeBSD-specific problem. Moreover,
it is likely to get fixed in a new release.

So what I'd like to focus on is how I can get my console back after X
got stuck.

 >  > No. It doesn't show up in the process list, so I assume it exits with an error
 >  > right away.
 > 
 > You assume?  I'm pretty sure there _must_ be something in
 > the logs, or an error message on stdout/stderr when you try
 > to start the X server.  (BTW, how do you start it?)
 > 

I tried both ways you suggested:

1) run startx blindly. The login test told me that the box still
listens to keypresses, so I assumed this might work

2) log in via ssh and run startx </dev/ttyv0 

I assume that the duplicate "Error in I830WaitLpRing" entry in
Xorg.0.log is all I get. As I told previously, the screen is still in
graphics mode, so whatever shows up on stdout or stderr is lost on me.

 > You mentioned that you run FreeBSD 6.1.  Does that mean
 > 6.1-RELEASE?  If yes, you should consider updating to
 > RELENG_6 ("6-stable"), which is currently in code freeze
 > for the 6.2 release cycle.  I'm running it on my notebook,
 > too.
 > 

FreeBSD yeti.mininet 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Mon Aug 28
22:24:48 CEST 2006
markus at yeti.mininet:/usr/src/sys/i386/compile/YETI  i386


 > Did you try the VESA mode suggestion?  What happened?  It
 > should either reset the screen mode, or print an error
 > message (if VESA isn't supported).
 > 
I tried the vidcontrol stuff without X. Setting 80x25 or VGA_80x25
does work, whereas VESA_132x25 causes an error message saying VESA is
not supported.

However, if I try one of these suggestions after X froze (either
blindly or through ssh) the screen is not affected except that it
sometime goes from all white to all black.

regards,
Markus

-- 
Markus Hoenicka
markus.hoenicka at cats.de
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de