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

[phoronix]

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

Queued up this week as part of the HID subsystem fixes ahead of today's Linux 6.6-rc6 kernel test release has been a rather embarrassing bug: unplugging Logitech USB receivers has for the past several months been causing the Linux kernel to crash. After a number of bug reports around this issue from unplugging Logitech keyboard/mice receivers to simply switching away on a USB switch with the device(s) attached, the Linux 6.6-rc6 kernel is carrying the fix and it's also marked for back-porting to existing stable Linux kernel series...

https://www.phoronix.com/news/Logitech-USB-Unplug-Linux-Crash

[zexelon]

I think this has been fixed in windows since what... Win98SE?? This is a fundamental design flaw with the monolithic Linux kernel design.

Yanking any PnP piece of hardware out should NEVER cause a general kernel failure, there are so many things wrong with that. Even if the whole USB stack implodes it should not bring down the kernel. Heck on modern windows the whole graphical subsystem can implode for any number of reasons and Windows will re-init it from the ground up with only a flicker of the screen (and probably an error message for whatever game caused the reset).

Linux is an awesome OS for hosting where users never interact with it, you can get pretty insane performance and its generally going to just run... I doubt Linux will ever make it on the desktop... it just has to many wholes.

[access]

I think this has been fixed in windows since what... Win98SE?? This is a fundamental design flaw with the monolithic Linux kernel design.

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

[dlq84]

I think this has been fixed in windows since what... Win98SE?? This is a fundamental design flaw with the monolithic Linux kernel design.

Yanking any PnP piece of hardware out should NEVER cause a general kernel failure, there are so many things wrong with that. Even if the whole USB stack implodes it should not bring down the kernel. Heck on modern windows the whole graphical subsystem can implode for any number of reasons and Windows will re-init it from the ground up with only a flicker of the screen (and probably an error message for whatever game caused the reset).

Linux is an awesome OS for hosting where users never interact with it, you can get pretty insane performance and its generally going to just run... I doubt Linux will ever make it on the desktop... it just has to many wholes.

It's a bug, and it has nothing to do with being monolithic or not... Windows isn't bug free either. Also, Linux has made it, and dominates everything but the desktop (including pretty much every consumer device you can imagine). This Logitech USB bug did not stop it from doing that. There's another reason why Linux is yet to dominate the desktop, and I'll let you keep guessing why.

[zexelon]

It's a bug, and it has nothing to do with being monolithic or not... Windows isn't bug free either. Also, Linux has made it, and dominates everything but the desktop (including pretty much every consumer device you can imagine). This Logitech USB bug did not stop it from doing that. There's another reason why Linux is yet to dominate the desktop, and I'll let you keep guessing why.

Exactly correct, it is a bug in a relatively minor subsystem (as in not critical to the function of the kernel) that brings the whole kernel down. This only happens in a monolithic arch.

In the Windows hybrid arch the USB stack would fail but the system would remain online and re-init the stack.

I think ReactOS has a beter desktop chance than Linux atm.

Windows is NOT bug free... but very few bring the system down these days.

[zexelon]

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

Lol... yah... I mentally block Windows ME.... It was possibly the worst os ever made (Vista is a close second).

[AndyChow]

This is beyond embarrassing. Obviously a USB device shouldn't be able to make a kernel panic.

[-MacNuke-]

Windows is NOT bug free... but very few bring the system down these days.

And yet I had like 5 bluescreens on my Windows notebook from work only this year.

[SoongVilda]

I think this has been fixed in windows since what... Win98SE?? This is a fundamental design flaw with the monolithic Linux kernel design.

Yanking any PnP piece of hardware out should NEVER cause a general kernel failure, there are so many things wrong with that. Even if the whole USB stack implodes it should not bring down the kernel. Heck on modern windows the whole graphical subsystem can implode for any number of reasons and Windows will re-init it from the ground up with only a flicker of the screen (and probably an error message for whatever game caused the reset).

Linux is an awesome OS for hosting where users never interact with it, you can get pretty insane performance and its generally going to just run... I doubt Linux will ever make it on the desktop... it just has to many wholes.

Meanwhile, Windows 10 crashed when I plugged off a USB Wi-Fi card from my laptop, and BSOD showed kernel panic. My friend have u bug with MS Teams, when he mutted the microphone, Windows crashed and BSOD showed kernel panic. So I think you are completely wrong.

[stargeizer]

I think this has been fixed in windows since what... Win98SE??

This is beyond embarrassing. Obviously a USB device shouldn't be able to make a kernel panic.

You wish...

https://answers.microsoft.com/en-us/windows/forum/all/blue-screen-due-to-usb-disconnect-and-re-connect/e6ac83d3-078c-4807-80e6-6e24d74e75a9

The problem of course lies within the drivers (legacy drivers) in the case of windows. USB issues are not that uncommon in Windows, more commonly in USB devices requiring/using a watchdog and requires manual intervention. Apple only had recently fixed an issue with Realtek USB related crashes.

So, there you are, it's 2023 and USB still can crash your system. Granted, only happens in certain configurations. And In the Linux case: the problem is related to race conditions, A.K.A. code (most probably legacy) that assumed a single processor instead of processors with multiple cores/threads.