Random Freeze (Kernel Panic) when Powering via USB-C (linux-zen)

shanoaice · 2025-03-23 01:40:57

Second time posting this. Last time I am still on Arch Linux. I was just using CachyOS-patched Kernels on AUR. I have switched over to Arch Linux stock linux-zen kernel and problem still persists: random freeze only occurs when I power the laptop via USB-C. When I use the provided brick power supply it doesn't happen.

ASUS ROG Zephyrus G16 2025 (GU605MV), Intel CPU, Nvidia GPU on nvidia-open driver.

I am fairly sure that this is caused by USB-C powering since journalctl reports the last kernel message before freeze is almost always this:

3月 21 23:22:23 archlinux kernel: INFO: task kworker/3:1:191 blocked for more than 1105 seconds.
3月 21 23:22:23 archlinux kernel:       Tainted: G           OE      6.13.7-zen1-1-zen #1
3月 21 23:22:23 archlinux kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
3月 21 23:22:23 archlinux kernel: task:kworker/3:1     state:D stack:0     pid:191   tgid:191   ppid:2      flags:0x00004000
3月 21 23:22:23 archlinux kernel: Workqueue: events ucsi_handle_connector_change [typec_ucsi]
3月 21 23:22:23 archlinux kernel: Call Trace:
3月 21 23:22:23 archlinux kernel:  <TASK>
3月 21 23:22:23 archlinux kernel:  __schedule+0x484/0x1f70
3月 21 23:22:23 archlinux kernel:  ? acpi_ns_get_normalized_pathname+0x75/0x170
3月 21 23:22:23 archlinux kernel:  ? acpi_ns_build_normalized_path+0x170/0x1b0
3月 21 23:22:23 archlinux kernel:  schedule_preempt_disabled+0x2e/0x100
3月 21 23:22:23 archlinux kernel:  __mutex_lock.constprop.0+0x433/0x7b0
3月 21 23:22:23 archlinux kernel:  ? queue_work_on+0x42/0x80
3月 21 23:22:23 archlinux kernel:  ucsi_handle_connector_change+0x2a/0x2c0 [typec_ucsi 74df5e63409e011aba8ed63f7fb7c63611a2adbc]
3月 21 23:22:23 archlinux kernel:  process_one_work+0x18f/0x350
3月 21 23:22:23 archlinux kernel:  worker_thread+0x24c/0x380
3月 21 23:22:23 archlinux kernel:  ? __pfx_worker_thread+0x10/0x10
3月 21 23:22:23 archlinux kernel:  kthread+0xcf/0x100
3月 21 23:22:23 archlinux kernel:  ? __pfx_kthread+0x10/0x10
3月 21 23:22:23 archlinux kernel:  ret_from_fork+0x31/0x50
3月 21 23:22:23 archlinux kernel:  ? __pfx_kthread+0x10/0x10
3月 21 23:22:23 archlinux kernel:  ret_from_fork_asm+0x1a/0x30
3月 21 23:22:23 archlinux kernel:  </TASK>

Full log
What can I try to fix this? Is there any kernel parameter that I am able to test?

EDIT: I have tried the Arch Linux stock linux kernel, and it appears to be working fine. I feel that some patchset used for both linux-zen and linux-cachyos is not behaving well with ACPI / USB-C Powering.

Last edited by shanoaice (2025-03-23 06:38:42)

V1del · 2025-03-23 11:31:31

Your hostname was literally cachyos, that's not something that changes between kernels, unless that was a attempt at obfuscating it, in which case the better approach would be to obfuscate it with a token that makes it clear that this is an obfuscation that's not going to clash with the rest of the information (e.g. MYPRIVATEHOSTNAME -> MYHOSTNAME and not a generic string (-> archlinux, cachyos) that has no relation)

I somewhat doubt that either of these kernel patches something in the ACPI/UCSI stacks unless some more aggressive tick rates/scheduler timings bring the thing out of kilt, which is somewhat possible but would still be weird.

shanoaice · 2025-03-24 05:06:51

V1del wrote:

Your hostname was literally cachyos, that's not something that changes between kernels, unless that was a attempt at obfuscating it, in which case the better approach would be to obfuscate it with a token that makes it clear that this is an obfuscation that's not going to clash with the rest of the information (e.g. MYPRIVATEHOSTNAME -> MYHOSTNAME and not a generic string (-> archlinux, cachyos) that has no relation)
I somewhat doubt that either of these kernel patches something in the ACPI/UCSI stacks unless some more aggressive tick rates/scheduler timings bring the thing out of kilt, which is somewhat possible but would still be weird.

I just realized that I did not set the hostname for my machine in /etc/hostname (my fault). The default hostname between kernels might be different. I will try to gather a bit more log, and also on the newly released 6.13.8 kernel to see how things goes.

EDIT: It also happened on stock stable linux kernel 6.13.7, just before I updated and rebooted. It seems to trigger when CPU load is high (I was testing with high zstd compression level on mkinitcpio), probably on my yesterday test the pressure was not enough to trigger the problem. Then same error. Let's see if 6.13.8 changes anything.

EDIT2: Same thing. Stable linux 6.13.8 still have random freeze under high CPU pressure. Also happens while compressing mkinitcpio images.

Last edited by shanoaice (2025-03-24 05:49:08)

seth · 2025-03-24 08:48:31

The default hostname between kernels might be different.

https://aur.archlinux.org/cgit/aur.git/ … achyos#n54 - setting a custom hostname in important in a LAN environment

random freeze under high CPU pressure

When I use the provided brick power supply it doesn't happen.

So the problem is insufficient power supply via that port.
Is it the correct one (all of them might be wired up for power supply but only one of them has been selected by the vendor to allow the mandatory current)

What happens if you run on battery?
What happens if you run on USB but the battery power profile?

Edit: x-ref, https://bbs.archlinux.org/viewtopic.php?id=304434

Last edited by seth (2025-03-24 14:49:16)

Arch Linux

#1 2025-03-23 01:40:57

Random Freeze (Kernel Panic) when Powering via USB-C (linux-zen)

#2 2025-03-23 11:31:31

Re: Random Freeze (Kernel Panic) when Powering via USB-C (linux-zen)

#3 2025-03-24 05:06:51

Re: Random Freeze (Kernel Panic) when Powering via USB-C (linux-zen)

#4 2025-03-24 08:48:31

Re: Random Freeze (Kernel Panic) when Powering via USB-C (linux-zen)

Board footer