Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Problems with TOD clock data on i386?



Recently, following the most recent round of netbsd-6 pullups, one of my
systems running the i386 port is taking issue with the TOD clock.

NetBSD 6.0_BETA2 (SKULD) #36: Thu Jul 12 17:23:59 CDT 2012
        sysop@skuld:/d0/build/netbsd-6/obj/i386/sys/arch/i386/compile/SKULD
total memory = 3263 MB
avail memory = 3202 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
HP Pavilion 061 ER975AA-ABA A1235C (0nx1114RE101ASTER00)
mainbus0 (root)
cpu0 at mainbus0 apid 0: Intel(R) Pentium(R) 4 CPU 2.93GHz, id 0xf49
cpu1 at mainbus0 apid 1: Intel(R) Pentium(R) 4 CPU 2.93GHz, id 0xf49
ioapic0 at mainbus0 apid 2: pa 0xfec00000, version 21, 24 pins
acpi0 at mainbus0: Intel ACPICA 20110623
acpi0: X/RSDT: OemId <HP-CPC,OEMRSDT ,12000526>, AslId <MSFT,00000097>
ACPI Error: Method parse/execution failed [\_PR_.CPU1._PDC] (Node 0xc3e94444), 
AE_INVALID_TABLE_LENGTH (20110623/psparse-560)
ACPI Error: Method parse/execution failed [\_PR_.CPU2._PDC] (Node 0xc3e94504), 
AE_INVALID_TABLE_LENGTH (20110623/psparse-560)

[...]
root file system type: ffs
WARNING: preposterous TOD clock time
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
[...]

Dropping into the machine's BIOS/setup shows the clock set to the
correct time/date (set to UTC).  It does not appear to be modified
by the system.

In the past, this same machine would regularly report the clock gained
some number of days (usually the number of days since the last reboot),
but it seemed otherwise to work.


While I'm using ntpd to synchronize the clock (with -g to force large
initial adjustment), this seems to come too late for PAM/kerberos to
synchronize with my KDC so my pam-enabled 'sudo' requires a local password
instead of accepting the realm password for the sudoer trying to
authenticate.

(This behavior appeared after the KDC changed addresses on my network,
but all addressing/name-resolution has been verified correct, so that
leads me to consider time offsets.)

The only other system I see such a warning on is my Lemote Yeeloong,
but I think that has to do with what evbmips considers the 'epoch'
for their various hardware or firmware monitor.  In the case of the
Yeeloong, the TOD clock gets reprogrammed to 20 years in the past.

--
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645


Home | Main Index | Thread Index | Old Index