Description of problem: Version-Release number of selected component (if applicable): 2.4.20-20.9 How reproducible: Not reproducable here Steps to Reproduce: 1. 2. 3. Actual results: Oops from ext3 code Expected results: System remains usable Additional info:
Created attachment 95749 [details] syslog $uname -a Linux my.machine 2.4.20-20.9 #1 Mon Aug 18 11:45:58 EDT 2003 i686 i686 i386 GNU/Linux
Created attachment 95750 [details] syslog showing IDE & ext3 Excerpts from syslog showing ide & ext3 information System has no SCSI disks
Ext3 just happens to be calling the inode lookup here, but the real problem is in the VFS inode list handling internals. We've got a bad pointer, 0xffffffff, on a hash list, it appears. 99 times out of a hundred, corruption like this in a core VFS list is either due to manually-loaded kernel modules or bad hardware. There's no evidence of bad modules here --- have you tried memtest86 on this box?
Yes. Full test suite from Memtest-86-v3.0 reprots no errors. As the module list in the log shows, no self written / non-RedHat modules were loaded. AFAIK, there is no such module on this system :)
Unfortunately, this is a one-off crash involving corruption of a linked list which is relied on utterly by every kernel, so it's part of the kernel reckoned to be pretty reliable. It could well just be a random hardware flip. We'd need more information to take it any further, but this footprint is not one I've ever seen reported anywhere else. Please do keep an eye on it though and report if this happens again. Right now, though, there's really not enough to work on.
Thanks Stephen. I shall certainly reopen if I spot it again. I understand I haven't been able to provide much to look into.