> On 27. May 2022, at 16:24, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 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:
What is the recipe?
> 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.
No -- the name is confusing, it waits for spec_io_enter/exit to drain.
Better ask Taylor ...
--
J. Hannken-Illjes - hannken%mailbox.org@localhost
Attachment:
signature.asc
Description: Message signed with OpenPGP