On 31/01/2024 15:16, Guilherme G. Piccoli wrote: > [...] >>> And ftrace timestamps unfortunately don't help with that, it's not >>> showing how much time the device stay suspended, so it might be >>> confusing and both cases could appear as the same exact scenario, even >>> if they are completely different (fail vs success cases). >> >> That's odd.. my assumption was the timestamps to be valid. Were you able >> to confirm that it's the issue with the timestamps? Perhaps check if the >> other devices in the system also wakeup at the approximately same >> time printed in the timestamps? >> > > Hi Thinh, indeed - this a bit odd right? I guess this is maybe related > with the way kernel keeps track of clocks on suspend - despite TSC keeps > accounting on suspend (at least for all modern x86 processors IIUC), the > timestamps in both tracing buffer or dmesg do not reflect suspend time. > > Is it different in your x86 systems? Or maybe in other architectures you > have experience with? > > I've done a test on Steam Deck, take a look in both attachments - seems > to be aligned with my perception. Also checked dmesg on my Intel laptop > (i5-6300U, with "nonstop_tsc" capability) and the timestamps do not > reflect the time spent in S3 suspend... > Just a heads-up: just noticed that on s2idle sleep, the timestamps seems to reflect the suspended time - just tested here. But on S3/deep sleep, they don't... Cheers!
