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: SSD hides itself from the Linux Kernel

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.

When the SSD is detected as normal 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 being detected:

   [ 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!

Accepted answers

All comments

IronFly

Good catch!

i can't confirm your fix, since i don't own an Alpha 12 but it looks like a BIOS issue; stupid question: is your BIOS updated?

Probably an highlight to Acer can help to fix it but honestly i doubt they will spend resources on doing it, since Linux is not supported on your laptop.

quadpixels

Hi IronFly,

This is a good question, I should have mentioned it in the post --- BIOS is updated to 1.03, released on Nov. 18, the latest version as of now. So the BIOS update didn't quite help with this issue :-S

IronFly

Ok.
Maybe...it should be worth to send an email about that to Acer support, as i wrote...i'm not sure they would take care.

At this point, i'm curious how windows OS manage this thing.

quadpixels

Thanks for the advice ... I think I will shoot Acer Support an email!

My guess on how Windows handles it is Windows has a mechanism that sends some particular commands to activate the SATA channels. Once you get the right way of doing so, the SSD will not hide itself. People seem to have figured out to do certain particular initialization steps for some particular hardware platforms, as can be seen from the source codes.

I think Intel, Microsoft and Acer may have an agreement to market the Switch Alpha 12 as a Windows Tablet and due to this Windows always get the priority when it comes to support for new hardware. For Linux, maybe the users will get prepared to make their own fixes... at least in the beginning... ha!

IronFly

Ehehehe
Yes, can be a good guess. Smiley Happy

RobFran

Hi...

I was trying to install the Elementary distro of linux to my device. I encountered the exact promblem u described. Sometimes the SSD gets regognized sometimes not.

I would like to try your duct-tape fix. But im not sure on how to go about installing it. Now i removed the OS from the partition becuase i falied to boot it on several occasions. And now i cant seem to install it at all because the SSD wont show up in the installer.

Could you maybe walk me through the process of installing it. Also, is it possible to still dual-boot with windows 10.

quadpixels

Hi RobFran,

Thanks for your reply and join the family of people who use Switch Alpha 12 but can't get their SSDs reliably recognized by the Kernel! XD

The "duct tape solution" is to modify the Linux Kernel source, then compile and install the Kernel with the modified source. The walkthrough will be like every other "compiling the Linux Kernel" tutorial. I followed this one: https://www.howtoforge.com/kernel_compilation_ubuntu_p2

The basic steps of building a Kernel as I know is:

1) Download the source, expand the compressed file, modify drivers/ata/ahci.c .

2) Type the compilation command, and wait for the .deb file to show up

(Note: Steps 1 and 2 can be done on another computer, as long as its architecture is also x86_64)

3) install the .deb file on the Acer Switch Alpha 12, and you will have a new entry in GRUB for the newly-compiled kernel with the patch described in this post.

The tricky part is the patch must be installed on the Acer Switch Alpha 12 when the internal SSD gets recognized. So you may have to reboot a few times until this happens.

I can try to make some screenshots and a new tutorial when I get time .. maybe over the weekend.

RobFran

Hi,

Thank you for the reply.

I'm on the verge of giving up and just run linux in vmware.

Managed to reinstall the linux distro by just reebooting in to the live media alot of times suddenly the ssd was there and i could go ahead and install. But thats it, I never get the option to boot into it after its installed despite how many times i reboot.

So have not been able to try the fix.

I turned off the secure boot option in bios.

I upgraded the bios to the latest version 1.04.

Perhaps im doing sumething wrong when im installing?.

I shrunk the windows partition to make room for linux and just use the option provided to install alongside windows. The installer should take care of everything else right?

I wonder if this problem is present in every device of this kind or only some of them. So far the only place i've read about it was here.

Also i have not tried installing a 32-bit verison of linux. Since it is address related isssue.

quadpixels

Hi RobFran,

I checked my settings again, and I realized I have had done 2 more things, so I guess you may want to try them out. Here they are:

1. In BIOS, set the following files

(HD0)\EFI\ubuntu\grubx64.efi

(HD0)\EFI\ubuntu\fwupx64.efi

(HD0)\EFI\ubuntu\shimx64.efi

as trusted for executing.

(I added all the EFI files I can find under HDD0 as trusted for executing.)

Tap this item, and repeatedly add the EFI files as trusted for execution.

2. In Windows, set the "Windows Boot Manager" to \EFI\ubuntu\grubx64.efi

To achieve this, type the following command in a command prompt with Administrator Privilege:

bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi

After you type that command and GRUB is set as the "Windows Boot Manager", this is what you should see by typing "bcdedit":

GRUB set as the "Windows Boot Manager".

================================================================================

As for BIOS Settings --- I can successfully get the system to load GRUB every time, despite having set the Boot Device to Windows Boot Manager. (Maybe because Windows Boot Manager is set to chain-load GRUB in the second picture above.)
The following are my BIOS settings:

Main
  - F12 Boot Menu: Disabled
  - Lid Open Resume: Enabled
  - GPT Partition Recovery: None

Security
  - Supervisor Password Is: Set
  - User Password Is: Clean
  - Password on Boot: Disabled
  - Secure Boot Mode: Standard
  - Change TPM State: Enabled

Boot Mode:
  - Set System Boot Mode: UEFI
  - Secure Boot: Enabled
  - Boot Priority Order:
    1. Windows Boot Manager
    2. HDD: Liteon CV1-8B256
    3. USB FDD
    4. Network Boot-IPV4
    5. USB HDD
    6. USB CDROM
    7. Network Boot-IPV6

Hope this helps!

12_SetUEFIExecutable_1.jpg

13_BCDEDIT.png

quadpixels

I just re-confirmed this by changing the Windows boot manager to

\WINDOWS\system32\winload.efi

and back to

\EFI\ubuntu\grubx64.efi

and rebooting the computer.

It seems that I can only boot into Linux when Windows Boot Manager is set to the latter (\EFI\ubuntu\grubx64.efi), no matter what my boot sequence in BIOS is.