Hi, > > ok. Had no trouble with freebsd, will go fetch netbsd images. What > > arch is this? i386? x86_64? > > i386 7.0 for the reference, but I`m sure that this wouldn`t matter in > any way.
7.0 trace: [ ... ] 12417@1453119296.506252:usb_ehci_opreg_write wr mmio 0020 [USBCMD] = 0 12417@1453119296.506284:usb_ehci_queue_action q 0x7f94f7a98bb0: free [ ... ] 12417@1453119296.507336:usb_ehci_state periodic schedule INACTIVE 12417@1453119296.507340:usb_ehci_usbsts usbsts PSS 0 12417@1453119296.507344:usb_ehci_queue_action q 0x7f94f7a98cd0: free 12417@1453119296.507349:usb_ehci_queue_action q 0x7f94f7a98c40: free 12417@1453119296.507353:usb_ehci_queue_action q 0x7f94f749f040: free 12417@1453119296.507357:usb_ehci_queue_action q 0x7f94f749efb0: free 12417@1453119296.507361:usb_ehci_state async schedule INACTIVE 12417@1453119296.507365:usb_ehci_usbsts usbsts ASS 0 12417@1453119296.507369:usb_ehci_usbsts usbsts HALT 1 12417@1453119296.507402:usb_ehci_opreg_write wr mmio 0020 [USBCMD] = 2 12417@1453119296.507413:usb_ehci_reset === RESET === 12417@1453119296.507418:usb_ehci_port_detach detach port #0, owner ehci 12417@1453119296.507423:usb_ehci_irq level 1, frindex 0x2958, sts 0x1004, mask 0x37 12417@1453119296.507435:usb_ehci_port_attach attach port #0, owner comp, device QEMU USB MSD 12417@1453119296.507444:usb_ehci_opreg_change ch mmio 0020 [USBCMD] = 80000 (old: 0) 12417@1453119296.507466:usb_ehci_opreg_read rd mmio 0024 [USBSTS] = 1000 12417@1453119296.507510:usb_ehci_opreg_read rd mmio 0024 [USBSTS] = 1000 [ ... ] So, to shutdown ehci netbsd clears the cmd register, then sets the reset bit in the cmd register. Fine. Then it goes read the status register, in a loop, forever. No idea why, and I also can't spot then place in the source code. Hmm ... > Just to mention - ancient 2.6, like 2.6.18, are actually > doing things quite faster using same frontend+backend combination, may > be due to lack of proper timeout checks... Actually there is a very > small chance that the real performance regression was introduced > during further development, so I instead believe in improper > interaction of a newer guest EHCI driver and qemu frontend. Could also be older ehci guest drivers took a shortcut which turned out to not be correct and not working reliable ... > Please let > me know if any countable measurements like fio could be a matter of > interest - I don`t think that many people are concerned about USB/USB2 > frontend performance at all, since they are bringing in a ton of > unwelcomed wakeups and the one thing which could be a matter of > concern in that case is an emulated xHCI, IMHO. Yes, xhci is clearly the best choice when it comes to performance. Reasons to use ehci instead basically boils down to (a) lacking/broken guest drivers (old windows versions, also early linux xhci driver versions had endian issues, firmware needs xhci support too to boot from usb) and (b) historical (ehci emulation was there first, so support in the management stack tends to be better for that, also people are used to it). cheers, Gerd
