Arch Linux

Dyslectric

Member

Registered: 2022-06-05

Posts: 1

ata "Failed to resume link" seemingly heavily inflating boot times

I am doing my absolute best to type this without doing so through teared eyes and gritted teeth, but I have been trying to solve this for a few hours and it seems like I just cannot use a search engine for the life of me to find a solution to this issue. I've seen this error code come up in other places but it never seems to be the center of attention when diagnosing long boot times because it seems like the least of concerns. This error seems to be causing 10 seconds of delay during kernel initialization. here is the output of "dmesg | grep ata" (messages after systemd starts are omitted).

[    0.069927] Memory: 16208252K/16727116K available (14343K kernel code, 2098K rwdata, 10980K rodata, 1852K init, 3368K bss, 518604K reserved, 0K cma-reserved)
[    0.270962] libata version 3.00 loaded.
[    2.481017] ata1: SATA max UDMA/133 abar m131072@0xfcc80000 port 0xfcc80100 irq 45
[    2.481019] ata2: SATA max UDMA/133 abar m131072@0xfcc80000 port 0xfcc80180 irq 45
[    2.481021] ata3: SATA max UDMA/133 abar m131072@0xfcc80000 port 0xfcc80200 irq 45
[    2.481022] ata4: SATA max UDMA/133 abar m131072@0xfcc80000 port 0xfcc80280 irq 45
[    2.481024] ata5: SATA max UDMA/133 abar m131072@0xfcc80000 port 0xfcc80300 irq 45
[    2.481025] ata6: SATA max UDMA/133 abar m131072@0xfcc80000 port 0xfcc80380 irq 45
[    2.481027] ata7: SATA max UDMA/133 abar m131072@0xfcc80000 port 0xfcc80400 irq 45
[    2.481028] ata8: SATA max UDMA/133 abar m131072@0xfcc80000 port 0xfcc80480 irq 45
[    2.481222] ata9: SATA max UDMA/133 abar m2048@0xfce00000 port 0xfce00100 irq 47
[    2.481402] ata10: SATA max UDMA/133 abar m2048@0xfcd00000 port 0xfcd00100 irq 49
[    2.789898] ata1: SATA link down (SStatus 0 SControl 300)
[    2.789902] ata10: SATA link down (SStatus 0 SControl 300)
[    2.789903] ata9: SATA link down (SStatus 0 SControl 300)
[    3.100327] ata2: SATA link down (SStatus 0 SControl 300)
[    4.133587] ata3: failed to resume link (SControl 0)
[    4.133603] ata3: SATA link down (SStatus 0 SControl 0)
[    5.166924] ata4: failed to resume link (SControl 0)
[    5.166940] ata4: SATA link down (SStatus 0 SControl 0)
[    5.476918] ata5: SATA link down (SStatus 0 SControl 300)
[    5.786954] ata6: SATA link down (SStatus 0 SControl 300)
[    6.820255] ata7: failed to resume link (SControl 0)
[    6.820271] ata7: SATA link down (SStatus 0 SControl 0)
[    7.853594] ata8: failed to resume link (SControl 0)
[    7.853609] ata8: SATA link down (SStatus 0 SControl 0)
[    7.855352] Write protecting the kernel read-only data: 28672k
[    7.855681] Freeing unused kernel image (text/rodata gap) memory: 2040K
[    7.855840] Freeing unused kernel image (rodata/data gap) memory: 1308K
[    7.883673] rodata_test: all tests were successful
[   10.506514] EXT4-fs (nvme0n1p3): mounted filesystem with ordered data mode. Quota mode: none.

All of the messages from 2.780 to 7.853 are exactly the same as unfiltered dmesg. The best solution, I'd think, in my case, is to just outright and completely disable AHCI since I have absolutely no intention of using SATA drives in my PC ever again. I have tried blacklisting AHCI in modprobe.d to no avail for solving this error.
This is all observed on the official base archlinux kernel on a Gigabyte AB350M-DS3H motherboard with a single NVME drive and no connected SATA drives.

EDIT: I have ran lsmod | grep "ahci", no output. Does anyone know what module would be causing this SATA linking tom-foolery?

further EDIT: I have stopped this problem from happening by switching my SATA mode in UEFI to raid from ahci. I guess this is a working solution for me on account of not having sata drives. The message no longer shows up and not much of anything else has changed (it does boot much faster now, 2 second kernel time as opposed to 13 seconds)

Last edited by Dyslectric (2022-06-06 02:44:06)