Created attachment 184311 [details]
I'm running Arch Linux on a ASRock Z87 Extreme 6. After switching from 4.0 kernel to 4.1. All drives attached to the ASMedia Chipset stopped working.
To inspect this further I switched over to vanilla kernel and did a git bisect to mirror it down to the following commit:
[387d37577fdd05e9472c20885464c2a53b3c945f] PCI: Don't clear ASPM bits when the FADT declares it's unsupported
Created attachment 184321 [details]
4.0 Kernel wit no drive attached to asm1062 ports
Created attachment 184331 [details]
4.0 Kernel with no drive attached to asm1062 ports
Created attachment 184341 [details]
4.0 lspci no drives attached
Created attachment 184351 [details]
4.0 dmesg no drives attached
Created attachment 184361 [details]
4.0 dmesg drive attached
Created attachment 184371 [details]
4.0 lspci drive attached
Created attachment 184381 [details]
4.1 dmesg no drives attached
Created attachment 184391 [details]
4.1 lspci no drives attached
Created attachment 184401 [details]
4.1 dmesg drive attached
Created attachment 184411 [details]
4.1 lspci drive attached
Created attachment 184421 [details]
4.1 dmesg drive hotplugged
Created attachment 184431 [details]
4.1 lspci drive hotplugged
Does it work again if you apply this patch?
Nope. I applied it to v4.1 with no success. Same error messages on boot with no detected drives.
I assume this is still broken. Please correct me if I'm wrong.
True. Still not working. (4.8.6-1-ARCH #1)
Any hint what I can do to work around this? I.e. disable aspm for this device only.
Strangely even disabling aspm completeley (pcie_aspm=off) doesn't work (see attached dmesg/lspci).
The command  seems to disable apsm for the asmedia controller but I'm not able to get any readings from any of the attached drives. Neither helped a pci reset .
 setpci -s 04:00.0 CAP_EXP+10.b=40
 echo 1 > /sys/bus/pci/devices/0000\:04\:00.0/reset
Created attachment 243901 [details]
Created attachment 243911 [details]
Your system advertises ACPI_FADT_NO_ASPM. Prior to 387d37577fdd ("PCI: Don't clear ASPM bits when the FADT declares it's unsupported"), we actively disabled ASPM on all PCIe links. After 387d37577fdd, we leave ASPM alone, so if the BIOS enabled it, it will remain enabled.
ASPM is mostly managed from the upstream end of the link, and your attachment #184411 [details] ("4.1 lspci drive attached") shows it as enabled:
00:1c.4 PCI bridge
Capabilities:  Express (v2) Root Port (Slot+), MSI 00
LnkCtl: ASPM L0s Enabled
Can you try this on a v4.1 or later kernel:
setpci -s 00:1c.4 CAP_EXP+10.b=40
setpci -s 04:00.0 CAP_EXP+10.b=40
I still have the same problem with 4.19.0-5 (devuan beowulf/ceres) after upgrading from older kernel (3.16.0). I managed to set ASPM off using the above setpci command (It only worked if I did it for both, the SATA controller AND the appropriate PCIe bridge!!!) in an initramfs script. I documented the workaround in Czech language here: http://www.abclinuxu.cz/poradna/hardware/show/447956#16 .
The problem lies in the fact that my controller is a cheap chinese crap that does set ASPM on in it's BIOS but it won't work (at least not in combination with my motherboard).
However I feel that it is really a bad practise to break (even broken hardware) which once worked flawlessly in Linux and I would like to suggest that something like "aspm_pcie=force_off" be added which would go back to the behaviour prior to 4.1. Or maybe a hook for a this controller which would switch ASPM by default may even be better???
I agree; as far as possible, we should never break something that previously worked.
What is your motherboard? Would you mind attaching the complete dmesg log and "sudo lspci -vvxxx" output to this bugzilla?
ASPM is mostly a property of an individual link, i.e., the connection between your Root Port and the SATA controller. The BIOS might enable/disable ASPM if it wants to optimize for power or performance, but proper functioning of ASPM shouldn't really depend on the BIOS.
Therefore, I suspect either a Linux ASPM defect or a hardware issue somewhere between the Root Port and the SATA controller. In André-Sebastian's case (see comment #20), I think Linux mostly leaves the ASPM settings alone, and the Root Port is a widely-used Intel device ("00:1c.4 Intel 8 Series/C220 Series Chipset Family PCI Express Root Port") so my guess is an ASMedia SATA controller problem or some sort of electrical issue with the link, e.g., the wires on this motherboard.
André-Sebastian, your v4.1 lspci shows an Intel I211 Gigabit NIC at 03:00.0 (slot #3) with ASPM L0s enabled and the ASMedia SATA at 04:00.0 (slot #4). The SATA doesn't work, but I assume the NIC does. It would be really interesting to know what happens if you can swap the NIC and the SATA controller.
Butrus, if you have another device that supports ASPM, could you try it in the slot where your SATA controller currently is, and attach the "sudo lspci -vvxxx" output here?
If we can figure out that either the ASMedia SATA controller or the slot is broken, we should be able to add a quirk to automatically disable ASPM in that case.