On 5/21/24 12:27, Marek Vasut wrote:
On 5/17/24 5:39 PM, Gatien CHEVALLIER wrote:
Hi,
Possibly. I use script as init which contains basically #!/bin/sh ,
mount of a few filesystems like dev, proc, sys, and then the pm_test
sequence to avoid wasting time booting full userspace.
Ok,
The strangest thing is not being to enable the clock, maybe there's
something on the clock driver side. Tracking clock enable/disable
may lead to something.
I suspect the problem is that rng_read and runtime suspend/resume can
run in parallel, that's why this problem occurs.
Hum, this looks strange... This would need to be confirmed in your
use case. That would mean that flags aren't synced at the entry of these
functions?
FYI, I have been running your script with (echo devices >
/sys/power/pm_test) for 5 hours now and haven't been able to
reproduce the issue.
Maybe the 'devices' test is not enough and the deeper pm_test states
have some sort of impact ?
Maybe, I don't have the knowledge to confirm or invalidate this.
Tasks should be frozen before drivers are put to sleep so my instinct
would say no but you can't take it for granted :)
Could it be the kernel that requires randomness ?
That can be confirmed by adding traces to the entry point in random.c.
Maybe activating CONFIG_WARN_ALL_UNSEEDED_RANDOM will help investigate
this. It will add verbosity if crng isn't ready.
Or maybe try calling directely rng_is_initialized() to see if the crng
is ready when your issue occurs.
Best regards,
Gatien
