On 4/16/20 7:34 AM, Alan Stern wrote:
On Wed, 15 Apr 2020, Paul Zimmerman wrote:
Hi Alan,
On Wed, 15 Apr 2020 15:40:31 -0400 (EDT) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
Paul, I trust this new patch won't mess up your Bluetooth adapter. It
should still clear the hub->change_bits entry before the hub workqueue
thread wakes up.
Alan Stern
Unfortunately, my testing on this is somewhat inconclusive. I updated
to the latest Linus kernel, then did about a half-dozen suspend/resume
cycles to verify it was still working. Then I applied the patch and
rebooted into the new kernel. At first I thought it was OK, but after
about 5 or 6 suspend/resume cycles, the bluetooth stopped working (the
desktop bluetooth manager in Linux Mint froze when I opened it). Another
suspend/resume cycle brought it back to life, but after a couple more
cycles it froze again.
That sounds different from your original bug report. Didn't the
adapter fail in a significantly larger fraction of suspends?
Yes it did.
But looking at the dmesg log, there were no errors concerning the
bluetooth adapter. With the original failure, it would show errors
before or during the firmware update of the bluetooth adapter, but
now, the firmware update seemed to complete OK. And to top it off,
after a reboot, I am no longer able to make it fail. I did more than
a dozen suspend/resume cycles and have not seen any further failures.
So, make of that what you will :)
Overall, I guess we can call it a success. Do you want to collect a
usbmon trace to verify that the patch behaves as expected, or are you
happy with the testing so far?
I doubt a usbmon trace would show us anything unless I could get the
bluetooth to fail again. And since I was the only one who saw the
original problem anyway, I think it's fine to proceed with this patch
as-is.
Thanks,
Paul
