Re: USB, NetBSD 7/amd64: crashes

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Jul 07, 2015 at 12:04:08PM +0200, tlaronde%polynum.com@localhost wrote:
> On Tue, Jul 07, 2015 at 10:32:12AM +0200, Manuel Bouyer wrote:
> > On Tue, Jul 07, 2015 at 08:40:11AM +0200, tlaronde%polynum.com@localhost wrote:
> > > I have tried a netbsd-7 kernel and it crashes as well and the problem is
> > > still with locking.
> > 
> > I'm not sure it is a locking problem. In the dmesg you provide there
> > is "sd1: detached"; so it looks like the device is gone while still trying
> > to access it.
> 
> Whether one or the other. May the kernel "release" the faulting device
> before faulting? Furthermore, it is a bi-core, if the fault is on cpu1
> are messages from cpu0 and cpu1 guaranteed to be ordered in dmesg? i.e.
> can one be sure that if "sd1: detached" appears before uvm_fault
> there is a resp. time ordering? And a cause/consequence link is
> not guaranteed either with two cores?
> 
> I don't have, unfortunately, a single CPU node on which I could test
> whether it happens or not in this not concurrent case. This could give
> a supplementary indication about the level the problem is. (Can one
> instruct NetBSD to use only one CPU without an ad-hoc kernel?)

I'm almost sure that the "sd1: detached" leads to a NULL pointer dereference
later (and yes, messages are ordered). There is a race between probe and
detach, which should be fixed.
But even when this is fixed; I'm not sure the drive will work. It's not clear
why sd1 is detaching so early.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--