David Malone <[EMAIL PROTECTED]> 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: > > http://www.maths.tcd.ie/~dwmalone/clock.patch > > 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 E-mail: [EMAIL PROTECTED] _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
