On Mon, Jan 18, 2016 at 4:55 PM, Gerd Hoffmann <kra...@redhat.com> wrote: > 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:
Whoops, sorry, should be 5.1/i386. On a 7.0 I observe same endless loop as you do. > > [ ... ] > 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 >
