David Malone <email@example.com> writes:
>> Yes, I'll test them.
>> The problem is - the same kernel works when booted off a hard drive, so
>> unless the VMWare BIOS is very messed up (it's the first time I see such
>> problems) it may not help. Please, scatter debug printf's around so I
>> can see what's going on :)
> Try the patch at:
> It checks the return values of the various clock reading functions
> in the kernel and prints an error message if it finds that it can't
> set the clock OK. Some machines have a BIOS that doesn't count the
> day-of-week correctly, and recently FreeBSD has started treating
> this as an error on some platforms.
Just a "mee too" - I've been suffering from precisely this problem -
on a hardware box, not vmware. I have instrumented clock_ts_to_ct in
my kernel to see what happens, and yes, ct.dow is 0 today, on monday,
and day_of_week(days) expects 1. I couldn't find on what day of week
dow should be 0 anywhere in the specs - on sunday or on monday - so
probably there are just bioses that behave differently in this
respect. Thanks for clarifying the issue.
Also, this was a surprise to an unexperienced me, but I have also
found that vfs_mount initializes RTC with the latest timestamp found
on local file systems - this explains why kernel "worked" for Ivan on
a hard drive. It didn't actually work, but used timestamp which was
stored on filesystem during unmount.
WBR, Victor V. Snezhko