Re: NOHZ tick-stop error: local softirq work is pending, handler #08!!! on Dell XPS 13 9360
From: Paul Menzel <hidden>
Date: 2025-02-11 11:58:20
Also in:
linux-usb, lkml
Dear Frederic, Thank you for your reply. Am 10.02.25 um 14:26 schrieb Frederic Weisbecker:
Le Mon, Feb 10, 2025 at 12:59:42PM +0100, Paul Menzel a écrit :
quoted hunk ↗ jump to hunk
quoted
Am 10.02.25 um 12:45 schrieb Michał Pecio:quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
On Dell XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022, with Linux 6.9-rc2+quoted
Just for the record, I am still seeing this with 6.14.0-rc1Is this a regression? If so, which versions were not affected?Unfortunately, I do not know. Right now, my logs go back until September 2024. Sep 22 13:08:04 abreu kernel: Linux version 6.11.0-07273-g1e7530883cd2 (build@bohemianrhapsody.molgen.mpg.de) (gcc (Debian 14.2.0-5) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.1) #12 SMP PREEMPT_DYNAMIC Sun Sep 22 09:57:36 CEST 2024quoted
How hard to reproduce? Wasn't it during resume from hibernation?It’s not easy to reproduce, and I believe it’s not related with resuming from hibernation (which I do not use) or ACPI S3 suspend. I think, I can force it more, when having the USB-C adapter with only the network cable plugged into it, and then running `sudo powertop --auto-tune`. But sometimes it seems unrelated.quoted
IRQ isuses may be a red herring, this code here is a busy wait under spinlock. There are a few of those, they cause various problems. if (xhci_handshake(&xhci->op_regs->status, STS_RESTORE, 0, 100 * 1000)) { xhci_warn(xhci, "WARN: xHC restore state timeout\n"); spin_unlock_irq(&xhci->lock); return -ETIMEDOUT; } This thing timing out may be close to the root cause of everything.Interesting. Hopefully the USB folks have an idea.Handler #08 is NET_RX. So something raised the NET_RX on some non-appropriate place, perhaps... Can I ask you one more trace dump? I need: echo 1 > /sys/kernel/tracing/events/irq/softirq_raise/enable echo 1 > /sys/kernel/tracing/options/stacktrace Unfortunately this will also involve a small patch:diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index fa058510af9c..accd2eb8c927 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c@@ -1159,6 +1159,9 @@ static bool report_idle_softirq(void) if (local_bh_blocked()) return false; + trace_printk("STOP\n"); + trace_dump_stack(0); + tracing_off(); pr_warn("NOHZ tick-stop error: local softirq work is pending, handler #%02x!!!\n", pending); ratelimit++;
Thank you for your help. I applied the patch on top of 6.14-rc2, and was able to reproduce the issue. Please find the Linux messages attached, and the trace can be downloaded [1]. Kind regards, Paul [1]: https://owww.molgen.mpg.de/~pmenzel/20250210--dell-xps-13-9360--linux-6.14-rc2--NOHZ-tick-stop-error-local-softirq-work-is-pending--trace.txt.7z
Attachments
- 20250210--dell-xps-13-9360--linux-6.14-rc2--NOHZ-tick-stop-error-local-softirq-work-is-pending.txt [text/plain] 349361 bytes · preview