Submitter : dxm Status : open
Assigned Engineer : btg Priority : 3
*Modified Date : 06/22/00 *Modified User : lord
*Modified User Domain : sgi.com *Description :
syscalls into XFS can get hung up sleeping on an event
that doesn't ever happen (or just delayed for many seconds).
XFS qa 013 will often trip this bug: the fsstress process sits
in 'R' state, waiting for a syscall to return.
kdb> btp 16558
EBP EIP Function(args)
0xc311fbd8 0xc01134b2 schedule+0x2b6 (0xc311fbec)
kernel .text 0xc0100000 0xc01131fc 0xc0113660
.....
==========================
ADDITIONAL INFORMATION (ADD)
From: lord@xxxxxxx
Date: Jun 22 2000 12:55:05AM
[pvnews version: 1.71]
==========================
Just a general comment here - fsstress reports a seed number when it starts
running. You can recreate the same sequence of events by using -s seed on
the comand line. It is a good idea in reporting fstress induced bugs
to include the command line and the seed value so that we can attempt to
reporoduce the scenario. It does not always work, but when it does it is
really useful.
Steve.
p.s. if anyone who is not doing 16 hour days at usenix wants to take alook,
we are missing a run_task_queue(&tq_disk) somewhere.
p.p.ps. Ted can answer questions about why the delay is there.
> View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Se
arch&wlong=1&view_type=Bug&wi=794397
>
> Submitter : dxm Submitter Domain : engr
> Assigned Engineer : btg Assigned Domain : sgi.com
> Assigned Group : xfs-linux Category : software
> Customer Reported : F Priority : 3
> Project : xfs-linux Status : open
> Description :
> syscalls into XFS can get hung up sleeping on an event
> that doesn't ever happen (or just delayed for many seconds).
>
> XFS qa 013 will often trip this bug: the fsstress process sits
> in 'R' state, waiting for a syscall to return.
>
> kdb> btp 16558
> EBP EIP Function(args)
> 0xc311fbd8 0xc01134b2 schedule+0x2b6 (0xc311fbec)
> kernel .text 0xc0100000 0xc01131fc 0xc0113660
> 0xc311fc04 0xc01131bf schedule_timeout+0x73
> kernel .text 0xc0100000 0xc011314c 0xc01131e0
> 0xc311fc0c 0xc4890188 [xfs]delay+0x18 (0x1, 0xc12ec344)
> xfs .text 0xc4816060 0xc4890170 0xc489018c
> 0xc311fc58 0xc4858dc0 [xfs]xfs_iget+0x284 (0xc2fac800, 0xc12f9558, 0x200b1, 0
x0, 0x4)
> xfs .text 0xc4816060 0xc4858b3c 0xc4859240
> 0xc311fc90 0xc4879388 [xfs]xfs_trans_iget+0x248 (0xc2fac800, 0xc12f9558, 0x20
0b1, 0x0, 0x4)
> xfs .text 0xc4816060 0xc4879140 0xc4879440
> 0xc311fcf0 0xc485b983 [xfs]xfs_ialloc+0x103 (0xc12f9558, 0xc0c8a0e0, 0x2124,
0x1, 0x0)
> xfs .text 0xc4816060 0xc485b880 0xc485bd80
> 0xc311fd6c 0xc487a5d8 [xfs]xfs_dir_ialloc+0x94 (0xc311fe18, 0xc0c8a0e0, 0x212
4, 0x1, 0x0)
> xfs .text 0xc4816060 0xc487a544 0xc487a7b8
> 0xc311fe60 0xc48801d7 [xfs]xfs_create+0x47b (0xc0c8a0f8, 0xc2fc66e0, 0xc311fe
a8, 0x0, 0x0)
> xfs .text 0xc4816060 0xc487fd5c 0xc48809a0
> 0xc311ff18 0xc4889c94 [xfs]linvfs_common_cr+0xe4 (0xc11c8740, 0xc33e2c00, 0x2
124, 0x4, 0x0)
> xfs .text 0xc4816060 0xc4889bb0 0xc4889d40
> 0xc311ff38 0xc488a271 [xfs]linvfs_mknod+0x69 (0xc11c8740, 0xc33e2c00, 0x2124,
0x0, 0x2000)
> xfs .text 0xc4816060 0xc488a208 0xc488a278
> 0xc311ff6c 0xc013bb5f vfs_mknod+0x123 (0xc11c8740, 0xc33e2c00, 0x2124, 0x0, 0
xc311e000)
> kernel .text 0xc0100000 0xc013ba3c 0xc013bbbc
> more> go
> 0xc311ffbc 0xc013bcce sys_mknod+0x112 (0x8052f08, 0x2124, 0x0, 0xbfffe96c, 0x
8052f08)
> kernel .text 0xc0100000 0xc013bbbc 0xc013bd80
> 0xc0109898 system_call+0x34
> kernel .text 0xc0100000 0xc0109864 0xc010989c
>
> Accessing the FS from another process will often cause the
> process to be woken up and continue on happily.
>
> (The delay(1)s in xfs_iget puzzle me...)
|