[StarLite Mk IV] [Coreboot] Shutdown hangs the machine

[ezaquarii]

Coreboot 8.24.

Trying to shutdown the machine from Open/Free/NetBSD using halt -p hangs it. Shutting it down from coreboot shell (no OS) using reset command hangs it. Shutting down from OpenBSD bootloader using machine poweroff hangs it.

Shutting down from Linux works, suggesting that it must be related to some early hardware setup.

[Sean-StarLabs]

We can't get involved with bsd but reset -s from the EFI shell should shut it down. Assuming that's what you meant, what EC version are you using?

[ezaquarii]

In EFI shell reset -s shuts down the system, but blue LEDs are illuminated and laptop drains battery. I can shut it down by pressing power-off button again.

[ezaquarii]

@Sean-StarLabs

# cat /sys/class/dmi/id/ec_firmware_release
1.4

[ezaquarii]

@Sean-StarLabs I found something interesting. When booting Linux and doing halt -p, the system shuts down correctly and the bug goes away. I can properly shut it down:

1. EFI shell reset -s
2. OpenBSD bootloader machine poweroff
3. OpenBSD halt -p

UNTIL I power-off the machine during boot.

The bug is triggered with the following procedure:

1. power cycle system
2. when coreboot prompt is shown (or GRUB, EFI shell), press power off button; the system should poweroff immediately after touching the button (no 10s long-press here)
3. power on again and enter EFI shell
4. reset -s leaves system with blue LEDs illuminated, machine poweroff and halt -p no longer work
5. boot Linux and run halt -p to fix the problem

It looks like powering off the system from EFI leaves firmware in some weird state and the state is persisted between power cycles.

[Sean-StarLabs]

8.37 in testing __might help - we're quite limited on XHCI control in coreboot

[ezaquarii]

@Sean-StarLabs 8.37 did not solve the problem. I observed another thing:

1. boot linux and halt -p
2. boot efi shell and reset -s to shutdown (works)
3. boot openbsd and halt -p (works)
4. boot openbsd and leave the system online for some time
5. halt -p will hang the machine (as well as reset -s in EFI).

Whatever Linux boot process does to the power management, I suspect firmware goes hairy in the background after some time.

[Sean-StarLabs]

Have you tried using shutdown? I wonder if halt doesn't let coreboot know it's going down, so it doesn't reset XHCI

[ezaquarii]

I tested both halt and shutdown on OpenBSD and both result in hang. I'll ask on the mailing list to see if there is a way to disable xhci via software.

I could also test if xhci can be disabled in firmware. Is it possible?

[Sean-StarLabs]

I doubt there is; and there isn't one in the firmware.

If you're asking the mailing list; it needs to be requesting S5, if it isn't, it wont do the reset and then in turn, hang.

[ezaquarii]

This problem happens in EFI firmware as well, when issuing reset -s. Does it perform shutdown via S5?

[Sean-StarLabs]

I can't replicate that; can you make it happen without BSD in the equation?

Does it perform shutdown via S5?

Not sure what you mean?

[ezaquarii]

Yes, when I boot into EFI shell reset -s hangs it.

But as I mentioned in the original report, if you run Linux first and shut down machine from there, it "fixes" it somehow for a while.

I can take a look later if it's possible to trigger that from EFI. I think i did that by doing some hard reset during boot, but need to sit down at home and fiddle with it to give you a detailed procedure.

In the meantime, I propose that you download OpenBSD install img, write it to USB stick. When it boots, it prompts user to run shell or installer. Just choose shell and do halt -p. It should trigger the failure.

When you power it off, try EFI shell reset -s. It should fail as well.

Booting Linux should fix it.

[Sean-StarLabs]

Sorry dude, we don't have the time to try to support BSD as the demand for it is almost non-existent.

Any bug with that out of the equation, I'm more than happy to help

[ezaquarii]

Here is how to trigger the condition:

1. run linux (tested with Ubuntu 22.04 installer)
2. shutdown as ususal (Gnome menu, Power off)
3. boot into EFI shell
4. reset -s powers off the machine
5. boot into EFI shell again
6. press power button to force poweroff
7. boot into EFI shell again
8. reset -s hangs the machine from now on
9. boot linux
10. shutdown with halt -p to "fix" the problem

[ak-coram]

I have the same problem on Linux 6.3.8: shutdown doesn't turn the machine off completely and I have to hold the power button to do so. I have been encountering this issue since I've updated to the 8.50 BIOS.

[Sean-StarLabs]

@ak-coram It's different, but now fixed in 8.51 - that's going up to the LVFS now so should be available in about 24 hours

[ak-coram]

@Sean-StarLabs: thanks for the letting me know, does this also fix the issue where it sometimes doesn't come back from sleep (screen doesn't turn on)?

[Sean-StarLabs]

Not aware of such an issue - was that only introduced in 8.50?

[ak-coram]

@Sean-StarLabs: I've had it since 8.37, it occurs pretty frequently (about 1 in 3 times) when waking from sleep.

[ak-coram]

It might be also something from an earlier release, since I've skipped a bunch of updates before 8.37.

[Sean-StarLabs]

There were a few bugs in 8.37, so maybe. If not, please open a issue

[ak-coram]

@Sean-StarLabs: okay, thanks!

[Sean-StarLabs]

Can't change this one; coreboot can only enumerate things as PCI devices, which the PMC isn't. Changing that would involving changing how coreboot works.

AMI won't have this issue though

[ezaquarii]

@Sean-StarLabs can you explain what the issue is? it's marked as completed but explaination suggests wontfix?

[Sean-StarLabs]

Long story short, the Power Management Controller isn't accessible, which is needed to turn off the USB controller. coreboot can only handle PCI devices but the PMC on GLK isn't one. It was disabled years ago (https://review.coreboot.org/c/coreboot/+/15530) to get the GPIO controllers working.

So yes, it's a "wontfix", as it would involve rewriting coreboot.