Hello Christophe, Il giorno mer, 26/08/2020 alle 15.53 +0200, Christophe Leroy ha scritto: [...] > If there is no warning, then the issue is something else, bad luck. > > Could you increase the loglevel and try again both with and without > VMAP_STACK ? Maybe we'll get more information on where it stops.
The problem is related to the CPU frequency changes. This is where the system stop: cpufreq get the CPU frequency limits and then start the default governor (performance) and then calls function cpufreq_gov_performance_limits() that never returns. Rebuilding after enabling pr_debug for cpufreq.c, I've got some more lines of output: cpufreq: setting new policy for CPU 0: 667000 - 867000 kHz cpufreq: new min and max freqs are 667000 - 867000 kHz cpufreq: governor switch cpufreq: cpufreq_init_governor: for CPU 0 cpufreq: cpufreq_start_governor: for CPU 0 cpufreq: target for CPU 0: 867000 kHz, relation 1, requested 867000 kHz cpufreq: __target_index: cpu: 0, oldfreq: 667000, new freq: 867000 cpufreq: notification 0 of frequency transition to 867000 kHz cpufreq: saving 133328 as reference value for loops_per_jiffy; freq is 667000 kHz no more lines are printed. I think this output only refers to the notification sent prior to the frequency change. I was thinking that selecting a governor that would run at 667mHz would probably skip the problem. I added cpufreq.default_governor=powersave to the command line parameters but it did not work: the selected governor was still performance and the system crashed. Bye, Giuseppe