Bug 189471
| Summary: | Acer Aspire Switch Alpha 12 (SA5-271) SSD not detected, all ATA ports are DUMMY + Dirty Fix | ||
|---|---|---|---|
| Product: | IO/Storage | Reporter: | Sui Chen (suichen6) |
| Component: | Serial ATA | Assignee: | Tejun Heo (tj) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | damianatorrpm |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 4.8 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
lspci_vvv
acer-kernel-ahci.patch patch for ahci.c using DMI Match dmidecode output proposed patch on January 24 revised patch on May 6 |
||
|
Description
Sui Chen
2016-12-02 05:59:36 UTC
Same issue here, but my laptop has kingston ssd - the issue seems to be with the controller. copr for fedora 25: https://copr.fedorainfracloud.org/coprs/damianatorrpm/acer_kernel/ To be able to boot up and the ssd to be detected you need to run a custom kernel. I have created such: https://copr.fedorainfracloud.org/coprs/damianatorrpm/acer_kernel/ and also I have created a custom Fedora .iso incorporating this kernel https://drive.google.com/drive/folders/0B_wtRVB2Z4pvWFpwVDUyTWlBcVU With that working the installation is possible but bootloader doesn't work. I have tried in UEFI/legacy mode grub (and using chroot after install trying to reinstall grub2). Tried rEFInd, systemd-boot and elilo as well). It is BIOS bug. So here the solution: How to install Fedora 25 (deletes Windows) 1) Download .iso with my custom kernel 2) Set boot mode in BIOS to legacy not UEFI 3) Make bootable usb stick from the iso you downloaded and boot from it. 4) Open Gnome disks and completely format the drive (not the partitions, with MBR!!! not GPT or it won't work) 5) Install Fedora. *Note: The custom kernel.rpm has set Epoch to 1 which means the kernel will never update back to the one from standard repo. Looks like the BIOS is messing up. I can't think of workarounds other than forcing the port map (or CAP) for the affected machines. ahci already contains a bunch of machine-specific workarounds. Can you please create a patch to match your system and apply the necessary workaround? Thanks. Created attachment 252401 [details]
acer-kernel-ahci.patch
Thanks for the patch but you can't match the CAP value and override it. If you run "dmidecode" as root, it will print out a bunch of identification information. "Product Name" in "System Information" or "Base Board Information" is usually a good field to match. This is how other system-specific workarounds are applied too. If you have trouble creating a patch, please attach the dmidecode output. I can do the patch. Thanks! Created attachment 252461 [details]
patch for ahci.c using DMI Match
Created attachment 252471 [details]
dmidecode output
Hi all, I created a patch using the DMI_MATCH routine but I'm not sure if I did it correctly so I attached the dmidecode output as well. Thanks! Sui, generally looks good to me but can you please make the following changes? * Separate out it to its own function as other workarounds do. * Other info messages aren't capitalized. Maybe drop the capitalization here too? * Please add comments explaining what's going on and link back to this bz. Once the patch is updated, can you please format the patch according to Documentation/process/submitting-patches.rst. There's a lot in there but it'd basically look like Subject: ahci: ONE LINE DESCRIPTION PATCH DESCRIPTION. Link: http://LINK_TO_THIS_BUG Signed-off-by: YOUR_NAME <YOUR_EMAIL> --- ACTUAL PATCH Thanks! Looks correct to me. If it triggers correctly on your machine, it should be fine. Created attachment 253091 [details]
proposed patch on January 24
I did the changes and formatted the patch and also added Damian as he has tested the patch. I found there some patches that are not in their individual functions (such as the ``MCP65 revision A1 and A2 can't do MSI'' one) but I still made the SA5-271 patch into its own function. Thanks! Update: There is a BIOS version update here: (https://www.acer.com/ac/en/US/content/support-product/6806?b=1 ) After flashing 1.04 the solution doesn't seem to work anymore. The system seems to hang at boot with a different reason; the ATA1 channel is up and then down again. As a result I downgraded to 1.03 . Correction: What I described in Comment #14 is a rare event, but it can happen with both BIOS versions 1.03 and 1.04. I did some more tests with version 1.04 and it seems the workaround can correctly trigger and the computer can successfully boot into the system most of the time. It seems the BIOS version is irrelevant to the occurrences of the rare event. I'll keep watching and see if there are any clues to the rare event. Sorry about the confusion ! I have yet only tested the original patch (not in own function). I am running BIOS 1.04 without any issues a week now or so. (In reply to Widen-Damian Ivanov from comment #16) > I have yet only tested the original patch (not in own function). > I am running BIOS 1.04 without any issues a week now or so. Hi, I'm back and I think I found what happened in Comment #14. It looks it's caused by n_ports being set to 1 in this line in function ahci_init_one in file ahci.c : n_ports = max(ahci_nr_ports(hpriv->cap), fls(hpriv->port_map)); In this case, only ATA1 is probed; ATA2 is not probed. Then, system failed to find the SSD on ATA1, and decides there is no SSD. It seems changing hpriv->port_map and hpriv->cap before n_ports is set, so n_ports becomes 2 or 3, can fix this issue. (The current fix sets these two values after n_ports is set.) The problem when n_ports is set to 1 may be triggered by booting into Windows, and rebooting into Linux. I'm using BIOS 1.04 . I'll test this fix for some more time to confirm it works stably. Created attachment 256241 [details]
revised patch on May 6
The SA5-271 workaround is moved before setting n_ports. This seems to make the workaround more stable in a boot that immediately follows a rebooting from Windows.
Sui Chen, can you post the patch to linux-ide@vger.kernel.org w/ proper patch description and Signed-off-by and cc me? Thanks! |