Description of problem:
I have had freezes 5-6 times since I use FC6. I never had this with FC5
Version-Release number of selected component (if applicable):
Steps to Reproduce:
( there is really no indication of what went wrong)
Can not move the mouse, can not restart X11 - nee to force shutdown
This is a ThinkPad T23 with 512 MB RAM and a DVD drive.
I tried to find anything in /var/log/messages to give me any hint what happened
- but I did not find any indications. :-(
Please attach output of dmesg and lspci, and /var/log/Xorg.0.log
Created attachment 139916 [details]
Created attachment 139917 [details]
Created attachment 139918 [details]
My T23 freeze with FC6 too :-(
Normally it did freeze 1x a day. Yesterday it froze 3 times in a row and then
ran for 4-5 hours no freeze and I could halt the notebook the standard way. I
have not yet found any pattern when it freezes.
I am install kernel-2.6.18-1.2835.fc6 (from testing) and
xorg-x11-drv-savage-2.1.1-5 with patch
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851. And my T23 is 6
My Thinkpad T30 freezes every session. Essentially FC6 is rendering my laptop
unusable. I really like the enhancements as compared to FC5, but I need a stable
OS. :( Please let me know if I can help or provide information to assist in any
way. Unfortunately I did not know exactly how Rudolph is buidling the fixes. I
gathered from the patches he must be merging the source changes and rebuilding.
Is this bug somewhere in the X video drivers?
Just had another freeze while trying to install kde via pirut. I have been
unable to create a duplicatable set of conditions. I can usually plan on a
freeze if I have more than one task running, e.g., updating via pirut, surfing
web via firefox at the same time.
Just found this; however, thread does not indicate a solution. My freeze ups
appear to occur when installing RPMs.
What would be the best method to test the file system for corruption? (Or is
this a "red herring"?)
This ThinkPad freeze is apparently (don't want to jump to conclusions, but..) is
caused by ATI Mobility Radeon 7500 (and other Mobility varients) driver bug.
Perusing the Ubuntu forums produced this finding:
Apparently the bug is fixed for Ubuntu. When will FC6 get this fix?
My ThinkPad T23 freeze is caused savage bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851. My T23 is 9
day stable ...
I am encountering the same problem too, kind of randomly....
- click on a link on firefox
- a email notification popup by gaim
I suspect Pango problem earlier, but the problem persist after I disable it.
I hope it is really a ATI driver bug, and I am willing to help testing fix.
Well as it is also in Savage driver it either is something those drivers have in
common or it is something different. But maybe these are really two bugs. We
will see if one part of us gets a relieve.
BTW, how do I apply the patch and rebuild the xorg-x11-ati driver? Is there an
instruction for it? I never tried apply patch top to a src rpm and rebuild (done
some striaght src rebuild...) or even better if someone can provide a rpm with
the patch. I can test for it.
just update a new version of xorg-x11-ati pushed out from pirut (thanx, BTW!). I
will report back if I still see this problem.
hi, would like to come back and report the problem on my T30 seem to be fixed
now. I tried to push as hard as I can for the past 2 days and no longer seeing
- surfing web, clicking on links after links
- run firefox, talk on skype on the same time
- run rhythmbox
These cases were trigger the crash in the past.
If the latest updates in xorg should have solved the problems I can not see any
solution on my T23 (Savage Graphics).
IBM T23 owner as well. Clean installation of FC6.
With kernel-2.6.18-1.2798.fc6, I would get a very infrequent system freeze.
Normally if I asked the disk I/O to over-exert itself by trying to do too many
disk intensive activities at once.
With kernel-2.6.18-1.2849.fc6, guaranteed to freeze the system with the
slightest amount of heavy disk I/O. For example, launching into KDE, or from a
virtual console running yum update and have it install updates. System is hung
so badly that not even Alt-SysRq-S, U, B will respond. (Yes, I did enable it.)
Any further information you require or any tests you would like me to perform, I
will be happy to oblige.
I think I hvae got a workaround. I now had put "acpi=off" at boot load
(/boot/grub/grub.conf ) and did not have a crash today. Not sure if this is the
reason why, so. But maybe others that continue to have this problem might check
this out? Maybe this also helps developers to find the root cause?
I have had one other crash yesterday. But this is a lot less frequent. So no
My Thinkpad T23 is 100% stable - zero freeze - with patch
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851 .... from November
I have the originally reported freeze problems too, ThinkPad R52,
01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Radeon Mobility M300]
I haven't found a FC6 kernel/Xorg version yet which is stable for me. Lockups
occur after few minutes to few hours (more likely "few minutes"). Even when not
actually working with the laptop. I wasn't able to reproduce lockups without
X11, so I guess it's an X.org and/or ATI driver bug.
Basically, I'm stuck at FC4...
I can now confirm that only X.org locks up, not the kernel. I can still log on
to my laptop via SSH and do find the X process like this:
root 3237 98.2 1.7 23456 17712 tty7 Rs+ 14:17 197:12 /usr/bin/Xorg
:0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7
Trying to kill -9 X.org leads to:
root 3237 98.2 0.0 0 0 ? Rs 14:17 197:26 [Xorg]
Let me know which kind of information I should collect when such a lock-up happens.
Problem still there with Fedora 7 i386 Live-CD - so a completely vanilla
If it is any help, there is an issue with F7 freezing and I have been following
threads on different sites. I am having a freeze and changing the video driver
changes the issue of freezes, but it still happens. Now what is interesting is
my Xorg goes to 98 % as well.
Now, on the Nvidia forums, this issue is common as well. One poster tried a
different kernel and since has had no freeze ups. It may be related and may
point to the problem so I thought I would share it.
Copy and Paste.
As soon as I got to thinking this might be the problem I compiled two kernels
identically with just a difference in schedulers, One with the commonly used cfq
and the other with the old default anticipatory. The cfq kernel definitely
freezes if left alone, return from screensavers and either no return to desktop
or mouse movement with frozen screen, the anticipatory since yesterday afternoon
does not, absolutely not a single freeze or delay.
Now, as a test I found that a short movie and played with mplayer. Change the
speed with } a couple of times and all keyboard input is gone. When the video
ends, all is back to normal. Maybe someone else can try this as well.
I hope this points in the correct direction.
Hope this may help. I've duplicated this bug for RHEL5 on a ThinkPad T60p ( Bug
#213227 ). Following are my tests:
1. kernel-2.6.18-8.1.3.el5, ATi driver 8.36.5-x86, FREEZE about once a day
2. kernel-2.6.18-8.1.4.el5, ATi driver 8.36.5-x86, NO-FREEZE
3. kernel-2.6.18-8.1.6.el5, ATi driver 8.36.5-x86, FREEZE about once a day
4. kernel-2.6.18-8.1.6.el5, ATi driver 8.35.5-x86, NO-FREEZE yet
To add some updates.
Now I have had freeze ups with both nvidia and ATI boards. Nvidia required the
nvidia drivers to actually freeze. Xorg would increase using the stock nv
driver but not freeze.
Today with my fully updated FC6 machine, it froze solid. Needed a power cycle
to continue operating. SSH into the machine and Xorg was over 95%. Tried to
strace it only to have the system fully freeze.
Changed the nvidia system Video card from at 5600 to 7600 and I cannot see any
issues. No loading issues or graphic distortions since installing it.
Those freezes still happen with F8. As I mentioned in Comment #25, it already
happens with the Live CD, so it has absolutely nothing to do with anything "custom".
I now managed to log in via SSH and catch dmesg output which happens when the
laptop locks up:
Nov 16 21:09:09 thinko kernel: Uhhuh. NMI received for unknown reason a0 on CPU 0.
Nov 16 21:09:09 thinko kernel: You have some hardware problem, likely on the PCI
Nov 16 21:09:09 thinko kernel: Dazed and confused, but trying to continue
Nothing related in Xorg.0.log. X.org is as usual at nearly 100% CPU:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2386 root 20 0 170m 20m 9m R 99.2 2.0 26:19.09 X
[root@thinko ~]# strace -p 2386
Process 2386 attached - interrupt to quit
--- SIGALRM (Alarm clock) @ 0 (0) ---
<no further output>
When I change to initlevel 3 (without X11), I do not experience lock-ups (tested
over a full week 24/7). So it seems like there is something in X11 which
triggers the NMI problem.
A lot of Ubuntu users are complaining as well:
I do currently have a locked-up laptop sitting here and can extract any info
you like via SSH... just tell me what you need.
FC4 was the last version not locking up (I was trying FC6, F7 and F8 to migrate
to, but all fail), so I'm still booting the FC4 installation :-Z
And I have the impression that glmatrix screensaver is a pretty good trigger for
the problem. It certainly raises the probability.
You might want to take a look at:
as well as the lockups section. Any of that information would be extremely
useful. If you are able to ssh in when it is hung then info from:
dmesg | tail
would also be helpful.
I guess this problem maybe related to system overheat, especially on some
ThinkPad models with ATI graphics cards that the chip is located very near to
CPU and north bridge. That's why some graphical intensive programs would trigger
the freeze. Some guys at ThinkPad service center told me that replace the fan
may reduce the possibility of this problem.
But this is only my guess (I'm using a ThinkPad T60p that suffers this problem,
and I've requested the service center to replace my fan). Your miles may vary.
You can monitor your ThinkPad's temperature by:
$ cat /proc/acpi/ibm/thermal
temperatures: 57 46 33 58 30 -128 25 -128 45 47 46 -128 -128 -128 -128 -128
The first 5 numbers are temperature of various parts in degree centigrade. If
there's any parts over 70, you may have the problem.
My Thinkpad T60 with Intel 950 video sometimes locks up when it gets really hot.
Using it on top a thick wooden desk is enough to make it overheat after a few
hours. I wish I bought an X series... =)
The NMI lockups are easily reproducible with screensavers like GLMatrix and
Flux. Thermal values were below 60° while lockups happened (left a "watch -n 1
cat /proc/acpi/ibm/thermal" running in a SSH session to the Thinkpad while
playing with screensaver preview).
Booting with nmi_watchdog=2 didn't lead to a backtrace. Actually it even
prevented the reporting of the NMI which works without nmi_watchdog=2, see my
The lock-ups now happen without the NMI bleep sound. Using magic SysRq, I can
get a call trace on on the locked-up X server process:
[<f8aacdce>] drm_lock_take+0x14/0x9a [drm]
[<f8aad0d4>] drm_lock+0x155/0x2b1 [drm]
[<f8aacf7f>] drm_lock+0x0/0x2b1 [drm]
[<f8aab841>] drm_ioctl+0x1b5/0x240 [drm]
I am getting the same messages on Dell Latitude 810.
Feb 9 23:04:45 kernel: Uhhuh. NMI received for unknown reason b0 on C
Feb 9 23:04:45 kernel: You have some hardware problem, likely on the
Feb 9 23:04:45 kernel: Dazed and confused, but trying to continue
My laptop hang and needs to be hard rebooted.
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.