Acer Spin 13 can't sleep/hibernate on Linux

[ciriousjoker]

When attempting to do it anyway, the system either shuts down (when on battery) or the fans start spinning at 100% until you resume.

Some folks have said it's a tpm issue, bug apparently, TPM is disabled in the bios already.

Here's a post I wrote about this in the arch forums. There are no replies, but I've uploaded some logs there if you're interested: https://bbs.archlinux.org/viewtopic.php?id=250514

[MrChromebox]

what firmware type / version are you running?

[ciriousjoker]

I'm running on 4.10 remix. The issue happens on UEFI as well as on legacy bios. On legacy bios, the boot flags or smth like that are also reset. This means that after the system is shut down like this (not via normal shut down), the white dev screen comes and when I try to boot from USB, it beeps and that's it. I can only boot Chrome OS at that point. If I recall correctly, before that, the "chrome is is dead" boot screen appears but after a restart it's like I described.

[MrChromebox]

suspend/resume issues on the legacy BIOS are a product of Google's use of the TPM in their verified boot -- there's nothing I can do about that, it's an issue with the stock firmware.

with the UEFI firmware, I'd need to see the output of the EC serial console to see what's going on. Also highly recommended to update to the 4.11 release to avoid NVRAM issues

[ciriousjoker]

Is there anything I can do to provide you with that output?

[MrChromebox]

if you have a USB-C debug cable, log the EC console starting just prior to suspend, let it sit 30s or so, then wake up. That would help me see what's going on with the EC that the fan state isn't getting set properly.

[ciriousjoker]

Currently, I don't have one, but I found this thing on eBay: https://www.ebay.it/ulk/itm/122662276987

Would this work?

[ciriousjoker]

Nevermind, this probably won't work, since the Chromium website says that to access CCD, you need a SuzyQ cable which I obviously don't own and also can't purchase since it's out of stock and relatively expensive for a one time use with uncertain outcome. :(

[MrChromebox]

Sparkfun shows backordered with 12/9 ETA: https://www.sparkfun.com/products/14746

[ciriousjoker]

Hmm, maybe I'll do it. If I get one, how would I read the EC console? I can use Windows or Arch Linux. I won't need any extra devices right?

[MrChromebox]

minicom under Linux is all you'd need. I believe the EC console is readable by default, so you'd just need to connect the cable (correct port, orientation) start minicom on the proper port (-D /dev/ttyUSB2), and start logging

edit: fixed EC ttyUSB port. 0 is CCD, 1 is AP/CPU, 2 is EC

[empathicqubit]

@CiriousJoker Were you able to make any progress on this? I'm running into this issue as well, and I was already considering the SuzyQ in case the flash broke. I ended up just partially unlocking the CCD and crossing my fingers really hard, but I'd still buy it if it meant finding a resolution.

[ciriousjoker]

No, I was and am super busy with other stuff, sorry :/

[empathicqubit]

I have the SuzyQable, if someone could walk me through what to do.

Edit: I'm lazy and didn't read the thread. I'll message again if I have any problems interpreting MrChromebox' original instructions.

[empathicqubit]

Relevant question regarding the TPM. If I flash my EFI will I lose my keys? The reason I'm asking is because I'm going to make a full image backup, but if I lose the system key then that will make that useless since the cryptohome won't decrypt without it. I created individual backups of Android and Crostini which should cover my bases anyway, but I'd rather not deal with those because I'll still need to reconfigure some stuff again if I have to use them.

[MrChromebox]

you'll lose the keys if you open the CCD as part of disabling the firmware write protect, since that will transition you out of Developer Mode and will wipe the TPM.

[empathicqubit]

Thanks, I just discovered that :/

IRT the fan state, I was seeing some messages repeating over and over, "Fan 0 stalled", when suspending with ChromeOS at the first time setup screen. I haven't been able to get them to come up again since setting up the system and unlocking the CCD again.

I've attached the suspend logs from ChromeOS with the default firmware, for both CCD and EC ports. I'll do the same for Linux once I go through reflashing.

sleep_chromeos_0.bin.gz

sleep_chromeos.bin.gz

[empathicqubit]

Was there a specific kernel I should be using? I'm using Xubuntu 19.10 with 5.3.0-46-generic.

[empathicqubit]

Linux EC and CCD logs. The suspend was executed with systemctl suspend because it wasn't clear to me if the lid switch was actually doing the correct thing.

sleep_linux_ec.bin.gz sleep_linux_ccd.bin.gz

[empathicqubit]

Would you be able to walk me through how you would use this information to debug the issue? I'm fairly technical and I want to help you. Also I would like to put CrOS back on my machine soon, but I've been putting it off in case you needed me to do something else.

[ciriousjoker]

@MrChromebox I'm also still interested in this, in case there's a fix, I'll try it out immediately

[MrChromebox]

having looked at the logs, it's not providing me with any info as to why sleep would be failing, or why the fan wouldn't be resuming coming out of suspend. And I'm not seeing this problem on other (non-ChromeOS) KBL-U boards here

[empathicqubit]

@MrChromebox Is it possible to do gdb debugging over the Cr50? Would that give you any useful information?

[MrChromebox]

@empathicqubit I'm not sure, but I don't think so. one can query the fan state from the EC console though, so one could check the fan mode, RPM, duty cycle, etc before and after suspend

[empathicqubit]

I don't think it's actually suspending so I'm not sure how useful that is, but I'll take a look. I also ran through all the commands in the EC and AP and got an output for that session. I'm not sure if that's useful.

diag.bin.gz diag2.bin.gz

Edit: There is a 32K memory dump in there. Given that it's so short I assume that's just a memory dump of the EC or the AP. I dunno.

Irrelevant to anything but I think it's funny that the stack has "deadd00d" in it when the system crashes.

Output with hcdebug every. I'm not sure it's actually anything different. It says the fan is "frustrated"

Actual:    0 rpm                                                                                                        Target: 2982 rpm                                                                                                        Duty:   100%                                                                                                            Status: 3 (frustrated)                                                                                                  Mode:   rpm                                                                                                             Auto:   yes                                                                                                             Enable: yes                                                                                                             >

hcenabled0.bin.gz hcenabled2.bin.gz

[empathicqubit]

Should the UART console be enabled and reporting over ttyUSB1, or am I getting that mixed up? Would that be useful?

[MrChromebox]

the CPU UART (ttyUSB1) might show the coreboot log on resume, assuming it actually suspends and then tries to resume. Otherwise it's not going to show anything useful

[empathicqubit]

I built coreboot myself and was able to enable a bunch of messages on the UART console as well as GDB. I was able to load the symbols and step through a bit. Probably useless though as it won't help determine what the correct suspend procedure is. I was thinking about trying to enable DCI in the ChromeOS IFD so that I could trace that instead and get more insight on what it's doing during suspend, but I'm not sure if that's even possible. I'm probably overcomplicating things.

What about the UART console for the ChromeOS kernel? There's a blank console option for it but I'm not sure if setting it will even do anything because documentation seems to imply that support needs to be compiled in and usually isn't.

Sorry for all the nonsense. I have no idea what I'm doing.

[MrChromebox]

Probably useless though as it won't help determine what the correct suspend procedure is

every other SKL/KBL coreboot device I have access to suspends/resumes correctly, I'd find it very surprising if one board is having an issue, vs a kernel or driver issue

[empathicqubit]

Should I close this bug and go complain to kernel devs? I want to help solve it I just need some direction.

[MrChromebox]

I'd say leave it open in case, but definitely pursue the other route as well. I'll see if I can get another NAMI-based board for testing

[empathicqubit]

Okay. I'll message them soon but I'm going to try experimenting a bit more before bothering them + double-checking to make sure it isn't already fixed in mainline. Does your build contain the blobs for the audio? When I tried building with that option myself it failed because it wasn't in the standard blobs repo. If you're not including that, could it cause it to behave weirdly on suspend?

[MrChromebox]

Does your build contain the blobs for the audio?

of course :)

