Red Hat Bugzilla – Bug 176696
Oops: kernel BUG at fs/inode.c:252
Last modified: 2015-01-04 17:23:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Description of problem:
fedora core 4
Dec 29 00:27:11 dbmx kernel: ------------[ cut here ]------------
Dec 29 00:27:11 dbmx kernel: kernel BUG at fs/inode.c:252!
Dec 29 00:27:11 dbmx kernel: invalid operand: 0000 [#1]
Dec 29 00:27:11 dbmx kernel: Modules linked in: ...
Version-Release number of selected component (if applicable):
kernel-2.6.14-1.1653_FC4 & kernel-2.6.14-1.1644_FC4
Steps to Reproduce:
Happens regularly (1day-1week)
don't know the trigger
system is not _completely_ frozen, open channels receive input (<cr> is echoed on an open SSH session) but any call to launch a program fails (ie, is frozen, ignored, whatever); new SSH connections stop responding at the protocol negotiation stage; you can kill the Xwindows screensaver (blankscreen) (with ctrl-alt-del), but the text login prompt comes up, accepts your username input and then does nothing. I will attach /var/log/messages portion with the Oops, the restart following it, and the intervening messages (shows GDM dying on restart). A google shows the debian people have found this one in 2.6.14, too.
Created attachment 122638 [details]
/var/log/messages: kernel oops, following restart
The debian people have a patch posted dealing with this exact Kernal BUG (252).
Although it is in a piece of s/w I believe FC4 doesn't have, I thought it might
provide a clue to which direction to look to those more familiar with the kernel
calls than I. The link to this patch is at
that patch is for in an issue in shfs though, which we don't have in Fedora.
Are you using any out-of-tree filesystems ? FUSE ?
(In reply to comment #3)
> that patch is for in an issue in shfs though, which we don't have in Fedora.
> Are you using any out-of-tree filesystems ? FUSE ?
Nothing out-of-tree. Just a fullish (nearly all things, servers & such; not the
"everything" box, though) install (from the ISO GUI), with all updates run
through the 12/22/05 set (ie, the most recent one).
I just mentioned the debian as a pointer to what calls might be searched for to
find what is causing the oops.
I will attach an rpm -qa from the system...Actually, come to think of it, I
will wait for a list of info you would like from the system, then produce &
attach it. Let me know.
As a side note, FYI: On my last reboot from a lock-up, I rebooted into
2.6.11-1.1369_FC4 (the kernel from the installation ISOs) and have had no
recurrence of the oops over the 2 days since (same usage patterns). I am in a
position that this box has to go into place (production) soon; if I don't
receive directed queries on things to look at/test, we will loose the test bed
(and I will "just go with what works"). This would be a shame, as it would
preclude running updates -- even security ones -- to the kernel on this box.
I note that in your announcement for kernel-2.6.14-1.1653_FC4 (13 December 2005)
A 32 bit integer overflow was discovered in the
invalidate_inode_pages2() function which could lead to a
local denial of service attack.
Is it possible a null-arg call to whatever is at line 252 in fs/inode.c was
introduced in this work? Seems this should be something you would want to get
can you try the test kernel at http://people.redhat.com/davej/kernels/Fedora/FC4
Created attachment 122802 [details]
Some /proc/... output for kernel 2.6.14-1.1653_FC4
Ok, I have put the 2.6.15-1.1782_FC4 kernel up and it's been
running for 4 hrs now with no oops (but no stress, either).
I was seeing intervals of 2 to 7 days before the chickens came home
to roost, so to speak; would it ne possible to leave this open for
a couple of days; give me a chance to see if it survives stresses
similar to what I was doing before (which wasn't much, for sure).
No immediate (< 2hrs) lockup at least, which was what I got with
the last boot into kernel 2.6.11-1.1369_FC4.
Snagged some info from /proc/ (probably _not_ what I _should_ have
gotten, though, let me know) for both the 1653_FC4 and 1782_FC4
builds; I will attach tgzs (just a bunch of *.txt files in dirs,
contents and file contents should be nominally self-explanatory).
Created attachment 122803 [details]
Some /proc/... output for kernel 2.6.15-1.1782_FC4
(In reply to comment #8)
> No immediate (< 2hrs) lockup at least, which was what I got with
> the last boot into kernel 2.6.11-1.1369_FC4....
That should have been "...ast boot into kernel2.6.14-1.1653_FC4".
ok, I'll put this in needinfo state for now (it'll transition back to assigned
when you add a comment). Let me know how it works out for you.
thanks, almost a full week now and it seems rock solid. Most likely,
some installation problem with the earlier kernels that is straightened
out, but whatever it is (was), it seems fixed now. Cheers to all (well,
really, you Dave, thanks).
thanks. The .15 kernel will go out as an errata pretty soon (There's one more
iteration about to go to updates-testing, and then its blocking on a necessary
This is a mass-update to all currently open kernel bugs.
A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
Closing per previous comment.
Sounds like it was fixed but never closed.