On Fri Aug 18, 2023 at 4:58 AM EEST, Limonciello, Mario wrote: > > > 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 It would be more useful perhaps to get full dmesg output after power on and before going into suspend. Also ftrace filter could be added to the kernel command-line: ftrace=function ftrace_filter=tpm* After bootup: mount -t tracefs nodev /sys/kernel/tracing cat /sys/kernel/tracing/trace BR, Jarkko
