From: zensonic@zensonic.dk (Thomas S. Iversen)
To: Andrew Morton <akpm@osdl.org>
Cc: dm-devel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: Help tracking down problem --- endless loop in __find_get_block_slow
Date: Wed, 23 Feb 2005 13:00:13 +0100 [thread overview]
Message-ID: <20050223120013.GA28169@zensonic.dk> (raw)
In-Reply-To: <20050222011821.2a917859.akpm@osdl.org>
> > 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
Ad inf. The output of the BUG() is show below. My questions remain:
1. Whos fault is this?
2. How do I fix/avoid this problem?
Regards Thomas
__find_get_block_slow() failed. block=101, b_blocknr=100
b_state=0x00000010, b_size=2048
device blocksize: 2048
------------[ cut here ]------------
DEBUG_PAGEALLOC
Modules linked in: ufs sha512 aes_i586 dm_bde md5 ipv6 af_packet evdev ehci_hcd usbcore agpgart dm_mod rtc unix
CPU: 0
EIP: 0060:[__find_get_block_slow+202/304] Not tainted
EFLAGS: 00010286 (2.6.8)
EIP is at __find_get_block_slow+0xca/0x130
eax: 00000017 ebx: dcd21208 ecx: c02c6950 edx: 000041e4
esi: c138d600 edi: 00000065 ebp: da63aed0 esp: da7e9c54
ds: 007b es: 007b ss: 0068
Process dd (pid: 1742, threadinfo=da7e8000 task=dc76da70)
Stack: c029a003 00000800 00000800 00000064 00000000 00000000 00000000 da63ae6c
00000065 00000800 c014ab5f da63ae6c 00000065 00000800 00000800 00000065
da63ae6c da764df8 c014abdb da63ae6c 00000065 00000800 00000000 00000000
Call Trace:
[__find_get_block+95/176] __find_get_block+0x5f/0xb0
[__getblk+43/96] __getblk+0x2b/0x60
[pg0+542048932/1070055424] ufs_new_fragments+0x1c4/0x740 [ufs]
[pg0+542070875/1070055424] ufs_inode_getfrag+0x23b/0x3f0 [ufs]
[pg0+542072873/1070055424] ufs_getfrag_block+0x349/0x3b0 [ufs]
[create_empty_buffers+37/128] create_empty_buffers+0x25/0x80
[__block_prepare_write+467/960] __block_prepare_write+0x1d3/0x3c0
[kernel_map_pages+40/144] kernel_map_pages+0x28/0x90
[inode_update_time+167/224] inode_update_time+0xa7/0xe0
[block_prepare_write+52/80] block_prepare_write+0x34/0x50
[pg0+542072032/1070055424] ufs_getfrag_block+0x0/0x3b0 [ufs]
[generic_file_aio_write_nolock+821/2624] generic_file_aio_write_nolock+0x335/0xa40
[pg0+542072032/1070055424] ufs_getfrag_block+0x0/0x3b0 [ufs]
[do_no_page+99/688] do_no_page+0x63/0x2b0
[generic_file_write_nolock+116/144] generic_file_write_nolock+0x74/0x90
[clear_user+51/80] clear_user+0x33/0x50
[read_zero+452/528] read_zero+0x1c4/0x210
[generic_file_write+85/112] generic_file_write+0x55/0x70
[generic_file_write+0/112] generic_file_write+0x0/0x70
[vfs_write+184/304] vfs_write+0xb8/0x130
[copy_to_user+62/80] copy_to_user+0x3e/0x50
[sys_write+81/128] sys_write+0x51/0x80
[syscall_call+7/11] syscall_call+0x7/0xb
Code: 0f 0b 15 02 c2 9f 29 c0 8b 06 f6 c4 08 75 17 8b 46 04 40 74
next prev parent reply other threads:[~2005-02-23 12:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-21 10:46 Help tracking down problem --- endless loop in __find_get_block_slow Thomas S. Iversen
2005-02-22 9:18 ` Andrew Morton
2005-02-22 22:46 ` Jeff Mahoney
2005-02-22 23:28 ` Andrew Morton
2005-02-26 0:03 ` Jeff Mahoney
2005-02-28 21:06 ` Jeff Mahoney
2005-02-28 21:09 ` Help tracking down problem --- endless loop in __find_get_block_slow (now with the patch) Jeff Mahoney
2005-02-23 12:00 ` Thomas S. Iversen [this message]
2005-02-23 12:10 ` Help tracking down problem --- endless loop in __find_get_block_slow Andrew Morton
2005-02-23 13:02 ` Thomas S. Iversen
2005-02-23 20:09 ` Andrew Morton
2005-02-23 22:24 ` Thomas S. Iversen
2005-02-23 23:17 ` Andrew Morton
2005-02-24 8:54 ` Thomas S. Iversen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050223120013.GA28169@zensonic.dk \
--to=zensonic@zensonic.dk \
--cc=akpm@osdl.org \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox