NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: port-riscv/60482



The following reply was made to PR port-riscv/60482; it has been noted by GNATS.

From: Nick Hudson <nick.hudson%gmx.co.uk@localhost>
To: gnats-bugs%netbsd.org@localhost,
 port-riscv-maintainer%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost,
 slackercruise%gmail.com@localhost
Cc: 
Subject: Re: port-riscv/60482
Date: Mon, 24 Aug 2026 17:18:16 +0100

 --Apple-Mail=_3D7300C5-BDEB-4FA0-8CC7-6FA8FEFB8B69
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=utf-8
 
 
 On 24/08/2026 17:10, Jeff Rizzo via gnats wrote:
 [...]
 >=20
 > =20
 >  I was unable to duplicate this with NetBSD-11.0 (release), which
 >  should not be different than 11.0_RC6 in this regard - so perhaps
 >  this is related to the specific nvme?  Here is the relevant
 >  section from my dmesg:
 > =20
 >  [   1.0000000] pci2 at jh7110pcie1 bus 0
 >  [   1.0000000] ppb1 at pci2 dev 0 function 0: vendor 1556 product =
 1111 (rev. 0x02)
 >  [   1.0000000] ppb1: PCI Express capability version 2 <Root Port of =
 PCI-E Root Complex> x1 @ 5.0GT/s
 >  [   1.0000000] pci3 at ppb1 bus 1
 >  [   1.0000000] nvme0 at pci3 dev 0 function 0: vendor 144d product =
 a809 (rev. 0x00)
 >  [   1.0000000] nvme0: NVMe 1.3
 >  [   1.0000000] nvme0: interrupting at plic0 irq 57
 >  [   1.0000000] nvme0: SAMSUNG MZALQ256HAJD-000L1, firmware BL1QFXV7, =
 serial S4YDNF0NC73147
 >  [   1.0000000] ld4 at nvme0 nsid 1
 >  [   1.0000000] ld4: 238 GB, 31130 cyl, 255 head, 63 sec, 512 =
 bytes/sect x 500118192 sectors (0 bytes/physsect)
 > =20
 >  ...and it gets to multiuser without issue.
 > =20
 >  The obvious difference I see is that my NVMe is version 1.3, not 1.4=20=
 
 >  (like all the ones that cause the hang).
 I used to see these semi-regularly when DEBUG was enabled, but it=E2=80=99=
 s not disabled by default. DEBUG was doing some pretty heavyweight =
 checks which meant timers could get blocked for too long.
 
 FWIW I=E2=80=99ve only tried NVMe 1.3.
 
 
 
 --Apple-Mail=_3D7300C5-BDEB-4FA0-8CC7-6FA8FEFB8B69
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/html;
 	charset=utf-8
 
 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
 content=3D"text/html; charset=3Dutf-8"></head><body =
 style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
 line-break: after-white-space;">
 
  =20
     <meta http-equiv=3D"Content-Type" content=3D"text/html; =
 charset=3DUTF-8">
  =20
   <div><p><br>
     </p>
     <div class=3D"moz-cite-prefix">On 24/08/2026 17:10, Jeff Rizzo via
       gnats wrote:<br>
     </div>
     [...]
     <blockquote type=3D"cite" =
 cite=3D"mid:20260824161002.7762A1A923C%mollari.NetBSD.org@localhost">
       <pre wrap=3D"" class=3D"moz-quote-pre">=20
  I was unable to duplicate this with NetBSD-11.0 (release), which
  should not be different than 11.0_RC6 in this regard - so perhaps
  this is related to the specific nvme?  Here is the relevant
  section from my dmesg:
 =20
  [   1.0000000] pci2 at jh7110pcie1 bus 0
  [   1.0000000] ppb1 at pci2 dev 0 function 0: vendor 1556 product 1111 =
 (rev. 0x02)
  [   1.0000000] ppb1: PCI Express capability version 2 &lt;Root Port of =
 PCI-E Root Complex&gt; x1 @ 5.0GT/s
  [   1.0000000] pci3 at ppb1 bus 1
  [   1.0000000] nvme0 at pci3 dev 0 function 0: vendor 144d product a809 =
 (rev. 0x00)
  [   1.0000000] nvme0: NVMe 1.3
  [   1.0000000] nvme0: interrupting at plic0 irq 57
  [   1.0000000] nvme0: SAMSUNG MZALQ256HAJD-000L1, firmware BL1QFXV7, =
 serial S4YDNF0NC73147
  [   1.0000000] ld4 at nvme0 nsid 1
  [   1.0000000] ld4: 238 GB, 31130 cyl, 255 head, 63 sec, 512 bytes/sect =
 x 500118192 sectors (0 bytes/physsect)
 =20
  ...and it gets to multiuser without issue.
 =20
  The obvious difference I see is that my NVMe is version 1.3, not 1.4=20
  (like all the ones that cause the hang).</pre>
     </blockquote>
     I used to see these semi-regularly when DEBUG was enabled, but =
 it=E2=80=99s not disabled by default. DEBUG was doing some pretty =
 heavyweight checks which meant timers could get blocked for too =
 long.</div><div><br></div><div>FWIW I=E2=80=99ve only tried NVMe =
 1.3.</div><div><br></div><div><br></div>
 
 </body></html>=
 
 --Apple-Mail=_3D7300C5-BDEB-4FA0-8CC7-6FA8FEFB8B69--
 




Home | Main Index | Thread Index | Old Index