Hi, thanks for looking at it. 1) Has it happened more than once? With this exact signature (fput+0x1b reached from do_sys_poll -> fdget): once so far, on 2026-10-13 11:36:23 (-03), kernel 7.0.0-38-generic, version_signature "Ubuntu 7.0.0-38.38~24.04.4-generic 7.0.14". There is one related but distinct kernel-side fault in the same poll/descriptor area on this same machine, on an older kernel (6.17.0-1026-oem, 2026-06-19): Oops "invalid opcode" with RIP pipe_poll+0x95/0x160, six Oopses in the same second on different CPUs, followed by a soft-lockup cascade; the processes caught were gnome-shell, firefox, a Chrome child process, curl and VS Code. I never reported that one, and both kernels are superseded now, but it suggests the family reappears on this hardware.
2) How often? Once during this 47 h boot (boot 2026-10-11 12:32:18 -> crash 2026-10-13 11:36:25). Other boots on this machine have run 24-49 h without this signature. So: rare, but not a one-off in the machine's history. agora 3) Is there anything that can reliably trigger it? No, I have no reproduction. Two observations, offered as hypotheses rather than measured triggers: - One second before the first Oops (11:36:22) a Chrome worker died with SIGILL in userspace, which suggests memory corruption was already in flight beforHi, thanks for looking at it. 1) Has it happened more than once? With this exact signature (fput+0x1b reached from do_sys_poll -> fdget): once so far, on 2026-10-13 11:36:23 (-03), kernel 7.0.0-38-generic, version_signature "Ubuntu 7.0.0-38.38~24.04.4-generic 7.0.14". There is one related but distinct kernel-side fault in the same poll/descriptor area on this same machine, on an older kernel (6.17.0-1026-oem, 2026-06-19): Oops "invalid opcode" with RIP pipe_poll+0x95/0x160, six Oopses in the same second on different CPUs, followed by a soft-lockup cascade; the processes caught were gnome-shell, firefox, a Chrome child process, curl and VS Code. I never reported that one, and both kernels are superseded now, but it suggests the family reappears on this hardware. 2) How often? Once during this 47 h boot (boot 2026-10-11 12:32:18 -> crash 2026-10-13 11:36:25). Other boots on this machine have run 24-49 h without this signature. So: rare, but not a one-off in the machine's history. 3) Is there anything that can reliably trigger it? No, I have no reproduction. Two observations, offered as hypotheses rather than measured triggers: - One second before the first Oops (11:36:22) a Chrome worker died with SIGILL in userspace, which suggests memory corruption was already in flight before the kernel fault surfaced. - In both occurrences the machine was running several heavy pollers at the same time (Chrome + Firefox + GNOME shell + Xorg + a CLI agent spawning subprocesses), i.e. many concurrent poll()/pipe users. The June event also had a CLI agent doing terminal/subprocess work. The kernel command line carries only the usual amdgpu workarounds (plus drm.debug=0xe and log_buf_len=8M), no exotic options. I will add a comment here if it happens again: there is a watchdog on the machine that reports any kernel Oops, and the logs are kept. Hi, thanks for looking at it. 1) Has it happened more than once? With this exact signature (fput+0x1b reached from do_sys_poll -> fdget): once so far, on 2026-10-13 11:36:23 (-03), kernel 7.0.0-38-generic, version_signature "Ubuntu 7.0.0-38.38~24.04.4-generic 7.0.14". There is one related but distinct kernel-side fault in the same poll/descriptor area on this same machine, on an older kernel (6.17.0-1026-oem, 2026-06-19): Oops "invalid opcode" with RIP pipe_poll+0x95/0x160, six Oopses in the same second on different CPUs, followed by a soft-lockup cascade; the processes caught were gnome-shell, firefox, a Chrome child process, curl and VS Code. I never reported that one, and both kernels are superseded now, but it suggests the family reappears on this hardware. 2) How often? Once during this 47 h boot (boot 2026-10-11 12:32:18 -> crash 2026-10-13 11:36:25). Other boots on this machine have run 24-49 h without this signature. So: rare, but not a one-off in the machine's history. 3) Is there anything that can reliably trigger it? No, I have no reproduction. Two observations, offered as hypotheses rather than measured triggers: - One second before the first Oops (11:36:22) a Chrome worker died with SIGILL in userspace, which suggests memory corruption was already in flight before the kernel fault surfaced. - In both occurrences the machine was running several heavy pollers at the same time (Chrome + Firefox + GNOME shell + Xorg + a CLI agent spawning subprocesses), i.e. many concurrent poll()/pipe users. The June event also had a CLI agent doing terminal/subprocess work. The kernel command line carries only the usual amdgpu workarounds (plus drm.debug=0xe and log_buf_len=8M), no exotic options. I will add a comment here if it happens again: there is a watchdog on the machine that reports any kernel Oops, and the logs are kept. e the kernel fault surfaced. - In both occurrences the machine was running several heavy pollers at the same time (Chrome + Firefox + GNOME shell + Xorg + a CLI agent spawning subprocesses), i.e. many concurrent poll()/pipe users. The June event also had a CLI agent doing terminal/subprocess work. The kernel command line carries only the usual amdgpu workarounds (plus drm.debug=0xe and log_buf_len=8M), no exotic options. I will add a comment here if it happens again: there is a watchdog on the machine that reports any kernel Oops, and the logs are kept. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2170730 Title: 7.0.0-38-generic: Oops in fput+0x1b via do_sys_poll (poll syscall) kills gnome-shell and Xorg - 3 Oopses in 3 s To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170730/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
