System freezes upon losing Internet conection

Ask Fedora
, , ,
1

Continuing the discussion from Freeze during heavy file transferral:

The referenced issue was most certainly caused by my dodgy PCI-e Wifi/Bluetooth adapter, but there’s more to the story.

Several times over the course of a few days now, I’ve come home to find my computer in a frozen up state. Upon having left, I’ve left the computer standing idle, but not suspended, and auto-suspend is toggled off.

For the moment the only Internet provision I have is my Smartphone’s Wifi hotspot, and so when I leave with my phone my other devices at home are obviously left without Internet entirely.

Judging by the logs it appears obvious that a networking-related crash is what happens, as a load of this sort of stuff is recorded right before the crash.

Mar 17 14:29:26 fedora systemd[1]: Finished dnf-makecache.service - dnf makecache.
Mar 17 14:29:26 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="syst>
Mar 17 14:29:26 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="syste>
Mar 17 14:29:52 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:30:48 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:31:44 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:32:40 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:33:19 fedora NetworkManager[1298]: <info>  [1679059999.2608] device (wlp3s0): set-hw-addr: set MAC address to 6E:C1:35:EA:C4:1E (scanning)
Mar 17 14:33:19 fedora NetworkManager[1298]: <info>  [1679059999.6303] device (wlp3s0): supplicant interface state: inactive -> interface_disabled
Mar 17 14:33:19 fedora NetworkManager[1298]: <info>  [1679059999.6304] device (p2p-dev-wlp3s0): supplicant management interface state: inactive -> interface_>
Mar 17 14:33:19 fedora NetworkManager[1298]: <info>  [1679059999.6307] device (wlp3s0): supplicant interface state: interface_disabled -> inactive
Mar 17 14:33:19 fedora NetworkManager[1298]: <info>  [1679059999.6307] device (p2p-dev-wlp3s0): supplicant management interface state: interface_disabled -> >
Mar 17 14:33:36 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:34:41 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:35:38 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:36:34 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:37:30 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:38:26 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:39:03 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:39:56 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:40:13 fedora NetworkManager[1298]: <info>  [1679060413.2860] device (wlp3s0): set-hw-addr: set MAC address to 9E:12:21:7B:A6:84 (scanning)
Mar 17 14:40:13 fedora NetworkManager[1298]: <info>  [1679060413.6553] device (wlp3s0): supplicant interface state: inactive -> interface_disabled
Mar 17 14:40:13 fedora NetworkManager[1298]: <info>  [1679060413.6553] device (p2p-dev-wlp3s0): supplicant management interface state: inactive -> interface_>
Mar 17 14:40:13 fedora NetworkManager[1298]: <info>  [1679060413.6663] device (wlp3s0): supplicant interface state: interface_disabled -> inactive
Mar 17 14:40:13 fedora NetworkManager[1298]: <info>  [1679060413.6663] device (p2p-dev-wlp3s0): supplicant management interface state: interface_disabled -> >
Mar 17 14:40:52 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:41:48 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:42:44 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:43:40 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:44:04 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:44:52 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:45:49 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:46:45 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:47:07 fedora NetworkManager[1298]: <info>  [1679060827.1959] device (wlp3s0): set-hw-addr: set MAC address to 1A:69:0B:4C:3E:E0 (scanning)
Mar 17 14:47:07 fedora NetworkManager[1298]: <info>  [1679060827.5652] device (wlp3s0): supplicant interface state: inactive -> interface_disabled
Mar 17 14:47:07 fedora NetworkManager[1298]: <info>  [1679060827.5653] device (p2p-dev-wlp3s0): supplicant management interface state: inactive -> interface_>
Mar 17 14:47:07 fedora NetworkManager[1298]: <info>  [1679060827.5734] device (wlp3s0): supplicant interface state: interface_disabled -> inactive
Mar 17 14:47:07 fedora NetworkManager[1298]: <info>  [1679060827.5734] device (p2p-dev-wlp3s0): supplicant management interface state: interface_disabled -> >
Mar 17 14:47:41 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:48:37 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:49:05 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:49:55 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:50:51 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:51:47 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:52:43 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:53:39 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:54:01 fedora NetworkManager[1298]: <info>  [1679061241.2870] device (wlp3s0): set-hw-addr: set MAC address to AE:D9:49:2A:50:59 (scanning)
Mar 17 14:54:01 fedora NetworkManager[1298]: <info>  [1679061241.6563] device (wlp3s0): supplicant interface state: inactive -> interface_disabled
Mar 17 14:54:01 fedora NetworkManager[1298]: <info>  [1679061241.6563] device (p2p-dev-wlp3s0): supplicant management interface state: inactive -> interface_>
Mar 17 14:54:01 fedora NetworkManager[1298]: <info>  [1679061241.6633] device (wlp3s0): supplicant interface state: interface_disabled -> inactive
Mar 17 14:54:01 fedora NetworkManager[1298]: <info>  [1679061241.6633] device (p2p-dev-wlp3s0): supplicant management interface state: interface_disabled -> >
Mar 17 14:54:06 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:54:55 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:55:52 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:56:48 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:57:44 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:58:40 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:59:07 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 14:59:56 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 15:00:52 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.
Mar 17 15:00:55 fedora NetworkManager[1298]: <info>  [1679061655.2509] device (wlp3s0): set-hw-addr: set MAC address to A2:D6:6C:D6:14:37 (scanning)
Mar 17 15:00:55 fedora NetworkManager[1298]: <info>  [1679061655.6204] device (wlp3s0): supplicant interface state: inactive -> interface_disabled
Mar 17 15:00:55 fedora NetworkManager[1298]: <info>  [1679061655.6204] device (p2p-dev-wlp3s0): supplicant management interface state: inactive -> interface_>
Mar 17 15:00:55 fedora NetworkManager[1298]: <info>  [1679061655.6264] device (wlp3s0): supplicant interface state: interface_disabled -> inactive
Mar 17 15:00:55 fedora NetworkManager[1298]: <info>  [1679061655.6264] device (p2p-dev-wlp3s0): supplicant management interface state: interface_disabled -> >
Mar 17 15:01:48 fedora Tor[1329]: Failed to find node for hop #1 of our path. Discarding this circuit.

