kern/53672: New AMD AHCI controller product 43b8 can't do RESET

[brad%anduin.eldar.org@localhost]

>Number:         53672
>Category:       kern
>Synopsis:       New AMD AHCI controller product 43b8 can't do RESET
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 16 13:25:00 +0000 2018
>Originator:     Brad Spencer
>Release:        NetBSD 8.99.25
>Organization:
	eldar.org
>Environment:
System: NetBSD andor.nat.eldar.org 8.99.25 NetBSD 8.99.25 (XEN3_DOM0) #0: Mon Oct  8 22:52:23 EDT 2018  brad%samwise.nat.eldar.org@localhost:/sys/arch/amd64/compile/XEN3_DOM0 amd64
Architecture: x86_64
Machine: amd64
>Description:

I have a new system that uses a pretty new AHCI chip from AMD.  In
fact, so new that no one seems to know what to call it.  None of the
usual PCI DEV ID web sites have it listed yet.

From dmesg:

[     1.000003] ahcisata0 at pci2 dev 0 function 1: vendor 1022 product 43b8 (rev. 0x02)


In any case, this chip does not appear to do WDCTL_RST correctly, or
at least not in the manor our driver expects.  Much of the time, the
wdX device will fail to probe with the:

clearing WDCTL_RST failed

message (from ahcisata_core.c).  There is a bad work around I found in
that if I fob around with nearly any BIOS setting I can get the system
to boot once correctly.  That is, turn off something and save the
settings.  The next time a reboot happens, the device will fail to
probe again, and I simply reset the setting back and it works again,
for one time.  Once the device fails to probe once, no matter how many
times a reboot occurs, or how many times a power cycle occurs, it does
not appear that the device will work, unless you fob something in the
BIOS.

This obviously isn't a very workable solution.

>How-To-Repeat:

Simply try to reboot my new system

>Fix:

This is how I "fixed" it...  With this quirk enabled, the wdX device
probes correctly every single time and there does not appear to be any
obvious down sides.

*** sys/dev/pci/ahcisata_pci.c.DIST	Thu Oct 13 13:55:34 2016
--- sys/dev/pci/ahcisata_pci.c	Wed Oct  3 15:56:05 2018
***************
*** 194,199 ****
--- 194,201 ----
  	    AHCI_PCI_QUIRK_FORCE },
  	{ PCI_VENDOR_ASMEDIA, PCI_PRODUCT_ASMEDIA_ASM1061_12,
  	    AHCI_PCI_QUIRK_FORCE },
+ 	{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_43B8_SATA,
+ 	    AHCI_QUIRK_SKIP_RESET },
  };
  
  struct ahci_pci_softc {

*** sys/dev/pci/pcidevs.DIST	Thu Aug 23 01:18:45 2018
--- sys/dev/pci/pcidevs	Wed Oct  3 15:52:56 2018
***************
*** 1061,1066 ****
--- 1061,1067 ----
  product AMD HUDSON_PCIE_1	0x43a1	Hudson PCIE Root Port 1
  product AMD HUDSON_PCIE_2	0x43a2	Hudson PCIE Root Port 2
  product AMD HUDSON_PCIE_3	0x43a3	Hudson PCIE Root Port 3
+ product AMD 43B8_SATA	0x43b8	AMD SATA Controller
  product AMD SC751_SC	0x7006	AMD751 System Controller
  product AMD SC751_PPB	0x7007	AMD751 PCI-PCI Bridge
  product AMD IGR4_AGP	0x700a	AMD IGR4 AGP Bridge


Regened pcidevs.h and such after the second patch.