Bug 176951

Summary: boot fails unless acpi=off Acer Travelmate X-349
Product: SCSI Drivers Reporter: bernold.georg
Component: OtherAssignee: scsi_drivers-other
Status: NEEDINFO ---    
Severity: high CC: 700ghz, a.tiboni, dmitry.sysoletin, itsallenergy, kunyavskiy, lenb, martin, matteo.terruzzi, mus.svz
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 4.4 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: acpidump of 4.1.0-rc8 with acpi
Kernel Panic Arch Linux x64 kernel 4.9
dmesg with ACPI errors (kernel 4.10rc2)
Stacktrace screenshot 1
Stacktrace screenshot 2

Description bernold.georg 2016-10-07 11:29:57 UTC
Created attachment 241081 [details]
acpidump of 4.1.0-rc8 with acpi

Overview: 
Hardware is an Acer Travelmate X-349 (i5-6200U, details: http://www.acer.com/ac/de/DE/content/professional-model/NX.VDFEG.005)
installing elementary OS loki 0.4 (a Ubuntu 16 derivate) and also Ubuntu 16 fails depending on kernel version.
After anything is selected in grub, the system hangs when trying to boot
The behavior is depending on kernel version.

Steps to Reproduce: 
1) Boot Notebook

2) Press shift to enter Grub

3) Select Kernel to boot

Actual Results:
Whether or not booting works with kernel versions: 
3.19 --> Works
4.0.0 --> Works
4.0.1 --> Works
4.0.9 --> Works
4.1.0-rc6 --> Works
4.1.0-rc8 --> Works
4.1.0 --> does not work at all
4.1.10 --> does not work at all
4.3 --> does not work at all
4.4 --> does not work, unless acpi=off is set, acpi=ht fails to boot
4.8 --> does not work at all

Expected Results: 
The system shall boot with acpi activated, to assure the hardware is working properly.

Build Date & Hardware: 
Build 2016-09-15 on elementary OS 0.4

Additional Builds and Platforms:
Same for Ubuntu 16 (which elementary OS 0.4 forks from)

Additional Information:
The acpi dump is attached for booting the system with kernel 4.1.0-rc8 with acpi ENABLED

As the notebook hardware is quite similar to the Acer Swift 3 (which could get quite popular in my opinion) we could do preliminary work for users of this hardware (shipping should start soon)
Comment 1 Zhang Rui 2016-10-08 07:08:57 UTC
(In reply to bernold.georg from comment #0)
> Created attachment 241081 [details]
> acpidump of 4.1.0-rc8 with acpi
> 
> Overview: 
> Hardware is an Acer Travelmate X-349 (i5-6200U, details:
> http://www.acer.com/ac/de/DE/content/professional-model/NX.VDFEG.005)
> installing elementary OS loki 0.4 (a Ubuntu 16 derivate) and also Ubuntu 16
> fails depending on kernel version.
> After anything is selected in grub, the system hangs when trying to boot
> The behavior is depending on kernel version.
> 
> Steps to Reproduce: 
> 1) Boot Notebook
> 
> 2) Press shift to enter Grub
> 
> 3) Select Kernel to boot
> 
> Actual Results:
> Whether or not booting works with kernel versions: 
> 3.19 --> Works
> 4.0.0 --> Works
> 4.0.1 --> Works
> 4.0.9 --> Works
> 4.1.0-rc6 --> Works
> 4.1.0-rc8 --> Works
> 4.1.0 --> does not work at all

please run git bisect to find out which commit introduces the problem.
Comment 2 Len Brown 2016-10-10 23:52:19 UTC
> 4.1.0-rc8 --> Works
> 4.1.0 --> does not work at all

