I'm filing this under gnome-session because I'm reasonably sure that's where the problem is occuring, but I'm not positive (read on) I have a fresh Red Hat 8.0 install, with all updates as of yesterday applied. My system is an AMD Duron 850 (running the athlon kernel variant) with 512MB of RAM and an ATI Radeon VE video card. Starting GNOME on this system puts up the splash screen (without any icons), then locks it hard - so hard that the mouse pointer no longer moves. At that point a powercycle is the only option. The same happens if I disable gdm, log in on the console, and use startx to start GNOME. KDE is not affected. This is 100% reproducible, although the session sometimes runs longer than others before locking. The only real clue I've been able to get is by modifying the default GNOME session to run all the clients through strace. metacity is the only client that manages to get started before the system locks. I can't tell from the strace if anything metacity is doing is the culprit - everything in the strace looks pretty reasonable to me. I'll attach the strace output to this bug. RH 8.0 GNOME works fine on another system of mine with an entirely different processor (Intel Pentium III) and an entirely different, *known buggy* video chipset (Intel i830), which is why I'm thinking either the AMD processor or the Radeon video card is to blame here. I don't have any other hardware to try with this system, though.
Created attachment 85206 [details] output of strace running metacity in gnome-session
Hard system locks are always X or kernel bugs (by definition the X/kernel system is supposed to be robust against anything an app can do).
kernel-2.4.18-18.8.0 appears to fix this problem.
I appear to have spoken too soon. The new kernel fixed the problem *once* - when the system was rebooted, the problem described above returned, same as before.
Attach your X config file, log file, and /var/log/messages to all XFree86 bug reports please.
Created attachment 88740 [details] XF86Config
Created attachment 88741 [details] XFree86.0.log
Created attachment 88742 [details] messages
The log files you requested are attached. I am running XFree86-4.2.0-72 with kernel-2.4.18-18.8.0-athlon.
(II) PCI: 01:00:0: chip 1002,5159 card 1787,0202 rev 00 class 03,00,00 hdr 00 This is a "Powered by ATI" board, and not a "Built by ATI" board. There are known reported issues with clone Radeon boards, and no known solutions. Your /var/log/messages was only 5 lines long and rather useless. Please attach the whole file, and any logrotated versions that go back at least as far as the last boot or earlier please.
The 5 "rather useless" lines of /var/log/messages represent the entire relevant system log output relating to this issue. Any other log information has already been purged per my log-retention policy and I do not intend to hard-lock this machine to provide you with additional irrelevant log information, given your attitude. Since it's apparent that you don't intend to actually do anything about this (after all, I did have to personally bug a personal friend in Red Hat QA to even get the appearance of interest after the bug sat unacknowledged for almost a month), I am marking it WONTFIX and will consider it abandoned. This should, I trust, relieve you of any further responsibility for diagnosing this problem with my hardware, which has successfully run three prior versions of Red Hat Linux, as well as other Linux distributions' builds of XFree86 4.2.0. I apologize for wasting your time by filing a showstopper bug; I will in the future consider it my responsibility to not file "rather useless" bug reports when a Red Hat product hard-locks my system. In seven years of being a Red Hat customer I have generally found the developers to be quite helpful, but it is apparent that I should no longer disturb developers with reports of standard system components causing major, unrecoverable system failures. I shall not do so in the future. Merry Christmas.
>The 5 "rather useless" lines of /var/log/messages represent the entire relevant >system log output relating to this issue. Any other log information has already >been purged per my log-retention policy and I do not intend to hard-lock this >machine to provide you with additional irrelevant log information, given your >attitude. In no way is there any "attitude" present in what I've said. You posted a 5 line log file of which contains no useful information about the kernel or anything else. I did not ask you to grep through the log or skim through it and pull out parts of it that you thought might be useful or relevant to troubleshooting the problem. I asked you to attach the log file itself, and I wanted all information since the last boot at least. Of course one is free to strip any private information that would jeopardize security, or divulge too much private info, however a full log was requested, and that is what is needed. If I need to justify the detailed reasons for requesting additional information to each and every bug reporter, then I end up wasting my time. I need to know information about the kernel running on this machine, in order to be able to determine any possible kernel related interactions/problems with your machine. If you are unwilling to provide that information, then solving this problem and are going to get upset with me about it then that is your choice. As it stands, this "problem" does not really seem that important to you. Those 5 lines do not at all in any way represent any sort of information that I am looking for. Concerning a bug being reported and not updated for a while, I am one single developer in charge of all bugs reported against XFree86 and 30+ other packages. In addition to dealing with bug reports, I also have a job to do, and it isn't reading bug reports all day long every day. When a bug is reported, it almost certainly will not get fixed tomorrow, and maybe not next week or next month either. The point of reporting a bug, is to let someone know that there is a problem, and to track that problem. Bugzilla is a Red Hat developer's tool - not a tool for the community to nag developers and kick them into fixing problems. We believe however that allowing the community to have access to bugzilla benefits both sides much more than having a private bug tracker like some other distributions do. Anyone reporting a bug however, and expecting 24 hour response turnaround and resolution is seriously expecting the wrong thing. I would need to clone myself 300 times just to be able to respond to the incoming bug reports within 24 hours. People getting frustrated and going off about not getting a response immediately do not help anything either. Don't bother reporting bugs in bugzilla unless you're also willing to work along with developers to find a solution to the problem, and also willing to wait until the problems you have reported have come around the queue. That might be a day, a week, a month or longer, and is heavily dependant on developers other priorities, tasks, and other bugs that have been reported. One must also be willing to provide information that is requested by a developer in order to help troubleshoot problems, and without asking 20 questions to demand why. Otherwise, bug reports like this do indeed waste both parties time. I hope this clarifies any issues. On the other hand, if you are willing to provide information and work with us, then we are here willing to do the same.
FWIW, this issue no longer occurs in the Phoebe beta. The issue really is fixed now. Thank you. (Really. I mean that.) I have other thoughts about the way this bug was handled, but this is not the place to discuss them.