There have been very few preceding warnings, and none right before the freeze.

It obviously doesn’t seem right that a freeze or crash must occur in this sort of situation. By the timings given it appears the freeze occurs when the connection cuts out, rather than upon attempted reconnect as I get home.

As a side-question, any recommendations for checking out what hardware is installed, in particular PCI-e cards, would be much appreciated. I’ve tried lspci, dmidecode, /proc/vmstat, /proc/loadavg, and a bunch others, but none will give me a readable name for what card it is I have installed. I only get networking and meaningless PCI-slot numberings. I managed to print out a syslog before, but I am now failing to.

2

try lshw

3

People (including local emergency services) may rely on a wifi hotspot during emergencies, so time spent to sort out your issue may benefit ohers.

Have your tried lspci -v? If your system is a commercial build, you can search for it at Linux Hardware by vendor and model. If it is found there will be some wifi works or fails reports for various linux distros, but the reports don’t get to the level of detail for your use case.

You can work back from the name of your wifi kernel module (example below from a old iMac). Along the way you may encounter useful error messages

  1. What module is used by cfg80211?
% lsmod | grep ^cfg80211
cfg80211             1114112  1 wl
  1. use the name (wl) of the wifi module to find relevant lines in dmesg:
dmesg | grep -w "wl"
[   17.980065] wl: loading out-of-tree module taints kernel.
[   17.980613] wl: module license 'MIXED/Proprietary' taints kernel.
[   17.984103] wl: module verification failed: signature and/or required key missing - tainting kernel
[   17.991022] wl 0000:03:00.0: enabling device (0000 -> 0002)
[   18.040550] wl 0000:03:00.0 wlp3s0: renamed from eth0
  1. Use original (before renaming) device name (eth0) to find details:
