GalliumOS / galliumos-distro

Docs, issues, and artwork sources for GalliumOS
https://galliumos.org/
GNU General Public License v2.0
348 stars 11 forks source link

Suspend fails on Gallium 3.0 beta (Acer C720) #512

Open keithfarvis opened 5 years ago

keithfarvis commented 5 years ago

Acer C720 i3 4GB, PEPPY (Gallium 3.0 Beta, stock, RW_LEGACY, chrx, dual boot)

As of 4.16.18-galliumos update from 23rd June 2019 suspend is now failing every time, with the result that OS is unusable when resuming and have to press-hold the power key to shut down. I had the this problem very occasionally before this update but it is consistent now.

dmesg is here https://paste.ubuntu.com/p/42w8PQ89vH/ - suspend starts at 148.898678

reynhout commented 5 years ago

@keithfarvis I am not able to reproduce this error. Are you able to suspend when booted in the live ISO image? Anything unusual about your environment?

My test: fresh install via chrx on PEPPY (using -r dev), MrChromebox RW_LEGACY firmware, packages fully updated.

Another reasonable test would be to boot from the Haswell ISO (currently 3.0rc1) in https://galliumos.org/releases/nightly

keithfarvis commented 5 years ago

Using the PEPPY (using -r), MrChromebox RW_LEGACY firmware.

Using the nightly galliumos-haswell-bismuth-3.0rc1-20190623T052042Z.iso in Live mode, I get the same warning: with stack backtrace on first lid closure but not on subsequent lid closures. This does not appear to cause any subsequent running issues. See https://paste.ubuntu.com/p/gXSMKtDyNc/ First lid closure at 113.443104 with warning a backtrace Second lid closure at 253.089962 goes OK, without warning Third lid closure at 395.400090 also goes OK

This was using WiFi, but I normally use a wired connection so, back to my normal setup. If I start off with WiFi then add a wired connection and then disable the WiFi all works fine - see []https://paste.ubuntu.com/p/vH4NS6vDNC/(https://paste.ubuntu.com/p/vH4NS6vDNC/) But if I just start off with only a Wired connection I get the problem - see https://paste.ubuntu.com/p/JMmZNn6BjZ/

Any ideas? Thanks

keithfarvis commented 5 years ago

A bit more information. I wondered whether my USB Ethernet dongle was faulty but I have a second one and they both behave the same. The device is an ASIX AX88x72A and it fails on first resume from a lid closure - no network and the system locks up after a while. This is the dmesg after the failed resumption - https://paste.ubuntu.com/p/NzbSsrtBxw/

However I also have an ASIX AX88179 USB Ethernet dongle with an integral USB hub - and this works.
This is the dmesg after the first successful resumption - https://paste.ubuntu.com/p/jfVPZ2D9sy/ Subsequent lid closures are also successful.

So it looks like driver 'asix' fails whereas 'ax88179_178a' succeeds. And this failing behaviour started from 23rd June 2019 update

keithfarvis commented 5 years ago

I noticed a couple of asix driver patches to do with suspend and resume failures from 2016, https://lore.kernel.org/patchwork/patch/740070/ https://lore.kernel.org/patchwork/patch/700819/