Folks,
I just wanted to summarize USB problems and status.
And to ask some questions to USB developers.
- USB zero packet
hci_usb was indeed not setting USB_ZERO_PACKET flag on bulk transfers.
Next preX release won't have that problem.
In the mean time just change
urb->transfer_flags = USB_QUEUE_BULK;
to
urb->transfer_flags = USB_QUEUE_BULK | USB_ZERO_PACKET;
in kernel/drivers/hci_usb.chci_usb_send_bulk function
- hci_usb crashes with 3com, Intel, Casira and some other devices
I spent quite a few hours staring at logs and oops traces and finally found
what's causing it.
This is somewhat complicated problem which is partially hci_usb driver's fault
and partially because of the inconsistencies in USB controller drivers.
Normally control transfer (hci command) completes (completion handler gets
called) before
interrupt transfer (hci event in response to the command). That's how it
works on most devices.
ie command #1 (ctrl), command #1 complete (urb->complete), event (intr),
command #2(ctrl).
However with 3Com and Intel (I suppose Casira as well) interrupt transfer
may arrive before the completion
of the control transfer. ie command #1 (ctrl), event (intr), command #2
(ctrl), command #1 complete.
Which doesn't make sense to me. I mean how can device send an event if it
didn't yet receive a command.
I'm not sure who's bug is it and is it a bug at all :)
USB folks, comments ?
Anyway this means that hci_usb tries to initiate new control transfer while
old one is still in progress.
But more than one active control transfer is not allowed and call
usb_submit_urb fails with ENXIO error.
When usb_submit_urb fails hci_usb driver frees urb and buffers used in this
transfer. And everything
would've been fine but it turns out that uhci driver calls completion
handler even if usb_submit_urb failed.
So we end up unlinking and freeing stuff twice.
usb_submit_urb and ENXIO error is handled differently in all 3 usb drivers:
uhci - calls completion handler
usb-uhci - doesn't call completion handler
usb-ohci - doesn't not return ENXIO at all
uhci seems to be the wrongest here :). It doesn't call completion handler
on errors like EINVAL, etc but does
call it on ENXIO. usb-uhci and usb-ohci never call completion handler if
submit_urb failed.
Go figure when you have to free stuff and when you don't :).
USB folks, comments ? How should we fix that ?
Also it's not clear whether completion handler can free urb or not.
usb-uhci and usb-ohci don't seem to use
urb after calling completion handler (except interrupt and ring transfers
where you obviosly must not free urb)
but uhci uses bunch of fields in urb after calling completion.
Current hci_usb driver does free urb in completion handler. Most of the
Bluetooth bulk transfers look like:
alloc_urb ---> submit_urb ---> urb->complete ---> free_urb
USB folks, what is the general rule here ? Can completion handler free urb
or not ?
If urb is allocated dynamically it makes sense to allow completion handler
to free it.
Max
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