% dmesg | grep eth0
[    2.607072] tg3 0000:04:00.0 eth0: Tigon3 [partno(BCM957766a) rev 57766001] (PCI Express) MAC address 68:5b:35:9d:59:af
[    2.607093] tg3 0000:04:00.0 eth0: attached PHY is 57765 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
[    2.607106] tg3 0000:04:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[    2.607116] tg3 0000:04:00.0 eth0: dma_rwctrl[00000001] dma_mask[64-bit]
[    2.608994] tg3 0000:04:00.0 enp4s0f0: renamed from eth0
[   18.019992] eth0: Broadcom BCM43a0 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334)
[   18.040550] wl 0000:03:00.0 wlp3s0: renamed from eth0
[   23.707050] ipheth 1-2.4:4.2 enp0s20u2u4c4i2: renamed from eth0

The line(s) you want should come just before the “renamed” line found in step 2. Here it tells me the wifi is a “Broadcom BCM43a0 802.11 Hybrid Wireless Controller” and PCI address 03:00.0.


4) go back to `lspci`:

Use `lspci -n` to get the device ID:

% lspci -n | grep 03:00.0
03:00.0 0280: 14e4:43a0 (rev 03)


5) Finally, use the device if (here: `14e4:43a0`) to get verbose `lspci` output fro your device:

% lspci -d 14e4:43a0 -vv
03:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4360 802.11ac Wireless Network Adapter (rev 03)
Subsystem: Apple Inc. Device 0111
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at b1a00000 (64-bit, non-prefetchable) [size=32K]
Region 2: Memory at b1800000 (64-bit, non-prefetchable) [size=2M]
Capabilities:
Kernel driver in use: wl
Kernel modules: bcma, wl


