On 22/11/09 16:14, Alan Stern wrote: > On Sun, 22 Nov 2009, Simon Arlott wrote: >> On 18/11/09 22:25, Alan Stern wrote: >> > On Wed, 18 Nov 2009, Simon Arlott wrote: >> >> > What happens with other sorts of devices, such as a USB flash drive? >> >> >> >> I can write a 10MB file to an USB flash drive over OHCI, and umount+sync >> >> takes around 13 seconds. >> > >> > Yes, that's about right. It leads me to wonder if something funny is >> > going on with the device, or least with the firmware-loading part of >> > it. Odd that it works differently with UHCI and OHCI, though. There >> > shouldn't be any differences visible to the device. You don't have >> > anything else attached to the same bus, do you? >> >> Yes, but not in use and I could disconnect everything to test it. >> >> core/hcd.c has an interesting comment in usb_hcd_check_unlink_urb(): > > You mean usb_hcd_poll_rh_status(). Yes... misplaced paste from my other email. >> /* The USB 2.0 spec says 256 ms. This is close enough and won't >> * exceed that limit if HZ is 100. The math is more clunky than >> * maybe expected, this is to make sure that all timers for USB devices >> * fire at the same time to give the CPU a break inbetween */ >> >> I'll try increasing the frequency of this timer too. > > It shouldn't make any difference; that timer is used with OHCI only in > exceptional circumstances (like immediately after a device is plugged > in or unplugged), not during normal operation. But maybe something > strange is going on. You could add a printk in ohci_hub_status_data(), > which is the routine that timer ends up calling. I've tried sending 64 and 2048 bytes at a time, with the same speed (4ms and 128ms), so that time is just a coincidence. Submitting it all as multiple asynchronous URBs in one go doesn't help either. I've been trying to get EHCI working too (via two different high speed hubs) but that's not working even if I add long delays. -- Simon Arlott -- 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