Re: USB transfers stuck in kernel/libusb not sent out until next transfer is submitted
Hi, further data: If I wait 2ms between each transfer they never get stuck. As you mentioned in your other post, no usbdump yet in 8.0 But I can positively say that: 1. the transfer got submitted and the submit returned 0 2. no device NAK's on the USB bus (I'm looking at it with a sniffer) So its definitely getting held in libusb/kernel -- Peer On Fri, Oct 19, 2012 at 11:44 AM, Hans Petter Selasky hans.petter.sela...@bitfrost.no wrote: 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
Re: USB transfers stuck in kernel/libusb not sent out until next transfer is submitted
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
USB transfers stuck in kernel/libusb not sent out until next transfer is submitted
Hi, I have a embedded system that communicates to gateway devices via just on IN and OUT bulk endpoint. With one kind of gateway devices it works like a charm via High-Speed USB2. Now we've built another gateway thats using Full-Speed USB only (using one of the Atmega CPUS). We were experiencing lost transfers that never reached the gateway. After first suspecting the gateway we now concluded that the gateway is not losing this transfers. I see transfers being submitted to libusb with libusb_submit_transfer(), but they are not showing up in the callback, neither as completed nor as any errors. I'm also watching the USB Bus with a sniffer and I don't see this transfers being sent. What I see however that older transfers that were also missing are sent at the same time I submit a new transfer. This only seems to happen if I send a few OUT transfers consecutively (not sure if waiting in between helps) without any IN transfers in between. The gateway is always ready to receive more OUT transfers, I never see a NAK in the traces. Unfortunately the FreeBSD on these devices is relatively old: FreeBSD triton.stritzinger.com 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 It would screw up my deadlines if I need to upgrade the OS to make this work again, so I thought I asked first: * Is this a known problem thats being already fixed in newer FreeBSD's? (so if I loose the time I can be sure it works then) * Is there a workaround to get this running without upgrading first (would help a lot meeting the deadline, then upgrading in my own time) * Any tips how to debug this further? Cheers, -- Peer ___ 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
Re: Powercycling USB device on hub
On Sat, Jul 23, 2011 at 11:47 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Saturday 23 July 2011 18:53:46 Peer Stritzinger wrote: In newer libusb there is a function to get the parent HUB address. Ah great, I've to update the production systems soon. Is it already in 8 stable? -- Peer ___ 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
Re: Powercycling USB device on hub
Hi, On Thu, Jul 21, 2011 at 12:49 PM, Hans Petter Selasky hsela...@c2i.net wrote: Using the usbconfig utility in 8 stable and 9 current, you can set the configuration to 255 which means unconfigured and then 0 for the root HUB. For non-root HUBs you can BUS-reset the devices usbconfig -d X.Y reset or set_config aswell. Have you tried usbconfig -d X.Y reset ? Problem is that the production system where I need to do this is still running 8.0 ... But I got it working with usbconfig -u X -a Y reset, did not work first because I got the wrong device. Not since I'm reseting the correct (non root) HUB I see a powercycle on the USB device, so it works. Do a power_off command before the parent HUB reset, if the parent HUB reset is not enough. Beware that some motherboards hardwire the powersupply to the USB port. I.E. it is not possible to power-cycle the root HUB USB port. Even worse: after trying to reset one of the root HUBS I get: $ sudo usbconfig -u 3 -a 1 reset usbconfig: could not reset device: Device not configured and after this all devices hat are on this bus are no longer visible to usbconfig until the next reboot. Cheers -- Peer --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
Re: Powercycling USB device on hub
Hi, On Sat, Jul 23, 2011 at 5:17 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Saturday 23 July 2011 17:18:34 Peer Stritzinger wrote: $ sudo usbconfig -u 3 -a 1 reset usbconfig: could not reset device: Device not configured and after this all devices hat are on this bus are no longer visible to usbconfig until the next reboot. This is a known issue which was fixed in stable. Great. Since power-cycling needs to reset the HUB I now have the problem to find out on which HUB in the system my device hangs. There are two HUB's on the same root HUB and I don't want to power-cycle all devices. Is there a way to learn the physical structure of a USB bus? -- Peer --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
Re: Powercycling USB device on hub
On Sat, Jul 23, 2011 at 5:55 PM, Hans Petter Selasky hsela...@c2i.net wrote: Since power-cycling needs to reset the HUB I now have the problem to find out on which HUB in the system my device hangs. There are two HUB's on the same root HUB and I don't want to power-cycle all devices. Is there a way to learn the physical structure of a USB bus? devinfo Address 1 is always the root HUB. Tried this already but it only shows the hubs but none of my devices because they have no driver (custom built USB devices, only talk to them via libusb). e.g. usbus3 uhub3 uhub4 pnpinfo vendor=0x0424 product=0x2514 devclass=0x09 devsubclass=0x00 sernum= release=0x0bb3 intclass=0x09 intsubclass=0x00 at port=7 interface=0 uhub5 pnpinfo vendor=0x0424 product=0x2514 devclass=0x09 devsubclass=0x00 sernum= release=0x0bb3 intclass=0x09 intsubclass=0x00 at port=8 interface=0 There is one of the devices attached either to uhub4 or uhub5 (visible in usbconfig) but nothing shown in devinfo (even with -v). -- Peer ___ 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
Re: Powercycling USB device on hub
Hi, On Wed, Jul 20, 2011 at 3:19 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Wednesday 20 July 2011 14:30:37 Peer Stritzinger wrote: ... Using the usbconfig utility in 8 stable and 9 current, you can set the configuration to 255 which means unconfigured and then 0 for the root HUB. For non-root HUBs you can BUS-reset the devices usbconfig -d X.Y reset or set_config aswell. Do I understand this right: I reset the USB Hub device to powercycle all devices connected to it? There is also a power_off command, but your device might not come back after that. This would probably really not help since I try to reboot a USB device with hung software, so it won't recognize any commands itself. -- Peer ___ 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
Powercycling USB device on hub
Hi, is ist possible to power-cycle the HUB port of a USB device by programmatic means (via script or libusb or some ioctl)? It would be perfect if I could power-off/on just a certain device but it would also help to power-cycle all devices on a HUB. Cheers, Peer Stritzinger ___ 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
Re: FreeBSD 8: libusb async mode + select(2) = nogo?
Hi, On Fri, Jul 23, 2010 at 7:21 PM, Hans Petter Selasky hsela...@c2i.net wrote: Should work, but it might be that the second poll, when you try to process the events, don't work like expected. After any event on the two fd's you should call libusb_handle_events_locked() using a tv = NULL. I was calling libusb_handle_events_timeout(ctx, NULL), does this make an difference (only running single threaded) -- Peer ___ 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
Re: libusb10: libusb_bulk_transfer returns LIBUSB_ERROR_OTHER caused by USB_FS_OPEN ioctl in ugen20_tr_open
Hi, On Wed, Jul 14, 2010 at 9:35 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Tuesday 13 July 2010 23:40:43 Peer Stritzinger wrote: What I get is rv - LIBUSB_ERROR_OTHER to get closer to re reason for IN endpoints must be OR'ed with 0x80. That was the problem, from the documentation (fbsd man page and sourceforge) it wasn't clear that this has to be done. OTOH it might have occurred to me that libusb_bulk_transfer couldn't always guess the direction so it must be told somehow. It works now quite well now. Thanks a lot! Could you dump the configuration descriptor of your device? Also you might need to claim the interfaces. Claiming the interface or not didn't make any difference (both ways it works). Looking at the code of libusb_claim_interface it doesn't do much, and claiming doesn't prevent other processes accessing the interface (I can start the program that claims the interface multiple times without problem). Actually what I would like to do is reading one endpoint of a interface in one process and writing in another process -- saves me polling an/or doing async i/o. It looks like it might just work but somehow I have the impression that it wouldn't be the right way to do it and might break in future versions of FreeBSD. Best regards -- Peer ___ 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
Re: read(2) always returns 0 when reading from /dev/usb/n.m.k bulk IN endpoint
Hi, FYI: just tried using the short xfer ioctl, but the behavior didn't change. in = open (argv[0], O_RDONLY); ioctl(in, USB_SET_RX_SHORT_XFER, 1); n = read(in, buf, NBUF); now trying libusb for this. -- Peer On Mon, Jul 12, 2010 at 10:41 PM, Peer Stritzinger pee...@gmail.com wrote: Hi, On Mon, Jul 12, 2010 at 8:20 PM, Hans Petter Selasky hsela...@freebsd.org wrote: On Monday 12 July 2010 19:22:28 Peer Stritzinger wrote: However the read always returns 0. Tried different buffer sizes etc. Hi, Maybe you are missing to set the short transfer OK flag. Else I recommend using LibUSB. --HPS Did'nt set this flag (not doing any ioctls on the ugen device at all). However I did try matching either the max packetlen, or the read buffer size with the actual bytes sent, so I thought it shouldn't matter. I'll move on to libusb and not waste any more time with the raw interfaces. Thanks -- Peer ___ 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
libusb10: libusb_bulk_transfer returns LIBUSB_ERROR_OTHER caused by USB_FS_OPEN ioctl in ugen20_tr_open
Hi,
with the setup from my post of yesterday I'm trying IN transfers with
libusb 1.0 and now I'm a bit stuck.
In essence I'm doing:
cnt = libusb_get_device_list(NULL, list);
... find device - now in found
if (found) {
libusb_device_handle *handle;
...
rv = libusb_open(found, handle);
trans_len = 0;
rv = libusb_bulk_transfer(handle, ep, buf, NBUF, trans_len, 0);
What I get is rv - LIBUSB_ERROR_OTHER to get closer to re reason for
this I debugged the last call into libusb
The error return is caused in ugen20_tr_open():
ioctl(xfer-pdev-file, USB_FS_OPEN, temp)
returns != 0, errno - EINVAL
Params to this ioctl are:
(gdb) p temp
$1 = {max_bufsize = 16384, max_frames = 1, max_packet_length = 0,
dev_index = 0 '\0', ep_index = 24 '\030', ep_no = 6 '\006'}
(gdb) p *xfer
$2 = {pdev = 0x282033c0, callback = 0x28094190 libusb10_bulk_intr_proxy,
priv_sc0 = 0x282033c0, priv_sc1 = 0x28221060, ppBuffer = 0x2822208c,
pLength = 0x28222088, maxTotalLength = 0, maxFrames = 1, nFrames = 0,
aFrames = 0, timeout = 0, timeComplete = 0, trIndex = 24, maxPacketLen = 0,
flags = 0 '\0', status = 0 '\0', is_opened = 0 '\0', is_pending = 0 '\0',
is_cancel = 0 '\0', is_draining = 0 '\0', is_restart = 0 '\0'}
(gdb) p *xfer-pdev
$3 = {ddesc = {LIBUSB20_DEVICE_DESC_FORMAT = 0x2809abd4, bLength = 18 '\022',
bDescriptorType = 1 '\001', bcdUSB = 512, bDeviceClass = 0 '\0',
bDeviceSubClass = 0 '\0', bDeviceProtocol = 0 '\0',
bMaxPacketSize0 = 64 '@', idVendor = 1133, idProduct = 49177,
bcdDevice = 0, iManufacturer = 1 '\001', iProduct = 2 '\002',
iSerialNumber = 0 '\0', bNumConfigurations = 1 '\001'}, session_data = {
session_data = 1731721030, tv = {tv_sec = 1731721030, tv_nsec = 0},
plugtime = 1731721030}, dev_entry = {tqe_next = 0x0,
tqe_prev = 0x28202030}, methods = 0x2809aac0, beMethods = 0x2809aa80,
pTransfer = 0x28209c00, privBeData = 0x28215300, privLuData = 0x28207100,
claimed_interface = 0 '\0', file = 12, file_ctrl = 11, debug = 0,
nTransfer = 64, bus_number = 3 '\003', device_address = 2 '\002',
usb_mode = 0 '\0', usb_speed = 3 '\003', is_opened = 1 '\001',
usb_desc = ugen3.2: CY7C68001 Cypress at usbus3, '\0' repeats 57 times}
BTW usb_desc is showing the right device.
Any suggestions?
Kind regards,
Peer Stritzinger
___
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
read(2) always returns 0 when reading from /dev/usb/n.m.k bulk IN endpoint
Hi, on FreeBSD 8.0-RELEASE I try to read from a bulk IN endpoint device node with read(2). The USB client it is talking to is a embedded controller with Cypress SX2 USB client chip, enumeration goes quite well (SX2 does it itself) and its reported correctly on console. The device nodes in /dev/usv/n.m.k appear for the control endpoint and two OUT and IN endpoints each. I can write to one of the OUT endpoints with e.g. dd and what I read on the device is correct. However I can't read any data from a corresponding IN endpoint: What I doing is in a loop: n = read(in, buf, NBUF); printf (read-test: read %ld bytes\n, n); this is run as root. I'm watching the USB with a USB protocol analyzer, BTW its running in High-Speed. As soon as the first read is done (and blocks) I see IN-NAK (device did not write to the IN endpoint) polling on the USB. When the device writes to the endpoint buffer I see a correct bulk IN transfer that is ACKed by the host with the analyzer. However the read always returns 0. Tried different buffer sizes etc. Is this supposed to work as I'm using it. I'm planning to go to libusb-1.0 later, should I debug this with the /dev/usb/n.m.k node reading or proceed to libusb because my approach can't work anyway? Best regards, Peer Stritzinger ___ 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
Re: read(2) always returns 0 when reading from /dev/usb/n.m.k bulk IN endpoint
Hi, On Mon, Jul 12, 2010 at 8:20 PM, Hans Petter Selasky hsela...@freebsd.orgwrote: On Monday 12 July 2010 19:22:28 Peer Stritzinger wrote: However the read always returns 0. Tried different buffer sizes etc. Hi, Maybe you are missing to set the short transfer OK flag. Else I recommend using LibUSB. --HPS Did'nt set this flag (not doing any ioctls on the ugen device at all). However I did try matching either the max packetlen, or the read buffer size with the actual bytes sent, so I thought it shouldn't matter. I'll move on to libusb and not waste any more time with the raw interfaces. Thanks -- Peer ___ 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