When I tried building with that option myself it failed because it wasn't in the standard blobs repo

you extract them from the stock firmware image using cbfstool

[empathicqubit]

Hmm

TPM Interface Specification 1.3 Interface / TPM 2.0 FIFO Interface - (SPI) (TCG_TIS_SPI) [M/n/y/?] m
    Cr50 SPI Interface (TCG_TIS_SPI_CR50) [N/y/?] (NEW) ?

CONFIG_TCG_TIS_SPI_CR50:

If you have a H1 secure module running Cr50 firmware on SPI bus,
say Yes and it will be accessible from within Linux.

Symbol: TCG_TIS_SPI_CR50 [=n]
Type  : bool
Defined at drivers/char/tpm/Kconfig:70
  Prompt: Cr50 SPI Interface
  Depends on: TCG_TPM [=y] && TCG_TIS_SPI [=m]
  Location:
    -> Device Drivers
      -> Character devices
        -> TPM Hardware Support (TCG_TPM [=y])
          -> TPM Interface Specification 1.3 Interface / TPM 2.0 FIFO Interface - (SPI) (TCG_TIS_SPI [=m])

    Cr50 SPI Interface (TCG_TIS_SPI_CR50) [N/y/?] (NEW) 

[MrChromebox]

that's not affecting suspend on my UEFI firmware, but might help with suspend/resume on the stock firmware

[empathicqubit]

The good news is that mainline doesn't have the fan issue. The bad news is that suspend freezes the computer. Power button, lid, keyboard won't wake it. It's possible I got something wrong with make oldconfig so I'll try working through it again, or maybe trying stable instead.

[empathicqubit]

Why is it so hard for manufacturers to do this in a standard way? With nearly every Linux laptop I've had this has been a issue at some point.

Edit: I tried with Ubuntu's prebuilt mainline kernel and same issue. The graphics are also really slow on my desktop.

[empathicqubit]

Bug filed at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1882543 . Apologies for the delay. Was trying to figure out the best place to do it. Linux kernel support documentation is not very clear, and Ubuntu already has the data collector so I just decided to use that since it seemed easier. They will probably kick it upstream but I figured it was best for me not to bother them directly.

[empathicqubit]

Please subscribe to the bug to bump up the score also.

[ciriousjoker]

@empathicqubit Can you update the launchpad issue? They asked for the journalctl -b -1 -k log and since you're the bug creator I doubt they'll accept mine

[empathicqubit]

I'll try. I saw it but I got back to needing the machine again. Thankfully I didn't have to powerwash the last time I switched the firmware back so I'll try it again soon.

[krrrak]

same problem in coreboot4.19

[MrChromebox]

nobody has provided any info which leads me to believe there is a firmware issue