You are not logged in.

#1 2025-08-04 18:42:24

avi9526
Member
Registered: 2015-05-15
Posts: 121

[SOLVED] Kernel waste time probing SATA ports

I have PCI-E x1 cheap SATA controller (6 ports) and it is probably causing troubles, but I need those few extra ports. I noticed that my kernel boots slowly, `systemd-analyze plot` shows 10 sec kernel time. I didn't saw any problems in `journal -kb`. But after enabling `earlyprintk=efi,keep loglevel=8` i have noticed that kernel logs are "squished" in time (have same timestamp) in `journal -kb`, which I didn't know. But while spectating those kernel messages in real time with help of `earlyprintk` I have noticed that there is 6 second waste on probing SATA ports:

ata42: SATA link down (SStatus 0 SControl 300)
ata41: SATA link down (SStatus 0 SControl 300)
ata5: SATA link down (SStatus 0 SControl 300)
ata6: SATA link down (SStatus 0 SControl 300)
ata10: SATA link down (SStatus 0 SControl 300)
ata12: SATA link down (SStatus 0 SControl 300)
ata14: SATA link down (SStatus 0 SControl 300)
ata17: SATA link down (SStatus 0 SControl 300)
ata18: SATA link down (SStatus 0 SControl 300)
ata19: SATA link down (SStatus 0 SControl 300)
ata20: SATA link down (SStatus 0 SControl 300)
ata21: SATA link down (SStatus 0 SControl 300)
ata22: SATA link down (SStatus 0 SControl 300)
ata23: SATA link down (SStatus 0 SControl 300)
ata24: SATA link down (SStatus 0 SControl 300)

I don't have that many SATA ports. There is 4 in MB and 6 in PCI-E card. Maybe card is low quality and have non-existent ports.
If I do:

readlink /sys/class/ata_link/* | perl -pe 's|^(.+?)/ata.*$|\1|' | sort | uniq -c

      8 ../../devices/pci0000:00/0000:00:02.1/0000:16:00.1
     32 ../../devices/pci0000:00/0000:00:02.1/0000:16:00.2/0000:20:06.0/0000:27:00.0
      1 ../../devices/pci0000:00/0000:00:08.2/0000:31:00.0
      1 ../../devices/pci0000:00/0000:00:08.2/0000:31:00.1

and compare to

lspci -v | grep "27:00.0"

    27:00.0 SATA controller: ASMedia Technology Inc. ASM1166 Serial ATA Controller (rev 02) (prog-if 01 [AHCI 1.0])

it proves that this card is at fault.

The question is - how to handle this to achieve better boot times while keeping this trash card?

Last edited by avi9526 (2025-08-04 19:08:22)

Offline

#2 2025-08-04 18:59:18

cryptearth
Member
Registered: 2024-02-03
Posts: 1,978

Re: [SOLVED] Kernel waste time probing SATA ports

there was a change to ahci due to exact problem
the change caused issues with cheap HBAs not correctly implementing port multiplication to drop the downlink ports (I was affected)
the solution was the change was reverted because the maintainer figured the additional time some waste due to phantom ports causing delay in probing is the lesser evil than breaking non-compliant HBAs completely

so I guess even if you report this upstream you will get exact that reply
you may build your own kernel with the patch applied but the root cause is the firmware of your HBA is actually some generic one reporting more ports than it actually provides

tldr: getting cheap sata HBAs is not a problem - but you cheaped too much getting some with a bad firmware - if possible return it and get another one for maybe a few bucks more

Offline

#3 2025-08-04 19:07:00

avi9526
Member
Registered: 2015-05-15
Posts: 121

Re: [SOLVED] Kernel waste time probing SATA ports

cryptearth wrote:

…you cheaped too much…

At least this card has heatsink, previous one was giving me random drive disconnects until reboot.
I have second hand LSI SAS 9300-16i but it is overkill (I don't have 16 drives) and also overheat (require extra fan).

You are indeed correct: https://bugzilla.kernel.org/show_bug.cgi?id=211873

adding parameter to kernel cmd:

ahci.mask_port_map=0000:27:00.0=0x3f

was ugly but a solution

Last edited by avi9526 (2025-08-04 19:07:40)

Offline

#4 2025-08-04 23:20:35

cryptearth
Member
Registered: 2024-02-03
Posts: 1,978

Re: [SOLVED] Kernel waste time probing SATA ports

if you want to read up - here's the initial issue: https://bbs.archlinux.org/viewtopic.php?id=293493 which lead to my regression report and revert after there was no other fix without another break: https://lore.kernel.org/lkml/2024031321 … too.org/T/ and https://git.kernel.org/pub/scm/linux/ke … 53674e5de7
as you can see this is an ASMedia specific issue

fun fact: ASMedia seem to have yet another issue on modern platforms due to ourdate firmwares: https://youtu.be/SubIdMugDcw

so I guess until them pushing new firmwares and all those cheap chinese implementors start shipping them - likely only after millions of old stock is flushed first - the "just take an asm1x6x based hba" way isn't one to go - either for some time or not all anymore

other known brands - the lsi sas hba's you mentioned - or jmicron with either jmb582 or jmb585 based layouts with both supporting the jmb575 port-multiplier for up to 30 or 75 ports, respecticely

imagine have your kernel wait on 75 phantom ports ... guess the lsi sas hba doesn't look as bad of an option anymore

as for the heat issue: the lsi ones are specifically designed to be used in racks with high air flow to be cooled passively - they're not meant to be used in regular midi style pc cases

Last edited by cryptearth (2025-08-04 23:22:53)

Offline

Board footer

Powered by FluxBB