On Sun, 2005-03-13 at 23:15 +0100, Christian Kujau wrote:
> hi,
>
> in the course of creating, mounting, unmounting several filesystems one
> mount of a newly created jfs filesystem produced an oops:
>
> http://nerdbynature.de/bits/prinz/2.6.11-gentoo-r3/jfs/
>
> i am aware that the kernel is tainted (by some vmware module) and
> currently i see no way to reproduce the error. i just thought it is worth
> publishing the oops, maybe it's worth looking at it.
Mar 13 22:41:50 prinz dbUnmount: db_active[112531505] = 1112760110
Mar 13 22:41:50 prinz dbUnmount: db_active[112531506] = 1229148255
Mar 13 22:41:50 prinz dbUnmount: db_active[112531507] = 134351408
Mar 13 22:41:50 prinz dbUnmount: db_active[112531508] = 1397771347
These come from this code (fs/jfs/jfs_dmap.c):
/*
* Sanity Check
*/
for (i = 0; i < bmp->db_numag; i++)
if (atomic_read(&bmp->db_active[i]))
printk(KERN_ERR "dbUnmount: db_active[%d] = %d\n",
i, atomic_read(&bmp->db_active[i]));
bmp->db_numag should be no larger than 128, so something must have
overwrote that value. Well, it's newly formatted, so maybe it was never
sane. Either way, I haven't seen this problem before.
You should run fsck -f against the file system to make sure it gets
fixed, since this function should have just written the block map to
disk.
This loop has probably outlived it's usefulness, and I should either
remove it entirely, or make a sanity check against db_numag at the top,
which would avoid the oops.
--
David Kleikamp
IBM Linux Technology Center
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
