Bug 217412

I can imagine not a lot of people have your HW and run 6.3.1, so it'd be best perform regression testing using git bisect.

https://docs.kernel.org/admin-guide/bug-bisect.html

What do you mean with : "I can imagine not a lot of people have your HW and run 6.3.1" ?

I was advise by Archlinux bugs to report the bug here :

https://bugs.archlinux.org/task/78427#comment217717

But as you suggest I'm going to report it to systemd/udev.

The bug is reported by systemd/udev :

https://github.com/systemd/systemd/issues/27557

This looks like a kernel regression, no idea why you filed a bug report in systemd bug tracker.

You really could perform regression testing using git bisect.

https://docs.kernel.org/admin-guide/bug-bisect.html

This problem is 100% reproducible for me on Arch with current kernel 6.3.1 and goes away if I downgrade to previous 6.2.13 so not a systemd issue.

@ Artem S. Tashkinov, because in your bug-bisect link they say first :

Devices not appearing

Often this is caused by udev/systemd. Check that first before blaming it on the kernel.

That's why I did it.

Anyway, I will try to bisect but I have never done that, I'm not so confident.

@guy.b: have you tried booting 6.2.y again to see if this goes away? If you confirm this I'll forward the report to the developers, maybe you are lucky and they have an idea what might cause this, then a bisection won't be needed. But if you are unlucky, one will be needed...

@ Thorsten : I can confirm that downgrading to 6.2.13 the problem goes away and no hang nor boot errors. And no problem/hangs by removing/plugging the receiver after the boot.

It will be really difficult to bisect because I have not the knowledge fir that.

