Bug 218896

Please perform regression testing using:

https://docs.kernel.org/admin-guide/bug-bisect.html


Would be great if you attached `dmesg -t` output for kernels 6.6 and 6.7.

Created attachment 306355 [details]
'dmesg -t' kernel 6.6

You will see a SSD Crucial and a HDD Samsung, both plugged with SATA connector

Created attachment 306356 [details]
'dmesg -t' kernel 6.9

Whereas both my Crucial SSD and Samsung HDD are connected, it's like they do no exist.

Hello, i uploaded 'dmesg -t' output for kernel 6.6 and 6.9.

Indeed, i did not have 6.7 installed anymore, it's EOL and i uninstalled it months ago. And it's no more in my distro repository either.

So, you have output for 6.6 and 6.9. Please tell me if you want a dmesg output for 6.8, i can re-install it for you if you want.

Nonetheless, the issue i face of SATA devices not recognized is the same for any kernel version since 6.7 (6.8 and 6.9 subsequently)

Best regards

-ata8: SATA link down (SStatus 0 SControl 300)
-ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
-ata6: SATA link down (SStatus 0 SControl 300)
-ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
-ata5.00: LPM support broken, forcing max_power
-ata5.00: supports DRM functions and may not be fully accessible
-ata5.00: ATA-9: Crucial_CT512MX100SSD1, MU03, max UDMA/133
-ata7.00: HPA detected: current 1953523055, native 1953525168
-ata7.00: ATA-7: SAMSUNG HD103UJ, 1AA01112, max UDMA7
-ata7.00: 1953523055 sectors, multi 16: LBA48 NCQ (depth 32), AA
-ata7.00: configured for UDMA/133
-ata5.00: 1000215216 sectors, multi 16: LBA48 NCQ (depth 32), AA
-ata5.00: Features: Trust Dev-Sleep NCQ-sndrcv NCQ-prio
-ata5.00: LPM support broken, forcing max_power
-ata5.00: supports DRM functions and may not be fully accessible
-ata5.00: configured for UDMA/133
-ahci 0000:00:17.0: port does not support device sleep
-scsi 4:0:0:0: Direct-Access     ATA      Crucial_CT512MX1 MU03 PQ: 0 ANSI: 5
-ata5.00: Enabling discard_zeroes_data
-sd 4:0:0:0: [sda] 1000215216 512-byte logical blocks: (512 GB/477 GiB)
-sd 4:0:0:0: [sda] 4096-byte physical blocks
-sd 4:0:0:0: [sda] Write Protect is off
-sd 4:0:0:0: [sda] Mode Sense: 00 3a 00 00
-sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-sd 4:0:0:0: [sda] Preferred minimum I/O size 4096 bytes
-scsi 6:0:0:0: Direct-Access     ATA      SAMSUNG HD103UJ  1112 PQ: 0 ANSI: 5
-ata5.00: Enabling discard_zeroes_data
-sd 6:0:0:0: [sdb] 1953523055 512-byte logical blocks: (1.00 TB/932 GiB)
-sd 6:0:0:0: [sdb] Write Protect is off
-sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
-sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-sd 6:0:0:0: [sdb] Preferred minimum I/O size 512 bytes
- sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9
-sd 4:0:0:0: [sda] supports TCG Opal
-sd 4:0:0:0: [sda] Attached SCSI disk
- sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 >
-sd 6:0:0:0: [sdb] Attached SCSI disk
+PM: genpd: Disabling unused power domains
+ata8: SATA link down (SStatus 4 SControl 300)
+ata6: SATA link down (SStatus 4 SControl 300)
+ata5: SATA link down (SStatus 4 SControl 300)
+ata7: SATA link down (SStatus 4 SControl 300)

Yeah, kernel 6.9 just gives up and doesn't want to detect anything.

Here's what I've googled up:

https://lore.kernel.org/all/20240513135302.1869084-1-dev@kayoway.com/T/

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2063229

This should be fixed in future stable 6.9.x releases.

