Re: kern/42455: tstile hang with nfs

["Christoph Egger" <Christoph_Egger%gmx.de@localhost>]

The following reply was made to PR kern/42455; it has been noted by GNATS.

From: "Christoph Egger" <Christoph_Egger%gmx.de@localhost>
To: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost, 
gnats-admin%netbsd.org@localhost,
 kern-bug-people%netbsd.org@localhost
Cc: 
Subject: Re: kern/42455: tstile hang with nfs
Date: Fri, 30 Apr 2010 13:24:53 +0200

 db> ps /w
 PID   LID          COMMAND     EMUL  PRI WAIT-MSG    WAIT-CHANNEL
 1206    1             sync   netbsd   43 tstile       ffffa00026b52498
 327   237          qemu-dm   netbsd   43              0
 327     2          qemu-dm   netbsd   43 netio        ffffa0000114f3b8
 327     1          qemu-dm   netbsd   34 genput       ffffa000005a0840
 
 db> show lock 0xffffa00026b52498
 lock address : 0xffffa00026b52498 type     :     sleep/adaptive
 initialized  : 0xffffffff80693b1b
 shared holds :                  0 exclusive:                  1
 shares wanted:                  0 exclusive:                  1
 current cpu  :                  0 last held:                  0
 current lwp  : 0xffffa0002320ec00 last held: 0xffffa00026628400
 last locked  : 0xffffffff8069161d unlocked : 0xffffffff80691696
 owner/count  : 0xffffa00026628400 flags    : 0x0000000000000007
 
 Turnstile chain at 0xffffffff80c383f0.
 => Turnstile at 0xffffa000260de308 (wrq=0xffffa000260de328, 
rdq=0xffffa000260de3
 38).
 => 0 waiting readers:
 => 1 waiting writers: 0xffffa00026b57000
 
 This is the hanging 'sync' process:
 
 db> tr /a 0xffffa00026b57000
 trace: pid 1206 lid 1 at 0xffffa00026bffa00
 sleepq_block() at netbsd:sleepq_block+0xbf
 turnstile_block() at netbsd:turnstile_block+0x2c7
 rw_enter() at netbsd:rw_enter+0x1d0
 vlockmgr() at netbsd:vlockmgr+0xe2
 VOP_LOCK() at netbsd:VOP_LOCK+0x28
 vn_lock() at netbsd:vn_lock+0xd5
 vget() at netbsd:vget+0xe9
 nfs_sync() at netbsd:nfs_sync+0xb9
 sys_sync() at netbsd:sys_sync+0xe6
 syscall() at netbsd:syscall+0xa8
 
 
 This is the hanging 'qemu-dm' process:
 
 db> tr /a 0xffffa00026628400
 trace: pid 327 lid 1 at 0xffffa0002661e880
 sleepq_block() at netbsd:sleepq_block+0xbf
 mtsleep() at netbsd:mtsleep+0x128
 genfs_do_putpages() at netbsd:genfs_do_putpages+0x7f9
 VOP_PUTPAGES() at netbsd:VOP_PUTPAGES+0x30
 nfs_flush() at netbsd:nfs_flush+0x27
 VOP_FSYNC() at netbsd:VOP_FSYNC+0x34
 sys_fsync() at netbsd:sys_fsync+0x53
 syscall() at netbsd:syscall+0xa8
 
 
 So it is qemu-dm who hangs first and any subsequent 'sync'
 call hangs, too.
 
 That explains why the Xen DomU suddendly hangs during IO.
 
 The question is why does the 'sync' syscall hang in first
 place ?
 
 Christoph