Bug 77935 - gnome-session hard locks system - maybe hardware related
Summary: gnome-session hard locks system - maybe hardware related
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-11-15 17:04 UTC by Mark Cornick
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-12-19 14:35:53 UTC

Attachments (Terms of Use)
output of strace running metacity in gnome-session (26.58 KB, text/plain)
2002-11-15 17:05 UTC, Mark Cornick
no flags Details
XF86Config (3.27 KB, text/plain)
2002-12-15 13:58 UTC, Mark Cornick
no flags Details
XFree86.0.log (29.60 KB, text/plain)
2002-12-15 13:59 UTC, Mark Cornick
no flags Details
messages (618 bytes, text/plain)
2002-12-15 13:59 UTC, Mark Cornick
no flags Details

Description Mark Cornick 2002-11-15 17:04:59 UTC
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.

Comment 1 Mark Cornick 2002-11-15 17:05:49 UTC
Created attachment 85206 [details]
output of strace running metacity in gnome-session

Comment 2 Havoc Pennington 2002-11-15 17:09:04 UTC
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).

Comment 3 Mark Cornick 2002-11-16 19:28:09 UTC
kernel-2.4.18-18.8.0 appears to fix this problem.

Comment 4 Mark Cornick 2002-11-17 02:04:09 UTC
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.

Comment 5 Mike A. Harris 2002-12-15 08:45:33 UTC
Attach your X config file, log file, and /var/log/messages to all XFree86
bug reports please.

Comment 6 Mark Cornick 2002-12-15 13:58:41 UTC
Created attachment 88740 [details]

Comment 7 Mark Cornick 2002-12-15 13:59:13 UTC
Created attachment 88741 [details]

Comment 8 Mark Cornick 2002-12-15 13:59:32 UTC
Created attachment 88742 [details]

Comment 9 Mark Cornick 2002-12-15 14:00:53 UTC
The log files you requested are attached. I am running XFree86-4.2.0-72 with

Comment 10 Mike A. Harris 2002-12-19 11:35:19 UTC
(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.

Comment 11 Mark Cornick 2002-12-19 14:35:53 UTC
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

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.

Comment 12 Mike A. Harris 2002-12-20 02:14:11 UTC
>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

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.

Comment 13 Mark Cornick 2003-03-20 21:10:56 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.