On Thu, Nov 10, 2016 at 7:47 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
small update:
I have tried to bridge the weak wire to the capacitor with an external wire.
Unfortunately there is as expected no visible difference (well, this statistics isn't very precise due to small sample size). But as before it did come to login: in 2 out of 10 attempts and stuck in 8 of 10 (@1.25 GHz OPP enabled).
Then I made another observation which makes me believe a little more in a SW issue again:
If the kernel freezes, it is always between 6 and 10 seconds kernel time (@1.25 GHz).
Never before and never after this.
If the kernel runs successfully for 10 seconds, the boot process completes and after ~30 seconds we have a login: prompt.
This 6-10 seconds windows is for 30 boot attempts where a total of 7 did succeed.
Now I really wonder what the kernel doing in this time frame which can make it freeze here but not outside this window?
Some interrupt initialization? Waiting during a spinlock for some wrong address to have a specific state?
I think it's better to go back to booting with powersave governor to eliminate some randomness from the tests, as there are too many things going on during boot that are racing each other. Here is part of a message from yourself sent in July:
- change defconfig
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set -# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set +CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y +# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
- echo "ENABLE=false" >$SD/etc/default/cpufrequtils
or Debian would try to enable the ondemand govenor at the end of the boot process.
- After adding two OPP for 1.25GHz and 1.5GHz to DT I could run
additional tests.
cpufreq-set -f 1Ghz runs fine. No problems. cpufreq-set -f 1.25GHz might hang cpufreq-set -f 1.5GHz hangs almost immediately within a second or so. Even as the CPU is almost idle (waiting for shell and blinking LEDs)
GraÅžvydas