(In reply to guy.b from comment #8)
> @ Thorsten : I can confirm that downgrading to 6.2.13 the problem goes away

thx.

Can I CC you on the mails when forwarding the report?
 
> It will be really difficult to bisect because I have not the knowledge fir
> that.

Then let's hope the developers have a clue -- or that somebody else runs into this and is able to bisect it.

> Can I CC you on the mails when forwarding the report?

Sure.

>Then let's hope the developers have a clue -- or that somebody else runs into
>>this and is able to bisect it.

Mark Blakeney (comment 5) is also affected and maybe able to bisect that ?

Anyway, thank you very much.

Bisection is time consuming so if I get time I will do it.

Forwarded:

https://lore.kernel.org/regressions/9b987585-0834-bb8c-3414-283c29f3f2ab@leemhuis.info/T/#u

I can confirm the issue since 6.3.1, made my boot time increase by 17 seconds

Folks, a quick remark is I may:

If you specify a version that is broken, it would help a lot if you also specify the last version that was working: it's quite a difference if something broke when updating from 6.2.y to 6.3.y or when updating from 6.3 to 6.3.1

@Thorsten, as guy.b and I said above, this problem was introduced with kernel 6.3.1 and does not occur with previous kernel 6.2.13.

I also see this (similar) with 6.3.1 and not on 6.2.12 using openSuse tumbleweed although it doesnt seem to affect my boot times, it does show up in dmesg

I see no difference with boot with hangs on boot process. But since linux update from 6.2.13 to 6.3.1 I hit system freeze every time I use a scroll wheel. In console, or somewhere, I saw that it's in fact kernel panic.

Additionally, I'm hitting logs like this with my M560 for a very long time:

logitech-hidpp-device 0003:046D:402D.0010: error in parameter

Also having a second receiver with paired K360.

Is this the same issue or related? How can I help with hunting the bug?

@Thorsten, Arch never released kernel 6.3, the core package went from 6.2.13 to 6.3.1 because 6.3.1 was so soon after 6.3. However, I noticed that the Arch kernel maintainer did build 6.3 and it got as far as the testing repo. So I was able to download Arch kernel 6.3 and confirm that this bug exists there also. So we know at least that this bug was introduced between 6.2.13 and 6.3.

In 6.2.13 I see:```
dmesg | grep "3-10"
[    6.709222] usb 3-10: new full-speed USB device number 5 using xhci_hcd
[    6.851805] usb 3-10: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=12.11
[    6.851808] usb 3-10: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    6.851809] usb 3-10: Product: USB Receiver
[    6.851810] usb 3-10: Manufacturer: Logitech
[    8.107111] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/0003:046D:C52B.0003/input/input18
[    8.165029] input: Logitech USB Receiver Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.1/0003:046D:C52B.0004/input/input19
[    8.165154] input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.1/0003:046D:C52B.0004/input/input20
[    8.219364] input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.1/0003:046D:C52B.0004/input/input21
[    8.712336] input: Logitech Wireless Device PID:4013 Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.2/0003:046D:C52B.0005/0003:046D:4013.0006/input/input23
[    9.007809] input: Logitech M525 as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.2/0003:046D:C52B.0005/0003:046D:4013.0006/input/input28
```
in 6.3.1 I see```
[    6.619711] usb 3-10: new full-speed USB device number 5 using xhci_hcd
[    6.762393] usb 3-10: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=12.11
[    6.762397] usb 3-10: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    6.762398] usb 3-10: Product: USB Receiver
[    6.762399] usb 3-10: Manufacturer: Logitech
[    7.811131] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/0003:046D:C52B.0003/input/input18
[    7.866743] hid-generic 0003:046D:C52B.0003: input,hidraw2: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-10/input0
[    7.868586] input: Logitech USB Receiver Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.1/0003:046D:C52B.0004/input/input19
[    7.868735] input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.1/0003:046D:C52B.0004/input/input20
[    7.923150] input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.1/0003:046D:C52B.0004/input/input21
[    7.923297] hid-generic 0003:046D:C52B.0004: input,hiddev96,hidraw3: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-10/input1
[    7.924828] hid-generic 0003:046D:C52B.0005: hiddev97,hidraw4: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-10/input2
[    8.363587] logitech-djreceiver 0003:046D:C52B.0005: hiddev96,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-10/input2
[    8.477931] input: Logitech Wireless Device PID:4013 Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.2/0003:046D:C52B.0005/0003:046D:4013.0006/input/input23
[    8.478134] hid-generic 0003:046D:4013.0006: input,hidraw3: USB HID v1.11 Mouse [Logitech Wireless Device PID:4013] on usb-0000:00:14.0-10/input2:1
[    8.629712] input: Logitech Wireless Device PID:4013 as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.2/0003:046D:C52B.0005/0003:046D:4013.0006/input/input27
[    8.629812] logitech-hidpp-device 0003:046D:4013.0006: input,hidraw3: USB HID v1.11 Mouse [Logitech Wireless Device PID:4013] on usb-0000:00:14.0-10/input2:1
[   11.145979] logitech-hidpp-device 0003:046D:4013.0006: Can not get the protocol version.
[   24.031984] logitech-hidpp-device 0003:046D:4013.0006: Can not get the protocol version.
[   30.958007] logitech-hidpp-device 0003:046D:4013.0006: Can not get the protocol version.
[  631.154620] logitech-hidpp-device 0003:046D:4013.0006: HID++ 2.0 device connected.
```
or
```
[  805.759471] usb 3-10: USB disconnect, device number 10
[  860.372927] usb 3-10: new full-speed USB device number 11 using xhci_hcd
[  860.515729] usb 3-10: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=12.11
[  860.515732] usb 3-10: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  860.515734] usb 3-10: Product: USB Receiver
[  860.515735] usb 3-10: Manufacturer: Logitech
[  643.615271] logitech-djreceiver 0003:046D:C52B.0009: hiddev96,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-10/input2
[  643.738605] input: Logitech Wireless Device PID:4013 as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.2/0003:046D:C52B.0009/0003:046D:4013.000A/input/input28
[  643.738733] logitech-hidpp-device 0003:046D:4013.000A: input,hidraw3: USB HID v1.11 Mouse [Logitech Wireless Device PID:4013] on usb-0000:00:14.0-10/input2:1
[  645.552597] logitech-hidpp-device 0003:046D:4013.000A: Can not get the protocol version.
[  696.092699] logitech-hidpp-device 0003:046D:4013.000A: Can not get the protocol version.
[  860.515735] usb 3-10: Manufacturer: Logitech
[  860.523047] logitech-djreceiver 0003:046D:C52B.000D: hiddev96,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-10/input2
[  860.644553] logitech-hidpp-device 0003:046D:4013.000E: HID++ 1.0 device connected.
[  860.650601] input: Logitech Wireless Device PID:4013 as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.2/0003:046D:C52B.000D/0003:046D:4013.000E/input/input29
[  860.650894] logitech-hidpp-device 0003:046D:4013.000E: input,hidraw3: USB HID v1.11 Mouse [Logitech Wireless Device PID:4013] on usb-0000:00:14.0-10/input2:1
```
Notice the HID++ protocol is not stable, sometimes I get HID++ 1.0 but most of the time it shows HID++ 2.0.  Also in 6.2.13 the device shows as M525 in the last log entry.  In 6.3.1 I seem PID:4013 instead, which is a lot less human friendly.

Another point, in 6.2.13 upower --dump gives reasonable numbers and updates.  In 6.3.1 upower is not nearly as stable, sometimes nothing is shown, other time it has a value but does not update it after a battery change, unlike 6.2.13

I poked the developers as so many affected users showed up here, but in the end there is still a decent chance that someone that's affected has to bisect to make progress. 

FWIW, here is a document to build a trimmed kernel:
https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html

With such a config a bisect from v6.2 to v6.3 shouldn't take that long.

Looks like the issue has been resolved in 6.4-rc1

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/hid/hid-logitech-hidpp.c?id=v6.4-rc1&id2=v6.3

I can confirm installing linux-mainline 6.4rc1-1 on ArchLinux that the issue has been resolved

(In reply to Ali Molaei from comment #22)
> Looks like the issue has been resolved in 6.4-rc1

That's good to know, but doesn't bring us much closer to fixing this in 6.3.y, as we'd need to known which change(s) fixes the issue.

To get closer it would be great:

* if at least one other person could confirm 6.4-rc1 fixes things for them
* if anyone could check before if 2653e3fe33 is broken and d9d5623f37c0a2 is fine; and if it is, do a bisection in that range to identify the change(s) that fixes things

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/hid/hid-logitech-hidpp.c

Hi,

I built 6.4-rc1.  I still see the same errors:

[    6.683606] usb 3-10: new full-speed USB device number 5 using xhci_hcd
[    6.829310] usb 3-10: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=12.11
[    6.829317] usb 3-10: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    6.829319] usb 3-10: Product: USB Receiver
[    6.829320] usb 3-10: Manufacturer: Logitech
[    7.827959] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/0003:046D:C52B.0003/input/input18
[    7.883789] hid-generic 0003:046D:C52B.0003: input,hidraw2: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-10/input0
[    7.885608] input: Logitech USB Receiver Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.1/0003:046D:C52B.0004/input/input19
[    7.885659] input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.1/0003:046D:C52B.0004/input/input20
[    7.940397] input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.1/0003:046D:C52B.0004/input/input21
[    7.940564] hid-generic 0003:046D:C52B.0004: input,hiddev96,hidraw3: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-10/input1
[    7.941941] hid-generic 0003:046D:C52B.0005: hiddev97,hidraw4: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-10/input2
[    8.394981] logitech-djreceiver 0003:046D:C52B.0005: hiddev96,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-10/input2
[    8.515190] input: Logitech Wireless Device PID:4013 Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.2/0003:046D:C52B.0005/0003:046D:4013.0006/input/input23
[    8.517679] hid-generic 0003:046D:4013.0006: input,hidraw3: USB HID v1.11 Mouse [Logitech Wireless Device PID:4013] on usb-0000:00:14.0-10/input2:1
[    8.617323] input: Logitech Wireless Device PID:4013 as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.2/0003:046D:C52B.0005/0003:046D:4013.0006/input/input27
[    8.617432] logitech-hidpp-device 0003:046D:4013.0006: input,hidraw3: USB HID v1.11 Mouse [Logitech Wireless Device PID:4013] on usb-0000:00:14.0-10/input2:1
[ 5752.989406] logitech-hidpp-device 0003:046D:4013.0006: Can not get the protocol version.

and upower --dump no longer see the logitech device at all (eg.  The regression has got worst)

And to all reporters here, kernel documentation has already covered bisection [1]. Hope it helps.

[1]: https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html

I'm experiencing boot delays with a Logitech Unifying Receiver plugged in.


586e8fede7953b1695b5ccc6112eff9b052e79ac is the first bad commit
commit 586e8fede7953b1695b5ccc6112eff9b052e79ac
Author: Bastien Nocera <hadess@hadess.net>
Date:   Thu Feb 9 16:49:15 2023 +0100

    HID: logitech-hidpp: Retry commands when device is busy
    
    Handle the busy error coming from the device or receiver. The
    documentation says a busy error can be returned when:
    "
    Device (or receiver) cannot answer immediately to this request
    for any reason i.e:
    - already processing a request from the same or another SW
    - pipe full
    "
    
    Signed-off-by: Bastien Nocera <hadess@hadess.net>
    Link: https://lore.kernel.org/r/20230209154916.462158-1-hadess@hadess.net
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

 drivers/hid/hid-logitech-hidpp.c | 54 ++++++++++++++++++++++------------------
 1 file changed, 30 insertions(+), 24 deletions(-)

(In reply to poncho from comment #26)

> 586e8fede7953b1695b5ccc6112eff9b052e79ac is the first bad commit

thx for bisecting. Could you (and ideally at least one other person affected by this) please try if reverting this ontop of latest mainline (and/or 6.3.y) actually works and solves the problem?

Reverting 586e8fede7953b1695b5ccc6112eff9b052e79ac on top of 6.3.y fixes the issue




I can't reproduce the issue on mainline.
Using git bisect start --term-new=fixed --term-old=unfixed results in:

e0138763be2d8bcc181c2f6110ef0f66979f1ce4 is the first fixed commit
commit e0138763be2d8bcc181c2f6110ef0f66979f1ce4
Author: Bastien Nocera <hadess@hadess.net>
Date:   Thu Mar 2 11:55:50 2023 +0100

    HID: logitech-hidpp: Simplify array length check
    
    Use the compiler to force a 100-length array, rather than check the
    length after the fact.
    
    Signed-off-by: Bastien Nocera <hadess@hadess.net>
    Link: https://lore.kernel.org/r/20230302105555.51417-1-hadess@hadess.net
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

 drivers/hid/hid-logitech-hidpp.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

As suggested on Archlinux (my original bug report) by loqs :

https://bugs.archlinux.org/task/78427

A "detail" : By non working kernels in xfce desktop > parameters > mouse/keyboard the name of the devices are not listed (example logitech K800) but the device id (0003:046D:2010.0005).

And as already mentioned by Ed Tomlinson in #19.

Could anybody (ideally someone for whom 6.4-rc is still broken) check if reverting 586e8fede7953b1695b5ccc6112eff9b052e79ac in 6.3 fixes the problem?

We have the unfortunate situation that the primary person that has to look into this is not available this month, so any help from you would help to speed things up.

And that test would be useful, as I wonder if we deal with two different issues here, because 6.4-rc doesn't fix it for everyone).

I can confirm that the bug takes about 16 seconds of boot time. 
I am also having issues when trying to wake up the system from sleep with my mouse or keyboard using the receiver in conjunction to the slow boot.

Linus himself briefly looked into this an provided a entirely untested patch that might or might not help. Maybe someone is willing to give it a try:

https://lore.kernel.org/all/CAHk-%3DwhvhkSk6m8_AidhofgR9nq0Md%2BHbNad5r1RE69tZgbv6Q@mail.gmail.com/

I have tried Archlinux patched kernel with that patch :

https://lore.kernel.org/all/CAHk-%3DwhvhkSk6m8_AidhofgR9nq0Md%2BHbNad5r1RE69tZgbv6Q%40mail.gmail.com/

Still buggy and no changes.

A patch for the overly long boot times on some systems is available here:
https://patchwork.kernel.org/project/linux-input/patch/20230531082428.21763-1-hadess@hadess.net/

I'd appreciate testing, you can even import the mbox of the patch into your email client to reply to it and the mailing-list.

(In reply to guy.b from comment #33)
> I have tried Archlinux patched kernel with that patch :
> 
> https://lore.kernel.org/all/CAHk-
> %3DwhvhkSk6m8_AidhofgR9nq0Md%2BHbNad5r1RE69tZgbv6Q%40mail.gmail.com/
> 
> Still buggy and no changes.

If reverting 586e8fede7953b1695b5ccc6112eff9b052e79ac doesn't fix the problem for you, I would absolutely need a bisect run to figure out which patch introduced the problem.

That 1st patch in the above comment does not fix the ~15 sec delay when re-plugging my logitech receiver which is the clearest way I test for this bug. There is no delay with previous working (i.e. 6.2.13 and earlier) kernels.

I should add that reverting 586e8fede7953b1695b5ccc6112eff9b052e79ac does fix the problem for me.

I can confirm as Mark Blakeney #36 that reverting 586e8fede7953b1695b5ccc6112eff9b052e79ac does fix the problem for me as well.

A fix for this is now in master; I'll try to ensure it will also be picked up for next weeks stable release.
https://git.kernel.org/torvalds/c/6199d23c91ce53bfed455f09a8c5ed170d516824

If anyone afterwards still has problems, open a new bug and drop a quick note about it here.

@ Thorsten Leemhuis : To be clear, the patch mentioned in your #38 link doesn't fix the problem. We (Mark Blakeney & myself) tested it without success on the  linux-6.3.5.arch1-1.1. The only fix is the modified linux-6.3.2.arch1-1.1 from here done by loqs :

https://bugs.archlinux.org/task/78427

(In reply to guy.b from comment #39)
> To be clear [...]

I suspected something like that, as there were already indicators that we deal with two different issues here. That's why the comment you mentioned contains: 

If anyone afterwards still has problems, *open a new bug* and drop a quick note about it here.

Thanks for the explanation.

As soon as the patch #38 will be introduced I will test it and consequently open an other bug report if not fixed.

(In reply to guy.b from comment #41)

> As soon as the patch #38 will be introduced I will test it and consequently
> open an other bug report if not fixed.

FWIW, there is no need to wait, if either (a) mainline or (b) a 6.3.y kernel with 6199d23c91ce applied ontop still shows a regression for you.

(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #42)
> (In reply to guy.b from comment #41)
> 
> > As soon as the patch #38 will be introduced I will test it and consequently
> > open an other bug report if not fixed.
> 
> FWIW, there is no need to wait, if either (a) mainline or (b) a 6.3.y kernel
> with 6199d23c91ce applied ontop still shows a regression for you.

Ok, done here :

https://bugzilla.kernel.org/show_bug.cgi?id=217523

This is now solved by

    https://git.kernel.org/linus/7c28afd5512e371773dbb2bf95a31ed5625651d9

in Linus' tree.

Tested right now and can confirm that the boot delay and unplug/plug hang is solved with :

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6199d23c91ce53bfed455f09a8c5ed170d516824
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7c28afd5512e371773dbb2bf95a31ed5625651d9

Applied on Archlinux kernel linux-6.3.6.arch1-1.3-x86_64

Thanks a lot.

Just wondering, if this fix has fould its way to released kernels yet?


My Logitech G613 G keys as diverted keys broke (they are dead as diverted) when updating from 6.2.9 to 6.3.2. G keys are still dead as diverted. In https://forums.opensuse.org/t/logitech-g613-keyboards-g-keys-stopped-working-under-solaar-control/166336 discussion I got suggested to follow this bug, that's why I am asking here, if fix is now in kernel.

@Juha, kernel 6.3.7 adds the 2 patches intended to fix this bug and the startup delay is now gone. However, I have had 2 cases over the last 5 days in which I have been running 6.3.7 where my mouse fails to be detected at all after startup. I have to pull the Logitech receiver out/in to get the mouse working. Never seen this issue before so I suspect the patches are not right.

(In reply to Mark Blakeney from comment #47)
> @Juha, kernel 6.3.7 adds the 2 patches intended to fix this bug and the
> startup delay is now gone. However, I have had 2 cases over the last 5 days
> in which I have been running 6.3.7 where my mouse fails to be detected at
> all after startup. I have to pull the Logitech receiver out/in to get the
> mouse working. Never seen this issue before so I suspect the patches are not
> right.

Thx for bringing this up. I just brought this to the developers attention, but you might want to open a fresh bug for this and afterwards add a link to it here, as your problem otherwise might easily fall through the cracks.

(In reply to Mark Blakeney from comment #47)
> @Juha, kernel 6.3.7 adds the 2 patches intended to fix this bug and the
> startup delay is now gone. However, I have had 2 cases over the last 5 days
> in which I have been running 6.3.7 where my mouse fails to be detected at
> all after startup. I have to pull the Logitech receiver out/in to get the
> mouse working. Never seen this issue before so I suspect the patches are not
> right.

Mark, as per https://lore.kernel.org/all/CAO-hwJLyA%3D%3D_Wkyi-gTn-FOAAne2JKDfNMY2EaELoFDo5Qbe-A@mail.gmail.com/, could you please give this patch a try:

https://lore.kernel.org/linux-input/20230621-logitech-fixes-v1-1-32e70933c0b0@redhat.com/

@Thorsten, I will when I get back from holidays in 5 days. The issue is not reproducible and occurs only VERY intermittently so any patch will be hard to prove.

Hi,

After this morning boot with the new 6.3.9 archlinux kernel update the uevent triggering is hanging again few seconds, the unplug/plug is working properly :

jun 23 07:35:27 Cockpit systemd[1]: Finished Load Kernel Module loop.
jun 23 07:35:27 Cockpit systemd[1]: Repartition Root Disk was skipped because no trigger condition checks were met.
jun 23 07:35:33 Cockpit kernel: logitech-hidpp-device 0003:046D:2010.0005: HID++ 1.0 device connected.
jun 23 07:35:36 Cockpit systemd-tty-ask-password-agent[429]: Password query on /dev/tty1 finished successfully.

Sorry, it was only the first boot after the update that was hanging the next are fine, so no problem with 6.3.9.

IDK if I face related problem, but I am running mainline Kernel tag v6.4 only with this patch:
https://lore.kernel.org/linux-acpi/20230601221151.670-1-mario.limonciello@amd.com/T/#u

and any external mouse I can find does not work - either generic Gigabyte-branded USB mouse by showing as:
[  323.729146] usb 3-1: New USB device found, idVendor=093a, idProduct=2521, bcdDevice= 1.00
[  323.729154] usb 3-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[  323.729158] usb 3-1: Product: USB OPTICAL MOUSE

or Fujitsu-branded wireless mouse, with receiver showing as:

[ 1686.950309] usb 3-1: New USB device found, idVendor=1a81, idProduct=1004, bcdDevice= 0.01
[ 1686.950316] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1686.950319] usb 3-1: Product: Wireless Dongle
[ 1686.950320] usb 3-1: Manufacturer: G-Tech

or even Microsoft Arc bluetooth mouse.

Every device just show up and connect properly, but does not work - no reaction whatsoever to clicking, rolling wheel, etc. No errors in dmesg.

I also could not find any other related bug here so before I open up a new one, am I missing something? Should your patch already be applied to 6.4? Could it be something with the IRQ override patch?

@Juha, I won't bother with the patches you suggest because I experienced those failures on kernel 6.3.7 but Arch has updated to 6.3.8 and now 6.3.9 (since 5 days ago) and I have not seen the issue on those kernels.

(In reply to Marek Šanta from comment #53)
> IDK if I face related problem,

This is most likely to be unrelated. 

> but I am running mainline Kernel tag v6.4
> only with this patch:
> https://lore.kernel.org/linux-acpi/20230601221151.670-1-mario.
> limonciello@amd.com/

You want to try 6.4 without that patch to check if the issue vanishes. 

You might also want to test with a older kernel to ensure it's really the kernel that is causing your problem.

I believe that patches associated with this bug may well be the cause of problems
with Fedora 38 kernels and Logitech Rxs.
May I refer you to
https://bugzilla.redhat.com/show_bug.cgi?id=2227221

System lockups "sometimes" occur when disconnecting Logitech receivers.
They are not present when using a wired Logitech mice.

kernel-6.3.11-200.fc38.x86_64 works OK but
later kernels up to and including 6.4.12-200.fc38.x86_64 cause crashes.

(In reply to ja from comment #56)
> I believe that patches associated with this bug may well be the cause of
> problems
> with Fedora 38 kernels and Logitech Rxs.
> May I refer you to
> https://bugzilla.redhat.com/show_bug.cgi?id=2227221

That might or might not be related, hence it's best discussed in a seperte mug, as things otherwise might get confusing. 

But before you open a new ticket, could you please check if https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=60165ab774cb0c helps (it will likely be in 6.6-rc1 in ~10 days from now)

There is a thread about Logitech dongles causing kernel hangs (not total hangs, but bringing machine unusable, forcing hard reboot), which refers to this bugzilla as possible source: https://community.frame.work/t/tracking-12-gen-fedora-38-crashed-on-usb-disconnect/35366
Every stack trace there mentions logi_dj_remove, but I don't see that mentioned here. Could someone with some insights perhaps say if the above fixes would fix this as well?



Recapping my own report. On 6.4.12 and onward (but not quite sure where) I started noticing that when I switched away my USB hub, which has a unifying receiver in it, I sporadically get these hangs. The computer is still responsible, but not in a stable way. For example sway works and existing TCP connections work, but I cannot create new TCP connections and I cannot run some commands, like sudo. So essentially in a useless state. 

* Arch Linux
* kernel 6.4.12
* Onboard USB ports on Asus X570 Prime motherboard with AMD Ryzen 5900x. lspci reports as USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
* Aten US224 USB switch, with a Logitech wireless keyboard & a yubikey
* A lot of things running, keyboard and yubikey not in active use while switching



BUG: unable to handle page fault for address: ffffafe963344a80
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 100000067 P4D 100000067 PUD 1001e7067 PMD 11b23e067 PTE 0 
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 2681961 Comm: kworker/0:2 Tainted: P           OE      6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
Hardware name: System manufacturer System Product Name/PRIME X570-PRO, BIOS 4802 06/15/2023
Workqueue: usb_hub_wq hub_event
RIP: 0010:power_supply_uevent+0xee/0x1d0
Code: 75 4e 48 8b 13 48 83 7a 28 00 74 75 45 31 ff 31 c0 eb 10 48 8b 13 41 83 c7 01 49 63 c7 48 3b 42 28 73 5e 48 8b 52 20 8>
RSP: 0018:ffffafe9452337b8 EFLAGS: 00010297
RAX: 0000000000000003 RBX: ffff989f96299800 RCX: ffff98a148934000
RDX: 00000000f0889610 RSI: 00000000c6808203 RDI: ffff989f96299800
RBP: ffff989f96299838 R08: 0000000000000007 R09: ffff989f1aeaa308
R10: ffffffffffffffff R11: 0000000000000000 R12: ffff989e1aeaa000
R13: 0000000000000000 R14: ffff98a148934000 R15: 0000000000000003
FS:  0000000000000000(0000) GS:ffff98acaea00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffafe963344a80 CR3: 000000016789c000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 <TASK>
 ? __die+0x23/0x70
 ? page_fault_oops+0x171/0x4e0
 ? srso_alias_return_thunk+0x5/0x7f
 ? exc_page_fault+0x175/0x180
 ? asm_exc_page_fault+0x26/0x30
 ? power_supply_uevent+0xee/0x1d0
 ? power_supply_uevent+0x10d/0x1d0 
 ? srso_alias_return_thunk+0x5/0x7f
 dev_uevent+0x112/0x2d0
 kobject_uevent_env+0x294/0x680
 power_supply_unregister+0x8e/0xa0 
 release_nodes+0x40/0xb0
 devres_release_all+0x8c/0xc0
 device_unbind_cleanup+0xe/0x70
 device_release_driver_internal+0x1cc/0x200
 bus_remove_device+0xc6/0x130
 device_del+0x15c/0x3e0
 ? __queue_work+0x1df/0x440
 hid_destroy_device+0x4b/0x60
 logi_dj_remove+0x9a/0x100 [hid_logitech_dj d43d018d7924207bf124eb09ddb07ddd68a2e21b]
 hid_device_remove+0x47/0x90
 device_release_driver_internal+0x19f/0x200
 bus_remove_device+0xc6/0x130
 device_del+0x15c/0x3e0
 ? __queue_work+0x1df/0x440
 hid_destroy_device+0x4b/0x60
 usbhid_disconnect+0x47/0x60 [usbhid 7dfa265d9e4e418c5b40b99cb0a80cd663a1de29]
 usb_unbind_interface+0x93/0x270
 device_release_driver_internal+0x19f/0x200
 bus_remove_device+0xc6/0x130
 device_del+0x15c/0x3e0
 ? srso_alias_return_thunk+0x5/0x7f
 ? kobject_put+0xa0/0x1d0
 usb_disable_device+0xcd/0x1e0
 usb_disconnect+0xde/0x2c0
 usb_disconnect+0xc3/0x2c0
 hub_event+0xea5/0x1c80
 ? srso_alias_return_thunk+0x5/0x7f
 ? __mod_timer+0x11f/0x370
 process_one_work+0x1c7/0x3d0
 worker_thread+0x51/0x390
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe8/0x120
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2c/0x50
 </TASK>
Modules linked in: exfat vhost_net vhost vhost_iotlb tap tun xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_ne>
 drm_display_helper platform_profile crypto_simd rfkill asus_ec_sensors mxm_wmi wmi_bmof mousedev mc snd_timer igb cryptd ce>
CR2: ffffafe963344a80
---[ end trace 0000000000000000 ]---
RIP: 0010:power_supply_uevent+0xee/0x1d0
Code: 75 4e 48 8b 13 48 83 7a 28 00 74 75 45 31 ff 31 c0 eb 10 48 8b 13 41 83 c7 01 49 63 c7 48 3b 42 28 73 5e 48 8b 52 20 8>
RSP: 0018:ffffafe9452337b8 EFLAGS: 00010297
RAX: 0000000000000003 RBX: ffff989f96299800 RCX: ffff98a148934000
RDX: 00000000f0889610 RSI: 00000000c6808203 RDI: ffff989f96299800
RBP: ffff989f96299838 R08: 0000000000000007 R09: ffff989f1aeaa308
R10: ffffffffffffffff R11: 0000000000000000 R12: ffff989e1aeaa000
R13: 0000000000000000 R14: ffff98a148934000 R15: 0000000000000003
FS:  0000000000000000(0000) GS:ffff98acaea00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffafe963344a80 CR3: 000000016789c000 CR4: 0000000000750ef0
PKRU: 55555554

(In reply to Johan from comment #58)
> There is a thread about Logitech dongles causing kernel hangs (not total
> hangs, but bringing machine unusable, forcing hard reboot), which refers to
> this bugzilla as possible source:
> https://community.frame.work/t/tracking-12-gen-fedora-38-crashed-on-usb-
> disconnect/35366
> Every stack trace there mentions logi_dj_remove, but I don't see that
> mentioned here. Could someone with some insights perhaps say if the above
> fixes would fix this as well?

Please try a kernel with commit 60165ab774cb0c ("HID: logitech-hidpp: rework one more time the retries attempts") [e.g. v6.6-rc1, v6.5.3, v6.4.16 or later] and see if it helps.

(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #59)
> (In reply to Johan from comment #58)
> > There is a thread about Logitech dongles causing kernel hangs (not total
> > hangs, but bringing machine unusable, forcing hard reboot), which refers to
> > this bugzilla as possible source:
> > https://community.frame.work/t/tracking-12-gen-fedora-38-crashed-on-usb-
> > disconnect/35366
> > Every stack trace there mentions logi_dj_remove, but I don't see that
> > mentioned here. Could someone with some insights perhaps say if the above
> > fixes would fix this as well?
> 
> Please try a kernel with commit 60165ab774cb0c ("HID: logitech-hidpp: rework
> one more time the retries attempts") [e.g. v6.6-rc1, v6.5.3, v6.4.16 or
> later] and see if it helps.

Unfortunately no easy way for me to do this, openzfs does not yet support >=6.5, and arch-linux last build of the 6.4 package was 6.4.12 (Now it's 6.5). I could perhaps figure out how to build the 6.4.16 myself but unfortunately don't have the time atm.
Staying on linux-lts (6.1) for now, hoping for the 6.5 support in openzfs next release to come soon.

Unfortunately it appears that 6.5.3 does not fix the issue, at least not on Arch:

Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08
Sep 22 20:01:35 eric kernel: #PF: supervisor write access in kernel mode
Sep 22 20:01:35 eric kernel: #PF: error_code(0x0002) - not-present page
Sep 22 20:01:35 eric kernel: PGD 100000067 P4D 100000067 PUD 1001eb067 PMD 0 
Sep 22 20:01:35 eric kernel: Oops: 0002 [#1] PREEMPT SMP NOPTI
Sep 22 20:01:35 eric kernel: CPU: 17 PID: 1256 Comm: kworker/17:3 Tainted: G     U     OE      6.5.3-arch1-1 #1 ed5b3b894d0aeb37298a77837232ca9b353cc27d
Sep 22 20:01:35 eric kernel: Hardware name: Framework Laptop (12th Gen Intel Core)/FRANMACP08, BIOS 03.05 08/23/2022
Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event
Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel: Code: 75 4e 48 8b 13 48 83 7a 28 00 74 75 45 31 ff 31 c0 eb 10 48 8b 13 41 83 c7 01 49 63 c7 48 3b 42 28 73 5e 48 8b 52 20 8b 14 8>
Sep 22 20:01:35 eric kernel: RSP: 0018:ffffb214048637a8 EFLAGS: 00010297
Sep 22 20:01:35 eric kernel: RAX: 0000000000000003 RBX: ffff8fefee72a000 RCX: ffff8ff06f6d7000
Sep 22 20:01:35 eric kernel: RDX: 000000004bda3ad9 RSI: 0000000088d38080 RDI: ffff8fefee72a000
Sep 22 20:01:35 eric kernel: RBP: ffff8fefee72a038 R08: 0000000000000007 R09: ffff8ff113a5932f
Sep 22 20:01:35 eric kernel: R10: ffffffffffffffff R11: ffffb21404863840 R12: ffff8ff013a59000
Sep 22 20:01:35 eric kernel: R13: 0000000000000000 R14: ffff8ff06f6d7000 R15: 0000000000000003
Sep 22 20:01:35 eric kernel: FS:  0000000000000000(0000) GS:ffff8fff2fa40000(0000) knlGS:0000000000000000
Sep 22 20:01:35 eric kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 22 20:01:35 eric kernel: CR2: ffffb2140e017f08 CR3: 0000000e78020000 CR4: 0000000000750ee0
Sep 22 20:01:35 eric kernel: PKRU: 55555554
Sep 22 20:01:35 eric kernel: Call Trace:
Sep 22 20:01:35 eric kernel:  <TASK>
Sep 22 20:01:35 eric kernel:  ? __die+0x23/0x70
Sep 22 20:01:35 eric kernel:  ? page_fault_oops+0x171/0x4e0
Sep 22 20:01:35 eric kernel:  ? exc_page_fault+0x175/0x180
Sep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30
Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0
Sep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0
Sep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680
Sep 22 20:01:35 eric kernel:  power_supply_unregister+0x8e/0xa0
Sep 22 20:01:35 eric kernel:  release_nodes+0x3d/0xb0
Sep 22 20:01:35 eric kernel:  devres_release_group+0xfc/0x130
Sep 22 20:01:35 eric kernel:  hid_device_remove+0x56/0xa0
Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
Sep 22 20:01:35 eric kernel:  ? __queue_work+0x1df/0x440
Sep 22 20:01:35 eric kernel:  hid_destroy_device+0x4b/0x60
Sep 22 20:01:35 eric kernel:  logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4]
Sep 22 20:01:35 eric kernel:  hid_device_remove+0x44/0xa0
Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
Sep 22 20:01:35 eric kernel:  ? __queue_work+0x1df/0x440
Sep 22 20:01:35 eric kernel:  hid_destroy_device+0x4b/0x60
Sep 22 20:01:35 eric kernel:  usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3]
Sep 22 20:01:35 eric kernel:  usb_unbind_interface+0x90/0x270
Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
Sep 22 20:01:35 eric kernel:  ? kobject_put+0xa0/0x1d0
Sep 22 20:01:35 eric kernel:  usb_disable_device+0xcd/0x1e0
Sep 22 20:01:35 eric kernel:  usb_disconnect+0xde/0x2c0
Sep 22 20:01:35 eric kernel:  usb_disconnect+0xc3/0x2c0
Sep 22 20:01:35 eric kernel:  hub_event+0xe80/0x1c10
Sep 22 20:01:35 eric kernel:  ? __schedule+0x3f0/0x1410
Sep 22 20:01:35 eric kernel:  process_one_work+0x1de/0x3f0
Sep 22 20:01:35 eric kernel:  worker_thread+0x51/0x390
Sep 22 20:01:35 eric kernel:  ? __pfx_worker_thread+0x10/0x10
Sep 22 20:01:35 eric kernel:  kthread+0xe5/0x120
Sep 22 20:01:35 eric kernel:  ? __pfx_kthread+0x10/0x10
Sep 22 20:01:35 eric kernel:  ret_from_fork+0x31/0x50
Sep 22 20:01:35 eric kernel:  ? __pfx_kthread+0x10/0x10
Sep 22 20:01:35 eric kernel:  ret_from_fork_asm+0x1b/0x30
Sep 22 20:01:35 eric kernel:  </TASK>
Sep 22 20:01:35 eric kernel: Modules linked in: hid_logitech_hidpp hid_logitech_dj uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videodev vide>
Sep 22 20:01:35 eric kernel:  snd_compress snd_hda_codec_idt coretemp btusb ac97_bus snd_hda_codec_generic ledtrig_audio snd_pcm_dmaengine btrtl mac80211 snd_h>
Sep 22 20:01:35 eric kernel:  int340x_thermal_zone acpi_pad acpi_thermal_rel mac_hid vmmon(OE) vmw_vmci dm_multipath sg crypto_user fuse loop zram ip_tables x_>
Sep 22 20:01:35 eric kernel: CR2: ffffb2140e017f08
Sep 22 20:01:35 eric kernel: ---[ end trace 0000000000000000 ]---
Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel: Code: 75 4e 48 8b 13 48 83 7a 28 00 74 75 45 31 ff 31 c0 eb 10 48 8b 13 41 83 c7 01 49 63 c7 48 3b 42 28 73 5e 48 8b 52 20 8b 14 8>
Sep 22 20:01:35 eric kernel: RSP: 0018:ffffb214048637a8 EFLAGS: 00010297
Sep 22 20:01:35 eric kernel: RAX: 0000000000000003 RBX: ffff8fefee72a000 RCX: ffff8ff06f6d7000
Sep 22 20:01:35 eric kernel: RDX: 000000004bda3ad9 RSI: 0000000088d38080 RDI: ffff8fefee72a000
Sep 22 20:01:35 eric kernel: RBP: ffff8fefee72a038 R08: 0000000000000007 R09: ffff8ff113a5932f
Sep 22 20:01:35 eric kernel: R10: ffffffffffffffff R11: ffffb21404863840 R12: ffff8ff013a59000
Sep 22 20:01:35 eric kernel: R13: 0000000000000000 R14: ffff8ff06f6d7000 R15: 0000000000000003
Sep 22 20:01:35 eric kernel: FS:  0000000000000000(0000) GS:ffff8fff2fa40000(0000) knlGS:0000000000000000
Sep 22 20:01:35 eric kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 22 20:01:35 eric kernel: CR2: ffffb2140e017f08 CR3: 0000000e78020000 CR4: 0000000000750ee0
Sep 22 20:01:35 eric kernel: PKRU: 55555554
Sep 22 20:01:35 eric kernel: note: kworker/17:3[1256] exited with irqs disabled

Let's try this again, but this time without less truncating the output... sorry about that.

Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08
Sep 22 20:01:35 eric kernel: #PF: supervisor write access in kernel mode
Sep 22 20:01:35 eric kernel: #PF: error_code(0x0002) - not-present page
Sep 22 20:01:35 eric kernel: PGD 100000067 P4D 100000067 PUD 1001eb067 PMD 0 
Sep 22 20:01:35 eric kernel: Oops: 0002 [#1] PREEMPT SMP NOPTI
Sep 22 20:01:35 eric kernel: CPU: 17 PID: 1256 Comm: kworker/17:3 Tainted: G     U     OE      6.5.3-arch1-1 #1 ed5b3b894d0aeb37298a77837232ca9b353cc27d
Sep 22 20:01:35 eric kernel: Hardware name: Framework Laptop (12th Gen Intel Core)/FRANMACP08, BIOS 03.05 08/23/2022
Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event
Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel: Code: 75 4e 48 8b 13 48 83 7a 28 00 74 75 45 31 ff 31 c0 eb 10 48 8b 13 41 83 c7 01 49 63 c7 48 3b 42 28 73 5e 48 8b 52 20 8b 14 82 <f0> 48 0f ab 54 24 08 48 8b 13 4c 89 f1 4c 89 e6 48 89 ef 48 8b 52
Sep 22 20:01:35 eric kernel: RSP: 0018:ffffb214048637a8 EFLAGS: 00010297
Sep 22 20:01:35 eric kernel: RAX: 0000000000000003 RBX: ffff8fefee72a000 RCX: ffff8ff06f6d7000
Sep 22 20:01:35 eric kernel: RDX: 000000004bda3ad9 RSI: 0000000088d38080 RDI: ffff8fefee72a000
Sep 22 20:01:35 eric kernel: RBP: ffff8fefee72a038 R08: 0000000000000007 R09: ffff8ff113a5932f
Sep 22 20:01:35 eric kernel: R10: ffffffffffffffff R11: ffffb21404863840 R12: ffff8ff013a59000
Sep 22 20:01:35 eric kernel: R13: 0000000000000000 R14: ffff8ff06f6d7000 R15: 0000000000000003
Sep 22 20:01:35 eric kernel: FS:  0000000000000000(0000) GS:ffff8fff2fa40000(0000) knlGS:0000000000000000
Sep 22 20:01:35 eric kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 22 20:01:35 eric kernel: CR2: ffffb2140e017f08 CR3: 0000000e78020000 CR4: 0000000000750ee0
Sep 22 20:01:35 eric kernel: PKRU: 55555554
Sep 22 20:01:35 eric kernel: Call Trace:
Sep 22 20:01:35 eric kernel:  <TASK>
Sep 22 20:01:35 eric kernel:  ? __die+0x23/0x70
Sep 22 20:01:35 eric kernel:  ? page_fault_oops+0x171/0x4e0
Sep 22 20:01:35 eric kernel:  ? exc_page_fault+0x175/0x180
Sep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30
Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0
Sep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0
Sep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680
Sep 22 20:01:35 eric kernel:  power_supply_unregister+0x8e/0xa0
Sep 22 20:01:35 eric kernel:  release_nodes+0x3d/0xb0
Sep 22 20:01:35 eric kernel:  devres_release_group+0xfc/0x130
Sep 22 20:01:35 eric kernel:  hid_device_remove+0x56/0xa0
Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
Sep 22 20:01:35 eric kernel:  ? __queue_work+0x1df/0x440
Sep 22 20:01:35 eric kernel:  hid_destroy_device+0x4b/0x60
Sep 22 20:01:35 eric kernel:  logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4]
Sep 22 20:01:35 eric kernel:  hid_device_remove+0x44/0xa0
Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
Sep 22 20:01:35 eric kernel:  ? __queue_work+0x1df/0x440
Sep 22 20:01:35 eric kernel:  hid_destroy_device+0x4b/0x60
Sep 22 20:01:35 eric kernel:  usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3]
Sep 22 20:01:35 eric kernel:  usb_unbind_interface+0x90/0x270
Sep 22 20:01:35 eric kernel:  device_release_driver_internal+0x19f/0x200
Sep 22 20:01:35 eric kernel:  bus_remove_device+0xc6/0x130
Sep 22 20:01:35 eric kernel:  device_del+0x15c/0x3f0
Sep 22 20:01:35 eric kernel:  ? kobject_put+0xa0/0x1d0
Sep 22 20:01:35 eric kernel:  usb_disable_device+0xcd/0x1e0
Sep 22 20:01:35 eric kernel:  usb_disconnect+0xde/0x2c0
Sep 22 20:01:35 eric kernel:  usb_disconnect+0xc3/0x2c0
Sep 22 20:01:35 eric kernel:  hub_event+0xe80/0x1c10
Sep 22 20:01:35 eric kernel:  ? __schedule+0x3f0/0x1410
Sep 22 20:01:35 eric kernel:  process_one_work+0x1de/0x3f0
Sep 22 20:01:35 eric kernel:  worker_thread+0x51/0x390
Sep 22 20:01:35 eric kernel:  ? __pfx_worker_thread+0x10/0x10
Sep 22 20:01:35 eric kernel:  kthread+0xe5/0x120
Sep 22 20:01:35 eric kernel:  ? __pfx_kthread+0x10/0x10
Sep 22 20:01:35 eric kernel:  ret_from_fork+0x31/0x50
Sep 22 20:01:35 eric kernel:  ? __pfx_kthread+0x10/0x10
Sep 22 20:01:35 eric kernel:  ret_from_fork_asm+0x1b/0x30
Sep 22 20:01:35 eric kernel:  </TASK>
Sep 22 20:01:35 eric kernel: Modules linked in: hid_logitech_hidpp hid_logitech_dj uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videodev videobuf2_common snd_usb_audio snd_usbmidi_lib snd_ump snd_rawmidi mc ccm xt_MASQUERADE xt_mark nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device tun nf_tables nfnetlink qrtr cmac algif_hash algif_skcipher af_alg bnep vmnet(OE) hid_sensor_als hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common industrialio mousedev joydev snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel snd_sof_intel_hda_mlink soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core r8153_ecm vfat snd_soc_acpi_intel_match cdc_ether fat snd_soc_acpi usbnet snd_hda_codec_hdmi soundwire_generic_allocation intel_uncore_frequency soundwire_bus intel_uncore_frequency_common snd_soc_core x86_pkg_temp_thermal intel_powerclamp iwlmvm
Sep 22 20:01:35 eric kernel:  snd_compress snd_hda_codec_idt coretemp btusb ac97_bus snd_hda_codec_generic ledtrig_audio snd_pcm_dmaengine btrtl mac80211 snd_hda_intel btbcm kvm_intel snd_intel_dspcfg snd_intel_sdw_acpi cros_usbpd_charger btintel cros_usbpd_notify cros_usbpd_logger cros_ec_chardev cros_ec_sysfs cros_ec_debugfs libarc4 snd_hda_codec btmtk cros_ec_dev kvm snd_hda_core bluetooth snd_hwdep iwlwifi irqbypass processor_thermal_device_pci iTCO_wdt r8152 pmt_telemetry cros_ec_lpcs snd_pcm processor_thermal_device rapl intel_pmc_bxt ecdh_generic hid_multitouch hid_sensor_hub mii ee1004 mei_wdt mei_hdcp mei_pxp iTCO_vendor_support snd_timer processor_thermal_rfim intel_cstate crc16 intel_rapl_msr pmt_class cros_ec cfg80211 spi_nor intel_uncore ucsi_acpi intel_lpss_pci processor_thermal_mbox snd wmi_bmof i2c_i801 mei_me pcspkr typec_ucsi mtd intel_lpss processor_thermal_rapl thunderbolt soundcore i2c_smbus rfkill mei intel_rapl_common idma64 intel_vsec typec roles igen6_edac i2c_hid_acpi i2c_hid int3403_thermal int3400_thermal
Sep 22 20:01:35 eric kernel:  int340x_thermal_zone acpi_pad acpi_thermal_rel mac_hid vmmon(OE) vmw_vmci dm_multipath sg crypto_user fuse loop zram ip_tables x_tables dm_crypt cbc encrypted_keys trusted asn1_encoder tee usbhid btrfs dm_mod i915 blake2b_generic crct10dif_pclmul libcrc32c crc32c_generic crc32_pclmul crc32c_intel polyval_clmulni xor polyval_generic raid6_pq gf128mul i2c_algo_bit ghash_clmulni_intel serio_raw drm_buddy sha512_ssse3 atkbd ttm aesni_intel libps2 intel_gtt nvme vivaldi_fmap crypto_simd cryptd drm_display_helper nvme_core spi_intel_pci xhci_pci spi_intel xhci_pci_renesas cec nvme_common video i8042 wmi serio
Sep 22 20:01:35 eric kernel: CR2: ffffb2140e017f08
Sep 22 20:01:35 eric kernel: ---[ end trace 0000000000000000 ]---
Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel: Code: 75 4e 48 8b 13 48 83 7a 28 00 74 75 45 31 ff 31 c0 eb 10 48 8b 13 41 83 c7 01 49 63 c7 48 3b 42 28 73 5e 48 8b 52 20 8b 14 82 <f0> 48 0f ab 54 24 08 48 8b 13 4c 89 f1 4c 89 e6 48 89 ef 48 8b 52
Sep 22 20:01:35 eric kernel: RSP: 0018:ffffb214048637a8 EFLAGS: 00010297
Sep 22 20:01:35 eric kernel: RAX: 0000000000000003 RBX: ffff8fefee72a000 RCX: ffff8ff06f6d7000
Sep 22 20:01:35 eric kernel: RDX: 000000004bda3ad9 RSI: 0000000088d38080 RDI: ffff8fefee72a000
Sep 22 20:01:35 eric kernel: RBP: ffff8fefee72a038 R08: 0000000000000007 R09: ffff8ff113a5932f
Sep 22 20:01:35 eric kernel: R10: ffffffffffffffff R11: ffffb21404863840 R12: ffff8ff013a59000
Sep 22 20:01:35 eric kernel: R13: 0000000000000000 R14: ffff8ff06f6d7000 R15: 0000000000000003
Sep 22 20:01:35 eric kernel: FS:  0000000000000000(0000) GS:ffff8fff2fa40000(0000) knlGS:0000000000000000
Sep 22 20:01:35 eric kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 22 20:01:35 eric kernel: CR2: ffffb2140e017f08 CR3: 0000000e78020000 CR4: 0000000000750ee0
Sep 22 20:01:35 eric kernel: PKRU: 55555554
Sep 22 20:01:35 eric kernel: note: kworker/17:3[1256] exited with irqs disabled

(In reply to Ryan Petris from comment #62)
> Let's try this again, but this time without less truncating the output...
> sorry about that.

Then please open a new but and drop the link here. Continuing here leads to a messy ticket that is hard to grasp.

https://linux-regtracking.leemhuis.info/post/frequent-reasons-why-linux-kernel-bug-reports-are-ignored/

Johan, Ryan Petris,

I believe that I have root-caused and fixed the crash in power_supply_uevent() on USB disconnect.

Here is a patch which should fix this:
https://lore.kernel.org/linux-input/20231005182638.3776-1-hdegoede@redhat.com/

Hans, thanks I'll have to try the patch out over the weekend to confirm. In the meantime, thanks for finding the problem!

Thorsten, sorry I'm just now seeing this; if it's still necessary in light of Hans' fix then I'll go ahead and file a new bug for this.

(In reply to Hans de Goede from comment #64)
> I believe that I have root-caused and fixed the crash in
> power_supply_uevent() on USB disconnect.

Hans, many thx for taking care of this, much appreciated!

(In reply to Ryan Petris from comment #65)
> Thorsten, sorry I'm just now seeing this; if it's still necessary […]

No worries & no need, getting the patch tested is the important thing now.

I have just tested the above patch on one F38 machine using Logitech MX Master 3
I used a KVM switch to switch between RL9.2 & 6.5.5-200.bz2227221.fc38.x86_64
No problems for at least 10 switches.
Tried switching between RL9.2 & 6.5.5-200.fc38.x86_64
Standard F38 kernel fell over after 3 switches.
Things are looking good!
Many thanks to Hans and others.

This can probably be closed; I haven't had this issue happen in a long time.