linux-kernel - Re: [REGRESSION][BISECTED] 5.5-rc suspend/resume failure caused by patch a4f55d8b8c14 ("usb: hub: Check device descriptor before resusciation")

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:   Mon, 20 Jan 2020 10:23:11 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Paul Zimmerman <pauldzim@...il.com>
cc:     David Heinzelmann <heinzelmann.david@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        <linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: Re: [REGRESSION][BISECTED] 5.5-rc suspend/resume failure caused by
 patch a4f55d8b8c14 ("usb: hub: Check device descriptor before resusciation")

On Sun, 19 Jan 2020, Paul Zimmerman wrote:

> I reported this regression last week (see
> https://lore.kernel.org/linux-usb/20200115153714.03d5b3aa@EliteBook/T/#u)
> but I got no response to my email. Today I have retested with 5.5-rc7
> and verified that the problem still exists. So I am resending with a
> different subject line to see if anyone responds.
> 
> The $subject patch causes a regression on my HP EliteBook laptop with a
> built-in USB bluetooth adapter. About 50% of the time, a suspend/resume
> cycle will cause the bluetooth adapter to stop working.
> 
> The dmesg log below shows two suspend/resume cycles. At time 63.928 you can
> see the bluetooth adapter being successfully resumed, and at time 140.969
> you can see it fail. After reverting the patch, the bluetooth adapter
> resumes 100% of the time.
> 
> I also included below a lsusb -v of the bluetooth adapter. Is there any
> other debugging info you'd like me to send?

It looks like your dmesg log was made without enabling debugging 
messages in usbcore.  Can you collect another log with debugging 
messages turned on?

	echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control

Also, it might not hurt to collect and post a usbmon trace for a bad
suspend-resume cycle.

Alan Stern