[gentoo-amd64] Re: X crashing so oftenly

[Duncan]

jai kumar <jaikumar1004_in@××××××××.in> posted
20060808150529.47884.qmail@×××××××××××××××××××××.com, excerpted below, on 
Tue, 08 Aug 2006 16:05:28 +0100:

> sometimes while doing
>  "ctrl+alt+f1(for teminal tty0)"  my X server crash down and restart
>  again. I did google for the same but didn't find any matching answer.

I won't attempt a direct troubleshoot as my hardware is rather different,
but FWIW here's some generally related info.

Due to the nature of video hardware and how it interacts with the kernel
and X, it's really a wonder that VT-switching works at all, in most cases,
so it's not a wonder that it would be unstable at times.

The kernel has one set of video drivers, normally tho not always simply
text-mode console drivers, with DRM/DRI drivers to facilitate video memory
access for some video chips (and used in X mode, not the CLI), while X has
another set. Because xorg is designed not just for Linux, but to be run on
other *ix as well, it must maintain a measure of separation from the Linux
kernel, all the while trying to drive video as efficiently as possible. 
In effect, while in X, X controls the video with its own video drivers and
with help from the kernel's DRI/DRM, but with the kernel's console mode
video drivers essentially disabled.  Switching between X and a text mode
VT then becomes an /incredibly/ complex job whereby the X drivers must
suspend all their super-efficient direct video memory access and other
fancy stuff, and the kernel must reactivate its text mode drivers.  It's
technically one of the most complex operations the computer is called upon
to do, involving extremely delicate timing issues subject to all sorts of
race conditions and two different software packages, xorg and the kernel,
both extremely complex on their own and evolving independently of each
other, plus various combinations of hardware, various pieces of which have
their own bugs and idiosyncrasies which must be worked around or risk
triggering a crash.  Even worse, because of the nature of the hardware
involved, unlike the situation with most user space applications, when X
crashes, there's a real chance of taking down the kernel with it, or at
least corrupting the video subsystem such that the only way to work with
the system is entirely blind, or remotely, even when the kernel does
remain responsive.

As I said, it's /really/ a wonder that it works at all, even more so that
it can be made trouble-free enough in most instances to actually be
usable, and to cause complaints when it does /not/ work reliably.

This doesn't pertain directly to your issue, but the solution should.
Sometime in the early xorg series, I believe about xorg 6.8, the first
release with new code after the transfer from xfree, it became impossible
with my Radeon to switch to VT at all -- it would /always/ hang,
corrupting video to the point where the system was unusable (I have only
one system, so remote access is out of the question).  I could shut down X
safely, work in the VTs as desired, and restart X, but I couldn't switch
to other VTs while X remained running, without a crash.  I had to get used
to either shutting down X, or working from a terminal window (konsole, in
my case), avoiding the VT switch from X.  The next release fixed the
problem, and I was again able to use VTs at will, but it was during that
episode that I read up on things enough to understand the issues, as laid
out above.

In the immediate term, it's possible/likely you'll have to work with a
similar workaround, using terminal windows or shutting down X, not trying
the VTs with X running.  It's inconvenient, but once you retrain yourself
not to hit the VT-switch keys, workable.

Meanwhile, another solution that may or may not work for you, and if it
works, may or may not be something you can live with.  The kernel also has
graphics mode framebuffer video drivers.  These can give you a higher
resolution in your VTs, 1024x768, 1280x1024, even higher, and are thus
often favored by those preferring to work in a CLI most of the time. 
When these are used in CLI mode, one doesn't use the regular X drivers for
their hardware, but instead, the framebuffer drivers.  Most of the time,
this means less efficient acceleration in X mode, particularly 3D/OpenGL,
but depending on the specific framebuffer driver and hardware used, some
acceleration is possible, so you aren't forced into unaccelerated
compatibility mode, at least.  I've never used this mode so can't go into
much detail on it, but from my understanding, it means you use the same
resolution in both CLI/VT and X modes, and therefore, that
resolution-switching in X is disabled -- you have just the single
resolution to work with.  Whether the lower level of acceleration and
single resolution limitation are acceptable to you or not I can't say, but
it /should/ eliminate the VT switching issue, because it's then the kernel
driver in direct control even within X -- aside from a few simple
optimizations possible at the framebuffer level, all the X driver does is
forward the video stuff to the kernel framebuffer driver, thus avoiding
the complexities of handing off control of the video hardware when
switching.  

We're actually fairly lucky on Linux and amd64, as for some
hardware/OS platforms, the framebuffer drivers are all that X supports. 
(From what I've read, X's drivers for the Radeon video hardware commonly
found in Apple's PowerPC arch are of this nature, framebuffer driver
support only.)

Back when the X/VT switch wasn't working for me, I contemplated going
framebuffer, particularly as I would have enjoyed the higher CLI/VT
resolution and don't do all that much 3D/OpenGL stuff (I'm not a big
gamer, the biggest driver of demand in the area), but two things put me
off from trying.  One, I DO use X's resolution switching fairly
frequently, and didn't want to lose that.  Two, the inconvenience of
reading up on and learning to configure both the kernel and X's
framebuffer drivers, along with the possibility that they didn't support
dual monitors at all.  I don't know if that's supported by the framebuffer
drivers or not, but that would certainly make the configuration more
complex, and I had no intention of giving up my dual 21" monitors,
1600x1200 stacked for 1600x2400 total resolution, just to get working VT
switching back. Together, those factors were enough to discourage me from
pursuing the idea any further, but it might be something you'd find easier
to live with.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list