netdev - RE: Help testing for USB ethernet/xHCI regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Jan 2014 10:03:02 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Sarah Sharp' <sarah.a.sharp@...ux.intel.com>,
	Mark Lord <mlord@...ox.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: Help testing for USB ethernet/xHCI regression

From: Sarah Sharp
> On Tue, Jan 28, 2014 at 11:30:51PM -0500, Mark Lord wrote:
> > On 14-01-28 03:30 PM, Sarah Sharp wrote:
> > ..
> > > Can you please pull this branch, which contains a 3.13 kernel with
> > > David's patch reverted, and test whether your USB ethernet device works
> > > or fails?
> >
> > Fails.  dmesg log attached.
> 
> It's funny, because there's certainly data transferred over endpoint
> 0x82, even though there were link TRBs in the middle of transfers.  Did
> the "untransferred" messages stop when the device stopped working, or
> did they continue?

What I saw was that the USB transfers continued, but the ethernet
transmits stopped.
This rather changes the packets generated by TCP at both ends.
The effect can be seen in the timestamps (etc) in the USB trace.
There are still tx and rx packets, after a while they'll only
happen on ever-increasing timeouts.

That was the point where I wrote the NOP patch just to see if
it made a difference. I didn't really expect one!

I think that the LINK trb splits a 1k usb message in two.
This well and truly confuses the ethernet part of the ax88179_178a
hardware to the point where it doesn't even reset itself on the
next sub 1k message.

It might be that other targets (eg the smsx95xx) is more resilient
and only loses the single packet - which won't be immediately obvious.

	David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html