Re: Multi-seat X crashes

[Helge H. <hel...@ai...>]

Erik Walthinsen wrote:

>Hugo Vanwoerkom wrote:
>  
>
>>The reason for the textconsole is if the crash is a
>>kernel panic then that is where the last message will
>>show up.
>>    
>>
>Of course.  But if it's corrupted by the other heads, I'm not sure
>whether or not a panic message would even have showed up anyway.  OTOH
>kgdb should give me even better results, if/when it happens again.
>
>  
>
>>I am still not clear on what exactly dies. Is anything
>>still running?
>>When the crash occurs, everything is dead?
>>    
>>
>It varies.  The most extreme crash is where everything just locks
>exactly where it is, with some heads sleeping and others with a mouse on
>its way to some menu somewhere on the screen, whatever is going on.  In
>these cases the machine ceases to respond to pings, and I have to
>hard-reset the box.
>
>Other cases involve a single head going black, and even shutting down
>the CRTC completely.  Yesterday I was actively using one of the heads
>and it blanked out from underneath me, then the LCD switched to
>displaying "No Cable Attached"...  Thing is, the rest of the machine was
>working properly, to the point of the other heads going to sleep and
>waking up as expected, before I rebooted the machine later.
>  
>
This is probably the classic problem where an xserver mistakenly
thinks it has the "only" vga-compatible card in the box, and
tries reprogramming video timings using legacy vga hardware
addresses that might affect the wrong card.

A workaround:
make sure you set up all your xservers with at least two
different resolutions.  The user who got a blank display can
then tap ctrl+alt and  "+" or "-" on the numeric keypad,
and that xserver will reset its own resolution.  (If the
other resolution isn't wanted, just press the key combination
again to get back.)

The resolution is reset, and the display restored.

Another workaround:  Use only graphichs cards that
aren't backwards compatible with VGA - at all.  If
you can find such cards, that is.

Third workaround: Configure framebuffers in your kernel,
get a framebuffer for each and every screen.  Set sutiable
resolutions using kernel boot parameters for the framebuffer drivers.
Use the framebuffer xserver.  This one don't try to set the resolution,
it uses whatever resolution the framebuffer is set to. So problems
don't ever happen.  Of course this driver is unaccelerated, so your
cpu(s) are going to do all the rendering work.  Performance may
still be fine for simple 2D work like word processing and web browsing
and simple 2D games.  (I didn't notice any X performance difference between
accelerated and unaccelerated 2D X with a 400MHz celeron cpu
and two screens.) 

The correct fix:  complain to x.org developers.  Perhaps a fix will
materialize someday.  It certainly won't happen if nobody complains.

Helge Hafting