Date: Sat, 7 May 2005 16:42:39 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: freebsd-usb@freebsd.org Subject: Re: recent USB MFCs cause panics Message-ID: <200505071642.39796.hselasky@c2i.net> In-Reply-To: <4279C572.50809@elischer.org> References: <200505042226.j44MQq2n004793@sep.oldach.net> <4279C572.50809@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200505071642.39796.hselasky>