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]
Message-ID: <53c5ebc06e454ed38a8254acbbabaa68@ausx13mpc120.AMER.DELL.COM>
Date:   Mon, 7 Jan 2019 18:27:56 +0000
From:   <Mario.Limonciello@...l.com>
To:     <mlord@...ox.com>, <hayeswang@...ltek.com>,
        <kai.heng.feng@...onical.com>
CC:     <aatteka@...ira.com>, <davem@...emloft.net>, <greg@...ah.com>,
        <romieu@...zoreil.com>, <netdev@...r.kernel.org>,
        <nic_swsd@...ltek.com>, <linux-kernel@...r.kernel.org>,
        <linux-usb@...r.kernel.org>, <ryankao@...ltek.com>
Subject: RE: r8152: data corruption in various scenarios

> -----Original Message-----
> From: Mark Lord <mlord@...ox.com>
> Sent: Monday, January 7, 2019 12:06 PM
> To: Limonciello, Mario; hayeswang@...ltek.com; kai.heng.feng@...onical.com
> Cc: aatteka@...ira.com; davem@...emloft.net; greg@...ah.com;
> romieu@...zoreil.com; netdev@...r.kernel.org; nic_swsd@...ltek.com; linux-
> kernel@...r.kernel.org; linux-usb@...r.kernel.org; ryankao@...ltek.com
> Subject: Re: r8152: data corruption in various scenarios
> 
> 
> [EXTERNAL EMAIL]
> 
> On 2019-01-07 11:01 a.m., Mario.Limonciello@...l.com wrote:
> >
> > TB16 contains ASMedia host controller.  It's a Thunderbolt dock and all USB
> devices
> > are connected to ASMedia host controller in the dock.
> >
> > WD15 does not contain an ASMedia host controller, it connected to system's
> > USB host controller.
> 
> 
> Thank-you, Mario.
> 
> So.. why are we enabling the r8153 (USB-ethernet) workaround on this WD15
> dock?
> The discussion back in 2017 was that only the TB15/TB16 were affected by
> the XHCI overruns it produces?
> 
> --

The xHCI overrun workaround should only be applied on TB16/TB16, correct.

Can you double check the verbose information from lsusb for the r8153 device
on your WD15?

I just double checked on my on hand WD15 with an XPS 9380 and it's not activating the
quirk (bcdDevice was different).

If it's the same information as the TB16 (which it sounds like it is) Kai Heng and I will check
around internally to find out why they're looking the same.

I can hypothesize a few guesses of what happened.
My first guess would be a comparison issue with the logic in 176eb614b.

Looking at that commit, I guess I would ask on the compiler behavior of !strcmp().
Would that be matching the less than case as well as the zero case?
If so, it might need to be changed to strcmp() == 0.

My second guess would be maybe newer ethernet NVM in manufacturing.
My third guess would be a manufacturing issue putting wrong NVM image on your WD15.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