Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #85063 > unrolled thread

Bug#1091893: linux-image-6.1.0-28-amd64: Watchdog detected hard LOCKUP on CPU 8, then CPU 0

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1091893: linux-image-6.1.0-28-amd64: Watchdog detected hard LOCKUP on CPU 8, then CPU 0 "Neal P. Murphy" <fest3er@nuxen.murent.us> - 2025-01-09 10:40 +0100
    Bug#1091893: linux-image-6.1.0-28-amd64: Watchdog detected hard LOCKUP on CPU 8, then CPU 0 Uwe Kleine-König <ukleinek@debian.org> - 2025-01-17 18:00 +0100

#85063 — Bug#1091893: linux-image-6.1.0-28-amd64: Watchdog detected hard LOCKUP on CPU 8, then CPU 0

On Wed, 8 Jan 2025 22:15:48 +0100
Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote:

> Hello Neal,
> 
> On Wed, Jan 01, 2025 at 11:18:37PM -0500, Neal Murphy wrote:
> > Package: src:linux
> > Version: 6.1.119-1
> > Severity: critical
> > Justification: breaks the whole system
> > 
> > Dear Maintainer,
> > 
> > I plugged in my SSK NVME-to-USB3 adapter. I mounted it, checked it (without
> > writing anything), and unmounted it. The system displayed the '... has data to
> > be written ...' msg for quite a while. Around then, the system displayed the
> > watchdog error on CPU 8. Shortly after, it displayed a watchdog error on CPU 0
> > and the system became unresponsive requiring a hard reset.
> > 
> > When I got the SSK, it worked well on the desktop. Months later, I had problems
> > with it, but didn't get any kernel oopses. The drive works OK on my Asus
> > laptop, so I'm beginning to suspect my desktop's hardware.
> > 
> > I'm reporting this because flaky hardware usually shouldn't cause a system
> > lockup.  
> 
> This isn't only half of the truth. In an ideal world it would be true,
> but in reality this often doesn't work.
> 
> There is another bugreport that looks quite similar to yours:
> https://lore.kernel.org/all/bug-219532-208809@https.bugzilla.kernel.org%2F/.
> The currently last message in that thread (from Dec 1, 22:07) has a
> patch. It would be great if you could test that and report upstream.
> 
> Best regards
> Uwe

Hmmm. It's definitely a hardware (mainboard) issue of some kind.

Running Linux 6.11.5 from backports.
------------------------------
The device works fine plugged into a USB3.2 port in the back of the computer. It will mount and umount rapidly many times. I can read many GiB of data from it. I can write 10 GiB of data to it. I can let it sit idle for some minutes. No errors appear in syslog.

Plugged into one of the front USB3 ports, it works fine. For about a minute. Then the system produces variations of the following:
----
2025-01-09T03:20:26.514887-05:00 playground kernel: [596625.269156] sd 9:0:0:0: [sdd] tag#18 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN 
2025-01-09T03:20:26.514900-05:00 playground kernel: [596625.269479] sd 9:0:0:0: [sdd] tag#18 CDB: Read(10) 28 00 00 00 00 00 00 00 01 00
----
and more errors, finally unmounting and disconnecting the drive. The errors occur whether or not I do anything with the drive (read, mount, read-write files, unmount, etc.)

If I plug the drive into a front port and do nothing with it, the errors occur after about 30 seconds.

Importantly, the system does *not* hang/crash when running 6.11.5; the errors are handled well.

Linux 6.1.0
-----------
As for Bookworm's 6.1 kernel, while I might have better luck patching/building the 6.1.0-28 kernel (trying to build 6.11 from backports was a Borg-ish experience), I would gladly run an xhci module patched/built by someone familiar with the Debian build methodology; it is alien territory for me. (Well, provided that the patch noted above is easily applied to 6.1.) If it has lots of debugging built in, even better.

Thanks,
Neal

