Switch Alpha 12 SSD Not Detected in Linux Duct Tape Fix, Need Help Testing

Hello Acer and Acer Community,

I recently purchased an Acer Aspire Switch Alpha 12 with the intent of running Linux on it. I found that intermittently the internal SSD will not get detected by Linux, be it the Linux installed on the local SSD, or a Live USB. The problem happens with Kernel versions 3.13, 4.2, 4.6 and 4.8.11 (released on Nov 26, 2016). Maybe the latest one as well because the last changes in the relevant code (drivers/ata) are about 14 days old and will likely be the same as 4.8.11.

When this happens on a Linux installed on the internal SSD, the Kernel will complain about "no root device /dev/sda". It looks like the following:

Similarly, when this happens in a Live Linux USB session, the internal SSD will not get detected by the Live system. GParted and blkid will only show the Live USB drive:

The same symptom is observed by a German user who has written a Chip.de post and mentioned this problem on Liliputing. There is also a post on the German Acer forum that says poking around BIOS settings may sometimes cause this problem to disappear.

This user's posts corroborate my experience, because when I attempted to install Linux the SSD didn't get hidden after I played around the BIOS settings. However, the next time when I boot from the installed Linux, the same problem may happen again, and it can take me tens of rebooting into Windows and fiddling with BIOS settings before I can boot into the installed Linux again.

=========== Some details ============

I poked around the dmesg output both when the boot is successful and when unsuccessful, and I found the following outputs.

   [    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

   [ 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 could compare the green and red outputs and see that ATA1 and ATA2 become DUMMY when the problem happens. The outputs are printed when the Serial ATA ports are being probed.

To be more specific, Specifically, the following lines in the Kernel are responsible for this:

Starting from Line 448, drivers/ata/ahci.c

/* Values prefixed with saved_ are written back to host after
* reset. Values without are used for driver operation.
*/
hpriv->saved_cap = cap = readl(mmio + HOST_CAP);
hpriv->saved_port_map = port_map = readl(mmio + HOST_PORTS_IMPL);

The value of the cap variable denotes the capabilities of the SATA controller as well as how many SATA ports are available (the last 5 bits to be specific.) The port_map variable is a bit vector indicating which ports are active. When the SSD is correctely detected, cap gets a value of 0xC734FF02 and port_map gets a value of 0x7. When the SSD is not detected, cap can get a value of 0xC734FF01 or 0xC734FF00 with the port_map being 0x0. That causes the kernel to think there are no SATA ports in the system, as if the SSD is disconnected.

One way to fix this is to always force cap to 0xC734FF02 and port_map to 0x7, like the following:

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;
}

On my Acer Aspire Switch Alpha 12, I manage to boot into Linux always successfully where the stock kernel can sometimes fail.

================ The Fix ==================

I've made the aforementioned fix into a DEB package which can be downloaded here: https://www.dropbox.com/sh/zh57i7d0do6x44n/AAALyo15OWfHv4DBjXbcR2_4a?dl=0

Note: In this patch the touchscreen doesn't work, but should not be difficult to fix. I think it's more important to boot up reliably.

I would like to know if the fix can help anyone who is experiencing the same problem.
The fix is called a Duct Tape fix because it overrides the values of cap and port_map, without anyone from Acer confirming this is the "official" way of booting Linux correctly.

Anyway, the fix has brought my Aspire Switch 12 to a useable state and I'm quite happy with Linux on this tablet. I hope this fix would help attract potential Linux users to the Switch Alpha 12.

Thanks!