Red Hat Bugzilla – Bug 440180
random crashes all 2.6.24 kernels, 2.6.23 stable
Last modified: 2008-08-19 14:34:18 EDT
Description of problem:
I see random hangs when running any 2.6.24 kernel. But if
I run 220.127.116.11-85, the system is stable. I managed to
capture the output of dmesg after one crash, and it
seems to have an oops.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot with kernel 2.6.24-50.fc8
2. Use the system for a while (streaming video may make problem
occur more quickly, but it may be an illusion)
System freezes, or X crashes. Attached output of dmesg after
such a crash
It should be at least as stable as 2.6.23
Created attachment 300007 [details]
output of dmesg
Created attachment 300152 [details]
dmesg output from kernel-debug-18.104.22.168-64.fc8
Another crash log
Problem is now fairly reproducible (watching
streaming video causes crash within 20 minutes).
Hardware is Thinkpad T41, with radeonfb module in the initrd.
memtest86+ has been run recently, with no problems reported.
Any other suggestions on how to debug this?
(In reply to comment #3)
> Problem is now fairly reproducible (watching
> streaming video causes crash within 20 minutes).
Watching streaming video using what network adapter?
I was using the wifi (ath5k driver) on kernel-debug-22.214.171.124
to get the crash.
I guess I could try watching streaming video using
a wired connection. Will report on this tomorrow.
Right now I am using the ath5k driver on kernel-126.96.36.199-85
and it is completely stable.
Four hours of streaming video using the wired network on kernel-debug-188.8.131.52
did not produce a crash. So perhaps the problem is some change in ath5k
or mac80211 after 184.108.40.206-85. Any suggestions on how to track it down further?
Hmm, another report that ath5k is probably scribbling on memory.
Is there a way to do the analogue of git bisect on fedora kernels?
I could try bisecting the mainline kernels if I could figure out which
mainline kernel corresponds to the versions of ath5k and mac80211
in fedora kernel 220.127.116.11-85. I can trigger the crash within half an
hour or so, so bisection is not out of the question.
18.104.22.168-85.fc8 was built in early December, well before 2.6.24 was available.
Yet, it probably contained wireless bits that will only be in 2.6.25 and
If you wouldn't mind, it might be helpful if you could determine whether or
not the issue is observable in the current linux-2.6 kernel from Linus. If
so, you could bisect between 2.6.24 and the current HEAD.
If the problem is not observable in Linus' kernel, then you could bisect the
wireless-testing tree. If Linus' kernel is not affected, then the problem
should occur between the merge-2008-04-01 tag and the master-2008-04-01.
(FWIW, merge-2008-04-01 tag is equivalent to 2.6.25-rc8 and master-2008-04-01
has all the wireless patches queued for 2.6.26 as of 2008-04-01.)
Thanks for offering the bisection service! :-)
I tried the current linus kernel, but I am not sure how to interpret
the results. I was able to stream video for a few hours, but eventually
I got a crash. This time, I had a whole bunch of "assertion failed"
notes in /var/log/messages (which are attached).
So I am not sure if this crash is the same issue as what I had before,
and I do not know what the next step should be. Any suggestions?
Created attachment 301391 [details]
/var/log/messages excrept from crash with current linus tree
That looks like a different issue to me. Perhaps you could try bisecting the
wireless-testing tree as described in comment 9?
I have been running the head of wireless-testing for two days now with no problems.
So at the moment it looks like the issue either got fixed or got masked by something
(or perhaps was not as reproducible as I thought).
So I guess there is not much sense in bisecting, but I will give another report
in a week.
The kernels here should have the same wireless code as in the wireless-testing
Do they resolve the problem as well?
It is very puzzling. I got two crashes within 20 minutes with the kernel from
(but did not capture an oops yet). On the other hand, wireless-testing head as
was running completely stable for more then a week.
So I am not sure what to think. Perhaps there is some difference in the kernel
which is responsible? I am attaching the .config from a kernel which works well
Created attachment 302964 [details]
.config from stable kernel (from comment #13)
Do you find the 2.6.25-based kernels satisfactory?
Closed due to lack of response...