search

GalliumOS / galliumos-distro

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

Caroline: After suspend/resume, no touchscreen, kernel spew re: i2c_designware/atmel_mxt_ts #511

Open bcarnes opened 5 years ago

bcarnes commented 5 years ago

Caroline/UEFI Running 3.0beta2

After suspend/resume, usually lose touchscreen, and get infinite spew in dmesg of:

[41763.241110] Disabling non-boot CPUs ...
[41763.251161] WARNING: CPU: 1 PID: 7225 at kernel/kthread.c:486 kthread_park+0x5a/0x70
...
[41763.298281] ACPI: Waking up from system sleep state S3
[41764.367592] i2c_designware i2c_designware.0: controller timed out
[41764.405234] i2c_designware i2c_designware.0: timeout in disabling adapter
[41764.405259] atmel_mxt_ts i2c-ATML0001:00: __mxt_read_reg: i2c transfer failed (-110)
[41764.405263] atmel_mxt_ts i2c-ATML0001:00: Failed to read T44 and T5 (-110)
[41764.431094] i2c_designware i2c_designware.0: timeout waiting for bus ready

@reynhout - you mentioned in https://github.com/GalliumOS/galliumos-skylake/pull/2#issuecomment-502812238 that "Shutdown and suspend have been consistently good for several kernel builds on CAROLINE".

I find the above reproduces very reliably. Can you try suspending/resuming your caroline a few times, and then confirm your touchscreen still works? The whole machine will be a bit slower during all the i2c timeouts and kernel logging infinite spew.

As mentioned in #274, the quickest workaround is just "echo s2idle > /sys/power/mem_sleep", but I've been running with a nicer one with a /lib/systemd/system-sleep/atmel_mxt_ts pre/post trigger that preserves S3 deep sleep.

Wanted to make sure you could reproduce the badness before I push a fix for it...

reynhout commented 5 years ago

@bcarnes I can't repro this issue on CAROLINE/UEFI/3.0final.

In 20 suspend/resume cycles, I did get one instance of the kernel/kthread.c:486 warning you pasted above. Touchscreen remained solid throughout. I am triggering Suspend via the power menu, not by waiting for an idle timer. I wouldn't expect that to matter, but you never know..!

Anyway, I'll merge your PR and publish a pkg to the testing repo. Not sure why our CAROLINEs are different, but I'm sure others have the same issues you're seeing. Thanks for putting this together!

bcarnes commented 5 years ago

@reynhout Try doing a handful of suspend/resumes by just closing the laptop lid, then reopening it. Disable this fix, and see if the above causes you to see the i2c errors and touchscreen breakage more reliably.

reynhout commented 5 years ago

@bcarnes Same results for suspend-via-lid-closure:

This is on a completely fresh and default install of 3.0final, only modifications to the system are pkg updates (testing repodist enabled).

bcarnes commented 5 years ago

@reynhout We've noticed a few differences between our carolines so far. Which UEFI bios version are you on? (check via "sudo dmidecode")

Can you update yours to the latest MrChromebox firmware. After doing so, you should see (from dmidecode):

    Vendor: coreboot
    Version: MrChromebox-4.9
    Release Date: 01/04/2019

That might resolve some of these differences in behavior. Curious if it'll make your touchscreen across suspend/resume misbehave in the same way, and if it might also fix your caroline's audio looking for a different firmware:

On mine I see.

$ sudo hexdump -C /sys/firmware/acpi/tables/NHLT | head -2 00000000 4e 48 4c 54 4c 1a 00 00 05 0d 43 4f 52 45 76 34 |NHLTL.....COREv4| 00000010 43 4f 52 45 42 4f 4f 54 00 00 00 00 43 4f 52 45 |COREBOOT....CORE|

Note the "COREv4". Which is where the "9d70-COREv4-COREBOOT-0-tplg.bin" comes from.

On yours, you needed "9d70-CORE-COREBOOT-0-tplg.bin". Perhaps when you update, that'll get normalized also?