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. :-)
Yeah, I can imagine. Would love to hack on this as well, but then I look at my backlog... ;) > >>> 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. [ Ah, now I actually read this part. ] Hmm, unfortunate. We can just hope it does not hurt performance too much (compared to all the overhead emulation brings, it should not). > > Right now there is a hack in the ehci model to do this, but the > usb-linux code would be a better place since it might be specific to > linux hosts. If libusb can handle this efficiently, that is surely be the best way. But maybe usb-linux looks different for some subtle reason... Jan
signature.asc
Description: OpenPGP digital signature
