linux-kernel - Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

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:   Wed, 26 Jul 2017 19:49:21 +0200
From:   Zdenek Kabelac <zkabelac@...hat.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     LKML <linux-kernel@...r.kernel.org>, dianders@...omium.org,
        linux@...ck-us.net, gregkh@...uxfoundation.org
Subject: Re: USB disk speed regression WD Elements - with bisect result
 22547c4cc4fe20698a6a85a55b8788859134b8e4

Dne 25.7.2017 v 21:50 Alan Stern napsal(a):
> On Tue, 25 Jul 2017, Zdenek Kabelac wrote:
> 
> 
> 08:18 usb 2-2: USB disconnect, device number 2
> 08:25 usb 2-2: new high-speed USB device number 3 using ehci-pci
> 08:26 usb 2-2: new high-speed USB device number 4 using ehci-pci
> 
> If the drive were working entirely correctly, it wouldn't do that.
> 
> We could continue futzing around with hardware and driver tests for a
> long time.  But there may be a shortcut: If you have a USB hub, you
> could try attaching the drive through it.  It's entirely possible that
> this will fix the problem.
> 
> If not, you'll have to start doing some very detailed tests.  As a
> start, you can enable debugging for the usbcore and ehci_hcd drivers
> immediately before the test:
> 
> echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
> echo 'module ehci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
> dmesg -C
> 
> Then after the test, see what shows up in the dmesg output.  And again,
> we'll want to do a comparison.  In fact, 4.12 with and without the
> commit you identified would make a better comparison than 4.12 vs. 4.8.
> 


Hi


So here we go with traces - made with freshly compiled recent 4.13-rc2.
OK trace is with revert patch applied.
BAD trace is the one with it (essentially vaniala master).

Trace also has KOBJECT debugging enabled - I think difference is
nicely visible between them - but I've no explanation for it.

Both traces start with cable detach followed with attachment.

Regards

Zdenek

View attachment "OKtrace.txt" of type "text/plain" (34274 bytes)

View attachment "BADtrace.txt" of type "text/plain" (40048 bytes)