[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <73b325e3-d5d9-f768-9033-3aa0d3683e47@leemhuis.info>
Date: Sat, 4 Dec 2021 11:26:45 +0100
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: regressions@...ts.linux.dev, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: Regression: plugging in USB scanner breaks all USB functionality
On 04.12.21 11:03, Greg KH wrote:
> On Fri, Dec 03, 2021 at 06:24:52PM +0100, Thorsten Leemhuis wrote:
>> On 02.12.21 16:13, Thorsten Leemhuis wrote:
>>> Hi, this is your Linux kernel regression tracker speaking.
>>>
>>> Thanks for the report.
>>>
>>> Top-posting for once, to make this easy accessible to everyone.
>>>
>>> FWIW, 5.14 is EOL, so it might not be fixed there. As the problem is in
>>> newer kernels as well, I suspect that it was a change applies to 5.15 or
>>> 5.16 that got backported. Maybe one of the developers might have an idea
>>> which commit causes it. If that's not the case you likely should try a
>>> bisection to find the culprit. Performing one between v5.14.11..v5.14.14
>>> is likely the easiest and quickest way to find it.
>>>
>>> To be sure this issue doesn't fall through the cracks unnoticed, I'm
>>> adding it to regzbot, my Linux kernel regression tracking bot:
>>>
>>> #regzbot ^introduced v5.14.11..v5.14.14
>>> #regzbot title usb: plugging in USB scanner breaks all USB functionality
>>> [regression present in 5.15.2 und 5.16-rc3, too]
>>> #regzbot ignore-activity
>>
>> #regzbot introduced ff0e50d3564f
>> #regzbot fixed-by 385b5b09c3546c87cfb730b76abe5f8d73c579a2
>
> Odd, where did that git commit id come from? I don't see it in
> linux-next or Linus's tree.
>
> confused,
Yeah, sorry, after sending that mail it occurred to me that this wasn't
ideal and hard to follow.
I got it from here:
https://lore.kernel.org/lkml/a649395b-0b91-a0d2-c510-ea8ec4aef917@linux.intel.com/
I already decided that next time something like this comes up I'll reply
to the mail with the details instead (with proper quoting) to make this
easier to follow.
Reading that message again I suspect that I might have been a bit quick
as well, as this might not be the commit id this ends up with when it
gets merged: I now see that this is likely a developers tree and not one
that gets indirectly merged.
Sorry, I'll manually keep an eye on things to fix this up once that
patch gets its real it.
Ciao, Thorsten
BTW, while at it:
#regzbot monitor
https://lore.kernel.org/linux-usb/20211126122340.1193239-2-mathias.nyman@linux.intel.com/
Powered by blists - more mailing lists