Description of problem:
Kernel 2.6.11-1.14_FC3 hangs with no errors on-screen or in /var/log/messages.
Version-Release number of selected component (if applicable):
Every few days or perhaps as often as once a day.
Steps to Reproduce:
1. update FC3 to Kernel 2.6.11-1.14_FC3
2. wait for lockup
Please see the thread starting at:
where several people have described the same (or a very similar) problem.
The symptoms are very real and hopefully someone will come forward with
some helpful debugging info or tips to track down the cause(s).
The systems that have crashed for me with the 2.6.11-1.14_FC3 kernel are a
ThinkPad T42p (model 2373-HTU) and a generic Athlon system built on an Asus
A7V600 motherboard. The chashes were both complete lockups and neither of the
systems were reachable through SSH connections. Both systems were running the
unmodified FC3 kernel and there were no 3rd-party kernel modules installed (for
instance, both are running the standard, updated FC3 Xorg RPMs and not any of
gthe ATi or nVidia drivers).
And in contrast, the 2.6.10-1.770_FC3 kernel has been completely stable for me.
Something's very wrong with this kernel version. See bug #145258 for an instance
where ntpd is killed suddenly. Also I've seen weird Postfix issues, but I cannot
tell for sure whether they're linked to this kernel or not (I only looked at the
logs _after_ upgrading to the new kernel, and i cannot re-test now).
Maybe a devel version of the kernel tree must be branched off after all... ;-)
Actually I'm experiencing the lockups (generic Athlon system) simply waiting for
some time (a few hours) or, simply plugging in two USB mass storage devices at
the same time. I can't keep on this, reverting kernel to 2.6.10-1.770_FC3.
I am also experiencing lockups with this kernel. In addition to updating the
kernel, at about the same time I started using the "owner" module in iptables
with syntax like "... -m owner --cmd-owner .....". Naturally I initially tended
to blame the "owner" module in iptables.
After backdating my firewall, the kernel has been more stable (no lockups for a
few days now).
I've tried to investigate as a prelude to making an intelligent bug report but
the issue is so random I've not been able to gather reliable data.
Also no hint of trouble in the log files.
But.... on at least one lock-up, I could ping the box even though I could not
telnet in, ssh in, or get a responce from the web server. So while the box
appeared to be dead, the IP stack was still working, at least for a while.
Comment #3 sounds a lot like #155472.
Ed, are you using usb keys?
Hi Sitsofe, yes I was using USB keys sporadically back when the crashes
occurred. I don't remember using the USB key often or at exactly the
same time that the crashes happened but yes I was occasionally using a
Also, I've stopped using 2.6.11-1.14_FC3 because the hangs were simply too
disruptive. I've reverted back to a 2.6.10-1.770_FC3-based kernel and have
had a week of blissful stability. I will try a newer kernel at some point
but I hate to loose work to known-flaky kernels. :-/
People are complaining about several different things here with no commonality.
The only way a problem can be solved is if it is isolated. This bug has no
chance of that happening.
Yes, Warren, the posts here are probably not all the same thing. Granted. But
declaring "no chance" is neither helpful nor informative. So, do you have any
constructive suggestions on what can be done to help "isolate" and/or gather
I am also encountering these lockups. I however have Fedora on two machines. One
which I use as a general purpose server, the other I use as my desktop. Thus I
am encountering these lockups at a very disheartening frequency.
CPU Type: Intel(R) Celeron(R) CPU 2.70GHz
CPU MHz: 2700.630
RAM Type: DDR
RAM Amount: 512MB
Run Level: 5
Number or lockups: 2
CPU Type: Pentium III (Coppermine)
CPU MHz: 751.798
RAM Type: SDRAM
RAM Amount: 512MB
Run Level: 5
Number or lockups: 5
The lockups seem totally random. I've never noticed any warnign signs such as
CPU at 100% before the lockups. I have notice no warnign signs. I have however
noticed, at least on the server, that TCP/IP is the last to go, as ip forwarding
can still occur even after IO has failed. I am still using this kernel,
2.6.11-1.14_FC3, hoping that I might be of some assistance in data collection on
If you aren't Ed please don't add further comments to this bug - file a bug of
Ed: Did you take a look at bug #155472 ? Does using a newer kernel solve the
lock up problem (assuming you used and removed a key before the lockup)?
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.