Bug 33868

Summary: RFE: Use fbdev to improve system stability.
Product: [Retired] Red Hat Linux Reporter: Ed McKenzie <eem12>
Component: XconfiguratorAssignee: Mike A. Harris <mharris>
Status: CLOSED DUPLICATE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-05-17 20:42:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ed McKenzie 2001-03-29 15:13:01 UTC
System stability can be increased considerably by having XFree86 (4.0) use
fbdev to control the video display on cards which have fbdev support in the
kernel. Setting this up by hand is trivial; just add "alias fb0
matroxfb_base" to modules.conf, and add the options "UseFBDev" and
"NoHWCursor" to the Device section in XF86Config-4. However, it'd be nice
if anaconda/Xconfigurator did this by default.

Rationale: Bugginess in DRI illustrates nicely how unstable the graphics
system under Linux is. A DRI lockup doesn't crash the machine, but it
trashes the console so that it might as well have. Using fbdev, the state
of the console is stored in the kernel, not in userland, and the console
can be restored remotely after a DRI blowup. Ideally, there would be some
sort of way to recover locally, but I suppose remote is better than not at
all. A patch is floating around on xfree-xpert that adds a client-kill key
sequence, which might be useful here.

Comment 1 Mike A. Harris 2001-03-29 16:12:24 UTC
Many people use DRI and have no problems at all.  It seems to be very
card dependant.  It also seems to depend on what type of RAM a card has,
what AGP mode you're using, as well as some other factors.  Personally,
I think the correct thing to do is to fix the XFree86 drivers, but this
doesn't happen overnight obviously.  Reassigning to Xconfigurator.

Comment 2 Ed McKenzie 2001-03-29 17:15:43 UTC
Other, non-DRI ways to crash X and trash the console on various video cards I've
owned (not that there aren't lots of 3d-related crash scenarios):

1. Go OOM with *
2. Run XMMS in DGA mode.
3. Run Netscape for long periods of time.
4. Switch VT's under load.
5. Run multiple instances of X, and occasionally switch between them. Add a dash
of system load to taste, or until well frozen
6. Set up gdm to launch logins on two separate VT's.

... and so on. I don't think _all_ of these will necessarily ever be fixed.
There will always be new features in X, and there will definitely be more
interesting ways to blow it up in the future. IMO, the problem is architectural
-- overall system stability shouldn't be compromised by the failure of a single
userland application. The kernel is the resource manager; Linux should not be
MS-DOS.

Anyway, as far as DRI issues go: with the suggested setup, DRI still locks up,
but the console can be recovered with a killall -9 X. Sure, DRI doesn't work at
all after that, but I think it's better for drivers to malfunction in a
contained way. MHO, of course. No downtime for the webserver, and I have the
_option_ of rebooting if I want functional DRI again. The only negative is that
matroxfb conflicts with the hardware cursor, but that's apparently being worked on.

Comment 3 Mike A. Harris 2001-03-29 23:30:17 UTC
What any of the last comment has to do with your feature request
is beyond me.  It's more of a rant than a constructive request, and I
think that rant would be best on xpert where the people
who make the bits are listening.  We package XFree86, we don't make
it.

Issue #1 has nothing to do with X at all, it is kernel memory overcommit.
If you want to change that, read "man ulimit" and use ulimit on rogue
applications. Same for #3 above.

Each single buggy behaviour you experience should be filed in a separate
bug report (one bug per report) in bugzilla and/or to the XFree86 team
as well.  If a bug isn't in bugzilla, it isn't a bug.


Comment 4 Ed McKenzie 2001-03-30 00:56:05 UTC
Sorry for the tone, but IMO X (and, by association, Linux) wouldn't have such 
a bad rep among new users if XFree86 were, well, bug-free. The world isn't an 
ideal place, but there are other ways to keep XFree86 from rendering the 
system unusable. While experts can figure it out with some work, I think 
Xconfigurator should set things up so the system is more stable 
out-of-the-box. My three cents. :)


Comment 5 Mike A. Harris 2001-03-31 06:55:28 UTC
There isn't a piece of software ever written that was bug free.
While I agree it would be nice, it is not realistic to expect.
Xconfigurator does do some of what you request, however we are not
aware of all of the plethora of various bad config option permutations.
it would be a very complex project to implement a matrix of option
combinations that work/dont work with each other in X configurator.
That doesn't mean it cannot be done, but it is something that will
take time to do if it is deemed worthwhile.  IMHO, X should stop
people from using bad combinations of things instead of the config
program being kludged all the time.

Remember though that XFree86 4 is very very new, and it will stabilize
and smooth out greatly over time IMHO.

Comment 6 Mike A. Harris 2001-08-01 04:10:01 UTC

*** This bug has been marked as a duplicate of 35474 ***