As in this example, there may be another kernel module to try (after searching the internet and the
Linux Hardware site to see what works for others.
1 Like
4

Thank you. I tried that command before, but missed the given model number.

5

Thank you.

There were some differing results to your example along the way, but I came up with the following result in the end

03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8192CE PCIe Wireless Network Adapter (rev 01)
	Subsystem: ASUSTeK Computer Inc. Device 84b6
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: I/O ports at e000 [size=256]
	Region 2: Memory at f7000000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: rtl8192ce
	Kernel modules: rtl8192ce

which is my Wifi card. I’ve been confused up until just now, because I’ve known my card by the name “ASUS PCE-N15”, while by your method of investigation, it comes up as named “RTL8192CE PCIe Wireless Network Adapter”. To make sure, I’ve correlated the two by searching for the two together online.

So I take it I should search to see if there’s a different Kernel module to this ‘RTL8192CE…’ one to install for the card.

6

does inxi -N provide the info you’re looking for?

7

That one works perfectly, thanks. I don’t think I tried it with that switch before. It still gives me the “RTL8192CE” name, but now I know that’s the right one.

I’ve been confused by believing I’d seen the “PCE-N15” name returned by some command before, but probably I was wrong about that.

8

The first step is to check for a firmware update. You may need to search for various combinations “RTL8192CE”, “ASUSTeK Device 84b6”, and “ASUS PCE-N15” for reports of your issue.

There are multiple variants of “rtl8192ce” chips. The driver supports them using “aliases”:

 % modinfo rtl8192ce | grep -w '^alias'
alias:          pci:v000010ECd00008176sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008177sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008178sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008191sv*sd*bc*sc*i*

Drivers often add “quirks” options to support these variants. One of the reasons for the 5 step chain to identify your chipset is that there can be informative messages associated with the details found in the search. There are procedures to diagnose linux system freezes .

9

I had a look over at Linux Hardware and probed my system, which showed there are a couple other drivers available that should work for my card.

I worked back from module to card again to get some things clear, and for posterity I’ll include the steps I took below.

1.

% lsmod | grep ^rtl8192ce

rtl8192ce              86016  0

so, that one’s using nothing.

% lsmod | grep rtl8192ce

Losing the hyphen in the command however, gives me

rtl8192ce              86016  0
rtl_pci                36864  1 rtl8192ce
rtl8192c_common        73728  1 rtl8192ce
rtlwifi               118784  3 rtl_pci,rtl8192c_common,rtl8192ce
mac80211             1486848  3 rtl_pci,rtlwifi,rtl8192ce

So there’s an rtlwifi and a mac80211, and both use rtl8192ce. Checking dmesg doesn’t show up any renaming for any of them, so I tried ‘renamed’ instead.

2.

% dmesg |grep renamed

[    2.297990] e1000e 0000:00:1f.6 enp0s31f6: renamed from eth0
[  161.085945] rtl8192ce 0000:03:00.0 wlp3s0: renamed from wlan0

dmesg does not show up a device or driver name for either of those, but wlp3s0 should be ‘the guy’. After all, it is the only thing that shows up in the logs by
journalctl -e _SYSTEMD_UNIT=NetworkManager.service.

3.

% lspci -n | grep 03:00.0

03:00.0 0280: 10ec:8178 (rev 01)

4.

% lspci -d | 10:ec8178 -vv

03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8192CE PCIe Wireless Network Adapter (rev 01)
	Subsystem: ASUSTeK Computer Inc. Device 84b6
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: I/O ports at e000 [size=256]
	Region 2: Memory at f7000000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: rtl8192ce
	Kernel modules: rtl8192ce

I did find some additional useful advice regarding How To Check Wireless Network Card Info.

For instance, using sudo lspci | grep -i wireless outputs as follows

03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8192CE PCIe Wireless Network Adapter (rev 01)

I’ll be checking for firmware and out those other drivers for now.

1 Like
10

Vendors can get customized versions, so this detail can explain why things called “RTL8192CE” work for some systems and has issues with others.

The missing information in dmesg may mean you need to increase the size of the ring buffer (by editing the kernel command line), see: Demystifying Systemd (page 39).

Edit: added link to page with kernel option examples

1 Like
11

% lspci -d | 10:ec8178 -vv

shouldn’t have the ‘|’ in there, by the way.

12

I am currently looking into the ring buffer biz, but in the meantime I could use some pointers with regards to installing drivers from source. I suppose I should create a different issue, perhaps referencing this one, for that.

Just for clarity, perhaps I never stated that I’ve never knowingly managed to install any other driver for the card besides the standard linux rtl8192ce etc, since I put the card in, and I’ve been updating on a weekly basis.

More clarity, or at least stuff, in case it is needed. Here’s a comprehensive list of network-related kernel warnings and errors on the last two occasions that I switched on the Wifi.

Current boot startup:

Mar 28 11:16:18 fedora kernel: x86/cpu: VMX (outside TXT) disabled by BIOS
Mar 28 11:16:18 fedora kernel: x86/cpu: SGX disabled by BIOS.
Mar 28 11:16:18 fedora kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
Mar 28 11:16:18 fedora kernel: MMIO Stale Data CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html for more details.
Mar 28 11:16:18 fedora kernel:  #5 #6 #7
Mar 28 11:16:18 fedora kernel: tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x200] vs fed40080 f80
Mar 28 11:16:18 fedora kernel: tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x200] vs fed40080 f80
Mar 28 11:16:18 fedora kernel: usb: port power management may be unreliable
Mar 28 11:16:18 fedora kernel: device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
Mar 28 11:16:18 fedora kernel: resource: resource sanity check: requesting [mem 0x00000000fdffe800-0x00000000fe0007ff], which spans more than pnp 00:07 [mem 0xfdb00000-0xfdffffff]
Mar 28 11:16:18 fedora kernel: caller pmc_core_probe+0xd2/0x540 mapping multiple BARs
Mar 28 11:16:18 fedora kernel: ata1.00: supports DRM functions and may not be fully accessible
Mar 28 11:16:18 fedora kernel: ata1.00: supports DRM functions and may not be fully accessible
Mar 28 11:16:18 fedora systemd[1]: bpf-lsm: Failed to load BPF object: No such process
Mar 28 11:16:18 fedora systemd[1]: systemd-sysctl.service: Failed with result 'exit-code'.
Mar 28 11:16:18 fedora systemd[1]: Failed to start systemd-sysctl.service - Apply Kernel Variables.
Mar 28 11:16:41 fedora kernel: kauditd_printk_skb: 7 callbacks suppressed
Mar 28 11:16:42 fedora systemd[1]: bpf-lsm: Failed to load BPF object: No such process
Mar 28 11:16:42 fedora systemd-sysv-generator[815]: SysV service '/etc/rc.d/init.d/livesys' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust.
Mar 28 11:16:42 fedora systemd-sysv-generator[815]: SysV service '/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust.
Mar 28 11:16:42 fedora systemd-gpt-auto-generator[807]: Failed to dissect: Permission denied
Mar 28 11:16:42 fedora (sd-executor)[792]: /usr/lib/systemd/system-generators/systemd-gpt-auto-generator failed with exit status 1.
Mar 28 11:16:43 fedora kernel: rtl8192ce 0000:02:00.0: Direct firmware load for rtlwifi/rtl8192cfw.bin failed with error -2
Mar 28 11:16:43 fedora kernel: rtlwifi: Selected firmware is not available
Mar 28 11:16:47 fedora kernel: rtl8192c_common: Polling FW ready fail! REG_MCUFWDL:0x00000006.
Mar 28 11:16:47 fedora kernel: rtl8192c_common: Firmware is not ready to run!
Mar 28 11:16:48 fedora kernel: rtl8192c_common: Polling FW ready fail! REG_MCUFWDL:0x00000006.
Mar 28 11:16:48 fedora kernel: rtl8192c_common: Firmware is not ready to run!
Mar 28 11:16:50 fedora kernel: rtl8192c_common: Polling FW ready fail! REG_MCUFWDL:0x00000006.
Mar 28 11:16:50 fedora kernel: rtl8192c_common: Firmware is not ready to run!

