Hi Marek,
On 5/14/24 16:37, Marek Vasut wrote:
On 5/14/24 10:10 AM, Gatien CHEVALLIER wrote:
Hi Marek,
Hi,
Strange indeed.
Yes.
A potential reason that comes to my mind would be that something tries
to get a random number after the driver suspended and fails to do so.
Possibly.
Else it might just be a bad clock balance.
I don't think so, this would be reported by the kernel and it would show
up in /sys/kernel/debug/clk/clk_summary as incrementing use count. It
would also not happen in a non-deterministic manner like this happens
here, the hang doesn't always happen after well defined suspend/resume
cycle count.
Can you describe the software ecosystem that you're running please?
(SCMI/no SCMI)?
STM32MP157C DHCOM PDK2 with mainline U-Boot 2024.07-rc2 , no SCMI.
Do you have the 3 fixes of stm32_rng.c that you've sent recently in your
software when testing?
Yes, but this happens even without them.
What if you add a trace in a random generation function in random.c?
Do you have a function name or line number for me ?
I put a trace in _get_random_bytes() in drivers/char/random.c. I'm not
100% sure but this should be the entry point when getting a random number.
After this, I'll try to reproduce the issue.
If you have a minute to test it on some ST MP15 board, that would be
real nice. Thanks !
I tried to reproduce the issue you're facing on a STM32MP157C-DK2 no
SCMI on the 6.9-rc7 kernel tag. I uses OP-TEE and TF-A in the bootchain
but this should not have an impact here.
How did you manage to test using "echo core > /sys/power/pm_test"?
In kernel/power/suspend.c, enter_state(). If the pm_test_level is core,
then an error is fired with the following trace:
"Unsupported test mode for suspend to idle, please choose
none/freezer/devices/platform."
I've tried using "echo devices > /sys/power/pm_test" so that I can at
least test that the driver is put to sleep then wakes up. I do not
reproduce your issue.
[ 169.026421] Filesystems sync: 0.013 seconds
[ 169.031087] Freezing user space processes
[ 169.036562] Freezing user space processes completed (elapsed 0.002
seconds)
[ 169.042238] OOM killer disabled.
[ 169.045383] Freezing remaining freezable tasks
[ 169.051408] Freezing remaining freezable tasks completed (elapsed
0.001 seconds)
[ 169.238226] dwc2 49000000.usb-otg: suspending usb gadget
configfs-gadget.g1
[ 169.270236] In stm32_rng_suspend
[ 169.275501] PM: suspend debug: Waiting for 5 second(s).
[ 174.283418] In stm32_rng_resume
[ 174.284291] stm32-dwmac 5800a000.ethernet end0: configuring for
phy/rgmii-id link mode
[ 174.337714] dwmac4: Master AXI performs any burst length
[ 174.341699] stm32-dwmac 5800a000.ethernet end0: No Safety Features
support found
[ 174.349138] stm32-dwmac 5800a000.ethernet end0: IEEE 1588-2008
Advanced Timestamp supported
[ 174.363442] dwc2 49000000.usb-otg: resuming usb gadget configfs-gadget.g1
[ 174.667669] onboard-usb-hub 2-1: reset high-speed USB device number 2
using ehci-platform
[ 174.989075] OOM killer enabled.
[ 174.990848] Restarting tasks ... done.
[ 175.003976] random: crng reseeded on system resumption
[ 175.009464] PM: suspend exit
[ 175.011473] random: ASKING FOR 96 BYTES
[ 175.011468] random: ASKING FOR 96 BYTES
[ 175.015747] random: ASKING FOR 16 BYTES
[ 175.044933] random: ASKING FOR 96 BYTES
[ 175.059399] random: ASKING FOR 96 BYTES
[ 175.070925] random: ASKING FOR 16 BYTES
[ 175.079285] random: ASKING FOR 96 BYTES
[ 175.082113] random: ASKING FOR 16 BYTES
[ 175.096759] random: ASKING FOR 16 BYTES
[ 175.098674] random: ASKING FOR 96 BYTES
[ 175.295584] random: ASKING FOR 16 BYTES
[ 175.302357] random: ASKING FOR 96 BYTES
[ 175.311525] random: ASKING FOR 16 BYTES
[ 175.312989] random: ASKING FOR 16 BYTES
Can you give it another shot with the trace so that we can ensure that
no random is asked after the driver is suspended in your case please?
Thanks,
Gatien
