> > 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.
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
