Beelink CS-Bettie Thanks again for passing on the details. The networking issue after recovery from (failed) suspends is quite serious. I hope a fix will also address the failing suspend itself. They may or may not be related.
Power button issue
Looking just now into the well known power button issue with Linux on the SER9. I haven’t found a fix yet, but the problem seems to lie between the DSDT and the kernel’s interpretation of it. Rationale: on a working AMD system (a Framework 16 laptop), I see the buttons detected early on during boot, and the power button, PNP0C0C, has been associated with the correct driver (button):
# working framework laptop, dmesg output
[ 1.094309] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/PNP0C09:00/PNP0C0D:00/input/input0
[ 1.094346] ACPI: button: Lid Switch [LID0]
[ 1.094393] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
[ 1.094417] ACPI: button: Power Button [PWRB]
root@framework16:~# cat '/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/uevent'
DRIVER=button
MODALIAS=acpi:PNP0C0C:
but no detection of any PNP0 devices during early boot, and no driver association.
root@ser9:~# cat '/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/uevent'
MODALIAS=
I have tried combinations of kernel parameters like acpi_osi=! acpi_osi='Windows 2022' (docs) at boot, but I haven’t been able to find any “magic” values that make the power button work. Correct behaviour does not seem to be dependent on the value the OS reports to the ACPI firmware, at least: folks watching this could try other values for acpi_os_name or acpi_osi, but I suspect you;d be wasting your time for this hardware (looking at the DSDT).
What is really weird is that the decompiled .dsl output from
cat /sys/firmware/acpi/tables/DSDT > dsdt.dat # binary, direct from firmware
iasl -d dsdt.dat # in acpica-tools on Debian
less dsdt.dsl # written by above, text file
does contain an entry for PNP0C0C, but it’s different from (and more complex than) the working one from the framework 16:
## Framework 16 (simpler, power button detected by kernel)
Scope _SB
{
/* .... */
Device (PWRB)
{
Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
## Bee-link SER9 (more complex, power button not detected by kernel)
Scope (_SB)
{
/*...*/
Device (PWRB)
{
Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID: Hardware ID
Name (_DDN, "Power button") // _DDN: DOS Device Name
Method (_STA, 0, NotSerialized) // _STA: Status
{
Name (PSTA, Zero)
M460 ("PLA-ASL-\\_SB.PWRB._STA = 0xB\n", Zero, Zero, Zero, Zero, Zero, Zero)
If ((CMBS == Zero))
{
PSTA = 0x0B
}
Return (PSTA) /* \_SB_.PWRB._STA.PSTA */
}
}
Unfortunately, Debian have made it difficult to override the DSDT (but maybe this still works?), and recompilation gives a lot of errors that I have no idea how to fix because this stuff is new to me. I’ll back off from messing with that right now, at my level of expertise! Anyone with an affected SER9 have any ideas in this area?
(The ideal fix is for R&D to have a good hard look at the DSDT again (pretty please!))
