On Fri, Oct 19, 2012 at 11:51 AM, Hans Petter Selasky
hans.petter.sela...@bitfrost.no wrote:
I see you are using 8.0 and I think that doesn't have usbdump.
Yep unfortunately.
Try fetching libusb sources from 8-stable and just make the stream open
routine return a failure, if it doesn't build.
Ok, I'll try.
Yes, there has been some issues fixes in this area (which involve some small
kernel patches sys/dev/usb/usb_generic.c), mostly if you start and stop
transfers rapidly.
I never start/stop transfers. Just submit one async bulk transfer
after the other.
Is there a limit how many transfers are allowed to be pending? Or a
old bug that is triggered by bursts of small transfers?
Also make sure that you don't mix synchronous and asynchronous transfers and
that only synchronous transfer is executed at a time. I.E. no multithreading
with synchronous transfers on the same USB device. Then you need to do it
asynchronously if you need background reading.
No synchronous transfers at all.
No multithreading, I just have loop that polls stdin/stdout and the
usb fds. Reading transfers from stdin and writing completed IN
transfers to stdout.
On the other end of stdin/stdout is a Erlang system that does all the
other protocol levels.
-- Peer
--HPS
-Original message-
From: Hans Petter Selasky hans.petter.sela...@bitfrost.no
Sent: Fri 19-10-2012 11:44
Subject: Re: USB transfers stuck in kernel/libusb not sent out until next
transfer is submitted
To: pee...@gmail.com;
Hi,
You should check using usbdump if the USB transfer is actually submitted. If
it is submitted, then it is most likely a problem with the USB device, that
it is NAK'ing on the endpoint. Are you short terminating properly for FULL
speed? Else it is a problem in libusb and/or the application.
usbdump -i usbusX -f Y -vvv -s 65536
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
