ACPI CSRT table updates not being reflected on resume from hibernate in OS component .

Hello,

I have some data that gets patched onto CSRT table on Boot , this data is then supposed to be read by a user mode component in OS . The data can also be modified on hibernate cycles.

I am seeing an issue where in the data is getting patched correctly and being read correctly on boot but if in the same cycle i do a hibernate and resume , we still read older data .
Using the following function to get handle to CSRT table GetSystemFirmwareTable .
The data being patched to the CSRT is dynamic and can change between hibernate resume cycles .
My observation is that if on first boot the data is 1 , and then we do hibernate resume cycle and data patched in CSRT is updated to 0 , on resume the user mode component again calls GetSystemFirmwareTable () to get handle to CSRT and reads data but i’m seeing this being read a 1 still (the update on resume is not reflected) .

Does CSRT table only get read once during boot by ACPI driver and any update to the table on hibernate-resume will not take effect ?

I’m sorry to say your question confuses me. You don’t say WHERE/HOW/WHEN you patch the CSRT. But, I’m guessing that your basic issue is that you want your table changes to be effective when the system resumes from Hibernate

If you could be bit more specific about how, when, and where you’re making the changes… that would definitely help. I’m guessing that your dynamically changing the CSRT from some other BIOS routine, and you’re not seeing that change when returning from S4, because you expect the CSRT to be re-read during S4-S0 and it’s not. But that’s a guess…

Does CSRT table only get read once during boot by ACPI driver

I would assume that it only gets read once. I’ve always assumed all the ACPI tables get read only once. There would ordinarily be no need to re-read them, because they wouldn’t change (you know, if something’s in the DSDT at original boot, it’s still going to be in the DSDT at resume from Hibernate).

I don’t know if any of that is helpful. But I hope it is.

Peter

Hi Peter,

The data being patched is done at UEFI level before boot to HLOS . One of the modules running in UEFI would check some parameters on each boot and update CSRT based on that . This is where we are seeing issue where in data read on first boot is fine but on each subsequent hibernate resume cycles the update to data isn’t reflected . There isn’t much info in MSDN on whether all of some of ACPI table get read again on resume or are read only on first boot . The best i could find is below thread where some one had a similar doubt .
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/79e139ff-259c-419c-a2c2-e7fc79db0752/acpi-table-updates-during-resuming-from-hibernate?forum=wdk

As Doron had mentioned in reply
"All static tables (those defined through the XSDT or the RSDT in ACPI) are read only at boot time. Any information which might be changed across a sleep/hibernate cycle must be in the dynamic part of ACPI, the DSDT or an SSDT "

As per above reply , i wanted to check which category CSRT table falls into? Whether it gets read only at boot or during each hibernate/resume cycle as well ?

I was reading up on MSDN page which has info on various ACPI tables but couldn’t find info i am looking for
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-system-description-tables
Any leads would be greatly appreciated .

All the ACPI Tables are located via the RSDT/XSDT. This includes the CSRT, the FADT, and everything else including the DSDT.

From a BIOS perspective, I don’t think there are two separate “groups” of tables (static and dynamic)… and I don’t think that’s what Doron was saying. Rather, I think he was saying only the DSDT (and SSDT, if it’s present) is expected to change dynamically. Everything else is expected to be static.

That makes sense to me.

I’m not sure why you’d need to change the CSRT dynamically, because (a) it’s sort of a “table of last resort” that you use only if there’s NO other way to describe what you need to (cuz, for one thing, it’s Windows only), and (b) the “stuff” it describes tends to live on the motherboard. But, I’ll assume you really do need to change it in your current design…

Maybe you can manage the changes you need with JUST changes to the DSDT or with your HAL Extension?

I’ll admit the full implications of CSRT decisions is a bit of a mystery to me (I haven’t read the Windows source code for this part of the system since the CSRT was added) and I am absolutely not a definitive expert in anything related to ACPI, no matter WHAT the table. The docs on the CSRT are also, ah, “less than expansive.” I’d be very interested to hear how you eventually work-around this issue.

Does any of that help?

Peter