View Incident:
http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=800480
Status : open Priority : 2
Assigned Engineer : lord Submitter : ananth
*Modified User : lord *Modified User Domain : sgi.com
*Description :
We have a semi-production build machine that is
running XFS bits as of 8/23/00. I have seen
things like "rm" getting into the following backtrace:
---------
schedule+0x415
_sv_wait+0xcd
xlog_grant_log_space+0x139
xfs_log_reserve+0x7b
xfs_trans_reserve+0x76
.....
==========================
ADDITIONAL INFORMATION (ADD)
From: lord@xxxxxxx (BugWorks)
Date: Sep 12 2000 12:46:58PM
==========================
This appears to be caused by something failing to sync the root
inode of the filesystem. There is one item in the AIL (in log,
but modified in memory still). This is an inode:
xnode 0xf730cc88
hash 0xf70d9800 next 0x00000000 prevp 0xf2595688 mount 0xf43ae400
mnext 0xd0bcfc88 mprev 0xf730ca7c vnode 0xf735a160
dev 811 ino 128[0:8:0]
blkno 0x40 len 0x10 boffset 0x0
transp 0x00000000 &itemp 0xf3007de8
&lock 0xf730cd14 lock_ra 0x00000000 &iolock 0xf730cd3c
udquotp 0x00000000 pdquotp 0x00000000
&flock 0xf730cd64 (1) &pinlock 0xf730cd8c pincount 0x0 &pinsema 0xf730cd7c
&rlock 0xf730cda8
next_offset 0 io_offset 0 reada_blkno 0[0:0] io_size 0x0
last_req_sz 0x0 new_size 0
write off 0 gap list 0x00000000
readiolog 16, readioblocks 16, writeiolog 16, writeioblocks 16, maxiolog 16
flags 0x0 <>
update_core 0x0 update size 0x0
gen 0x0 qbufs 0 delayed blks 0
chash 0xf44cfb10 cnext 0xca46a8d0 cprev 0xe7e13990
data fork
bytes 0x2d real_bytes 0x30 lastex 0x0 u1:data 0xf7715920
broot 0x00000000 broot_bytes 0x0 ext_max 9 flags 0x1 <inline >
u2 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
attr fork empty
magic 0x494e mode 040777 (d---rwxrwxrwx) version 0x1 format 0x1 (local)
nlink 0x5 uid 0x0 gid 0x0 projid 0x0
atime 0x39be151e:2de54480 mtime 0x39a6c3d3:2fc03e40 ctime 0x39a6c3d3:2fc03e40
size 0x2d nblocks 0 extsize 0x0 nextents 0x0 anextents 0x0
forkoff 0 aformat 0x2 (extents) dmevmask 0x0 dmstate 0x0 flags 0x0 <> gen 0x0
I will dig some more, but in the meantime, the machine is dead
again - the xfs kdb commands are way too dangerous in the way
we can crash the debugger.
|