Current boot after Wifi-hotspot phone died (with no freeze resulting from it) resulted in these two messages repeated some 10+ times.

Mar 29 04:42:01 fedora kernel: rtl8192c_common: Polling FW ready fail! REG_MCUFWDL:0x0c000006.
Mar 29 04:42:01 fedora kernel: rtl8192c_common: Firmware is not ready to run!

The only NetworkManager warnings were these two

Mar 29 04:42:00 fedora NetworkManager[1338]: <warn>  [1680057720.7944] device (wlp2s0): link timed out.
Mar 29 04:42:01 fedora NetworkManager[1338]: <warn>  [1680057721.7514] device (wlp2s0): Activation: failed for connection 'myWifiHotspotName'

Before this boot I had switched PCI-e slots to 02:00.0, since I noticed there was a slight tension causing the card to stick out a little at the inner end. Perhaps that actually fixed the freezing problem, but I still get these same errors, so I’ll have to test that further and see.

I believe that’s it while I look more into the ring buffers stuff.

13

You system appears to be missing the firmware. Here, I have:

 % ls -l /usr/lib/firmware/rtlwifi/rtl8192cfw.bin.xz
-rw-r--r--. 1 root root 8196 Mar 13 05:17 /usr/lib/firmware/rtlwifi/rtl8192cfw.bin.xz
% dnf whatprovides /usr/lib/firmware/rtlwifi/rtl8192cfw.bin.xz
[...]
linux-firmware-20220913-140.fc37.noarch : Firmware files used by the Linux kernel
Repo        : fedora
Matched from:
Filename    : /usr/lib/firmware/rtlwifi/rtl8192cfw.bin.xz

linux-firmware-20230310-148.fc37.noarch : Firmware files used by the Linux kernel
Repo        : @System
Matched from:
Filename    : /usr/lib/firmware/rtlwifi/rtl8192cfw.bin.xz

linux-firmware-20230310-148.fc37.noarch : Firmware files used by the Linux kernel
Repo        : updates
Matched from:
Filename    : /usr/lib/firmware/rtlwifi/rtl8192cfw.bin.xz

