Bug 33868
Summary: | RFE: Use fbdev to improve system stability. | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Ed McKenzie <eem12> |
Component: | Xconfigurator | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED DUPLICATE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | Keywords: | 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
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. 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. 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. 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. :) 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. |