There are VERY few changes (26) between these two tags,
though some graphics related.
Are you sure that you are building with a compatible kernel .config?
(try taking the working one, and put in the 4.1.0 tree and run "make oldconfig")
Comment 3 bernold.georg 2016-10-12 10:47:34 UTC
(In reply to Zhang Rui from comment #1)
> (In reply to bernold.georg from comment #0)
> > Created attachment 241081 [details]
> > acpidump of 4.1.0-rc8 with acpi
> > 
> > Overview: 
> > Hardware is an Acer Travelmate X-349 (i5-6200U, details:
> > http://www.acer.com/ac/de/DE/content/professional-model/NX.VDFEG.005)
> > installing elementary OS loki 0.4 (a Ubuntu 16 derivate) and also Ubuntu 16
> > fails depending on kernel version.
> > After anything is selected in grub, the system hangs when trying to boot
> > The behavior is depending on kernel version.
> > 
> > Steps to Reproduce: 
> > 1) Boot Notebook
> > 
> > 2) Press shift to enter Grub
> > 
> > 3) Select Kernel to boot
> > 
> > Actual Results:
> > Whether or not booting works with kernel versions: 
> > 3.19 --> Works
> > 4.0.0 --> Works
> > 4.0.1 --> Works
> > 4.0.9 --> Works
> > 4.1.0-rc6 --> Works
> > 4.1.0-rc8 --> Works
> > 4.1.0 --> does not work at all
> 
> please run git bisect to find out which commit introduces the problem.

Hi!

Bisect is a great tool! Thanks a lot... 
The commit which introduces the problem is:

commit 9253e667ab50fd4611a60e1cdd6a6e05a1d91cf1
Author: Sagi Grimberg <sagig@mellanox.com>
Date:   Thu Jun 4 19:49:19 2015 +0300

    iser-target: Fix variable-length response error completion
    
    Since commit "2426bd456a6 target: Report correct response ..."
    we might get a command with data_size that does not fit to
    the number of allocated data sg elements. Given that we rely on
    cmd t_data_nents which might be different than the data_size,
    we sometimes receive local length error completion. The correct
    approach would be to take the command data_size into account when
    constructing the ib sg_list.
    
    Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Jenny Falkovich <jennyf@mellanox.com>
    Cc: stable@vger.kernel.org # 3.16+
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

Whats very interesting, which happened with none of the other "bad ones", I get an error when installing the linux-image debian package:

> Preparing to unpack
> linux-image-4.1.0-custom-step8-custom_4.1.0-custom-step8-> > >
> custom-9_amd64.deb ...
> Unpacking linux-image-4.1.0-custom-step8-custom (4.1.0-custom-step8-custom-9)
> ...
> Setting up linux-image-4.1.0-custom-step8-custom
> (4.1.0-custom-step8-custom-9) ...
> ERROR (dkms apport): kernel package linux-headers-4.1.0-custom-step8-custom
> is not supported
> Error! Bad return status for module build on kernel:
> 4.1.0-custom-step8-custom (x86_64)
> Consult /var/lib/dkms/bcmwl/6.30.223.248+bdcom/build/make.log for more
> information.
> update-initramfs: Generating /boot/initrd.img-4.1.0-custom-step8-custom
> Generating grub configuration file ...

Even though, I am able to install and try it.
make.log:
> DKMS make.log for bcmwl-6.30.223.248+bdcom for kernel
> 4.1.0-custom-step8-custom (x86_64)
> Mit Okt 12 12:34:17 CEST 2016
> make: Entering directory '/usr/src/linux-headers-4.1.0-custom-step8-custom'
> CFG80211 API is prefered for this kernel version
> Using CFG80211 API
>   LD /var/lib/dkms/bcmwl/6.30.223.248+bdcom/build/built-in.o
>   CC [M] /var/lib/dkms/bcmwl/6.30.223.248+bdcom/build/src/shared/linux_osl.o
>   CC [M] /var/lib/dkms/bcmwl/6.30.223.248+bdcom/build/src/wl/sys/wl_linux.o
>   CC [M] /var/lib/dkms/bcmwl/6.30.223.248+bdcom/build/src/wl/sys/wl_iw.o
>   CC [M] >
>   /var/lib/dkms/bcmwl/6.30.223.248+bdcom/build/src/wl/sys/wl_cfg80211_hybrid.o
>   LD [M] /var/lib/dkms/bcmwl/6.30.223.248+bdcom/build/wl.o
>   Building modules, stage 2.
> CFG80211 API is prefered for this kernel version
> Using CFG80211 API
>   MODPOST 1 modules
> FATAL: modpost: GPL-incompatible module wl.ko uses GPL-only symbol 'cpu_tss'
> scripts/Makefile.modpost:90: recipe for target '__modpost' failed
> make[1]: *** [__modpost] Error 1
> Makefile:1386: recipe for target 'modules' failed
> make: *** [modules] Error 2
> make: Leaving directory '/usr/src/linux-headers-4.1.0-custom-step8-custom'
Comment 4 bernold.georg 2016-10-12 10:49:40 UTC
(In reply to Len Brown from comment #2)
> > 4.1.0-rc8 --> Works
> > 4.1.0 --> does not work at all
> 
> There are VERY few changes (26) between these two tags,
> though some graphics related.
> Are you sure that you are building with a compatible kernel .config?
> (try taking the working one, and put in the 4.1.0 tree and run "make
> oldconfig")

What I did:
1) check out a commit
2) cp /boot/config-`uname -r` .config
3) make clean
4) make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-custom
Comment 5 bernold.georg 2016-10-16 08:32:14 UTC
Acer released a new BIOS which lets the device boot with kernel 4.4.

