Folks,
Any ideas USB transaction can be screwed ?
Please read problem explanation below.
btw Greg, is there any reason why, in your Bluetooth -> TTY driver, you
submit bulk_in requests with the buf_len exactly
equal to max_packet_len on bulk endpoint instead of a larger buffer that
can hold co
>What kernel is this?
champ:/usr/src/bluez/kernel#uname -r
2.4.19-pre3
Max
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>His failure scenario sounds like the HC crashed, which would be a bit
>odd looking at the code. Do you get any other error messages around the
>time when the problems start occuring ?
Here is the log
- Device works with usb-uhci and zero packet enabled in driver.
- modprobe -r usb-uhci
- mod
>For DM1/DH1 packet this seems to work ok (a bit slow), but when I increase
>the packet size lots of kernel messages starts showing up in the recieving
>end. I've tried on a machine with an Intel controller with uhci.o and
>usb-uhci.o and on a machine with an Opti controller and ohci.o. They g
> > I meant any part of USB core. Whoever calls disconnect
> > could potentially tell HCD to cancel all requests on this device.
>
>The "potential" is that substantial (b) rework.
Ok. I'll give it more thinking and may be propose something later. Gotta
study USB code a bit more :).
Just to give
> > >Not entirely true. OHCI tries to safeguard against broken drivers,
> > >and in 2.5 anything using the new HCD code in usbcore does the
> > >same safeguarding. (Such as EHCI ...) The UHCI drivers may do
> > >things differently.
> >
> > Actually I would not call it broken driver. I think it
> > Is it valid to assume that if disconnect method is running completion
> > handler for bulk transfers will be called _only_ as a result of
> usb_unlink_urb ?
> > assuming that urb doesn't have a timeout of course.
>
>No, this is not the case.
>The only guarantee you have to make. On return fr
> > HCD and USB core do not unlink URBs on device disconnect because currently
> > it is driver's responsibility.
>
>Not entirely true. OHCI tries to safeguard against broken drivers,
>and in 2.5 anything using the new HCD code in usbcore does the
>same safeguarding. (Such as EHCI ...) The UHC
> > btw What will happen if unlink_urb is called while completion handler is
> > running ?
>
>An error code will be returned.
Good.
One more question.
HCD and USB core do not unlink URBs on device disconnect because currently
it is driver's responsibility.
Is it valid to assume that if disconne
> > How about ENXIO error in submit_urb ? Should we fix uhci ?
>
>Yes, it needs to be fixed and it's relatively easy. I'll send a patch to
>Greg when I get a chance to test it.
Looks like we can simply get rid of uhci_call_completion(urb) at the end of
uhci_submit_urb.
I'm not sure why would you
> > Sure. I meant that control transaction has not completed.
> > It doesn't make sense to start new transfer before acknowledging current
> > one. Or does it ?
>
>Somebody in the device firmware has exchanged two lines.
>You have to deal with it. The world is unfair :-)
Yeah. I found a work arou
> > 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.
>
>As Oliver stated, this is messy :)
>But the good news is that for 2.5 all of this is fixed, and you can jus
> > 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 :)
>
>Probably the device _has_ gotten the command. It just has not yet
>acknowledged.
Sure. I meant that control transaction ha
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
14 matches
Mail list logo
