On Sun, 10 Nov 2002, Andrew Morton wrote:
> > buffer layer error at fs/buffer.c:399
> > Pass this trace through ksymoops for reporting
> > Call Trace:
> > [<c0151db6>] __find_get_block_slow+0xe6/0x150
> > [<c0152ec6>] __find_get_block+0xd6/0xf0
> > [<c0153277>] unmap_underlying_metadata+0x17/0x50
> This means that we had pagecache floating about which has buffers,
> but those buffers had unexpected block numbers. Possibly something
> went wrong during an earlier invalidation of the device during the
> mount process. Do you remember if a fsck happened during that bootup?
Very likely, yes. AFAICT from the syslog the first occurence was about 4
hours after reboot. During the reboot there was a journal recovery for all
ext3-fs (all except rootfs are ext3). The initscripts force fsck when ext2
appears unclean so I'm pretty sure there was an automatic fsck. But
unfortunately I don't recall for sure whether it detected and fixed any
inconsistency. It completed without manual interaction and the forced fsck
after the fs/buffer.c:399 message didn't show anything.
> Is there anything unusual about your setup? Using initrd? Is the
No initrd. Nothing unusual IMHO. I wouldn't call the 1k blocksize unusual
since it was silently done by some distribution installer quite some time
ago and didn't cause any harm so far. The box had 2.5.45 running for
about a week and I've never seen the buffer layer error message before -
but there were more than a few unclean shutdowns due to sysfs/usb issues.
> rootfs backed by a normal old disk?
It's /dev/hda1 on a 40GB IDE disk - no indication of any IDE problem.
> Could I please see a `dumpe2fs -h' of that device?
> Please, run with this patch and see if if happens again, thanks.
Despite a few intentional unclean reboots it didn't reappear until now.
I'll keep the patch applied and will report if it does. However, chances
are it won't: After the initial appearance I could retrigger it a few
times when writing larger files. But suddenly it didn't appear anymore.
Maybe it was a singular event, hardly to reproduce.
dumpe2fs 1.25 (20-Sep-2001)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: a0dd0fc0-fe31-11d5-9437-e3df28bee53c
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: filetype sparse_super
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 128016
Block count: 512032
Reserved block count: 25601
Free blocks: 172670
Free inodes: 99826
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2032
Inode blocks per group: 254
Last mount time: Mon Nov 11 19:35:39 2002
Last write time: Mon Nov 11 19:41:44 2002
Mount count: 1
Maximum mount count: 33
Last checked: Mon Nov 11 19:35:38 2002
Check interval: 15552000 (6 months)
Next check after: Sat May 10 20:35:38 2003
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:23 EST