NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-arm/56842
The following reply was made to PR port-arm/56842; it has been noted by GNATS.
From: Jim Spath <jspath55%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc:
Subject: Re: port-arm/56842
Date: Mon, 23 May 2022 13:17:50 -0400
Thank you for the tips. Answering several:
> ps -l
While I don't see anything obvious in the output from "ps -l" I did
observe several processes that cron started. These should have
finished quickly but I can't tell immediately why they stalled. It
does give me ideas for other tests from cron. I've captured the output
in a log to compare with future states.
> timecounters on this hw?
I don't understand this suggestion, sorry. I did find a fascinating
page from 2006 on porting NetBSD to a new ARM SoC:
https://www.netbsd.org/docs/kernel/porting_netbsd_arm_soc.html
Most of those details are beyond my ken, however.
The dmesg output shows:
[ 1.000000] timecounter: Timecounters tick every 10.000 msec
[ 1.000000] timecounter: Timecounter "armgtmr0" frequency 19200000
Hz quality 500
[ 1.000003] timecounter: Timecounter "clockinterrupt" frequency
100 Hz quality 0
My Pi3 running NetBSD shows the same values.
> system time?
The ntp daemon looked normal, but then I saw this:
May 3 11:32:01 n0b ntpd[436]: kernel reports TIME_ERROR: 0x41: Clock
Unsynchronized
After reboot, that message reappeared, as well as similar messages
that I didn't spot before. On an unrelated note, I wish I could find a
way to stop ntpd from seeking IPV6 hosts, as my ISP doesn't support
that path. Just wastes time not getting responses.
The ntpdate output seems OK.
$ ntpdate 2.netbsd.pool.ntp.org
23 May 17:07:03 ntpdate[497]: adjust time server 192.227.183.3 offset
-0.014973 sec
> newer kernel?
The image I'm running is the first NetBSD version I've found that will
run on the 02W. I will search for the steps to install a current
build, on different media so I can preserve the (mostly) working
install.
Thank you for the suggestions. I rebooted the system today. Alas, it
hit errors that required fsck to resolve as it did not halt cleanly
after a shutdown request, necessitating a power-off. A partial list of
recovered files:
- /var/db/entroy-file
- /var/log/cron
I found the _httpd user crontab file was corrupted, so I reinstalled
that. The /var/log/cron file was removed by fsck cleanup and I reset
that also. I think the entropy-file self-corrected after reboots.
Did not see this before (uncertain if it had not been flushed to disk
or I overlooked)
# ls -l /var/cron
-rw------- 1 root wheel 415424 May 15 09:02 cron.core
I will report in a couple days one way or the other. The cron jobs are
running now.
Home |
Main Index |
Thread Index |
Old Index