A little update. It seems that the gadget itself has a strange behavior: I start monitoring the usb transfers using usbmon. My setup has remained the same, but NUM_ISO_PACKETS is 32. I also tryed, as Hans suggested, to submit two urbs in order to achieve double buffering, but nothing changed. I attach a little view of the usbmon output. As you can see, the first packet (second line) is received correctly, even though 1024 bytes are received while a packet of 512 bytes was requested by the host. After such receipt, nothing more is received. >From the gadget, I monitored the callback calls, and I noticed that the callback is continuously called, even before the host submit the first urb. Maybe this means that zero-length packets are sent all the time before the host's first request. But what about the strange behavior after the host's requests? A first data buffer is sent, but then nothing more... it's seems quite strange to me... Thanks in advance for any idea... Daniele --------USBMON OUTPUT------------ f63bb000 2632500048 S Zi:5:009:2 -115:8:0 32 -18:0:512 -18:512:512 -18:1024:512 -18:1536:512 -18:2048:512 512 < f63bb000 2632540517 C Zi:5:009:2 0:8:8112:0 32 0:0:512 0:512:512 0:1024:0 0:1536:0 0:2048:0 1024 = bafcc8fc d0fcc4fc ccfcc1fc d1fcccfc c8fcc1fc cafcbbfc c1fcc6fc c7fcd9fc f63bb000 2632540530 S Zi:5:009:2 -115:8:8112 32 -18:0:512 -18:512:512 -18:1024:512 -18:1536:512 -18:2048:512 512 < f63bb000 2632572504 C Zi:5:009:2 0:8:176:0 32 0:0:0 0:512:0 0:1024:0 0:1536:0 0:2048:0 0 f63bb000 2632572508 S Zi:5:009:2 -115:8:176 32 -18:0:512 -18:512:512 -18:1024:512 -18:1536:512 -18:2048:512 512 < f63bb000 2632604501 C Zi:5:009:2 0:8:432:0 32 0:0:0 0:512:0 0:1024:0 0:1536:0 0:2048:0 0 f63bb000 2632604504 S Zi:5:009:2 -115:8:432 32 -18:0:512 -18:512:512 -18:1024:512 -18:1536:512 -18:2048:512 512 < f63bb000 2632636501 C Zi:5:009:2 0:8:688:0 32 0:0:0 0:512:0 0:1024:0 0:1536:0 0:2048:0 0 2011/3/18 Daniele Capuano <el.einad@xxxxxxxxx>: >> >> That's not right. If the gadget isn't sending data then >> iso_frame_desc[n].status should not be 0. It should be -EPROTO or >> something like that. If status is 0, it means that the gadget actually >> did send a zero-length packet rather than sending nothing at all. >> > > I tryed to set the USB_SHORT_NOT_OK urb flag and then the callback > returns with urb->status = -121 (i.e. -EREMOTEIO). The > iso_frame_desc[i].status is always zero. > > >>> I use: >>> - a kernel 2.6.31.12 with the RT patch on the host; >> >> What type of host controller? >> > The gadget is registered as a high-speed device using ehci_hcd. > > >> Why not use a more recent kernel, like 2.6.37? >> > I can't use one of the latest kernel versions since I'm using the > RT-patch and, as you can see on > http://www.kernel.org/pub/linux/kernel/projects/rt/, the last > available kernel version for such patch is 2.6.33. > >> This is almost certainly wrong. If NUM_ISO_PACKETS were larger than 1 >> then the packet buffers would overlap, unless the endpoint's maxpacket >> size is 1. More likely this should be i * iso_in->iso_in_size. >> > ok, fixed, thanks :-) > >> >> What happened to .bEndpointAddress? You have to specify USB_DIR_IN. >> > Yes, i did. It has been properly initialized in the bind() function. > > >>> I suspect that it should be a synchronization issue. >> >> I doubt it. More likely the gadget code isn't sending the packets >> properly. >> > I think it is not the case since if i try to send a single buffer it > is received correctly, but only when the read urb on the host is > submitted AFTER the gadget has started sending data. I know that the > usb protocol works with the host starting each transmission, but it > seems to don't work... > >> Alan Stern >> > > Thanks, > Daniele > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
