Attempt to update Rock64 to head -r355976 failed to boot afterwards, a dev.cpu.0.freq= issue (in sysctl.conf in my normal boot)

[Mark Millard]

[History eliminated: better information now.]

I have isolated where in the boot sequence it crashes
when it does for my normal boot sequence: processing
a line in my /etc/sysctl.conf :

dev.cpu.0.freq=1296

This is something that I've been using that only recently
has lead to any problems. (But I'd not updated in a while.)

I do not know if or how specific it is to the 1296 figure
from the list:

dev.cpu.0.freq_levels: 1296/-1 1200/-1 1008/-1 816/-1 600/-1 408/-1

Previously to updating I had no hint of problems from using
the assignment in general, including 1296 working fine.


This was isolated, in part, via adding before and after
messages and finding no After-message to match up with:

/etc/rc.d/sysctl's sysctl_start: Before /sbin/sysctl -i -f /etc/sysctl.conf

With that knowledge I was able to experiment by hand with
sysctl commands in "boot -s" sessions and got example
crashes from the dev.cpu.0.freq assignment (but seemingly
dependent on prior activity [or lack of it] in the
session).

I still have no clue why messages from boot -v or
other activity makes a difference. But the context
for failing has been consistent so far.

I can not say that I've got a sequence that guarantees
a crash, just that I've gotten example crashes.


I had another oddity, in that when it did not crash, I
could not set the dev.cpu.0.freq figure again, for
example:

# sysctl dev.cpu.0.freq=600
dev.cpu.0.freq: 600 -> 600

# sysctl dev.cpu.0.freq=816
dev.cpu.0.freq: 600cpufreq_dt0: set freq failed, err 6
cpufreq_dt1: set freq failed, err 6
cpufreq_dt2: set freq failed, err 6
cpufreq_dt3: set freq failed, err 6

So each dev.cpu.0.freq test ended up being via a
separate boot, even if it had not crashed.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)