Re: kern/52147: deadlock when booting from USB disk

[Jaromír Doleček <jaromir.dolecek%gmail.com@localhost>]

Yes, the offending MODE SENSE was silenced, it doesn't try to print
anything out. But it could easily be reintroduced if we add there
something else, which would cause the same problem again. Having
something inherently deadlocking is quite dangerous.

Given that scsiverbose is only cosmetic and completely optional (code
prints some relevant info out even without it), I think it makes sense
to leave it up to explicit user action to have it loaded.


2017-04-12 14:25 GMT+02:00 Christos Zoulas <christos%zoulas.com@localhost>:
> On Apr 12,  5:30am, mlelstv%serpens.de@localhost (Michael van Elst) wrote:
> -- Subject: Re: kern/52147: deadlock when booting from USB disk
>
> |  >Can you print the deadlock path? Or instructions how to reproduce it?
> |
> |  This here happened on RPI with root on an a USB drive and filesystems
> |  using WAPBL. The deadlock occurs shortly after starting userland
> |  when a journal is played back (e.g. when root is remounted).
> |
> |  This could happen on all archs with SCSI disks.
>
> Yes, I understand.
>
> |  The journal play back triggered a SCSI error (bad MODE SENSE) which triggers
> |  a scsiverbose message which triggers the autoload but which cannot access
> |  the sd device because REQUEST SENSE processing has the periph frozen.
> |  Also, the message is printed synchronously in the completion thread, so
> |  even when you offload the module loading, no other error on the same scsi
> |  bus could be processed.
> |
> |  A workaround was to put scsiverbose into /etc/modules.conf which is
> |  done while root is still read-only.
>
> But hasn't the bad MODE SENSE been fixed now? I.e. the code was changed
> back not to do MODE SENSE? Or do we need the notion of "root is currently
> being mounted"?
>
> christos