Re: NetBSD Xen guest freezes system + vif MAC address confusion (NetBSD 9.99.97 / Xen 4.15.2)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, May 27, 2022 at 04:24:30PM +0200, Manuel Bouyer wrote:
> On Fri, May 27, 2022 at 02:52:55PM +0200, J. Hannken-Illjes wrote:
> > > On 27. May 2022, at 14:41, Matthias Petermann <mp%petermann-it.de@localhost> wrote:
> > > 
> > > Hello Jürgen,
> > > 
> > > Am 27.05.2022 um 14:14 schrieb J. Hannken-Illjes:
> > >> Stack trace of thread vnconfig (1239) and from ddb "call fstrans_dump"
> > >> should give even more details.
> > > 
> > > here is the stacktrace from the vnconfig process (the PID has changed since I restarted):
> > > 
> > > https://www.petermann-it.de/tmp/p7.jpg
> > 
> > This is the thread currently suspending the root fs (vrevoke suspends it).
> > 
> > Looks like it is waiting for I/O to drain on the vnd device ...
> > 
> > > You can find the output of fstrans_dump here:
> > > 
> > > https://www.petermann-it.de/tmp/p8.jpg
> > 
> > The owner is irritating, it should be vnconfig from above.
> 
> I can reproduce it:
> db{0}> ps
> PID    LID S CPU     FLAGS       STRUCT LWP *               NAME WAIT
> 2419  2419 3   8         0   ffff9000210b9280               tcsh fstchg
> 2415  2415 3  11         0   ffff90001f66f540           vnconfig fstchg
> 2416  2416 3  18         0   ffff900020ea3200            dirname fstchg
> 2417  2417 3  24         0   ffff900020e6c700                 sh fstchg
> 2414  2414 3  12         0   ffff90001f6d7a00           vnconfig specio
> [...]
> db{0}> tr/t 0t2415
> trace: pid 2415 lid 2415 at 0xffff90008ed3e980
> sleepq_block() at netbsd:sleepq_block+0x12c
> cv_wait() at netbsd:cv_wait+0x42
> fstrans_start() at netbsd:fstrans_start+0x193
> VOP_LOCK() at netbsd:VOP_LOCK+0x79
> vn_lock() at netbsd:vn_lock+0xae
> namei_tryemulroot() at netbsd:namei_tryemulroot+0x1024
> namei() at netbsd:namei+0x29
> vn_open() at netbsd:vn_open+0x133
> do_open() at netbsd:do_open+0xc3
> do_sys_openat() at netbsd:do_sys_openat+0x74
> sys_open() at netbsd:sys_open+0x24
> syscall() at netbsd:syscall+0x18c
> --- syscall (number 5) ---
> netbsd:syscall+0x18c:
> db{0}> tr/t 0t2414
> trace: pid 2414 lid 2414 at 0xffff90008c57e6c0
> sleepq_block() at netbsd:sleepq_block+0x12c
> cv_wait() at netbsd:cv_wait+0x42
> spec_io_drain() at netbsd:spec_io_drain+0x84
> spec_close() at netbsd:spec_close+0x1c6
> VOP_CLOSE() at netbsd:VOP_CLOSE+0x38
> spec_node_revoke() at netbsd:spec_node_revoke+0x14d
> vcache_reclaim() at netbsd:vcache_reclaim+0x4e7
> vgone() at netbsd:vgone+0xcd
> vrevoke() at netbsd:vrevoke+0xfa
> genfs_revoke() at netbsd:genfs_revoke+0x13
> VOP_REVOKE() at netbsd:VOP_REVOKE+0x35
> vdevgone() at netbsd:vdevgone+0x64
> vnddoclear.part.0() at netbsd:vnddoclear.part.0+0xaa
> vndioctl() at netbsd:vndioctl+0x78c
> bdev_ioctl() at netbsd:bdev_ioctl+0x91
> spec_ioctl() at netbsd:spec_ioctl+0xa5
> VOP_IOCTL() at netbsd:VOP_IOCTL+0x41
> vn_ioctl() at netbsd:vn_ioctl+0xb3
> sys_ioctl() at netbsd:sys_ioctl+0x555
> syscall() at netbsd:syscall+0x18c
> --- syscall (number 54) ---
> netbsd:syscall+0x18c:             
> db{0}> call fstrans_dump         
> Fstrans locks by lwp:
> [ 5691.3454404] 2414.241 (/) shared 2 cow 0 alias 0
> [ 5691.3454404] Fstrans state by mount:
> [ 5691.3454404] /                owner 0xffff90001f6d7a00 state suspended
> 
> In the ps output there is also:
> 0     2324 3   3       200   ffff90001fe43340               vnd0 vndbp
> db{0}> tr/a ffff90001fe43340     
> trace: pid 0 lid 2324 at 0xffff90008c806df0
> sleepq_block() at netbsd:sleepq_block+0x12c
> vndthread() at netbsd:vndthread+0x78c
> 
> So it looks like vnconfig waits for the vnd I/O to drain, but the vnd thread
> is idle.

could this happen if the vnd is still open ?
I suspect the xbd backend did not close the vnd.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--