xfs
[Top] [All Lists]

Lilo hanging in XFS development tree

To: chait@xxxxxxxxxxxx
Subject: Lilo hanging in XFS development tree
From: Steve Lord <lord@xxxxxxx>
Date: Wed, 04 Oct 2000 09:30:04 -0500
Cc: linux-xfs@xxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
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




<Prev in Thread] Current Thread [Next in Thread>