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 from /var/log/messages 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 How reproducible: Didn't try Steps to Reproduce: Happens regularly (1day-1week) don't know the trigger 1. 2. 3. Additional info: 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 http://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg26551.html Thanks.
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) you mention 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 rid of.
can you try the test kernel at http://people.redhat.com/davej/kernels/Fedora/FC4 please ?
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". Sorry.
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 udev update).
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. Thank you.
Closing per previous comment. Sounds like it was fixed but never closed.