Re: kern/57170: envstat uses uninterruptible system call

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

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

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: mayuresh%acm.org@localhost
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: kern/57170: envstat uses uninterruptible system call
Date: Fri, 6 Jan 2023 15:42:49 +0000

 When envstat(8) is in this state, can you start crash(8) and get
 output from the following commands?
 
 crash> bt/t 0t12345          (where 12345 is the pid of envstat(8))
 crash> ps
 crash> ps/w
 
 And, in the ps/w output, find the line for the envstat(8) process,
 which should look something like this:
 
 PID   LID          COMMAND     EMUL  PRI WAIT-MSG    WAIT-CHANNEL
 6627  6627         envstat   netbsd   38 tstile      ffff830197ed0500
 
 Take the string of letters and digits at the end under WAIT-CHANNEL,
 which is the address of the lock it's waiting for, and paste it into
 this:
 
 crash> x/Lx ffff830197ed0500
 ffff830197ed0500:       ffff8302bfe94182
 
 Take the word it shows, ffff8302bfe94182, and clear the low nybble,
 giving ffff8302bfe94180, the address of the lwp which owns the lock,
 and pass that to bt/a:
 
 crash> bt/a ffff8302bfe94180
 
 This shows what that lwp is up to.
 
 If the owner ffff8302bfe94180 is also in tstile according to ps (or
 waiting in mutex_vector_enter according to bt/a), keep doing that --
 find the lock via WAIT-CHANNEL in ps/w, find the owner of the lock
 with x/Lx and clear the low nybble, look at bt/a and ps for that lwp,
 until you find something that's not in tstile.
 
 With any luck, this will tell us what driver is stuck and where.
 
 (Also we should find a way to make this diagnosis less painful.)