ASM1166 issues with PVE 9 (kernel 6.14.11-1-pve)

[TheWallFe]

With the upgrade to PVE 9, all the disks on me ASM1166 based controller stopped working (devices get disabled after some rather arbitrary communication error messages).
Reverting back to 6.8.12-14-pve works fine for now.

Interestingly, the pass-through some other people report issues with, worked fine for me. I tried pass-through to update the firmware from a Windows VM, but the FW turned out to be recent already.

 

[dakralex]

Hi!

Which kernel were you using before that made the ASM1166 controller stop working? Could you include a bootlog and the communication errors that you reported?

AFAICS there were a few patches [0] [1] [2] regarding the ASM1166, but all of these patches are present in proxmox-kernel-6.14.11.1-pve and proxmox-kernel-6.8.12-14-pve. If you want, you can also take a closer look at [2] as that reports a regression with SATA port multiplication, which can be fixed with a separate kernel module parameter.

[0] https://lore.kernel.org/all/20240123183002.15499-1-conikost@gentoo.org/
[1] https://lore.kernel.org/all/20240313214650.2165-1-conikost@gentoo.org/
[2] https://lore.kernel.org/all/20240405125143.1134539-1-dlemoal@kernel.org/

 

[Zalaare]

Hello,

This seems possibly related to this thread.

 

[TheWallFe]

Hi,
the new kernel was 6.14.11-1-pve, just after upgrading to PVE 9

One of the drives has an issue and has to be replaced, but comparing the logs, this is what happens with the others (same picture for all other drives on the controller)

6.8.12-14-pve:

Sep 01 11:49:02 prox-x64-001 kernel: ata14: SATA max UDMA/133 abar m8192@0xdf380000 port 0xdf380380 irq 141 lpm-pol 0
Sep 01 11:49:02 prox-x64-001 kernel: ata14: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Sep 01 11:49:02 prox-x64-001 kernel: ata14.00: ATA-10: WDC WD40EFZX-68AWUN0, 81.00A81, max UDMA/133
Sep 01 11:49:02 prox-x64-001 kernel: ata14.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 32)
Sep 01 11:49:02 prox-x64-001 kernel: ata14.00: configured for UDMA/133

6.14.11-1-pve:

Sep 01 11:23:17 prox-x64-001 kernel: ata14: SATA max UDMA/133 abar m8192@0xdf380000 port 0xdf380380 irq 135 lpm-pol 3
Sep 01 11:23:17 prox-x64-001 kernel: ata14: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Sep 01 11:23:17 prox-x64-001 kernel: ata14.00: ATA-10: WDC WD40EFZX-68AWUN0, 81.00A81, max UDMA/133
Sep 01 11:23:17 prox-x64-001 kernel: ata14.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 32)
Sep 01 11:23:17 prox-x64-001 kernel: ata14.00: configured for UDMA/133
Sep 01 11:23:17 prox-x64-001 kernel: ata14: link is slow to respond, please be patient (ready=0)
Sep 01 11:23:17 prox-x64-001 kernel: ata14: link is slow to respond, please be patient (ready=0)
Sep 01 11:23:17 prox-x64-001 kernel: ata14: link is slow to respond, please be patient (ready=0)
Sep 01 11:23:17 prox-x64-001 kernel: ata14: limiting SATA link speed to 3.0 Gbps
Sep 01 11:23:17 prox-x64-001 kernel: ata14: hardreset failed
Sep 01 11:23:17 prox-x64-001 kernel: ata14: reset failed, giving up
Sep 01 11:23:17 prox-x64-001 kernel: ata14.00: disable device

In 6.14.11-1-pve lpm-pol 3 is set for the ASM1166 controller, which seems to cause the issue.

The working onboard Intel controller still uses lpm-pol 0 on 6.14.11-1-pve:

Sep 01 11:23:17 prox-x64-001 kernel: ata8: SATA max UDMA/133 abar m2048@0xdf44b000 port 0xdf44b480 irq 129 lpm-pol 0
Sep 01 11:23:17 prox-x64-001 kernel: ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Sep 01 11:23:17 prox-x64-001 kernel: ata8.00: ATA-10: WDC WD40EFZX-68AWUN0, 81.00B81, max UDMA/133
Sep 01 11:23:17 prox-x64-001 kernel: ata8.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 32)
Sep 01 11:23:17 prox-x64-001 kernel: ata8.00: configured for UDMA/133

Added libata.force=nolpm to the kernel parameters and it works now on 6.14.11-1-pve:

Sep 02 20:43:34 prox-x64-001 kernel: ata14: SATA max UDMA/133 abar m8192@0xdf380000 port 0xdf380380 irq 142 lpm-pol 3
Sep 02 20:43:34 prox-x64-001 kernel: ata14: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Sep 02 20:43:34 prox-x64-001 kernel: ata14.00: FORCE: modified (nolpm)
Sep 02 20:43:34 prox-x64-001 kernel: ata14.00: LPM support broken, forcing max_power
Sep 02 20:43:34 prox-x64-001 kernel: ata14.00: ATA-10: WDC WD40EFZX-68AWUN0, 81.00A81, max UDMA/133
Sep 02 20:43:34 prox-x64-001 kernel: ata14.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 32)
Sep 02 20:43:34 prox-x64-001 kernel: ata14.00: LPM support broken, forcing max_power
Sep 02 20:43:34 prox-x64-001 kernel: ata14.00: configured for UDMA/133

 

[dakralex]

Added libata.force=nolpm to the kernel parameters and it works now on 6.14.11-1-pve:

Thanks! It would be great if you added the "[ SOLVED ]" prefix to your post, so that other users with the same problem can find the solution quicker.

On another note, does the ASM1166/the disks support LRM? The lpm-pol 3 indicates that it's policy is reported as ATA_LPM_MED_POWER_WITH_DIPM by firmware or firmware settings, but was lrm-pol 0 before, i.e. ATA_LPM_UNKNOWN.

 

[TheWallFe]

Thanks! It would be great if you added the "[ SOLVED ]" prefix to your post, so that other users with the same problem can find the solution quicker.

On another note, does the ASM1166/the disks support LRM? The lpm-pol 3 indicates that it's policy is reported as ATA_LPM_MED_POWER_WITH_DIPM by firmware or firmware settings, but was lrm-pol 0 before, i.e. ATA_LPM_UNKNOWN.

Well, seems like it doesn't actually support LPM but reports wrong or the new driver interprets wrong whatever it gets reported. I would't know how to diagnose that.

 

[IreuN]

Thanks guys! I've got a mini pc with an M.2 E key -> 4x SATA adapter (ASM1064) it required `pci_aspm=off` under 6.8 kernel to boot correctly.

After update to kernel 6.14 it would not boot correctly even with that option, but additional `libata.force=nolpm` resolved this issue!