On Wed, 1 Jul 2015, Andy Furniss wrote: > Tom Yan wrote: > > Not sure if it's relevant at all, but Iong time ago I had a pci-e > > dtv tuner which requires c-state to be disabled in BIOS (workaround > > officially suggested by its vendor) to work. > > That's something I could try, though TBH as I bought this board to be > always on but low power, not something I would really "like" as a solution. > > Is there an obvious difference between ehci and xhci driver (same usb2 > ports) that would show a difference here. The two drivers are completely different. They share virtually no code in common. > 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. > 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. > 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. > 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. Alan Stern -- 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
