> > How about the "printer-0519.patch" ... did that resolve, by itself,
> > the problems in the printer driver? Specifically: the looping you
> > observed with the previous printer patch, caused by the fact that
> > usblp_write didn't drop the semaphore so usblp_disconnect could
> > never do its job. If that's fixed, then the oops-on-rmmod paths
> > will be very hard to trigger from usermode.
>
> The printer-0519 patch gives a flood of:
>
> printer.c: usblp0: error -110 reading printer status
Previously you'd said it looped forever there. What I'd expect to
see is a "flood" of such messages (processes using the device will
notice it's gone before khbud can) and then it should stop. Did
this flood not stop? What happens if you add a wait_ms(10) call
at about line 416, right after up (&usblp->sem) gets called?
I'm wondering why the khubd call to usblp_disconnect() doesn't
seem to have happened in your test. And trying to avoid a full
rewrite of usblp_write() ... that usb_submit_urb() assumes the
submission succeeds and later returns status in urb->status, which
is no better an assumption than the earlier one that it's safe to test
urb->status outside the completion callback!
> rmmod usb-ohci stops the flood and produces the usual oops.
Looking at that a bit more, it seems messy. The usbcore code
has a strong assumption that usb_dev->bus->op is always a
legitimate vtable ... but it can't be, when the bus's HCD module
was removed. And there seem to be other assumptions that the
usb_dev->bus field is always valid, dubious for the same reason.
> Still, adding the line "case -ETIMEDOUT:" to printer-0518 does cure the
> problem (but I have no idea what other diseases this may cause).
That fault could happen happen at any time, without necessarily
being an error or being related to device disconnection. I'd not
rely on that approach.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
