On Mon, May 13, 2019 at 11:31:15AM +0545, Brook Milligan wrote:
> sleepq_block() at sleepq_block+0x97
> turnstile_block() at turnstile_block+0x24f
> mutex_vector_enter() at mutex_vector_enter+0x34a
> dk_open() at dk_open+0x45
> Now I suppose the next step is to wade through the source to figure out what
> is happening?
sort of. dk_open requests one mutex ("dk_openlock") to serialize
concurrent open and close operations. This means that some other
process is trying to open or close the same disk device and
is blocked somewhere.
Next would be to identify that process and to find out why it doesn't
complete the operation.
An open process may block
- when querying the disk for parameters
- when reading the disklabel.
A close process may block
- when flushing the disk cache
Either can also block when the system runs out of memory or when all
CPUs are occupied with a real-time process or interrupt handler. But
I doubt that his is happening here...
None of these _should_ block forever but time out eventually which may
take some time, but you _should_ also see error messages on the console.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
