Unplugging Logitech USB Receivers Has Been Causing The Linux Kernel To Crash

[mos87]

Windows can normally (i.e. in most cases) reload a crashing GPU driver, Linux just dies.

What's a "a crashing GPU driver" then? Bc here this linux of mine reloads one quite successfully.

DISCLAIMER Nothing kernel-related is being harmed during the reloading.

[kzy909]

I hit this bug and the workaround was sort of buried in a pile of related problems. To fix the issue, one just needed to blacklist the logitech driver by creating
the file /etc modprobe.d/logitech-blacklist.conf (see below). After doing so, no more kernel oops. I'm still running without the logi hid. The fact that one doesn't need the hid driver at all to have a perfectly function system even when using the logi wireless dongle is sort of cool. What I imagine is that if you were running windows in a VM under linux, then anything in windows that required the driver (like the logi value add software) would fail. As for comments about bugs in the linux kernel somehow being due to poor development practices - These folks are clearly a little clueless. The purpose of mainline is to facilitate rapid development - and sometimes there are bugs. Comparing windows to upstream distros like fedora 38 leads one down a path of non-sequiturs. Did the problem exist in RHEL7/8/9? I don't think so and it was not in fedora 35, so introduced at some point, or at least not triggered until I think fedora 37. And RHEL10 will be just fine, because the fix is now rolled and going to be part of RHEL10 base. There has never been a more robust and bullet proof development process invented whose technological advances have surpassed most everything in the windows ecosystem - who in fact draws heavily from open source development - like most of the network stack. I think azure even runs windows instances (mostly) on top of linux - pls correct if I got this part wrong.

[root@barniclew Bugs.RBC]# cat /etc/modprobe.d/logitech-blacklist.conf
# switching away from USB device with logitech unifying reciever cause
# kernel Oops in fed38.
# RE: https://community.frame.work/t/track...nnect/35366/16
#
# In: Linux barniclew 6.4.15-200.fc38.x86_64
# Sep 19 09:26:55 barniclew kernel: BUG: unable to handle page fault for address: ffffb142c14bede0
# ...
# Sep 19 09:26:55 barniclew kernel: RIP: 0010ower_supply_uevent+0xee/0x1d0
#
# Suggested fix create /etc/modprobe.d/logitech-blacklist.conf with this value:
#

blacklist hid_logitech_dj

[boeroboy]

Huh I hit this bug years ago and even submitted a fix to patch when I saw code in usb.c executing by interrupt where comment clearly said "this code isn't called by interrupt" and it was rejected by GKH. He said it isn't the kernel's job to do NULL checks in drivers. I was thoroughly annoyed.

https://github.com/raspberrypi/linux/issues/2551

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1827452

A device like a webcam that increases power usage during initialization can disconnect itself if it can't get enough power. That automatically triggers a disconnect interrupt at the hub during a critical period where devices aren't expected to disconnect.

[Nefsen402]

Yes, that is why searching for "windows usb unplug bsod" gives zero results after 1999.

I just saw this on reddit and it reminded me of this comment. https://www.reddit.com/r/pcmasterrac...ng_for_the_pc/