> On May 13, 2019, at 12:39 PM, Michael van Elst <mlel...@serpens.de> wrote:
>
> 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...
So how can I figure out what is happening? which other process is blocking?
> 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.
Unfortunately, I am 8000 miles from the machine, which is rack-mounted without
a permanent console attached.
Cheers,
Brook
