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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170724210358.GC31959@roeck-us.net>
Date:   Mon, 24 Jul 2017 14:03:58 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Zdenek Kabelac <zkabelac@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>, dianders@...omium.org,
        gregkh@...uxfoundation.org
Subject: Re: USB disk speed regression WD Elements - with bisect result
 22547c4cc4fe20698a6a85a55b8788859134b8e4

On Mon, Jul 24, 2017 at 10:41:12AM -0400, Alan Stern wrote:
> On Mon, 24 Jul 2017, Zdenek Kabelac wrote:
> 
> > Hi
> > 
> > I've problem with my USB storage devices:  WD Elements 1TB.
> > (Bus 004 Device 002: ID 1058:10a8 Western Digital Technologies, Inc. Elements 
> > Portable (WDBUZG))
> > 
> > 
> > After kernel >4.9  when disk is attached via cable it has very low speed 
> > (less then 1MB/s).
> > 
> > It can run at full speed (>22MB/s) when the Linux kernel is fully rebooted (so 
> > disk is attached during the reboot of Lenovo T61, C2D, Fedora Rawhide).
> > 
> > However when >4.9 kernel is running and disk is just attached it's very slow.
> > 
> > I've played a bisect game - and the clean result has been:
> > 
> > 22547c4cc4fe20698a6a85a55b8788859134b8e4
> > 
> > When I just revert this patch with 4.13-rc1 - it's again running with full 
> > speed even when disk is attached (thus no reboot is needed for full speed).
> > 
> > 
> > So while I've no idea what 22547c4cc4fe20698... is doing, it seems to have 
> > some unpleasant side-effect on regular USB devices.
> > 
> > So what else is needed to get this properly working ?
> > (assuming plain revert of  22547c4cc4fe20698 is unwanted).
> > 
> > What more info can I provide to get this storage 'normally' usable without 
> > rebooting the machine.
> 
> Please post the dmesg logs showing what happens when the disk is 
> first attached and operates slowly, and what happens when the disk is 
> attached following a reboot and operates normally.
> 

Only idea I came up with is that some device may require more than one
port reset. Agreed, dmesg logs should give us an idea if this is the case.

I ordered one of those drives; maybe I can reproduce the problem.

Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