On 8/17/2023 5:33 PM, Jarkko Sakkinen wrote:
On Fri Aug 18, 2023 at 1:25 AM EEST, Todd Brandt wrote:
On Fri, 2023-08-18 at 00:47 +0300, Jarkko Sakkinen wrote:
On Fri Aug 18, 2023 at 12:09 AM EEST, Todd Brandt wrote:
While testing S3 on 6.5.0-rc6 we've found that 5 systems are seeing
a
crash and reboot situation when S3 suspend is initiated. To
reproduce
it, this call is all that's required "sudo sleepgraph -m mem
-rtcwake
15".
1. Are there logs available?
2. Is this the test case: https://pypi.org/project/sleepgraph/ (never
used it before).
There are no dmesg logs because the S3 crash wipes them out. Sleepgraph
isn't actually necessary to activate it, just an S3 suspend "echo mem >
/sys/power/state".
So far it appears to only have affected test systems, not production
hardware, and none of them have TPM chips, so I'm beginning to wonder
if this patch just inadvertently activated a bug somewhere else in the
kernel that happens to affect test hardware.
I'll continue to debug it, this isn't an emergency as so far I haven't
seen it in production hardware.
OK, I'll still see if I could reproduce it just in case.
BR, Jarkko
I'd like to better understand what kind of TPM initialization path has
run. Does the machine have some sort of TPM that failed to fully
initialize perhaps?
If you can't share a full bootup dmesg, can you at least share
# dmesg | grep -i tpm
I think it would be really good to try the following:
0) Start with a machine without this patch in place
1) At bootup run this command:
# tpm2_getcap properties-fixed
2) Suspend machine
3) Repeat that command after suspend
4) Reboot with that patch and repeat steps 1 and 2.
