clock problems with BeagleBone Black on 12.2BETA2

Michal Meloun meloun.michal at gmail.com
Fri Sep 25 12:43:18 UTC 2020



On 25.09.2020 13:29, Glen Barber wrote:
> On Fri, Sep 25, 2020 at 01:17:34PM +0200, Michal Meloun wrote:
>>
>>
>> On 25.09.2020 11:33, Glen Barber wrote:
>>> On Fri, Sep 25, 2020 at 12:07:03AM -0500, Mike Karels wrote:
>>>>> Date: Fri, 25 Sep 2020 00:33:47 +0000
>>>>> From: Glen Barber <gjb at freebsd.org>
>>>>
>>>>> On Thu, Sep 24, 2020 at 06:04:58PM -0400, Ed Maste wrote:
>>>>>> On Tue, 22 Sep 2020 at 14:09, Mike Karels <mike at karels.net> wrote:
>>>>>>>
>>>>>>> I just installed 12.2BETA2 on a BeagleBone Black (armv7), and it took
>>>>>>> at least an hour.  I hit ^T periodically, and time seemed screwed up
>>>>>>> (real time was progressing slowly at best).
>>>>>>
>>>>>> I've independently confirmed this on the 12.2BETA2 image; from my console:
>>>>>> ...
>>>>>> FreeBSD 12.2-BETA2 r365865 GENERIC arm
>>>>>> ...
>>>>>> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
>>>>>> Warning: no time-of-day clock registered, system time will not be set acc=
>>>>> urately
>>>>>> Growing root partition to fill device
>>>>>> random: read_random_uio unblock wait
>>>>>> load: 1.28  cmd: awk 39 [piperd] 0.12r 0.00u 0.00s 0% 2060k
>>>>>> load: 1.28  cmd: awk 39 [piperd] 0.14r 0.00u 0.00s 0% 2060k
>>>>>> ...
>>>>>>
>>>>>> time seems to be running about 500x slow.
>>>>>>
>>>>>> I ^C'd each startup script that was stuck (I'm not as patient as
>>>>>> Mike), and got to a login prompt. I was able to login as root just
>>>>>> fine and the system seemed responsive for commands that don't sleep. I
>>>>>> tried `sleep 0.01` and that took about 5 seconds of actual time.
>>>>>>
>>>>
>>>>> Given the 1 second = 5 seconds info, does it eventually finish, or have
>>>>> you just killed the power to it before getting that far?
>>>>
>>>> In my case, it finished, but took at least an hour.  It may have taken
>>>> longer if I didn't hit ^T periodically, e.g. I think that helped seed
>>>> entropy.  But according to Ed's measurement, it is closer to 1 second =
>>>> 500 seconds.
>>>>
>>>
>>> Err, sorry, I misread part of Ed's email, and 1 second = 500 seconds is
>>> what he seems to report as well.
>>
>> Glen,
>> do you see same problem also on CURRENT?
> 
> CURRENT is reportedly not exhibiting this behavior.

Thanks for response.
I currently preparing (slightly) bigger patchset which should
"normalize" situation about TI clock in CURRENT. These must be MFCed to
STABLE ASAP but I afraid that we miss 12.2 target :(

Michal



More information about the freebsd-arm mailing list