Message-ID: <2024091128-imperial-purchase-f5e7@gregkh>
Date: Wed, 11 Sep 2024 11:43:26 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Dan Williams <dan.j.williams@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [regression] frozen usb mouse pointer at boot

On Wed, Sep 11, 2024 at 09:55:03AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker.
> 
> I noticed a report about a linux-6.6.y regression in bugzilla.kernel.org
> that appears to be caused by this commit from Dan applied by Greg:
> 
> 15fffc6a5624b1 ("driver core: Fix uevent_show() vs driver detach race")
> [v6.11-rc3, v6.10.5, v6.6.46, v6.1.105, v5.15.165, v5.10.224, v5.4.282,
> v4.19.320]
> 
> The reporter did not check yet if mainline is affected; decided to
> forward the report by mail nevertheless, as the maintainer for the
> subsystem is also the maintainer for the stable tree. ;-)
> 
> To quote from https://bugzilla.kernel.org/show_bug.cgi?id=219244 :

This is very odd, because:

> > The symptoms of this bug are as follows:
> > 
> > - After booting (to the graphical login screen) the mouse pointer
> > would frozen and only after unplugging and plugging-in again the usb
> > plug of the mouse would the mouse be working as expected.
> > - If one would log in without fixing the mouse issue, the mouse
> > pointer would still be frozen after login.
> > - The usb keyboard usually is not affected even though plugged into
> > the same usb-hub - thus logging in is possible.
> > - The mouse pointer is also frozen if the usb connector is plugged
> > into a different usb-port (different from the usb-hub)
> > - The pointer is moveable via the inbuilt synaptics trackpad

The patch from Dan should only affect when the module is unloaded, not
when the device is removed.

And it should not diferenciate between device types (i.e. mouse,
keyboard, etc.) as it affects ALL devices in the system.

> > The kernel log shows almost the same messages (not sure if the
> > differences mean anything in regards to this bug) for the initial
> > recognizing the mouse (frozen mouse pointer) and the re-plugged-in mouse
> > (and subsequently moveable mouse pointer):
> > 
> > [kernel] [    8.763158] usb 1-2.2.1.2: new low-speed USB device number 10 using xhci_hcd
> > [kernel] [    8.956028] usb 1-2.2.1.2: New USB device found, idVendor=045e, idProduct=00cb, bcdDevice= 1.04
> > [kernel] [    8.956036] usb 1-2.2.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> > [kernel] [    8.956039] usb 1-2.2.1.2: Product: Microsoft Basic Optical Mouse v2.0 
> > [kernel] [    8.956041] usb 1-2.2.1.2: Manufacturer: Microsoft 
> > [kernel] [    8.963554] input: Microsoft  Microsoft Basic Optical Mouse v2.0  as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2.1/1-2.2.1.2/1-2.2.1.2:1.0/0003:045E:00CB.0002/input/input18
> > [kernel] [    8.964417] hid-generic 0003:045E:00CB.0002: input,hidraw1: USB HID v1.11 Mouse [Microsoft  Microsoft Basic Optical Mouse v2.0 ] on usb-0000:00:14.0-2.2.1.2/input0
> > 
> > [kernel] [   31.258381] usb 1-2.2.1.2: USB disconnect, device number 10
> > [kernel] [   31.595051] usb 1-2.2.1.2: new low-speed USB device number 16 using xhci_hcd
> > [kernel] [   31.804002] usb 1-2.2.1.2: New USB device found, idVendor=045e, idProduct=00cb, bcdDevice= 1.04
> > [kernel] [   31.804010] usb 1-2.2.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> > [kernel] [   31.804013] usb 1-2.2.1.2: Product: Microsoft Basic Optical Mouse v2.0 
> > [kernel] [   31.804016] usb 1-2.2.1.2: Manufacturer: Microsoft 
> > [kernel] [   31.812933] input: Microsoft  Microsoft Basic Optical Mouse v2.0  as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2.1/1-2.2.1.2/1-2.2.1.2:1.0/0003:045E:00CB.0004/input/input20
> > [kernel] [   31.814028] hid-generic 0003:045E:00CB.0004: input,hidraw1: USB HID v1.11 Mouse [Microsoft  Microsoft Basic Optical Mouse v2.0 ] on usb-0000:00:14.0-2.2.1.2/input0
> > 
> > Differences:
> > 
> > ../0003:045E:00CB.0002/input/input18 vs ../0003:045E:00CB.0004/input/input20

That's normal, just a different name for the device, they are always
dynamic.

> > and
> > 
> > hid-generic 0003:045E:00CB.0002 vs hid-generic 0003:045E:00CB.0004

Again, different device names, all should be fine.

> > The connector / usb-port was not changed in this case!
> > 
> > 
> > The symptoms of this bug have been present at one point in the
> > recent
> > past, but with kernel v6.6.45 (or maybe even some version before that)
> > it was fine. But with 6.6.45 it seems to be definitely fine.
> > 
> > But with v6.6.46 the symptoms returned. That's the reason I
> > suspected
> > the kernel to be the cause of this issue. So I did some bisecting -
> > which wasn't easy because that bug would often times not appear if the
> > system was simply rebooted into the test kernel.
> > As the bug would definitely appear on the affected kernels (v6.6.46
> > ff) after shutting down the system for the night and booting the next
> > day, I resorted to simulating the over-night powering-off by shutting
> > the system down, unplugging the power and pressing the power button to
> > get rid of residual voltage. But even then a few times the bug would
> > only appear if I repeated this procedure before booting the system again
> > with the respective kernel.
> > 
> > This is on a Thinkpad with Kaby Lake and integrated Intel graphics. 
> > Even though it is a laptop, it is used as a desktop device, and the
> > internal battery is disconnected, the removable battery is removed as
> > the system is plugged-in via the power cord at all times (when in use)!
> > Also, the system has no power (except for the bios battery, of
> > course)
> > over night as the power outlet is switched off if the device is not in use.
> > 
> > Not sure if this affects the issue - or how it does. But for
> > successful bisecting I had to resort to the above procedure.
> > 
> > Bisecting the issue (between the release commits of v6.6.45 and
> > v6.6.46) resulted in this commit [1] being the probable culprit.
> > 
> > I then tested kernel v6.6.49. It still produced the bug for me. So I
> > reverted the changes of the assumed "bad commit" and re-compiled kernel
> > v6.6.49. With this modified kernel the bug seems to be gone.

This is odd.

Does the latest 6.10.y release also show this problem?

I can't duplicate this here, and it's the first I've heard of it (given
that USB mice are pretty popular, I would suspect others would have hit
it as well...)

thanks,

greg k-h

Powered by blists - more mailing lists