Alan Stern wrote:
Of course I disabled USB3 in bios to get ehci - is there a way with
bios still in this state, to force xhci again for the usb2 ports?
The BIOS uses "USB3" rather imprecisely as a synonym for "xHCI". So
you are asking if there is a way to use xHCI while telling the BIOS
to turn xHCI off. Answer: No, there isn't.
Ok, thanks. I assume the reverse is h/w or driver dependent?
By which I mean that if I enable usb3 on the problem intel board I get
xhci for usb2 ports, but I notice on my desktop AMD chipset I have xhci
for usb3 ports and ehci for usb2.
One other thing I was going to try was capping with tcpdump or
usbmon
"Capping"? Do you mean "capturing"? Normally, capping something
means preventing it from exceeding some maximum value.
Apologies for my slang - yes capturing.
and seeing if the lost packets were lost after the wire. Does
anyone know of code that will allow capping of just the data via
usbmon?
By "lost after the wire", I guess you mean that you want to see if
the packets were transmitted by the device but not stored on the
computer. Neither tcpdump nor usbmon will show what was actually sent
across the USB bus; they both show what the kernel thinks it
sent/received.
Still, it's worth trying. I advise using usbmon's text mode
interface rather than its binary interface or tcpdump -- the binary
interfaces capture _all_ the data, which generates large capture
files and ends up hiding the things you want to look for.
Why would you want to capture _just_ the data? Usually the most
important things are in the metadata -- the times, packet lengths,
status codes, and so on. I can't imagine why you would want to
throw that information away.
The idea to capture the data would have been step 1 - TBH I can't think
of any other way to see if the ts packets that are missing were not
missing in the usbmon capture.
I would need to fire up a user space app to tune/start/record the
transfer (which may have a grace period for when the tuner is adjusting
its self and producing junk/loss).
Then when stable I would need to start full capturing with usbmon, leave
running long enough then analyse the 2 sets of data - tricky but
possible as I can use the fact that the ts packets have continuity
counters to easily detect low level loss.
Whether or not the loss is in both "places" further analysis would be
step 2 - but I have no idea how I would match the relatively rare and
small losses with usbmon events.
If I could show that the loss is "internal" then maybe the fix
could be done in s/w. I am thinking here of my previous tests with
3.18 that showed that spinning a CPU could hide isoc data loss
before the fix -
If you can work around the problem by preventing the CPU from going
idle, that suggests the problem doesn't lie in the USB stack at all,
but in the PCI or memory hardware.
OK
--
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
