On Sat, Nov 27, 2010 at 11:33:15AM +0100, MERIGHI Marcus wrote: > [email protected] (Jacob Meuser), 2010.11.26 (Fri) 18:29 (CET): > > On Fri, Nov 26, 2010 at 01:39:24PM +0100, MERIGHI Marcus wrote: > > > [email protected] (Jacob Meuser), 2010.11.25 (Thu) 20:29 (CET): > > > > hub interrupts is, well, sloppy. we totally ignore the status bit > > > > field, which tells us which port had a status change, or whether the > > > > hub had a status change. uhub_explore() only deals with port status > > > > changes, so we only need to run it when there is a port status > > > > change. uhub_explore() should also use the status bit field to know > > > > what ports need to be checked, instead of checking every port, but > > > > I'll leave that for later. > > > > > > > > I'm also interested if you see the following kernel messages when > > > > running with this diff: > > > > > > > > uhub_intr: no change > > > > uhub_intr: hub changed but not ports > > > > > > not yet. You mean on unplugging the pcmcia uhub, don't you? > > > > yes. well, at any time actually. > > > > > below output of the session, see "# unplug pcmcia uhub". > > > > > # unplug pcmcia uhub > > > uhci3: host system error > > > uhci3: host controller process error > > > uhci3: host controller halted > > > uhci4: host system error > > > uhci4: host controller process error > > > uhci4: host controller halted > > > ehci0: unrecoverable error, controller halted > > > ehci0: blocking intrs 0x10 > > > uhub3 detached > > > usb3 detached > > > uhci3 detached > > > uhub4 detached > > > usb4 detached > > > uhci4 detached > > > uhub5 detached > > > uvm_fault(0xd09f8080, 0xeffff000, 0, 1) -> d > > > kernel: page fault trap, code=0 > > > Stopped at usbd_do_request_flags_pipe+0x18: movl > > > 0x258(%eax),%ec > > > x > > > ddb> trace > > > usbd_do_request_flags_pipe(d1f34c80,efff0062,dc16aef8,0,0) at > > > usbd_do_request_f > > > lags_pipe+0x18 > > > usbd_do_request_flags(d1f34c80,dc16aef8,0,0,0) at > > > usbd_do_request_flags+0x3c > > > usbd_do_request(d1f34c80,dc16aef8,0,d079adad,d0a0f200) at > > > usbd_do_request+0x37 > > > usbd_reset_port(d1f34c80,1,d1f34100,d03e20f7,40) at usbd_reset_port+0x42 > > > uhub_explore(d1f34c80,d1f3484c,dc16af8c,d0797b46,d1f34800) at > > > uhub_explore+0x16 > > > f > > > usb_explore(d1f34800,20,d097eaf6,0,d6d7f768) at usb_explore+0x3f > > > usb_task_thread(d6d7f768) at usb_task_thread+0x76 > > > > hmm. well, uhci doesn't stop hub interrupts before it detaches. > > can you try the following? > > > > Index: uhci.c > > =================================================================== > > RCS file: /cvs/src/sys/dev/usb/uhci.c,v > > retrieving revision 1.86 > > diff -u -p uhci.c > > --- uhci.c 21 Nov 2010 01:29:07 -0000 1.86 > > +++ uhci.c 26 Nov 2010 17:21:11 -0000 > > @@ -608,6 +608,11 @@ uhci_detach(struct uhci_softc *sc, int flags) > > if (sc->sc_shutdownhook != NULL) > > shutdownhook_disestablish(sc->sc_shutdownhook); > > > > + if (sc->sc_intr_xfer != NULL) { > > + timeout_del(&sc->sc_poll_handle); > > + sc->sc_intr_xfer = NULL; > > + } > > + > > /* Free all xfers associated with this HC. */ > > for (;;) { > > xfer = SIMPLEQ_FIRST(&sc->sc_free_xfers); > > @@ -923,6 +928,9 @@ uhci_poll_hub(void *addr) > > u_char *p; > > > > DPRINTFN(20, ("uhci_poll_hub\n")); > > + > > + if (sc->sc_dying) > > + return; > > > > timeout_del(&sc->sc_poll_handle); > > timeout_set(&sc->sc_poll_handle, uhci_poll_hub, xfer); > > I applied this patch to a clean -current src/sys/dev/usb. > output below, see "# unplug pcmcia uhub".
> # unplug pcmcia uhub > uhci3: host system error > uhci3: host controller process error > uhci3: host controller halted > uhci4: host system error > uhci4: host controller process error > uhci4: host controller halted > ehci0: unrecoverable error, controller halted > ehci0: blocking intrs 0x10 > uhub3 detached > usb3 detached > uhci3 detached > uhub4 detached > usb4 detached > uhci4 detached > uhub5 detached > uvm_fault(0xd0a1a040, 0x0, 0, 1) -> e > kernel: page fault trap, code=0 > Stopped at usbd_do_request_flags_pipe+0x18: movl > 0x258(%eax),%ec > x > ddb> 1) it is impossible to ever fully close the race between when the device is physically detached and when the kernel will notice. 2) something odd is happening here. why is it in uhub_explore() in the frst place? I now have a cardbus card with the same chipset. thanks to whoever sent that to me. interestingly, it crashes one machine immediately when inserted (cardbus layer issues), attaches uhci/ehci but doesn't recognize USB devices and eventually freezes another machine (no crash, just totally unresponsive), and behaves exactly like what you see on another machine. so, at least now I can reproduce this to further investigate. -- [email protected] SDF Public Access UNIX System - http://sdf.lonestar.org
