Date: Wed, 25 Dec 2019 14:56:14 -0800 From: Mark Millard <marklmi@yahoo.com> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Attempt to update Rock64 to head -r355976 failed to boot afterwards, a dev.cpu.0.freq= issue (in sysctl.conf in my normal boot) Message-ID: <F7C8B317-A51C-461A-8BC0-2FAB8DC87B0F@yahoo.com> In-Reply-To: <4119BA31-2BE1-41AF-B075-D6D6C488B43D@yahoo.com> References: <78081E30-3758-46F3-A228-02B29CDAA6A6.ref@yahoo.com> <78081E30-3758-46F3-A228-02B29CDAA6A6@yahoo.com> <20191222113844.9385de125afd10e86358bc98@bidouilliste.com> <3C550401-A5BF-441E-81E6-29D5D917302B@yahoo.com> <FF778D08-0C49-4181-98B8-371003663F22@yahoo.com> <0AADC2F5-9867-40E7-B4C0-139CA16A3974@yahoo.com> <20191223153816.4e532acede0605a0c868a8e4@bidouilliste.com> <87E3B152-D7A1-4E9D-9710-3535F92B4DD2@yahoo.com> <4119BA31-2BE1-41AF-B075-D6D6C488B43D@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F7C8B317-A51C-461A-8BC0-2FAB8DC87B0F>