Brolin, sorry for the late reply. I've been offline due to a really bad cold.
Brolin Empey wrote: > Martin Burnicki wrote: >> Brolin, >> >> Brolin Empey wrote: >>> I run Windows 7 Professional IA-32 with RealTimeIsUniversal=1 on >>> brolin-V13, my Dell Vostro V13 laptop. This means brolin-V13?s hardware >>> clock (RTC) runs in UTC, as it should, instead of the local time zone, >>> as Microsoft still uses for the completely illogical default >>> configuration. RealTimeIsUniversal=1 is /finally/ fixed and fully >>> working beginning in Windows Vista SP2 + Windows 7, but there is still a >>> problem: When RealTimeIsUniversal=0, which is also used when the >>> RealTimeIsUniversal key does not exist, Windows 7 writes the Windows NT >>> system time to the hardware clock during the shut down process. When >>> RealTimeIsUniversal=1, though, the Windows NT system time is never >>> written to the hardware clock. >> >> Hm, this sounds like a Windows bug ... > > No, it is by design. :( Hm, then this is IMO a bad design. I knew there was a registry flag telling Windows the RTC runs on UTC instead of local time, and yet I had assumed the OS would read UTC instead of local time from the RTC at startup, and write UTC instead of local time to the RTC on shutdown. >>> Consequently, I have to boot Ubuntu from >>> a USB flash drive (brolin-V13 has no optical disc drive (ODD).), then >>> use ntpdate-debian + hwclock to synchronise the Linux system clock with >>> an NTP server on the Internet, then write the >>> sufficiently-accurate-for-me Linux system time to the hardware clock so >>> Windows 7 will set the Windows NT system clock from the accurate time in >>> the hardware clock. After some time (at least 1 week, not sure.), >>> though, my hardware clock is approximately 2 minutes behind the correct >>> time from an NTP server, but Windows 7 never writes the Windows NT >>> system time to the hardware clock when RealTimeIsUniversal=1, so I have >>> to use my Ubuntu USB flash drive again. >> >> Do you need correct time for the on-board RTC for a special application? > > No, but I still want my clocks to have accurate time. > >> As >> far as I know this is only used to initialize the Windows system time >> when Windows starts up, so your system time may be wrong until ntpd has a >> chance to correct it, i.e. it can reach an NTP server. > > I am using Microsoft?s w32time service, not ntpd. OK. > I have configured the w32time service to start automatically, but it > does not seem to start automatically, so my system time is approximately > 2 minutes behind until I run "net start w32time && w32tm /resync" in an > elevated (with administrative privileges) cmd.exe session. So this is already a different problem which should be fixed. Ntpdate should also be able to set the correct system time initially, but I'm not sure the NTP package can even be built for Windows on IA32. >>> I know the proper solution is >>> to get Microsoft to change Windows 7 so it can write the Windows NT >>> system time to the hardware clock even when RealTimeIsUniversal=1, but >>> that has not yet happened. I have at least asked a Microsoft employee >>> about it, though, so they know users (well, at least 1 user. :)) want >>> the feature. I can use w32time to force a synchronisation, but then I >>> have to do that every time I boot Windows 7. brolin-V13 travels with me >>> between home and work, so it is not always running. Maybe this causes >>> the hardware clock to fall behind, but I do not think I can prevent >>> having to shut down and boot brolin-V13 on a daily basis. Since I do >>> not know if Microsoft will ever enable Windows 7 to write the Windows NT >>> system time to the hardware clock when RealTimeIsUniversal=1, the next >>> best solution is probably to write a hwclock.exe application for Windows >>> NT, but I am hoping someone has already implemented this functionality >>> in an application such as an NTP client. Googling ?hwclock.exe? returns >>> lots of noise because some malware uses this file name, but I have not >>> found any real hwclock.exe equivalent to hwclock used on Linux. >> >> During normal operation the ntpd service should not call the Windows >> SetSystemTime() API since doing so causes a time offset offset to be >> applied to the system time. >> >> As far as I know ntpd calls SetSystemTime() only when the Windows system >> time needs to be stepped anyway, or when the ntpd service shuts down. >> >> Calling SetSystemTime() should also set the HW clock. If this doesn't >> happen then the Windows bug mentioned above is probably inside that >> Windows API call. > > Again, I am using w32time, not ntpd. The behaviour you call a bug is by > design. I looked up SetSystemTime on MSDN but could not find anything > even suggesting SetSystemTime is supposed to update the hardware clock. > I actually could not find any official documentation on how to set the > hardware clock from a userspace application on Windows NT, but I have > found how (see below). I said "as far as I know" SetSystemTime() also sets the system time. I had made some tests a few years ago, and if I remember correctly the RTC was updated when SetSystemTime() was called. However, I didn't try with the UTC registry flag set. Also, the exact behaviour can also depend on the OS version, SP level, and architecture like IA32 in your case. >>> So, is there an NTP client or any other application for Windows NT which >>> can write the Windows NT system time to the hardware clock so I do not >>> have to write hwclock.exe for Windows NT? >> >> A proper solution would indeed be to write a program which just reads the >> current system time without changing it, and then writes the system time >> to the HW clock. However, this requires a devce driver to be able to >> write to the CMOS chip. I'm not sure whether there is a documented or >> undocumented software interface to the Windows kernel to call Windows' >> built-in driver. > > The HalSetRealTimeClock function in the Windows NT kernel?s HAL needs to > be called but, AFAICT, even a device driver cannot call > HalSetRealTimeClock. Why do you think a driver can not call this? > I actually downloaded and installed Microsoft?s Windows Driver Kit > (WDK), formerly the Windows NT DDK, and searched the documentation, but > could not find anything about HalSetRealTimeClock. I do not know if > calling HAL functions from outside of the HAL is even officially > supported or was considered in the design of Windows NT. Hm, grepping for HalSetRealTimeClock over the Window directory returns restults at least in ntoskrnl.exe and hal.dll. So I'm assuming this function is just not documented publically. I bet it is exported by hal.dll and imported by ntoskrnl.exe, so it should be relatively easy to import the entry point from hal.dll and call the function from an own kernel driver, if the function prototype is known. I've found a hal.h here: http://read.pudn.com/downloads170/sourcecode/windows/vxd/786767/MyNtfs/inc/hal.h__.htm This header file contains prototypes for both HalSetRealTimeClock() and HalQueryRealTimeClock(). If you want to give it a try you need to be careful, though, since a faulty call may crash your system. Hm, BTW, I don't know how I could load such a kernel driver under Windows? Under NT you could install non-PNP drivers like a service, and then load them with "net start my_kernel_driver". In current systems drivers are loaded by the kernel automatically, e.g. if a PCI card is detected which is handled by that driver. Don't know if you can still load a kernel driver manually. [...] > I also found > <ftp://po.istu.ru/public/docs/other/OS/M$/inside/Schreiber/Samples/w2k_call/w2k_call.c> > from chapter 6 of "Undocumented Windows 2000 Secrets", but it is from > 2000-08-27 and uses ntoskrnl.exe (uniprocessor) instead of ntkrnlpa.exe > (multiprocessor), so I doubt it is still useful on Windows 7 with a > multiprocessor HAL. Hm, If I remember correctly then the ntoskrnl.exe is always used for booting, and always uses hal.dll as the HAL. During installation the appropriate version of hal and kernel are copied/renamed to those standard binaries. For example, on an XP system running here the current hal.dll has the same size as halmacpi from the installed service pack. However, I don't know if Win 7 still works this way. > And yes, I know this thread is probably off-topic for this group by now. There have been lots of discussions about details of Windows timekeeping, and IMO this is an interesting addition. ;-) >> Maybe a workaround would be the usual way to let Windows write the local >> time to the RTC, and then tell your Linux system the RTC runs in local >> time. This should only cause a problem if you whut down Windows before a >> DST changes, and boot Linux the next time after DST has changed. > > Running my hardware clock in the local time zone is *not* an acceptable > workaround for me. :) I used to do that, but had problems so I decided > my hardware clock *must* run in UTC. > > I actually had a PC (cannon, my tower PC at work) which ran only Linux > but with the hardware clock in the local time zone. cannon is usually > always running, except when the power is out, cannon stays off until I > manually press the soft (ATX) power switch on the front of the case to > power on again the next time I am at work after the power outage. > > A year or two ago, the power was out during the weekend when DST > changed. I know the Linux kernel can be configured to frequently > (11-minute mode, IIRC) write the system time to the hardware clock, but > I did not have that enabled, so the system time is written to the > hardware clock only when Linux shuts down. > > So, cannon was running during the weekend while I was not at work, DST > changed, then cannon lost power and remained off until I booted it when > I returned to work at the beginning of the next week. cannon?s system > time was then incorrect because the system time was set from the > hardware clock, which did not get updated after the DST change. Yes, but the case you describe above is the *only* case I know which causes problems if the RTC runs on local time. > That was when I finally decided my hardware clock *must* run in UTC > because trying to daylight switch the hardware clock twice per year is > completely illogical /and/ actually affects me in my practical usage. I agree. But the question is whether it's worth the effort to write a kernel driver which uses an undocumented kernel API call with all the potential problems this may cause just to get around another limitations of Windows' lousy implementation of the system clock. If your machine has access to an NTP server then a simple "ntpdate" call, or a server configuration line with the "iburst" keyword and running ntpd with the -g parameter should take care that your system time is quickly updated if you boot Linux, even if the RTC runs on local time and the DST status has changes while the machine is down. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
