On 14.04.2010, at 01:50, David S. Ahern wrote: > > > On 04/13/2010 05:35 PM, Jan Kiszka wrote: >> David S. Ahern wrote: >>> After a month of code refactoring and clean ups, etc, I thought I would >>> send along an update. The attached patch is relative to your ehci >>> branch; I also attached the full usb-ehci.c file for easier reading. >> >> Thanks for your work! I applied it and once again merged git head at >> this chance. >> >> Just one request for the future: Please keep a queue of incremental >> changes. This EHCI beast is sufficiently tricky, and at some point >> someone (you included) may want to go back in history to find >> out where some change came from, and why it was applied. > > Agreed. I will submit focused changes from now on. > >> >> E.g.: We apparently regressed further /wrt my favorite test case (as >> it's self-contained): "-usbdevice net". qemu is now entering an infinite >> loop when you start dhcpcd in the guest on that interface. > > I've been focused on a single path -- async, bulk transfers to a USB > key. I take a look at the ethernet device as well. > > I've struggled with the infinite loop part: the async train jumps the > track with FC-12 guest rather quickly (ie., the link list is no longer a > loop). I put in a loop detector in the advance_state function which > helps for storage devices - but clearly something is not right. I've > been roaming the ehci_hcd code in the kernel as well looking for clues. > A lot of details to gel and the day job keeps getting in the way. :-) > >> >>> >>> At this point I can get a Windows XP guest to format a 4GB key and read >>> from and write to it. I can get an FC-12 guest to format a 4GB key and >>> an 8GB key as well as read from and write to both. Write rates are on >>> the order of 8 MB/sec for dd: >>> >>> # dd if=/dev/zero of=test bs=1M count=100 oflag=dsync >>> 100+0 records in >>> 100+0 records out >>> 104857600 bytes (105 MB) copied, 12.1205 s, 8.7 MB/s >>> >>> rsync of text files (e.g., /var/log) is on the order of 2MB/sec. >>> >>> 4GB keys are definitely more stable; the 8GB is not recognized by >>> Windows XP. >>> >>> It still needs a lot of love, but definitely an improvement from the >>> last version. The biggest difference for the performance boost and >>> stability is discovering that the usbfs in linux limits transactions to >>> 16k versus the EHCI spec which allows 20k per qTD. I added a hack to >>> submit which detects 20k requests from a guest and breaks it up into 2 >>> requests through the host (a 16k and then a 4k). >> >> Did someone already bring this up on LKML or wherever usbfs is >> discussed? Should be fixable, I naively guess. > > I submitted the patch to linux-usb and it was nack'ed. The response was > that memory is allocated in powers of 2 so trying to up the limit from > 16k to 20k means it will actually want to find 32k of contiguous memory. > The suggestion was to handle it with multiple requests within qemu. I > guess libusb does that.
Any reason we're not using libusb? Alex