You probably need the 20230310-148 (or newer) version.

14

Ah, I had come to suspect this being the case, but there are several modules involved I wasn’t sure what one(s) to pay attention to beside the rtl8192ce one.

I do have linux-firmware-20230310-148.fc37.noarch

linux-firmware-20220913-140.fc37.noarch : Firmware files used by the Linux kernel
Repo        : fedora
Matched from:
Filename    : /usr/lib/firmware/rtlwifi

linux-firmware-20230310-148.fc37.noarch : Firmware files used by the Linux kernel
Repo        : @System
Matched from:
Filename    : /usr/lib/firmware/rtlwifi

linux-firmware-20230310-148.fc37.noarch : Firmware files used by the Linux kernel
Repo        : updates
Matched from:
Filename    : /usr/lib/firmware/rtlwifi

Package linux-firmware-20230310-148.fc37.noarch is already installed.

But what I have inside /usr/lib/firmware/ doesn’t match.

Mar 16 16:31 RTL8192E
Mar 16 16:31 rtl_bt
Mar 16 16:31 rtl_nic

Whatever caused this discrepancy, it might because of me mucking something up at some earlier time, as I’m a beginner at best.

Should I remove things, reinstall things? Before I mess up and lose my connection entirely.

15

You should have the directory noted and these contents.

# ls /usr/lib/firmware/rtlwifi/
rtl8188efw.bin.xz     rtl8192cufw.bin.xz          rtl8710bufw_SMIC.bin.xz    rtl8723bs_ap_wowlan.bin.xz  rtl8723fw_B.bin.xz
rtl8188eufw.bin.xz    rtl8192cufw_TMSC.bin.xz     rtl8710bufw_UMC.bin.xz     rtl8723bs_bt.bin.xz         rtl8723fw.bin.xz
rtl8188fufw.bin.xz    rtl8192defw.bin.xz          rtl8712u.bin.xz            rtl8723bs_nic.bin.xz        rtl8812aefw.bin.xz
rtl8192cfw.bin.xz     rtl8192eefw.bin.xz          rtl8723aufw_A.bin.xz       rtl8723bs_wowlan.bin.xz     rtl8812aefw_wowlan.bin.xz
rtl8192cfwU_B.bin.xz  rtl8192eu_ap_wowlan.bin.xz  rtl8723aufw_B.bin.xz       rtl8723bu_ap_wowlan.bin.xz  rtl8821aefw_29.bin.xz
rtl8192cfwU.bin.xz    rtl8192eu_nic.bin.xz        rtl8723aufw_B_NoBT.bin.xz  rtl8723bu_nic.bin.xz        rtl8821aefw.bin.xz
rtl8192cufw_A.bin.xz  rtl8192eu_wowlan.bin.xz     rtl8723befw_36.bin.xz      rtl8723bu_wowlan.bin.xz     rtl8821aefw_wowlan.bin.xz
rtl8192cufw_B.bin.xz  rtl8192sefw.bin.xz          rtl8723befw.bin.xz         rtl8723defw.bin.xz          rtl8822befw.bin.xz

If that directory does not exist or is missing the content then sudo dnf reinstall linux-firmware should recover it. Also if it is not currently up to date the reinstall will handle that as well. To see the currently installed version use

# dnf list installed linux-firmware

Installed Packages
linux-firmware.noarch                                               20230310-148.fc37                                               @updates
16

By sudo dnf reinstall linux-firmware I have all of that in place now.

So that should be as it should be, I reckon. I see no more network warnings as of now, but I’ll leave the thread open for a bit until I’ve tested the freezing issue properly.

I’ll just show a bit of my workings. As I had already been messing about with the firmware packages before, what I ended up doing now was, I removed the ‘extra’ linux-firmware-whence and linux-firmware-vendor packages I had. I then reinstalled the linux-firmware package which also added back linux-firmware-whence. So, these latter two I now have.

Many thanks for now, guys.

17

Potentially the linux-firmware-vendor package may have caused the problem.