4 out of 5 boots are not successful though, should I create a new issue?
Comment 6 mus.svz 2016-12-02 21:11:17 UTC
I can confirm this issue on my Acer Swift 3 Model SF314-51-59RF. Arch Linux x64 with kernel 4.8.11 and 4.9.rc7 hang with a black screen on boot.

However, I can also confirm some reports from this acer thread that this seems to be a x64 specific issue:

https://community.acer.com/t5/Swift-Spin-S-and-R-Series/Ubuntu-on-Swift-3-SF314-51-74FW-black-screen-after-menu-on-Live/td-p/464481/highlight/true/page/3

I'm typing this from a perfectly fine working Fedora 25 32-Bit Live system with kernel 4.8.6. The x64 version hangs on boot just like Arch Linux.

btw, there is no BIOS update available for the Swift 3 yet (BIOS version 1.05).
Comment 7 mus.svz 2016-12-14 17:48:06 UTC
Update:

It seems like this was partly fixed by BIOS upgrade 1.07 (only available via Windows Update).

Fedora x64 and Ubuntu x64 are confirmed to boot after the BIOS upgrade (see the mentioned acer community thread).

However, Arch Linux x64 still doesn't boot and I haven't figured out the difference yet. Arch has kernel 4.8.11 while Fedora boots fine with 4.8.6 and 4.8.13, so I doubt it's the kernel version.
Comment 8 Martin Goyot 2016-12-21 09:20:30 UTC
I confirm, I have this exact same problem with TravelMate X349-M.

Fedora 25 32-Bit Live system working, but impossible to boot the x64 version, black frozen screen after boot menu.

I cannot confirm for the BIOS update because of course I don't have windows anymore so I don't know how I will install it...
Comment 9 Martin Goyot 2016-12-21 12:32:05 UTC
Can now confirm. Updated Bios, can now run the x64 version.
Comment 10 mus.svz 2016-12-22 20:30:33 UTC
Created attachment 248381 [details]
Kernel Panic Arch Linux x64 kernel 4.9

Attached is a kernel panic I get with Arch Linux x64 and kernel 4.9. Unfortunately I can't get the whole stack trace. I tried to up the resolution with the vga= parameter but then the screen stays black. I actually got it to boot once, but had no other success after 10 other tries.

The stacktrace looks very similiar to Bug 58201 (comment 20 on this bug also mentions the same problem with vga=).

