ACPI ECDT bug

I’m not sure where the best place is to report this, but the ECDT ACPI table on the Framework (at least the i5 model) points to an invalid device in the DSDT:

[03Ch 0060   4]                          UID : 00000001
[040h 0064   1]                   GPE Number : 6E
[041h 0065  20]                     Namepath : "\_SB.PC00.LPCB.H_EC"

That should probably point to \_SB.PC00.LPCB.EC0 which is the actual PNP0C09 device.

3 Likes

Thanks for reporting this. This is the best place to report it. CC @Kieran_Levin

Hi jcs, just curious, what drove you diving into the table? (macOS?)

Hi, while fixing some things in OpenBSD to make it work better on the Framework Laptop, I was debugging why closing the lid didn’t cause the system to suspend, despite there being a PNP0C0D device in the DSDT and the acpibtn driver attaching to it. It ended up being the ECDT pointing at a bogus device which is preventing the acpiec driver from properly attaching to the PNP0C09 device (EC0) where all of the notifications are defined, so notifications are generated when the lid is closed but they don’t reach the acpiec driver for processing into an actual S3 suspend request.

4 Likes

I first got exposure to BSD (FreeBSD) about 25 years ago. Would love to give OpenBSD a try when my laptop arrives. Your writeup looks awesome!

Really glad we have someone like you in the community!

1 Like

@jcs we will fix this in bios 3.04.

4 Likes

Is there a publicly available bug / issue tracker for BIOS and drivers so people can know what’s coming down the pipeline and have awareness of known issues?

4 Likes

Great support, thanks @Kieran_Levin! Any rough idea when the next BIOS upgrade might appear? Thx

We are preparing 3.03 now for beta testing and then release. 3.04 would be the follow-on, and there are a few items pending completion before we can start a release schedule for it.