Bug 77935
Summary: | gnome-session hard locks system - maybe hardware related | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Mark Cornick <mark> | ||||||||||
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> | ||||||||||
Status: | CLOSED WONTFIX | QA Contact: | |||||||||||
Severity: | high | Docs Contact: | |||||||||||
Priority: | high | ||||||||||||
Version: | 8.0 | ||||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | i386 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2002-12-19 14:35:53 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: | |||||||||||||
Attachments: |
|
Description
Mark Cornick
2002-11-15 17:04:59 UTC
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. |