[EMAIL PROTECTED] (Thomas S. Iversen) wrote: > > > > dd if=/dev/zero of=/mnt/testfile count=N, N>6 > > It turns out N>6 is variable. But large enough and it will hang. Sugests > some kind of race I am afraid. > > > > I get into an endless loop in __find_get_block_slow. > > > > The only way in which __find_get_block_slow() can loop is if something > > wrecked the buffer_head ring at page->private: something caused an internal > > loop via bh->b_this_page. > > > > Are you sure that's where things are hanging? That it's not stuck on a > > spinlock? > > I get the same message again and again all over (this trace with > count=100 and a BUG() and panic inserted into buffer.c) > > Feb 23 13:38:34 localhost kernel: __find_get_block_slow() failed. > block=101, b_blocknr=100 > Feb 23 13:38:34 localhost kernel: b_state=0x00000010, b_size=2048 > Feb 23 13:38:34 localhost kernel: device blocksize: 2048
OK, so we're looking for the buffer_head for block 101 and the first buffer_head which is attached to the page represents block 100. So the next buffer_head _should_ represent block 101. Please print it out: --- 25/fs/buffer.c~a 2005-02-23 04:06:12.000000000 -0800 +++ 25-akpm/fs/buffer.c 2005-02-23 04:06:51.000000000 -0800 @@ -459,8 +459,10 @@ __find_get_block_slow(struct block_devic */ if (all_mapped) { printk("__find_get_block_slow() failed. " - "block=%llu, b_blocknr=%llu\n", - (unsigned long long)block, (unsigned long long)bh->b_blocknr); + "block=%llu, b_blocknr=%llu, next=%llu\n", + (unsigned long long)block, + (unsigned long long)bh->b_blocknr, + (unsigned long long)bh->b_this_page->b_blocknr); printk("b_state=0x%08lx, b_size=%u\n", bh->b_state, bh->b_size); printk("device blocksize: %d\n", 1 << bd_inode->i_blkbits); } _ > Ad inf. The output of the BUG() is show below. My questions remain: > > 1. Whos fault is this? Could be UFS. But what does "transparent block encryption and sector shuffling" mean? How is the sector shuffling implemented? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/