Chait,
I want to send this one your way, not sure why, but the latest kernels
from the development tree cause a hang in lilo.
0xc0e40000 00001226 00001215 0 000 stop 0xc0e40340 lilo
[1]kdb>
[1]kdb>
[1]kdb> btp 1226
EBP EIP Function(args)
0xc0e41ec4 0xc01172a8 schedule+0x420 (0x1b4)
kernel .text 0xc0100000 0xc0116e88 0xc0117560
0xc0e41ee4 0xc0131c5d __wait_on_buffer+0x4d (0xc2b9ed20)
kernel .text 0xc0100000 0xc0131c10 0xc0131cf0
0xc0131dac sync_buffers+0xbc (0x300, 0x1)
kernel .text 0xc0100000 0xc0131cf0 0xc0131f18
0xc0131fbd fsync_dev+0x81 (0x300)
kernel .text 0xc0100000 0xc0131f3c 0xc0131fc4
0xc0138b5d blkdev_put+0x61 (0xc7d79ba0, 0x0)
kernel .text 0xc0100000 0xc0138afc 0xc0138c10
0xc0138c22 blkdev_close+0x12 (0xc7d71b60, 0xc03a9bc0)
kernel .text 0xc0100000 0xc0138c10 0xc0138c28
0xc01319af __fput+0x23 (0xc03a9bc0, 0xc03a9bc0)
kernel .text 0xc0100000 0xc013198c 0xc0131a28
0xc0131a39 _fput+0x11 (0xc03a9bc0)
kernel .text 0xc0100000 0xc0131a28 0xc0131a7c
0xc0131a8f fput+0x13 (0xc03a9bc0, 0xc16f60a0)
kernel .text 0xc0100000 0xc0131a7c 0xc0131a94
0xc0130966 filp_close+0xa6 (0xc03a9bc0, 0xc16f60a0)
kernel .text 0xc0100000 0xc01308c0 0xc0130970
0xc01309cf sys_close+0x5f (0x4, 0x8059b80, 0x4010a1ec, 0x4000ae60, 0x
bffffa74)
kernel .text 0xc0100000 0xc0130970 0xc01309e4
[1]more>
0xc010a8cb system_call+0x33
kernel .text 0xc0100000 0xc010a898 0xc010a8d0
buffer_head at 0xc2b9ed20
next 0x00000000 bno 0 rsec 0 size 1024 dev 0x300 rdev 0x300
count 2 state 0x1d [Uptodate Lock Req Mapped] ftime 0xed44
b_page 0xc10b95c4 b_this_page 0xc2b9ed80 b_private 0x00000000
This buffer has no block number - or being as this is lilo it could
be block zero. However, if I follow the b_this_page pointer around I get
these buffers:
[0]kdb> bh 0xc2b9ed20
buffer_head at 0xc2b9ed20
next 0x00000000 bno 0 rsec 0 size 1024 dev 0x300 rdev 0x300
count 2 state 0x1d [Uptodate Lock Req Mapped] ftime 0xed44
b_page 0xc10b95c4 b_this_page 0xc2b9ed80 b_private 0x00000000
[0]kdb> bh 0xc2b9ed80
buffer_head at 0xc2b9ed80
next 0xc2bd0480 bno 106505 rsec 213010 size 1024 dev 0x801 rdev 0x801
count 0 state 0x19 [Uptodate Req Mapped] ftime 0xed3c
b_page 0xc10b95c4 b_this_page 0xc2b9ede0 b_private 0x00000000
[0]kdb> bh 0xc2b9ede0
buffer_head at 0xc2b9ede0
next 0x00000000 bno 0 rsec 0 size 1024 dev 0x800 rdev 0x800
count 0 state 0x19 [Uptodate Req Mapped] ftime 0x0
b_page 0xc10b95c4 b_this_page 0xc2b9ecc0 b_private 0x00000000
[0]kdb> bh 0xc2b9ecc0
buffer_head at 0xc2b9ecc0
next 0x00000000 bno 106508 rsec 213016 size 1024 dev 0x801 rdev 0x801
count 0 state 0x19 [Uptodate Req Mapped] ftime 0xed4b
b_page 0xc10b95c4 b_this_page 0xc2b9ed20 b_private 0x00000000
All the same page, but different devices and block numbers - this could
be a red herring though.
This is repeatable - even on a kernel where XFS has not even been loaded
in. Something in ll_rw_blk.c is probably at fault here. Root and /boot are
both on ext2 on /dev/sda.
Steve
|