Re: kern/56737: WDCTL_RST errors in 9.99.92 and 9.99.93

[Robert Nestor <rnestor%mac.com@localhost>]

The following reply was made to PR kern/56737; it has been noted by GNATS.

From: Robert Nestor <rnestor%mac.com@localhost>
To: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost,
 kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/56737: WDCTL_RST errors in 9.99.92 and 9.99.93
Date: Thu, 5 Jan 2023 09:33:13 -0600

 On Jan 5, 2023, at 8:05 AM, Manuel Bouyer <bouyer%antioche.eu.org@localhost> =
 wrote:
 
 > On Thu, Jan 05, 2023 at 01:50:01PM +0000, Martin Husemann wrote:
 >> The following reply was made to PR kern/56737; it has been noted by =
 GNATS.
 >>=20
 >> From: Martin Husemann <martin%duskware.de@localhost>
 >> To: gnats-bugs%netbsd.org@localhost
 >> Cc:=20
 >> Subject: Re: kern/56737: WDCTL_RST errors in 9.99.92 and 9.99.93
 >> Date: Thu, 5 Jan 2023 14:49:07 +0100
 >>=20
 >> Could you try a kernel with the patch below?
 >>=20
 >> Martin
 >>=20
 >>=20
 >> Index: ahcisata_pci.c
 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 >> RCS file: /cvsroot/src/sys/dev/pci/ahcisata_pci.c,v
 >> retrieving revision 1.68
 >> diff -u -p -r1.68 ahcisata_pci.c
 >> --- ahcisata_pci.c	12 Oct 2022 12:50:02 -0000	1.68
 >> +++ ahcisata_pci.c	5 Jan 2023 13:46:28 -0000
 >> @@ -206,6 +206,8 @@ static const struct ahci_pci_quirk ahci_
 >>  	    AHCI_QUIRK_BADPMP },
 >>=20
 >>      /* extra delay */
 >> +	{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6SERIES_AHCI_1,
 >> +	    AHCI_QUIRK_EXTRA_DELAY },
 >>  	{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_C600_AHCI,
 >>  	    AHCI_QUIRK_EXTRA_DELAY },
 >>  	{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_7SER_MO_SATA_AHCI,
 >=20
 > Actually I wonder it these quirks (AHCI_QUIRK_EXTRA_DELAY) is right.
 > The extra delay may depend on the drive connected to the adapter,
 > not the adapter itself.
 >=20
 > --=20
 > Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 >     NetBSD: 26 ans d'experience feront toujours la difference
 
 In my case it appears that the problem is drive related, not controller =
 related.  Slow drives fail to boot while faster drives succeed using the =
 same controller.  The good news though is that with Martin=92s patch =
 installed I was able to successfully boot one of my slower drives a =
 dozen times without a single failure.  I used a mix of BIOS and UEFI =
 boot to when testing the patch.
 
 Thanks to Martin for the quick patch/fix!
 -bob