I'm using the latest Liquorix kernel on a fresh install of antiX 26 (trixie) and it seems to be working really well except for one weird pbm: I have scripts that handle suspending and for detecting & switching between docked (wired ethernet via "e1000e" + exterman monitor) and undocked (wifi via "iwlwifi" & friends + laptop monitor) that I've used for years. To save memory, the scripts will unload the wifi drivers & modprobe "e1000e" when switching to docked & vice versa when "waking up" undocked from docked. Machine hard freezes requiring power-cycle when coming up docked. I started debugging over an afternoon and bisected it down to a single, repeatable cause: simply removing the drivers (order: killall wpa_supplicant; killall dhclient, ifconfig wlan0 down; rmmod iwldvm; rmmod iwlwifi; rmmod mac80211; rmmod cfg80211), then opening a window, switching between (getty) console and X, etc. Usually I don't get to removing any drivers after iwlwifi. Once I was on the console and got a crash-dump to the console, but it scrolled by before I could snap a photo of it. Each other time I had to switch back to X to get it to hang, but the bit I did see said "GPU HANG: ecode 5:0:000000" and "GTO: Resetting chip for no heartbeat on rcs0". This pretty much happens within a/b 30 seconds after removing iwlwifi and trying to do anything graphical. I've successfully worked around by simply leaving the wifi-related modules installed across suspend/resume, dock/undock, etc. & no longer having any issues. Note, I still take the wifi down (ifdown) to switch back to ethernet, and vice versa when undocking which works fine (as long as I leave the iwlwifi & drivers that depend on it installed), or even leave the machine disconnected from the internet.

This is really puzzling to me as to why simply removing the modules after taking down the wifi connection should ba able to cause a kernel / gpu panic?! Conspiracy-theory part of me wonders if the kernel is somehow trying to "phone home" somewhere via some very low-level "backdoor" & is stunned by suddenly not having the wifi driver loaded anymore?! I'm using integrated Intel graphics & Intel wifi on an HP Elitebook 8440p. Pbm. not in latest (but much older) antiX kernel (v6.6.19) - the only other kernel I have. Pbm. did not exist in last Liquorix kernel I had on prev. system (v6.7.10-1-1 liquorix v6.7-14.1~trixie).

Easy to dup: Just take down wifi & then rmmod the drivers, wait a/b 30 seconds, and do something "graphical", ie. move mouse, open/close a window, switch between console and X, etc.

uname -a:
Linux antix1 6.19.11-2-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 6.19-8.1~trixie (2026-04-04) x86_64 GNU/Linux

My inxi -bGxxz:

Back to top

So I'll be very honest, your methodology for managing your networking is non-standard and not a method anyone uses to switch between wireless and ethernet. The amount of memory savings is negligible, under 1 megabyte at most to unload and keep just one or the other.

What you're probably dealing with is a new locking/race condition that was introduced in v6.19, and you're probably the first person to find it.

In the meantime I would recommend something like TLP with the rfkill feature added. When you connect to ethernet you can have it automatically shut off the radio on your wireless device. This is much more stable since it's just toggling a power switch in the /sys directory.

And if you have a kernel OOPS from a previous, please post that here and I can do some initial research to see what might have caused it.
Back to top

Thank you damentz for your detailed & technical reply - I will heed your advice a/b using rfkill to stop the wifi vs unloading the drivers, along with just leaving the drivers alone in the docking scripts. Not sure what TLP stands for though. Been using Linux since late '90s when ram was more scarce and had gotten carried away way back then with scripts and memory-saving - looks like they need freshing up a bit! ;) I wanted to include a crash dump, but after the one I got scrolled off the console & I wasn't able to coax it to dump again while in the terminal & both me & my filesystems tired of hard-restarting I gave up.

Jim
Back to top

Hey no problem, if you have a systemd system you'll be lucky to run journalctl -kb -1 to see the entire previous kernel log. At the end of the pager will hopefully be your kernel oops. If you don't have journald then you'll have to look for an alternative place the logs could be.

EDIT: You can read more about TLP, it's an old project but still in active development: linrunner.de/tlp/

Almost every distribution packages a version of TLP, and that version is probably sufficient.
Back to top