David Malone <dwmalone_at_maths.tcd.ie> 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: snezhko_at_indorsoft.ruReceived on Mon Jul 16 2007 - 02:12:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:14 UTC