Red Hat Bugzilla – Bug 488395
Fedora 10 Randomly Freezes
Last modified: 2009-12-18 03:56:47 EST
+++ This bug was initially created as a clone of Bug #474948 +++
Created an attachment (id=325949)
Description of problem:
My Fedora 10 upgraded (from F9) installation on my Dell Precision 650 with ATI Technologies Radeon R300 NG (FireGL X1) graphics card freezes after about six hours. I thought this may be due to the kernel modesetting so I set nomodeset at the end of the line when I booted. (Even though I wondered about the problem given that I do not have the compiz installed. I have looked at /var/log/messages, /var/log/secure, no luck. I am running
% uname -a
Linux 22.214.171.124-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux
There are two CPU's Intel(R) Xeon(TM) CPU 3.06GHz
I have also tried setting up no rhgb at boot but still no luck.
My system is completely up to date: all components are updated to the latest released by Fedora.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot into system (with/without nomodeset, with/without rhgb)
The entire machine freezes after a long while. A hard boot (a la Windoze) is needed. The machine's fan is on at full speed after a while.
The machine should continue to work normally.
I am attaching Xorg.0.log as well as xorg.conf. These are obviously after the reboot (since I am frozen out). Please let me know what else I can provide.
--- Additional comment from firstname.lastname@example.org on 2008-12-05 19:23:28 EDT ---
Created an attachment (id=325950)
--- Additional comment from email@example.com on 2008-12-05 19:24:39 EDT ---
Please note that this appears different from the (similar) problem also reported: which seems to be that there is a problem introduced by kernel modesetting. Setting nomodeset seems to have ABSOLUTELY no effect.
--- Additional comment from firstname.lastname@example.org on 2008-12-07 11:28:55 EDT ---
Created an attachment (id=326045)
output from glxinfo
I have noticed that for me (running without rhgb quiet and with nomodeset), it does not freeze (after 40 hours) when i use xlock -mode blank. Based on someone's observation on the mailing list, it appears that glxgears may have something to do with it. So I am including the output of my glxinfo in hopes that it may be useful.
--- Additional comment from email@example.com on 2009-02-15 15:30:01 EDT ---
Same problem on a HP Pavilion Slimline with AMD Athlon 64 X2 and a NVIDIA GeForce 7300 (with third-party closed source Nvidia drivers from RPM fusion) computer just freezes randomly while working on it, and the power button is the only solution...
running without rhgb and with quiet nomodeset.
--- Additional comment from firstname.lastname@example.org on 2009-03-01 01:20:44 EDT ---
I am using a GeForce 9800GT and I am also getting random freezes, however only while xscreensaver is running.
I have the latest NVidia drivers 180.29 (64-bit) and an fully-updated machine. Is my issue unrelated, as the bug component is xorg-x11-drv-ati?
I have tested my memory and cannot find anything hardware related to be wrong with my machine.
Can you post some additional specific information about how this bug is manifested?
--- Additional comment from email@example.com on 2009-03-02 05:34:23 EDT ---
I refrained from using xscreensaver (used xlockmore instead) and my box is running stable for 1 day and 5 hours...
I am using xscreensaver-base-5.08-5.fc10.x86_64 ...
and NVidia 180.29 drivers.
I am becoming certain that this is an xscreensaver issue (at least for me). Please let me know if you need any specific information.
--- Additional comment from firstname.lastname@example.org on 2009-03-02 05:49:12 EDT ---
For me, I'm sure it is not a xscreensaver bug since its not installed and I experienced freezes while using firefox...
--- Additional comment from email@example.com on 2009-03-02 06:04:24 EDT ---
Unfortunately you are right.
My machine froze 10mins ago... I rushed the email it seems.
I would really appreciate for Redhat support to look at this. It is really unacceptable that the machine freezes using a "standard distribution".
I using an NVidia Card, so I am not even sure it's ATI related.
--- Additional comment from firstname.lastname@example.org on 2009-03-02 06:09:46 EDT ---
Why is the Priority of this bug Low Anyway?
A machine freeze is not a minor functional issue?
What is the workaround?
--- Additional comment from email@example.com on 2009-03-02 08:17:24 EDT ---
This thread is also related to this bug:
--- Additional comment from firstname.lastname@example.org on 2009-03-02 14:59:06 EDT ---
As a work around some try:
In the kernel command line (grub.conf)
But no definite work around known at the moment... af far as I know
--- Additional comment from email@example.com on 2009-03-02 16:24:47 EDT ---
I tried noapic, as suggested in the fedoraforum thread, however I still got the same behaviour, i.e. sporadic, random freezes, particularly while the system was idling.
I am now trying out acpi=off, as I suspected it was ACPI related.
I will report back about its behaviour.
--- Additional comment from firstname.lastname@example.org on 2009-03-03 12:01:24 EDT ---
acpi=off yields the same behavior.
I also updated my BIOS and my machine today to 126.96.36.199-170.2.35.fc10.x86_64
and I am still getting the same problem.
Is any maintainer interested in this problem or should we all just switch to Ubuntu/Gentoo, etc? (or even windows)...
Please let us know why this is taking so long and there are no signs of interest from the Fedora/Redhat Teams.
Some related threads which illustrate the # of affected users:
--- Additional comment from email@example.com on 2009-03-03 12:25:26 EDT ---
Same issue here on a Dell Vostro 1400. The noapic fix is maybe working, I've had only one freeze in 4 or 5 days, though I don't know if it was due to this issue or something different.
--- Additional comment from firstname.lastname@example.org on 2009-03-03 13:47:56 EDT ---
I agree with the frustration expressed by a previous poster: why is the priority so low for this important bug. It also appears strange that the assignee has never commented or asked for information: I wonder if he is even aware. That said, it appears that in my case, glxgears was the culprit. Getting rid of it (glx-utils rpm) has got rid of the problem for me. While not a great solution, it works for me for now.
I cloned Bug 474948 as the issue is NOT related to ATI but the Fedora 10 Kernel.
Basically, as stated above, the system freezes based on a hardware event, most likely ACPI/APIC event. Hard reboot is necessary, SYSRQ DOES NOT WORK.
Please let me know if you need more info.
CPU is: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 10)
00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port (rev 10)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
01:00.0 VGA compatible controller: nVidia Corporation GeForce 9800 GT (rev a2)
02:00.0 Ethernet controller: Attansic Technology Corp. L1e Gigabit Ethernet Adapter (rev b0)
04:01.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
I checked the differences in the F10 KERNEL COMPILE OPTIONS (standard .compile file under /usr/src/kernels) and I found one rather dubious option (which I have seen cause problems in the past):
$ diff 188.8.131.52-170.2.35.fc10.x86_64/.config 184.108.40.206-170.2.5.fc10.x86_64/.config
< # Linux kernel version: 220.127.116.11-170.2.35.fc10.x86_64
< # Mon Feb 23 12:58:10 2009
> # Linux kernel version: 18.104.22.168-170.2.5.fc10.x86_64
> # Wed Jan 21 01:31:56 2009
this comparison is between the current kernel version (on yum repos) and 2 kernels back.
Could this potentially be the issue?
Last but not least a temporary fix is to include
"noapic acpi=off" in the kernel command line.
None of those suggested fixes work for me. nomodeset, acpi, rgbh, etc etc.
Below is my thread with my problems, similar to everyone else but still waiting on a clear solution instead of temporary workarounds. I've included a jpg and the system error log text file in the posting so perhaps someone can help.
None of these have worked for me either. Kernel 22.214.171.124-117 is far worse than 126.96.36.199-170.2.35 fc10(x86_64). Updated my ati 2100 to most recent drivers via yum. I can reproduce the problem, and I've noticed in the past this has been a problem before. If I resize a window repeatedly without releasing the mouse button, when I release the mouse button, the PC freezes, but the cursor still moves about the screen, but the icon does not change. Only a hard boot gets me out.
Have you tried the latest kernel, i.e. 188.8.131.52-170.2.56.fc10.x86_64? Do you have the latest version of windows manager (KDE/gnome or whatever you use)?
Do you use any device drivers which may be buggy, e.g. madwifi? Have you tried whether the machine is stable using Generic VESA display driver? When the machine freezes can you logic using the network (ssh)? When the machine freezes can you reboot it using Kernel SysRq? Have a look at ttp://tldp.org/LDP/LGNET/issue81/vikas.html and try
echo "1" > /proc/sys/kernel/sysrq and when the machine freezes type
< Alt+SysRq > + s (sync),
< Alt+SysRq > + u (unmount),
< Alt+SysRq > + b (boot). If this works you know your kernel is alive and (almost) well.
Generally, try to narrow down the problem.
I used fedora 10 for a while just after the release and this bug was the reason why I went back to (k)ubuntu. I'm going to try fedora again when fedora 11 is released because I really liked it last time i tried. Lets hope the bug is gone in Leonidas.
If I remember correctly I didn't have to do a hard reboot, I just had to press the power button once and wait for it to do a normal shutdown. However, there was NO respond to ANY keyboard shortcuts (the caps lock lamp did not respond). Cursor did not freeze, nor did the music stop.
Hope this was helpful. I just searched for freeze bugs since ubuntu is now suffering from some random freezes and I wanted to make sure that they don't have to reinvent the wheel... My graphic card (intel gm965) is blacklisted for the moment because of this, so I'm unable ti enable desktop effects (since they seem to be causing the freezes).
(In reply to comment #7)
> have to reinvent the wheel... My graphic card (intel gm965) is blacklisted for
> the moment because of this, so I'm unable ti enable desktop effects (since they
> seem to be causing the freezes).
This card (I have it here on my notebook) is supported better in Fedora 11, but it should work (w/o Desktop Effects) in Fedora 10 as well (heck, it worked for me without much trouble since Fedora 7 ... well, and w/o Desktop Effects as well :)).
If you can find that Fedora 10 installation somewhere, please, file a new bug for xorg-x11-drv-i810 component and attach /etc/X11/xorg.conf (if any happens to exist) and /var/log/Xorg.0.log to the bug as separate uncompressed attachments.
Thank you very much
I've had three lockups since the last kernel 184.108.40.206-170.2.56.fc10.x86_64
all updates have been run on the system. I believe tow of my last three lockups were in citrix, while resizing a window within the citrix session (one outlook, one SSMS08). I have also had a lockup while resizing firefox with an flash page loaded. I am using the 64bit flash plugin, not the 32bit. I have always been able to ssh in to the machine and gracefully reboot. My sound (if I'm playing music in RhythmBox, always cuts off when I lockup. The cursor stops changing, but if free to move on the screen. I am happy to provide anything you need, I just may need some instructions on how to get it.
Created attachment 343246 [details]
dmesg output after system freezes
I can confirm similar behavior to comment #1. My laptop running f10 locks up about three times a week.
The display freezes, and none of the following keyboard combinations have any effect (ctrl-alt-f2, ctrl-alt-backspace, ctl-alt-delete, sysrq-B)
Environment: Fedora 10 (up to date) kernel 220.127.116.11-170.2.56.fc10.i686
Dell Latitude d620 dual-core T2300 @ 1.66GHz with Intel integrated graphics 945GM/GMS, 943/940GM
My lockup always occurs after an Xorg error; but it is a kernel issue, as I was able to ssh into my laptop from another machine and run dmesg. It shows:
EIP: [<f8e510e2>] i915_kernel_lost_context+0x16/0x6b [i915] SS:ESP 0068:f4dbbd4c
---[ end trace f077abd21d4f23b7 ]---
Fixing recursive fault but reboot is needed!
Attached is the full dmesg. output.
Same problem in Fedora 11 new release. I am at my wits end. Does anyone have a documented workaround?
Yes, I also encountered the problem in Fedora 11. As far as I know there is no workaround.
Should a new bug for Fedora 11 be filed?
Weird, I cannot ssh to a frozen computer. Ping works fine though.
Does killing X (init 3) unfreeze computer?
While I'm sorry to see that this is widespread, I'm glad to see that I'm not the only one.
I'm having the same issue on an updated F10 system running an AthlonXP 2500+, 2GB of RAM.
My system freezes in either runlevel 3 or runlevel 5...I've yet to see how long I can run the system in runlevel 1.
Some sort of fix/workaround would be appreciated.
To follow up, I left my system running for 2 weeks at runlevel 1. I applied all available updates, rebooted, allowed the system to come up to runlevel 5, and within 5 minutes, the system froze again.
I rebooted into runlevel 1, again, and the system has been up for nearly 24 hours with no issue.
I have also experienced the random freezes with Fedora 11, running kernel 18.104.22.168-217.2.3.fc11.x86_64 upon a system with a Gigabyte GA-MA790GP-UD4H motherboard, an integrated ATI Radeon HD3300, and an AMD Phenom II X4 CPU.
I don't know if this is of any help, but the freezing went from several times a day to a few times a week after changing the BIOS option for "OnChip SATA Type" from AHCI to Native IDE.
I'm having frequent random freezes too on a Asus P5G45 running 22.214.171.124-217.2.3.fc11.x86_64. No reaction to keyboard input or mouse clicks, only the mouse pointer follows movements. It is possible to ssh to the machine, but an init 3 does not shut down the X Server. I've tried the suggested workarounds without success.
As these freezes happen many times a day and the only way to make the system usable again for a short while is a restart, F11's Desktop is pretty useless for me. It is a pitty that this serious and widespread bug seems to get a low priority treatment only.
I placed a post here month ago, and also go no viable solution. I hate to add this comment in the Fedora forum. But the way I got around this problem was I downloaded Debian. It is stable and does not crash. I suggest you do the same and evaluate going back to Fedora when they get their act together.
I've seen similar sounding freezes under Fedora 11 with the following kernel, and those before: 126.96.36.199-217.2.7.fc11.i586. This is on a Dell Latitude D630 with intel graphics.
The symptoms are that the screen freezes, usually mid way through the rendering of some new window, except that the mouse pointer still works. The keyboard seems very dead, caps lock doesn't work, I can't switch to a console. Interestingly the system appears still to run as I usually listen to internet radio, and that continues playing normally (for minutes).
The only thing of interest that I can add is that the magic sys-req key (when previously enabled) seems to work. I have to first switch from raw mode, but can then get a working terminal via ctrl+alt+f2. Sadly I've not had a chance to collect any info of interest from the system in this state but will report back if I get some.
I suggest anyone seeing these hangs ensures "kernel.sysrq = 1" is set in /etc/sysctl.conf and keeps a printout of the magic keys handy. This may at least help classify any different types of freeze, and may allow collection of logs or more info.
So far I've seen this on every kernel upto kernel-188.8.131.52-217.2.16.fc11.i586. Still no useful info collected via magic sysreq though as the screen is staying stuck.
So far this is the closest issue I can find to match what I am experiencing in F10.
What I am looking for is if I should file a new bug for the following issue:
F10 - KDE desktop, installed from CD, fully updated
1) statically assigned address in use
2) Disable NetworkManager in services
3) use /etc/init.d/network to start/stop eth0
Anytime the network service is stopped, the network cable is unplugged, any connection loss to the outside at all causes the desktop to bog down real bad. It looks/behaves like it is frozen but really if you allow the operation like opening Dolphin several minutes it does eventually open.
As soon as the network link is re-established everything becomes real snappy again.
(In reply to comment #21)
> Anytime the network service is stopped, the network cable is unplugged, any
> connection loss to the outside at all causes the desktop to bog down real bad.
> It looks/behaves like it is frozen but really if you allow the operation like
> opening Dolphin several minutes it does eventually open.
> As soon as the network link is re-established everything becomes real snappy
Your problem has nothing to do with this bug.
Are you leaving nameservers configured in /etc/resolv.conf even when the network link is down?
>>Your problem has nothing to do with this bug.
Ok, I'll create a new bug. My apologies for polluting this bug.
>>Are you leaving nameservers configured in /etc/resolv.conf
>>even when the network link is down?
I've never had to monkey with resolv.conf so you may be on to something. I am doing nothing different than I have done since I began using Fedora long ago which is simply stopping the network link to block access to/from the outside world. I'll create a new bug and do some investigation around resolv.conf and post my findings there, thanks for the tip.
I've experienced this on machines recently upgraded to Fedora 11, most recently running 184.108.40.206-64.fc11.i686.PAE. I'm guessing it is the framebuffer locking up, as the machines don't respond to the keyboard or mouse and the display doesn't change even when I ssh in and kill X.
Any advice on what diagnostics I should run next time, given I can still ssh in and run stuff?
I'll attach the relevant bits of /var/log/messages.
Created attachment 366886 [details]
/var/log/messages extract from a display lockup
I have an Intel Based Motherboard D865 series with in built 512 MB of physical memory (RAM) and on board graphics Intel 82865 and FEDORA 11(installed via Live CD). My system just hangs when I am browsing the web using Firefox. Sometimes it hangs even i am using ssh in a terminal window. I updated my system with the latest updates, but still the system hangs. What should do? Thank You in advance.
The mouse pointer works!!
Here's one more bit of info. I am running RedHat Enterprise Linux in a lab of 6 Dell Optiplex 760. Nvidia video driver versions, 185.36 or 190.42.
The kernel is much older on these systems, it is 2.6.18. That makes me suspect the problem is not mainly in the kernel.
All systems are the same, updated daily against the same repository that I run.
Only 1 of these systems has the "frozen but still running" symptom. Neither the keyboard nor mouse clicks have any effect, but the mouse pointer does move on the screen AND I can log in with ssh and either reboot or "gdm-restart". gdm will restart and let me log in, no trouble. But as soon as I get some windows open, sometimes just a terminal, it freezes.
There is no trace of trouble at the end of dmesg or in Xorg.0.log or /var/log/messages. It is not a kernel panic, I believe.
I suspect it is a hardware problem, since it does not happen on the other systems. We had about 50 Dell systems 4 years ago and there was a flaw in a resistor (or was it capacitor) that gradually made the motherboard fail, and Dell would replace them, but they never broadcasted a recall or anything. Their rep told me it was cheaper for them to wait and see which ones actually fail. I suspected same here. However, I've run memtest86+ for hours, no problem. Dell consultants gave me a script that creates a bootable USB stick to run diagnostics. It says all is well.
I'm considering opening up the box and removing and reinserting all the cards.
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. 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 '10'.
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 10'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 10 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 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.