recent USB MFCs cause panics

[Hans Petter Selasky]

On Thursday 05 May 2005 09:04, Julian Elischer wrote:
> >I rebuilt my machine today and thus incorporated the USB changes that
> >have been MFC'd some days ago by julian at . Now I observe duplicated dmesg
> >entries for all newly attached USB devices, e.g.
> >
> >
> >Worse, the machine crashes when I remove USB sticks (tried various
> >models, all behave the same), saying
> >
> >umass0: BBB reset failed, STALLED
> >umass0: BBB bulk-in clear stall failed, STALLED
> >umass0: BBB bulk-out clear stall failed, STALLED
> >umass0: BBB reset failed, STALLED
> >umass0: BBB bulk-in clear stall failed, STALLED
> >umass0: BBB bulk-out clear stall failed, STALLED
> >umass0: BBB reset failed, STALLED
> >umass0: BBB bulk-in clear stall failed, STALLED
> >umass0: BBB bulk-out clear stall failed, STALLED
> >umass0: BBB reset failed, STALLED
> >umass0: BBB bulk-in clear stall failed, STALLED
> >umass0: BBB bulk-out clear stall failed, STALLED
> >umass0: at uhub1 port 2 (addr 4) disconnected
> >umass0: detached
> >
> >
> >Fatal trap 12:: BBB reset failed, STALLED
> > page fault while in kernel mode
> >fault virtual address   = 0x3c
> >fault code              = supervisor read, page not present
> >instruction pointer     = 0x8:0xc016dbfe
> >stack pointer           = 0x10:0xd159af08
> >frame pointer           = 0x10:0xd159af08
> >code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                        = DPL 0, pres 1, def32 1, gran 1
> >processor eflags        = interrupt enabled, resume, IOPL = 0
> >current process         = 3 (usb0)
> >interrupt mask          = none
> >trap number             = 12
> >panic: page fault
> >
> >: BBB bulk-in clear stall failed, STALLED
> >
> >I did already apply yesterday's change to uhub.c (1.21.2.11).
> >
> >My previous kernel was built on 29th April and works fine. This already
> >includes the ehci, uhci and ohci changes that were done on 26th April.
> >So this problem must be related to the USB changes on 30th April.
>
> I just tried this I can not make it fail with my Lexar jumpdrive on a
> UHCI port.
>
> can you say if you are using uhci, ehci or ohci?
>
>
> I however DID find another failure mode..
>
> If I boot with the drive plugged in, I get nested recursive interrupts
> (or rather polled interrupt equivalents)
> and it crashes.. (I think  it may even be running out of stack.. there
> were about 50 functions on
> the stack traceback)
>
> Unfortunatly I'm about to go offline for a week If I can't figure it out
> I'll revert those patches.
>

What branch is this. Current? It might not be related, but I just looked at 
the existing code (FreeBSD-6-current), and I found that 
"usbd_probe_and_attach()" will leave devices around if it fails. I assume 
that this was to enable hot driver loading, but that is _not_ the right way 
to do it. To allow this the "uaa" structure (usb_attach_arg) is allocated in 
memory, instead of on the stack, which is just a waste of memory! This 
structure is only supposed to be there during probe and attach, and to make 
this clear "device_set_ivars(..., NULL);" should be put somewhere, to have 
invalid use cause "page faults".

When a new driver is loaded "usbd_probe_and_attach()" must be called again! If 
"usbd_probe_and_attach()" detects that devices already exists it should just 
return. I suggest that "usbd_probe_and_attach()" is called from 
"uhub_explore()", to avvoid race conditions, when some parameter is set, and 
that "bus_driver_added" is not set to generic.

The reason is simple: One has to loop over the configurations again, because 
some devices have "ifaces". The current solution will only work for 
"iface"-less devices !

Yours
--HPS