Hi,
I've been using ext3 alpha release 0.0.2c on several VA servers and
workstations, and last friday one server died on an oops
The oops said: process kupdate, EIP 0010:[<0c012ee44>]
c012eca4 t sync_old_buffers
c012ef7c T sys_bdflush
c012f044 T bdflush
There was debugging output that said:
assertion failure in sync_old_buffers() at buffer.c linue 1956:
"!bh->b_transaction", which is consistent with the EIP info.
I'm afraid I have no idea what triggered the problem, so I can't reproduce
it at will.
The following boot said:
EXT3-fs: WARNING: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
JFS DEBUG: (journal.c, 528): journal_init_inode: journal dffe8a40: inode 30:01/177, size 4194304, bits 10, blksize 1024
JFS DEBUG: (recovery.c, 411): journal_recover: JFS: recovery, exit status 0, recovered transactions 1064 to 1133
EXT3-fs: recovery complete.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 168k freed
Adding Swap: 265064k swap-space (priority -1)
JFS DEBUG: (journal.c, 528): journal_init_inode: journal df51a480: inode 30:02/1406, size 4194304, bits 12, blksize 4096
JFS DEBUG: (recovery.c, 411): journal_recover: JFS: recovery, exit status 0, recovered transactions 14 to 14
JFS DEBUG: (journal.c, 528): journal_init_inode: journal df51a5a0: inode 30:05/133, size 16384000, bits 10, blksize 1024
JFS DEBUG: (recovery.c, 411): journal_recover: JFS: recovery, exit status 0, recovered transactions 57 to 57
JFS DEBUG: (journal.c, 528): journal_init_inode: journal df51a6c0: inode 30:06/125, size 16384000, bits 10, blksize 1024
JFS DEBUG: (recovery.c, 411): journal_recover: JFS: recovery, exit status 0, recovered transactions 173389 to 173397
EXT3-fs: recovery complete.
JFS DEBUG: (journal.c, 528): journal_init_inode: journal df51a7e0: inode 30:07/532, size 40960000, bits 12, blksize 4096
JFS DEBUG: (recovery.c, 411): journal_recover: JFS: recovery, exit status 0, recovered transactions 102076 to 102088
EXT3-fs: recovery complete.
EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
Does the last line mean that something is botched with /dev/rd/c0d0p7 and
that indeed I need to unmount it and run e2fsck on it?
If so, I'll send you the e2fsck output.
(The partitions are on Mylex hardware raid)
Marc
-- Microsoft is to software what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ (friendly to non IE browsers) Finger marc_f@merlins.org for PGP key and other contact information- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:30 EST