https://lore.kernel.org/all/20240513135302.1869084-1-dev@kayoway.com/T/

"However since it is not clear whether it is Alder Lake-S or
Alder Lake-P that was meant to be added to the list in the first place,
I have not committed that patch"

--> Can we make sure that this commit/patch is also available for Alder Lake-S (desktop CPU, like my system), because they are mainly talking about Alder Lake-P (mobile CPU) ?

Thank you.

(In reply to Barracuda from comment #6)
> https://lore.kernel.org/all/20240513135302.1869084-1-dev@kayoway.com/T/
> 
> "However since it is not clear whether it is Alder Lake-S or
> Alder Lake-P that was meant to be added to the list in the first place,
> I have not committed that patch"
> 
> --> Can we make sure that this commit/patch is also available for Alder
> Lake-S (desktop CPU, like my system), because they are mainly talking about
> Alder Lake-P (mobile CPU) ?
 
Please engage with/reply to the mailing list.

Your messages are lost here.

(In reply to Barracuda from comment #0)
> 
> Since Kernel 6.7 (subsequently 6.8, 6.9) none of SATA devices are recognized
> on Alder Lake S CPU. My motherboard has a B660 chipset.

(In reply to Barracuda from comment #6)
> https://lore.kernel.org/all/20240513135302.1869084-1-dev@kayoway.com/T/
> 
> "However since it is not clear whether it is Alder Lake-S or
> Alder Lake-P that was meant to be added to the list in the first place,
> I have not committed that patch"
> 
> --> Can we make sure that this commit/patch is also available for Alder
> Lake-S (desktop CPU, like my system), because they are mainly talking about
> Alder Lake-P (mobile CPU) ?

Let's add Niklas and Damien here, they should know best what is needed without going through the list (or did you do that already Barracuda? did not look like it).

(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #8)
> (In reply to Barracuda from comment #0)
> > 
> > Since Kernel 6.7 (subsequently 6.8, 6.9) none of SATA devices are
> recognized
> > on Alder Lake S CPU. My motherboard has a B660 chipset.
> 
> (In reply to Barracuda from comment #6)
> > https://lore.kernel.org/all/20240513135302.1869084-1-dev@kayoway.com/T/
> > 
> > "However since it is not clear whether it is Alder Lake-S or
> > Alder Lake-P that was meant to be added to the list in the first place,
> > I have not committed that patch"
> > 
> > --> Can we make sure that this commit/patch is also available for Alder
> > Lake-S (desktop CPU, like my system), because they are mainly talking about
> > Alder Lake-P (mobile CPU) ?
> 
> Let's add Niklas and Damien here, they should know best what is needed
> without going through the list (or did you do that already Barracuda? did
> not look like it).

I did not go through the list yet, i am afraid i do not know how to do it with those public inbox :(

The fix for Alder Lake-S (8086:7ae2)
(the comment in the code incorrectly says Alder Lake-P)
is queued and will be sent to Linus later this week:
https://git.kernel.org/pub/scm/linux/kernel/git/libata/linux.git/commit/?h=for-6.10-fixes&id=9e2f46cd87473c70d01fcaf8a559809e6d18dd50

For Alder Lake-P (8086:7ae2),
the PCI device ID does not exist in
static const struct pci_device_id ahci_pci_tbl[],
so a similar fix is not applicable/needed.

(In reply to Niklas Cassel from comment #10)
> The fix for Alder Lake-S (8086:7ae2)
> (the comment in the code incorrectly says Alder Lake-P)
> is queued and will be sent to Linus later this week:
> https://git.kernel.org/pub/scm/linux/kernel/git/libata/linux.git/commit/
> ?h=for-6.10-fixes&id=9e2f46cd87473c70d01fcaf8a559809e6d18dd50
> 
> For Alder Lake-P (8086:7ae2),
> the PCI device ID does not exist in
> static const struct pci_device_id ahci_pci_tbl[],
> so a similar fix is not applicable/needed.

Thank you guys, that's perfect !