Messages in this thread | | | Date | Thu, 20 Mar 2003 23:13:35 +0000 | From | Dave Jones <> | Subject | Re: reiserfs oops [2.5.65] |
| |
On Thu, Mar 20, 2003 at 04:59:41PM -0800, Andrew Morton wrote: > > > > Slab corruption: start=c70c7044, expend=c70c7213 problemat=c70c7044 > > Last user: [<c0280dcb>](reiserfs_alloc_inode+0x1b/0x30) > > Data: (lots of hex) > > Alas, the "(lots of hex)" is important - it lets us determine which member of > struct reiserfs_inode was actually altered.
You're in luck, as noted in the follow up, I captured it all.. http://www.codemonkey.org.uk/cruft/oops.txt
> It would be nice if we had a more robust way of capturing all this info, > especially the oops-while-running-X lossage. Dump-to-floppy or something.
The tricky thing about capturing this one was that something in the VFS was wedged hard, so I'm lucky the logs made it to disk. Using sysrq, I synced and the disks made really nasty chugging noises. umount read only made it write a bunch of stuff out, more chugging noises for 15 minutes, kill all tasks then popped up a getty for me to log in on. It took about 3 minutes to get a shell (disk IO was seriously slow). I took a peek at vmstat 1 (no logs of this sorry), and nothing out of the ordinary. Not much in swap, plenty of swap free. short: the machine was horked. I synced, and rebooted, and thankfully the logs were still there after fsck.ext2 recovered /var
Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |