On 2021-11-12 12:58, Rob Kossler wrote:
Yes, I had included the "hwclock" output in the original email of
this chain. It can't find a hw clock.
Ah, sorry. I missed that.
So, for whatever reason, the DS-1307 driver has been excluded from
the kernel image, OR there's a hardware problem--check dmesg to
see if it
makes any comments about the ds-1307 driver being loaded, etc.
But as I indicated, I don't think the DS-1339 RTC chip has a
back-up battery of any kind. So, there may have been a conscious
decision to remove
the driver for it. I'm still waiting to hear from R&D.
I think that my overall issue is related to writing files with bad
time stamps. I don't know why this can cause the file system check
"fsck" to fail, but when that happens, the /data partition doesn't
mount and I don't know how to recover (short of re-burning the file
system).
I can say that if I start with a fresh file system, I can boot
multiple times successfully if the eth0 is connected one-to-one to my
host and is unable to acquire a network time. On the other hand, if
I connect eth0 to our network such that it gets a network time, the
network time is preserved on subsequent boots, even if I have no
network cable connected on the subsequent boots such that it acquires
no network time. But, in this case I seem to somehow run into the
same corruption related to not being able to mount the /data partition
at bootup (which I am unable to clear short of a file system re-write).
So, for now, I can use the system as long as I don't hook up to a
network time server.
In terms of the booting issue, I wonder if the "eject" on your host
isn't actually clearing the "filesystem is dirty" flag. That would be
unusual, but not out of the question.
If you instead "sudo umount /dev/sdbXX" and THEN pop the sd card,
does the behavior change?
I'm at a loss to explain how NTPD can apparently find and set the RTC
clock when "hwclock" cannot.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
