Description of problem:
Kernel panics during modest disk activity
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create ext3 journaled filesystem
2. create lots of files
3. wait for kernel to crash
kernel crashes in at least two possible ways
kernel must not crash! kernel must be stress tested before being released!!
hmm, so you can repeat this on demand ?
If so, can you try the 2.6.24 based kernel from updates-testing ?
Adding Eric to Cc as maybe he's seen something similar in ext3 development.
no, I don't *think* I've seen this. It looks vaguely like bug #428329. But
then, it's not a lot to go on. Could you include the full oopses rather than
the heavily-edited versions?
Also, testing on a debug kernel (yum install kernel-debug) might yield clues.
I have gone back to kernel-184.108.40.206-21.fc7 because I have had this running on
other hardware for several months now. Pity that it has disappeared from nearly
every mirror though. Why do good rpms in updates repository get deleted and
replaced by inferior ones (more patches != better patches)?
Hm, I'll be sure to suggest to the kernel maintainers that they discontinue
their irrational, single-minded quest for more and more patches....
But anyway, you can usually find older rpms on koji.fedoraproject.org, for
If you'd like to see the problem resolved so that you don't have to stick with
fc7 kernels, posting the full oops output, or reproducing the problem on the
debug kernel as I suggested would be a great help. Otherwise I'm not sure we
can hope for a resolution, with the limited information provided.
Please post the complete oops messages.
I have gone back to FC7 kernel (kernel-220.127.116.11-21) which is nice and stable.
No problems whatsoever over last couple of days (FC8 kernel crashed at least
once every day).
Cannot vouch for current FC7 kernel update (kernel-18.104.22.168-80) because the
numbering has gone from 22.214.171.124 to 126.96.36.199 which doesn't make a lot of sense.
Somebody should make 188.8.131.52-21 available again because it is good.
Without more information, we cannot proceed on this bug.
If you can provide the requested data (full oops output, preferably from a debug
kernel), please re-open.
If you are comfortable ignoring the stack traces that I have provided then go
ahead and close this bug and pretend that FC8 kernel is fantastic. That is your
choice, not mine.
It certainly is a clever way to eliminate kernel flaws.
It is clearly a bug, (well, or perhaps bad memory or whatnot, so far we really
cannot tell) and I'd very much like to fix it if possible. I've not seen it
reported elsewhere, and you seem to be somewhat uniquely able to hit it.
However, the information you have provided is not enough to go on. "something
went wrong down this path" just isn't enough to go on. Maybe it was a null
pointer. Maybe it was a bad pointer. All I can do is guess.
There is a reason that the kernel provides copious amounts of information on an
oops; it is so an attempt can be made at debugging. You have provided perhaps
20% of the oops info, and seem to be unwilling or unable to run this one more
time to gather the information requested.
I have no testcase; I have no oops output. I have a stacktrace, and that is
all. I can't see registers, I don't know what modules were loaded, I don't know
if your kernel was tainted, etc etc. I don't even know what the actual first
line of the oops was. If you don't want me to close this bug, I need just a bit
more info from you, as the reporter. I cannot magically infer the missing
I have a hunch that it may be related to another bug I've seen, which in turn
may be related to suspend problems. But, there is simply not enough here to be
able to tell.
If you can provide the requested info by running the problematic kernel once
more, preferably the debug variant, I am more than willing to spend time digging
into this bug.