[toc] | [next] | [standalone]

#85174

[Multipart message — attachments visible in raw view] — view raw

Hey Neal,

On Thu, Jan 09, 2025 at 04:27:10AM -0500, Neal P. Murphy wrote:
> On Wed, 8 Jan 2025 22:15:48 +0100
> Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote:
> 
> > Hello Neal,
> > 
> > On Wed, Jan 01, 2025 at 11:18:37PM -0500, Neal Murphy wrote:
> > > Package: src:linux
> > > Version: 6.1.119-1
> > > Severity: critical
> > > Justification: breaks the whole system
> > > 
> > > Dear Maintainer,
> > > 
> > > I plugged in my SSK NVME-to-USB3 adapter. I mounted it, checked it (without
> > > writing anything), and unmounted it. The system displayed the '... has data to
> > > be written ...' msg for quite a while. Around then, the system displayed the
> > > watchdog error on CPU 8. Shortly after, it displayed a watchdog error on CPU 0
> > > and the system became unresponsive requiring a hard reset.
> > > 
> > > When I got the SSK, it worked well on the desktop. Months later, I had problems
> > > with it, but didn't get any kernel oopses. The drive works OK on my Asus
> > > laptop, so I'm beginning to suspect my desktop's hardware.
> > > 
> > > I'm reporting this because flaky hardware usually shouldn't cause a system
> > > lockup.  
> > 
> > This isn't only half of the truth. In an ideal world it would be true,
> > but in reality this often doesn't work.
> > 
> > There is another bugreport that looks quite similar to yours:
> > https://lore.kernel.org/all/bug-219532-208809@https.bugzilla.kernel.org%2F/.
> > The currently last message in that thread (from Dec 1, 22:07) has a
> > patch. It would be great if you could test that and report upstream.
> > 
> > Best regards
> > Uwe
> 
> Hmmm. It's definitely a hardware (mainboard) issue of some kind.
> 
> Running Linux 6.11.5 from backports.
> ------------------------------
> The device works fine plugged into a USB3.2 port in the back of the computer. It will mount and umount rapidly many times. I can read many GiB of data from it. I can write 10 GiB of data to it. I can let it sit idle for some minutes. No errors appear in syslog.
> 
> Plugged into one of the front USB3 ports, it works fine. For about a minute. Then the system produces variations of the following:
> ----
> 2025-01-09T03:20:26.514887-05:00 playground kernel: [596625.269156] sd 9:0:0:0: [sdd] tag#18 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN 
> 2025-01-09T03:20:26.514900-05:00 playground kernel: [596625.269479] sd 9:0:0:0: [sdd] tag#18 CDB: Read(10) 28 00 00 00 00 00 00 00 01 00
> ----
> and more errors, finally unmounting and disconnecting the drive. The errors occur whether or not I do anything with the drive (read, mount, read-write files, unmount, etc.)
> 
> If I plug the drive into a front port and do nothing with it, the errors occur after about 30 seconds.
> 
> Importantly, the system does *not* hang/crash when running 6.11.5; the errors are handled well.

That's good news, thanks for your test.
 
> Linux 6.1.0
> -----------
> As for Bookworm's 6.1 kernel, while I might have better luck
> patching/building the 6.1.0-28 kernel (trying to build 6.11 from
> backports was a Borg-ish experience), I would gladly run an xhci
> module patched/built by someone familiar with the Debian build
> methodology; it is alien territory for me. (Well, provided that the
> patch noted above is easily applied to 6.1.) If it has lots of
> debugging built in, even better.

I tend to not work on fixing 6.1 here. Someone could try to identify the
relevant changes between 6.1 and 6.11, but I guess that's a tidious work
and in the end it's not a single commit that needs backporting but a
whole bunch of commits. (That someone would probably have to be you, as
you have access to that hardware.)

So I suggest you just stick to the backport kernel until Debian 13.

Best regards
Uwe

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web