Hello, Linux-IDE mailing list,
I recently bought an Acer Aspire Switch Alpha 12 (Model Number: SA5-271)
2-in-1 convertible computer. This computer has an Intel Skylake i5-6200U
processor and a Lite-On CV1-8B256 SSD.
I noticed that the kernel will intermittently fail to detect the SSD as
/dev/sda and may be fixed by changing seemingly unrelated settings in
the BIOS (such as clearing secure boot databases) or with a "dirty hack"
in libahci.c (tested on Kernel 4.8). When the SSD is not detected, the
kernel will print an alert saying "Gave Up waiting for root device.
Alert! /dev/disk/by-uuid/ does not exist. Dropping to a shell." Typing
"blkid" in the initramfs shell shows no devices either.
When the SSD is detected the following lines can be seen in the dmesg
output:
[ 1.347021] ahci 0000:00:17.0: version 3.0
[ 1.365569] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 3 ports 6
Gbps 0x7 impl SATA mode
[ 1.367519] ahci 0000:00:17.0: flags: 64bit ncq pm led clo only
pio slum part deso sadm sds apst
[ 1.377574] scsi host0: ahci
[ 1.379465] scsi host1: ahci
[ 1.381373] scsi host2: ahci
[ 1.383060] ata1: SATA max UDMA/133 abar m2048@0xb1648000 port
0xb1648100 irq 124
[ 1.384665] ata2: SATA max UDMA/133 abar m2048@0xb1648000 port
0xb1648180 irq 124
[ 1.386305] ata3: SATA max UDMA/133 abar m2048@0xb1648000 port
0xb1648200 irq 124
However, when the SSD is not detecting:
[ 1.337065] ahci 0000:00:17.0: version 3.0
-> [ 1.343206] ahci 0000:00:17.0: implemented port map (0x7) contains
more ports than nr_ports (2), using nr_ports
-> [ 1.351165] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 2 ports 6
Gbps 0x0 impl SATA mode
[ 1.352323] ahci 0000:00:17.0: flags: 64bit ncq pm led clo only
pio slum part deso sadm sds apst
[ 1.355960] scsi host0: ahci
[ 1.357292] scsi host1: ahci
-> [ 1.358405] ata1: DUMMY
-> [ 1.359466] ata2: DUMMY
One can note the differences in the marked lines in the dmesg output
when the SSD is not detecting: 1) nr_ports becomes 2 instead of 3; 2)
ATA1 and ATA2 are both DUMMY.
Adding the following lines in the function "ahci_save_initial_config" in
file libahci.c, line 453 seems to fix this for now:
if ((cap & 0xC734FF00) == 0xC734FF00) {
dev_info(dev, "Forcing CAP to 0xC734FF02 and port_map to 0x7!\n");
hpriv->saved_cap = cap = 0xC734FF02;
hpriv->saved_port_map = port_map = 0x7;
}
What the code does is to force port_map to become 0x7 and saved_cap to
become 0xC734FF02. Actually, when the SSD is detecting the cap register
holds a value of 0xC734FF02 but when it fails, cap can be either
0xC734FF01 or 0xC734FF00.
My questions are:
Is this a bad way of solving this; can it possibly damage the computer?
Could this be possibly related to the BIOS of the specific computer?
Thank you so much!
2016-12-01
Sui
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html