You are not logged in.
Pages: 1
I have been using Arch Linux for a couple months now. Ever since I replaced my motherboard and RAM due to faulty hardware, I have been experiencing random crashes in a pretty random interval (1-2 days up to several weeks in between crashes). So far, I have identified a common concerning warning that appears every time before a crash happens. Here are the logs:
journalctl | grep iwlwifi Jun 11 12:22:27 *** kernel: iwlwifi 0000:04:00.0: Error sending STATISTICS_CMD: time out after 2000ms.
Jun 11 12:22:27 *** kernel: iwlwifi 0000:04:00.0: Current CMD queue read_ptr 204 write_ptr 205
Jun 11 12:22:30 *** kernel: iwlwifi 0000:04:00.0: Queue 0 is active on fifo 7 and stuck for 2500 ms. SW [204, 205] HW [255, 255] FH TRB=0x0ffffffff
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: Start IWL Error Log Dump:
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: Transport status: 0x0000004A, valid: -1
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: Loaded firmware version: 29.4063824552.0 7265D-29.ucode
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | ADVANCED_SYSASSERT
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | trm_hw_status0
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | trm_hw_status1
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | branchlink2
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | interruptlink1
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | interruptlink2
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | data1
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | data2
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | data3
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | beacon time
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | tsf low
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | tsf hi
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | time gp1
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | time gp2
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | uCode revision type
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | uCode version major
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | uCode version minor
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | hw version
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | board version
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | hcmd
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | isr0
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | isr1
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | isr2
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | isr3
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | isr4
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | last cmd Id
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | wait_event
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | l2p_control
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | l2p_duration
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | l2p_mhvalid
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | l2p_addr_match
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | lmpm_pmg_sel
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | timestamp
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | flow_handler
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: Fseq Registers:
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_ERROR_CODE
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_TOP_INIT_VERSION
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_CNVIO_INIT_VERSION
Jun 11 12:22:36 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_OTP_VERSION
Jun 11 12:22:37 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_TOP_CONTENT_VERSION
Jun 11 12:22:37 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_ALIVE_TOKEN
Jun 11 12:22:37 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_CNVI_ID
Jun 11 12:22:37 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_CNVR_ID
Jun 11 12:22:37 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | CNVI_AUX_MISC_CHIP
Jun 11 12:22:38 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | CNVR_AUX_MISC_CHIP
Jun 11 12:22:38 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
Jun 11 12:22:38 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
Jun 11 12:22:39 *** kernel: iwlwifi 0000:04:00.0: Queue 10 is active on fifo 7 and stuck for 10000 ms. SW [215, 217] HW [255, 255] FH TRB=0x0ffffffff
Jun 11 12:22:39 *** kernel: iwlwifi 0000:04:00.0: Collecting data: trigger 2 fired.The registers all being
0xFFFFFFFFis seems extremely concerning. Does this mean there are more hardware errors in my system?
Offline
I don't much about these things but maybe a newer firmware might work or I have read depending on the system and kernel downgrading firmware.
Online
The problems start here:
Jun 11 12:22:27 *** kernel: iwlwifi 0000:04:00.0: Error sending STATISTICS_CMD: time out after 2000ms.
That's 10 seconds ahead of whatever firmware dump there is.
Don't grep, please post a complete system journal for a boot covering such incident,
sudo journalctl -b | curl -F 'f:1=<-' ix.iofor the current one "(or … -b -1 …" for the previous boot)
Offline
Thanks for the response seth. The output of journalctl is exactly that for the last couple of lines with nothing in between, which is why I chose to grep for the info. Here is the last 100 lines for context.
journalctl -b -1 | tail -n 100 Jun 13 00:45:44 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:45:48 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:45:48 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:46:14 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:46:17 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:46:17 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:46:44 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:47:14 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:47:18 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:47:18 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:47:44 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:47:48 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:47:48 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:48:14 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:48:18 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:48:18 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:48:44 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:49:14 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:49:20 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:49:20 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:49:44 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:49:45 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:49:45 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:50:14 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:50:18 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:50:18 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:50:44 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:51:08 *** plasmashell[1951]: kde.wallpapers.potd: "apod" with arguments () failed to fetch the remote wallpaper. Please check your Internet connection or system date.
Jun 13 00:51:14 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:51:17 *** kded5[18152]: 2023-06-13T07:51:17.885Z [Modules] Checking for host updates.
Jun 13 00:51:18 *** kded5[18152]: 2023-06-13T07:51:18.053Z [Modules] Host is up to date.
Jun 13 00:51:18 *** kded5[18152]: 2023-06-13T07:51:18.053Z [Modules] Checking for module updates at https://discord.com/api/modules/stable/versions.json
Jun 13 00:51:18 *** kded5[18152]: 2023-06-13T07:51:18.081Z [Modules] No module updates available.
Jun 13 00:51:22 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:51:22 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:51:33 *** wpa_supplicant[887]: wlp4s0: WPA: Group rekeying completed with 88:1f:a1:31:c2:a7 [GTK=CCMP]
Jun 13 00:51:44 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:51:48 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:51:48 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:52:14 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:52:18 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:52:18 *** rtkit-daemon[1874]: Supervising 11 threads of 7 processes of 1 users.
Jun 13 00:52:44 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:52:51 *** syncthing[815]: [V7FVL] INFO: Joined relay relay://209.141.42.231:22067
Jun 13 00:53:14 *** kernel: [UFW BLOCK] IN=wlp4s0 OUT= MAC= SRC=fe80:0000:0000:0000:eed6:03e1:cb60:bda0 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=271 TC=0 HOPLIMIT=1 FLOWLBL=1016867 PROTO=UDP SPT=60662 DPT=21027 LEN=231
Jun 13 00:53:19 *** kernel: iwlwifi 0000:04:00.0: Error sending STATISTICS_CMD: time out after 2000ms.
Jun 13 00:53:19 *** kernel: iwlwifi 0000:04:00.0: Current CMD queue read_ptr 114 write_ptr 115
Jun 13 00:53:20 *** kernel: iwlwifi 0000:04:00.0: Queue 0 is active on fifo 7 and stuck for 2500 ms. SW [114, 115] HW [255, 255] FH TRB=0x0ffffffff
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: Start IWL Error Log Dump:
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: Transport status: 0x0000004A, valid: -1
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: Loaded firmware version: 29.4063824552.0 7265D-29.ucode
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | ADVANCED_SYSASSERT
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | trm_hw_status0
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | trm_hw_status1
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | branchlink2
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | interruptlink1
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | interruptlink2
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | data1
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | data2
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | data3
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | beacon time
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | tsf low
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | tsf hi
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | time gp1
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | time gp2
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | uCode revision type
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | uCode version major
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | uCode version minor
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | hw version
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | board version
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | hcmd
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | isr0
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | isr1
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | isr2
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | isr3
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | isr4
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | last cmd Id
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | wait_event
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | l2p_control
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | l2p_duration
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | l2p_mhvalid
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | l2p_addr_match
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | lmpm_pmg_sel
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | timestamp
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | flow_handler
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: Fseq Registers:
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_ERROR_CODE
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_TOP_INIT_VERSION
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_CNVIO_INIT_VERSION
Jun 13 00:53:28 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_OTP_VERSION
Jun 13 00:53:29 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_TOP_CONTENT_VERSION
Jun 13 00:53:29 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_ALIVE_TOKEN
Jun 13 00:53:29 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_CNVI_ID
Jun 13 00:53:29 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | FSEQ_CNVR_ID
Jun 13 00:53:29 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | CNVI_AUX_MISC_CHIP
Jun 13 00:53:29 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | CNVR_AUX_MISC_CHIP
Jun 13 00:53:30 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
Jun 13 00:53:30 *** kernel: iwlwifi 0000:04:00.0: 0xFFFFFFFF | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
Jun 13 00:53:30 *** kernel: iwlwifi 0000:04:00.0: Collecting data: trigger 2 fired.
Jun 13 00:53:30 *** kernel: ieee80211 phy0: Hardware restart was requestedOffline
Not tail, not grep - the entire journal.
I can't see what you're connecting to, which software (there's wpa_supplciant but your subject says "iwlctl" (which is probably not a thing but sounds a lot like iwctl) operates the NIC, whether ther're previous errors on the NIC or the bus… yaddayaddayadda.
The journal isn't supposed to contain sensitive data, but based on "tHe fIrMwArE CrAsHeD" I can't make any kind of even remotely informed comment.
On a limb, disable ax, ac and be and also mac randomization - also look at multiple incidents and whether it's typically preceeded by group rekeying.
Also, how does the previous boot end w/ a restart of the NIC, did you just push the power button or what?
Is there a parallel windows installation?
Offline
sudo journalctl -b | curl -F 'f:1=<-' ix.iofor the current one "(or … -b -1 …" for the previous boot)
I wasn't able to get the ix.io pastebin to work, as it was not returning the url for the pasted items. Any idea why this is happening?
Offline
If the journal is excessively long (eg. because of the UFW logs) you'll get quota'd.
Try
sudo journalctl -b -1 | curl -F 'file=@-' 0x0.stand you might want to redirect the journal into a file (first) anyway to see how big it actually is (and how long the upload could take you…)
Offline
Thanks! The full journal is located in
http://0x0.st/HTbF.txtOffline
There's only NM and wpa_supplicant.
MAC randomized scanning is active, but despite covering 36h (no interim S3), there's only one scan.
=> Do you configure the BSSID already?
Jun 11 12:23:42 *** kernel: iwlwifi 0000:04:00.0: Applying debug destination EXTERNAL_DRAM
Jun 11 12:23:42 *** kernel: iwlwifi 0000:04:00.0: Applying debug destination EXTERNAL_DRAM
Jun 11 12:23:42 *** kernel: iwlwifi 0000:04:00.0: FW already configured (0) - re-configuring
Jun 11 12:23:42 *** kernel: ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
Jun 11 12:23:42 *** kernel: ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
Jun 11 12:23:42 *** kernel: ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
Jun 11 12:23:42 *** kernel: ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
Jun 11 12:23:42 *** kernel: ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
Jun 11 12:23:42 *** kernel: ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)
Jun 11 12:23:42 *** kernel: ACPI: \: failed to evaluate _DSM bf0212f2-788f-c64d-a5b3-1f738e285ade (0x1001)Bogus ACPI implementation in the BIOS
There're 3 lease updates and almost 40 re-keyings, all uneventful.
There're no network or bus errors that would suggest any kind of problem.
The system has a fairly long uptime, but doesn't look like it's a server?
You could try to frequently (over night) disconnect the AP, reload iwlwifi and reconnect the AP in case this is really just a buffer overflow in the FW (because then other than reporting a bug upstream and/or pot. downgrading the FW there's not much else to mitigate this)
You didn't address
how does the previous boot end w/ a restart of the NIC, did you just push the power button or what?
Is there a parallel windows installation?
The firmware should™ have just restarted and the system continued.
systool -vm iwlwifi
systool -vm iwlmvmOffline
Also, how does the previous boot end w/ a restart of the NIC, did you just push the power button or what?
Is there a parallel windows installation?
It usually crashes when I'm away from the device while it's sitting idle, but when I am around to see it actively crash, the system usually freezes a bit and becomes extremely glitchy before crashing. I do not touch the power button, though I do have a dual boot windows install (which I haven't used in months).
Do you configure the BSSID already?
No I have not.
The system has a fairly long uptime, but doesn't look like it's a server?
You could try to frequently (over night) disconnect the AP, reload iwlwifi and reconnect the AP in case this is really just a buffer overflow in the FW (because then other than reporting a bug upstream and/or pot. downgrading the FW there's not much else to mitigate this)
There's a couple of things I need clarification on. What is an AP, and how would I perform that operation? Assuming that FW means firewall, I installed UFW some time after this issue started popping up. I'm not sure if that is relevant though.
Bogus ACPI implementation in the BIOS
Is this something I should be worried about?
systool -vm iwlwifi systool -vm iwlmvm
What does this do?
Also I have tried reinstalling the linux firmware and it doesn't seem to do anything, for what it's worth.
Offline
I do have a dual boot windows install
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
It usually crashes when I'm away from the device while it's sitting idle
Always "at night"?
There's a couple of things I need clarification on.
"FirmWare"
"Access Point" (hot spot, your wifi router)
https://wiki.archlinux.org/title/Networ … i_examples
To reload the module: "man modprobe", you can combine this eg. in a cronjob.
No I have not.
That's kinda odd, because NM is otherwise very scan-happy.
Maybe post the connection configuration, https://wiki.archlinux.org/title/Networ … connection
What does this do?
"man systool" (it prints the module configuration, but if you don't trust the command, you should not trust the descritption either)
I have tried reinstalling the linux firmware
Unless
pacman -Qkk linux-firmwaresuggests the package desintegrated, that's idempotent.
Offline
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
I have fast start disabled already (for writing to ntfs partition) and have reboot multiple times on both ends since then.
Always "at night"?
No, it's pretty random when it crashes.
The system has a fairly long uptime, but doesn't look like it's a server?
You could try to frequently (over night) disconnect the AP, reload iwlwifi and reconnect the AP in case this is really just a buffer overflow in the FW (because then other than reporting a bug upstream and/or pot. downgrading the FW there's not much else to mitigate this)
I am kind of using it like a server/remote workstation sometimes via ssh. My router is a Apple Airport Extreme, which has been discontinued/deprecated and hasn't had any firmware updates in many years.
Maybe post the connection configuration
My config file is default with only comments.
nmcli connection showNAME UUID TYPE DEVICE
****************** ************************************ wifi wlp4s0
****************** ************************************ loopback lo
****************** ************************************ ethernet -- Other module configurations
systool -vm iwlwifiModule = "iwlwifi"
Attributes:
coresize = "548864"
initsize = "0"
initstate = "live"
refcnt = "1"
srcversion = "5309898BCF2E615488FCDC8"
taint = ""
uevent = <store method only>
Parameters:
11n_disable = "0"
amsdu_size = "0"
bt_coex_active = "Y"
debug = "0"
disable_11ac = "N"
disable_11ax = "N"
disable_11be = "N"
fw_restart = "Y"
led_mode = "0"
nvm_file = "(null)"
power_level = "0"
power_save = "N"
remove_when_gone = "N"
swcrypto = "0"
uapsd_disable = "3"
Sections:systool -vm iwlmvmModule = "iwlmvm"
Attributes:
coresize = "618496"
initsize = "0"
initstate = "live"
refcnt = "0"
srcversion = "1A573A86D763251F4835B08"
taint = ""
uevent = <store method only>
Parameters:
init_dbg = "N"
power_scheme = "2"
Sections:Offline
hasn't had any firmware updates in many years.
I meant the iwlwifi firmware.
nmcli connection show
I rather meant the files in /etc/NetworkManager/system-connections/ (you must hide the password and can replace every number w/ 12:34:56:78:90)
systool -vm
All the default values.
I have fast start disabled already (for writing to ntfs partition)
You should probably check that it still is, as windows habitually re-enables it with udpates ![]()
I don't like the abrupt ending of the journal and w/
the system usually freezes a bit and becomes extremely glitchy before crashing
the problem could be something entirely different and the wifi is just an early symptom that is the last thing that gets logged.
The usual suspects are "nvme" and "ryzen"
https://wiki.archlinux.org/title/Solid_ … leshooting
* nvme_core.default_ps_max_latency_us=0
* iommu=soft
https://wiki.archlinux.org/title/Ryzen#Troubleshooting
* processor.max_cstate=1
* "use the AMD curve optimiser which is accessible via your motherboard's bios. Access it and put a positive offset of 4 points" (though that wouldn't fit the idle context of the crash)
Offline
I meant the iwlwifi firmware.
I'll set up a script for that using modprobe and cron and see how that goes.
I rather meant the files in /etc/NetworkManager/system-connections/
[connection]
id=**
uuid=**
type=wifi
interface-name=wlp4s0
[wifi]
mode=infrastructure
ssid=**
[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=**
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]You should probably check that it still is, as windows habitually re-enables it with udpates
Dangit Windows, I'll go check on it again when I reboot.
the problem could be something entirely different and the wifi is just an early symptom that is the last thing that gets logged.
Is it possible for this to be just a hardware issue?
The usual suspects are "nvme" and "ryzen"
From the link you sent,
kernel: mce: [Hardware Error]: Machine check events logged
kernel: mce: [Hardware Error]: CPU 22: Machine Check: 0 Bank 1: bc800800060c0859
kernel: mce: [Hardware Error]: TSC 0 ADDR 7ea8f5b00 MISC d012000000000000 IPID 100b000000000
kernel: mce: [Hardware Error]: PROCESSOR 2:a20f10 TIME 1636645367 SOCKET 0 APIC d microcode a201016sometimes does show up in my journals, though it's less consistent than seeing the iwlwifi messages which shows up every time it crashes.
I also am suspicious about the 0xFFFFFFFF registers in my iwlwifi logs, as everywhere else I've been able to find that error message it has been something more reasonable/random.
Offline
Is it possible for this to be just a hardware issue?
The usual suspects are "nvme" and "ryzen"
I don't think the HW is broken™ because you'd then see this
* immediately
* under stress
But you're getting it on idleness, so I'd look at those two things.
Unfortunately w/ this kind of condition there isn't much you can do but disable APST and higher c-states and iommu and wait and see and if the issue apparently went away, re-add those features one by one and wait out each step for the issue to re-appear ![]()
Because of the shortened log, what happens after the issue occurs?
You're not pushing the power button, does the system restart by itself? Do you reboot it correctly? Does anything weird happen during those reboots (timeouts, error messages, …)?
Offline
Because of the shortened log, what happens after the issue occurs?
You're not pushing the power button, does the system restart by itself? Do you reboot it correctly? Does anything weird happen during those reboots (timeouts, error messages, …)?
The system automatically restarts, but there are some interesting logs (see below, truncated up to Jun 14).
journalctl -b | curl -F 'file=@-' 0x0.sthttp://0x0.st/HTQX.txtUnfortunately w/ this kind of condition there isn't much you can do but disable APST and higher c-states and iommu and wait and see and if the issue apparently went away, re-add those features one by one and wait out each step for the issue to re-appear
I guess it's a waiting game at this point... hoping for the best with the small changes.
Offline
The system automatically restarts
Rather "ryzen" than "nvme" then, as indicated by the wiki, this is a known issue.
And it fits the idleness factor.
Offline
Rather "ryzen" than "nvme" then, as indicated by the wiki, this is a known issue.
And it fits the idleness factor.
The weird thing is that I'm using a R7 3700x instead of a 5000 series. This issue did appear after I received my motherboard replacement, so it might be an issue with 5000-compatible motherboards instead? I'm not exactly sure
Offline
The idleness points more towards the deeper c-states than the power curve, but maybe the new board undercuts voltage only in that context.
Raise the voltage and disable c-states > 1
If the system turns stable, raise the c-state limit (3, 5, then remove the limit) - you'll either get away w/ the voltage adjustment or have to sacrifice deeper c-states.
Offline
Pages: 1