On Mon, 25 Feb 2013, Christian Lamparter wrote: > > In fact this is both normal and required. Packets to any particular > > endpoint must always be delivered in order. Therefore the URBs have > > to complete in the same order as they were submitted. > Yes, I know that ;). I guess I should have said: "It's strange that > after such a long silence the urb tx trigger at 1519981417 seemd to > unfreeze the pending urb. It's almost as if a urb completion event > was lost and the urb_complete just had to wait until another tx urb > on the same ep went by to free it. That's quite possible. The new URB may trigger something in the xhci-hcd driver or in the xHCI hardware. Sarah (CC'ed), the maintainer for xhci-hcd, is the person who would know best. > > > From the device side, taking the data shouldn't be a problem. The > > > rx is handled by hardware dma. The data from the host is put into > > > packages of 320 bytes (The carl9170 firmware has about 180 to 190 > > > of these 320 byte packages reserved for this purpose. So at no > > > point there should be any long delay because of lack of resources > > > or whatever). Also, it doesn't look the was any unusually high > > > load on the link. And the hardware can handle sustained wifi traffic > > > up to 160mbit/s (udp peaks at about 180mbit/s) without choking. > > > > > > Or can you think of any other "interesting" > > > bits that could help to explain why the "Arrandale box [...] worked > > > perfectly" whereas (all his) Ivy Bridge ones have problems. > > > (Of course, I assume that it is always the same device, the > > > same firmware and the same kernel drivers in all tests, right)? > > > > No, not really. Unless one is using USB-2 and the other USB-3 -- the > > device might have a bug in its USB-3 firmware. > Don't worry, the device was designed about 5 years ago. Hence, we don't > need to care about any USB 3.0 features. Since the device firmware is therefore unlikely to be the cause of the problem, it now seems a lot more likely that the problem is in the xHCI hardware or driver. > > What happens if xhci-hcd is unloaded before the test? > Isn't xhci-hcd needed to drive the usb 3.0 ports? I know about the hub > concept with uhci/ohci and ehci, but I thought they did away with that. Yes. Without xhci-hcd, nothing will happen when a device is plugged into a USB-3 port. (Although on some systems, ports are wired up as both USB-2 and USB-3, so when xhci-hcd isn't loaded the ports are managed by ehci-hcd.) Never mind; when I wrote the question it wasn't clear that the failures occurred only when the device was attached to a USB-3 port. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