Since Fedora and Ubuntu are fixed by the BIOS upgrade but Arch Linux still doesn't boot, I guess this may be related to different kernel configs? Any hints on which configs could affect this?
Comment 11 Zhang Rui 2016-12-26 01:53:46 UTC
please check if the latest upstream kernel works for you or not.
If yes, I will close this bug as the original bug has been fixed by BIOS upgrade, and the arch linux 4.9 kernel issue sounds like a Distro problem to me.
Comment 12 Zhang Rui 2016-12-26 01:54:39 UTC
(In reply to Zhang Rui from comment #11)
> please check if the latest upstream kernel works for you or not.
> If yes, I will close this bug as the original bug has been fixed by BIOS
> upgrade, and the arch linux 4.9 kernel issue sounds like a Distro problem to
> me.
If no, please also check upstream 4.8 kernel to see if this is a upstream kernel regression and use git bisect to find out the offending commit.
Comment 13 matteo.terruzzi 2016-12-30 15:32:55 UTC
I'm reporting the same problem with Acer Travelmate X349-M, BIOS v1.07, 64bit in all tests.

Also, I can get to the login prompt of gdm with everything working good (including battery status, touchpad, wifi, special keys...) using Arch Linux with replaced Kernel 4.10r1 from Ubuntu distribution and `acpi=force acpi_osi='!Windows 2012'`,
but (unless acpi=off) it freezes on black screen just after successfull login (the same with GNOME, GNOME Classic, GNOME Xorg).

Tried Kernel 4.0.9 from Ubuntu with acpi on, and it worked good for 10 minutes on GNOME, but then stopped and didn't work at all for the following tries.
Tried Kernel 4.4.0: acpi=off, login ok; acpi on, crash with stack traces at boot, behavior similar to 4.0.9.
Also note that Ubuntu 16.10 Live official image (linux-image-4.8.0-22-generic) works perfectly.
Comment 14 matteo.terruzzi 2016-12-31 04:27:21 UTC
I now report complete functionality and stability with kernel linux-grsec 4.8.15.r201612151923-1 from Arch Linux community repository.
	
Also, in order to fix a different problem, I have always put in mkinitcpio.conf the following: MODULES="crc32_generic crc32-pclmul libcrc32c crc32c_generic crc32c-intel"
Comment 15 mus.svz 2016-12-31 11:59:27 UTC
I just made an actual Arch Linux Installation instead of just trying to boot the USB device - and on the installation everything works fine, including the standard kernel (4.8.3 and 4.9.0) without any acpi parameters.

The kernel on my USB image and the installed kernel (both 4.8.3) even have the same md5sum, but the USB one doesn't boot while the installed system works fine. They also have the same bootloader (systemd-boot).

So for some reason this problem only happens on Arch Linux kernels and only when booted via USB...!?

I'm gonna try the latest upstream kernel and bisect it...
Comment 16 mus.svz 2017-01-05 19:37:55 UTC
Created attachment 250411 [details]
dmesg with ACPI errors (kernel 4.10rc2)

Bisecting this is really frustrating because it randomly works in different combinations, depending on whether UEFI or Legacy boot is enabled in BIOS and whether you boot via USB or SSD and sometimes pure chance...

The good(?) news is: kernel 4.10rc2 boots in almost all circumstances. But the only combination that is actually stable is the same one that already works with 4.8 and 4.9: booting with legacy mode enabled from the internal SSD.

When I boot 4.10rc2 with UEFI mode enabled in BIOS or via USB, the system doesn't hang like with previous kernels. Instead I get quite a few ACPI errors and the system manages to boot completely most of the time, but freezes completely after a few seconds.

The full dmesg is attached. This is with UEFI mode enabled in BIOS and booting 4.10rc2 from the internal SSD. Hopefully the ACPI warnings and errors help narrow this down...
Comment 17 Dmitry Sysoletin 2017-01-26 08:07:57 UTC
Created attachment 253181 [details]
Stacktrace screenshot 1

Screenshot of hung kernel 4.10.0-rc5
Comment 18 Dmitry Sysoletin 2017-01-26 08:08:44 UTC
Created attachment 253191 [details]
Stacktrace screenshot 2

Another 4.10.0-rc5 fail
Comment 19 Dmitry Sysoletin 2017-01-26 08:15:21 UTC
(In reply to Zhang Rui from comment #11)
> please check if the latest upstream kernel works for you or not.
> If yes, I will close this bug as the original bug has been fixed by BIOS
> upgrade, and the arch linux 4.9 kernel issue sounds like a Distro problem to
> me.

I'am checked 4.10.0-rc5, and have about one successful reboot for 10 reboot attempts. I have 2 different types of fail - most often it happens about at 0.5 second uptime, but I catched another failure on ~24 second (screenshots attached).
System is 64-bit, booting with legacy mode, BIOS updated to 1.07 (it seems like switching legacy <-> UEFI don't make sense). Sometimes I able to boot, if I press F2 at power-up moment, enter EFI-shell, press ctrl+alt+del - seems like this increasing boot chances.
I tried with acpi=ht also, but this don't changes behaviour.


I'am able to boot ubuntu with 4.2 kernel from liveusb - and I see messages that some people able to run other distros. That distros use vanilla kernel, or have some patches? I guess ubuntu not using vanilla kernel - there must be some patches fixing/masking this issue.
Comment 20 Martin Goyot 2017-01-29 16:19:12 UTC
A new Bios update is available on Acer's website: https://www.acer.com/ac/en/GB/content/support-product/6917?b=1

v1.08 apparently. If anyone has tried it, does it solve the remaining problems?
Comment 21 Dmitry Sysoletin 2017-01-30 13:25:17 UTC
(In reply to Martin Goyot from comment #20)
> A new Bios update is available on Acer's website:
> https://www.acer.com/ac/en/GB/content/support-product/6917?b=1
> 
> v1.08 apparently. If anyone has tried it, does it solve the remaining
> problems?

I tried it - and it not helps. Still have crashes at boot.
Comment 22 Alan Welsh 2017-03-22 15:37:34 UTC
I can confirm the system does not boot unless either: a) passed with the acpi=off parameter in legacy mode or, b) booted in UEFI mode.

As for (a): This issue is resolved with grsecurity kernel.

As for (b): UEFI cannot be used because all linux bootloaders fail to be recognized by the firmware. There is not one distribution which boots after installation. The bootloader never loads. Only receive error message "disk not found" or something to that effect.

Acer swift 3 (bios 1.08)

All x64 flavors from: Ubuntu, Fedora, Gentoo, Arch, opensuse.
Comment 23 Max 2017-05-03 05:59:26 UTC
I can confirm the bug on my Acer Swift 3 Model SF314-51 (bios 1.08).
I able to install just Mint 18.1. I found that it freezes when:
1. ~4 times of 5 when my machine start ups (boot logo/black screen); 
2. usually when chrome starts; 
3. when brightness changes very fast; 
4. when shut down.
Comment 24 Alberto Tiboni 2017-05-04 11:07:42 UTC
I can confirm issue is still here: update bios at 1.08, nothing changed!

Tried Ubuntu and Lubuntu distro, 16.04, 16.10 and 17.04, both 64 and 32bits.

The only one that booted after installation was Lubuntu 16.04 32bit in legacy mode, with grub without "quite splash" parameters.

but it works rarely: 9 on 10 times it produces a kernel panic on apci init.

Now I'm trying linux Mint, but i'm quite sure problem will be there too.
Comment 25 Alberto Tiboni 2017-05-07 10:19:57 UTC
(In reply to Alberto Tiboni from comment #24)
> I can confirm issue is still here: update bios at 1.08, nothing changed!
> 
> Tried Ubuntu and Lubuntu distro, 16.04, 16.10 and 17.04, both 64 and 32bits.
> 
> The only one that booted after installation was Lubuntu 16.04 32bit in
> legacy mode, with grub without "quite splash" parameters.
> 
> but it works rarely: 9 on 10 times it produces a kernel panic on apci init.
> 
> Now I'm trying linux Mint, but i'm quite sure problem will be there too.



Hi there, found this https://www.reddit.com/r/linuxmint/comments/5lu69k/installing_linux_mint_181_on_an_acer_swift_3/

don't know if can help, but at second install attempt the system is stable with kernel 4.4.0-53-generic
Comment 26 Alan Welsh 2017-06-18 10:20:20 UTC
[Arch system, Legacy mode, 64 bit]

Can now boot with the "mainline" kernel [4.12.0-rc5-mainline] as well as the "hardened" kernel [4.11.6.a-1]. The latter is purposed as a replacement for the grsecurity kernel.

Does this mean we can expect a working kernel for our machines from the various distributions in the near future?
Comment 27 mus.svz 2017-06-19 19:13:59 UTC
Can confirm, this seems to be fixed in 4.12-rc5 mainline (Arch Linux x64). Machine boots and works fine now, even in UEFI mode.