http://bugme.osdl.org/show_bug.cgi?id=2125
------- Additional Comments From nathans@xxxxxxx 2004-02-18 14:36 -------
Thanks for that xfs_info dump Kent - looks like a bog standard mkfs;
I was curious whether you'd used any unusual sector/blocksize settings
and if that was somehow interacting oddly, but you're not.
> That is correct. 2.6 has never booted completely.
OK, going back to your trace and disassembling...
[<c0109ca9>] __down+0x14d/0x288
[<c011bdfc>] default_wake_function+0x0/0x1c
[<c010a1fb>] __down_failed+0xb/0x14
[<c0226c1b>] .text.lock.xfs_buf+0x41/0x46
[<c0225afd>] pagebuf_iostart+0x81/0x8c
c0225afd+0x81 would be the call to pagebuf_iowait (which is missing from
your trace, which happens sometimes) which does the down on the iodone
semaphore.
So, it looks like your device driver is not completing the I/O request,
and so is never letting XFS know when its done. Which means XFS is not
getting woken up and you hang. Could you try putting a printk inside
xfs_buf.c, right before the submit_bio call and a second printk right
at the start of pagebuf_iodone? I'd expect to see a bio get submitted
(the 1st printk), but then never see an I/O completion (and hence the
second printk shouldn't get triggered). If thats the case, this is
quite likely to be a device driver bug. From your original report:
36GB (RAID0) on Compaq Integrated Array Controller
/ device = /dev/ida/c0d0p6 (xfs)
that /dev/ida/* would be your RAID device I guess? Perhaps something
has regressed in that driver between 2.4 and 2.6.
(btw - if you like, I can send you a patch to add the printks - just
let me know if you want that)
cheers.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
|