Getting aroudn RTC interrupt trouble with hwclock locking system

[Hmmm...]

Not sure if someone else had a lot of trouble with hwclock not been able to detect the interrupt signal from RTC (the test example from the Linux documentation does work). I have had quite a lot of trouble with this on my dv9000 notebook, where reading or saving time from the hardware clock has lead to system lockups.

This far the only "work around" I knew was to disable the usage of hwclock and then let ntp to set the time, this of course leads to quite bad time jumps in the logs during boot time.
While testing different versions of kernels and settings, I found that if you build into the kernel RTC support, you get the option "Set system time from RTC on startup", this seems to assume the time is in UTC.

Device Drivers --->
Real Time Clock --->
<*> RTC class
[*] Set system time from RTC on startup

So without hwclock and ntp, the time will now be okey, of course this won't fix the saving of system time to hardware clock, so ntp is wise to use, but now the difference in time should be quite small (seconds/minutes instead of weeks/months).

[Steven E. Protter]

Shalom,

Two things:
1) GREAT itrc user name
2) Why not just use ntp to keep system time and move on to something fun?

SEP

[Hmmm...]

I use ntp, but there are a couple of issues,

1. ntp isn't started before after network is up running and that leads to that everything that is done before ntp is started will have the wrong time, which can lead to unnecessary error messages.

2. Times when you can't connect to the net, you will have a clock that can be in the far future, which can cause real trouble when you reboot and get the clock set to correct time. Say you had to recompile the kernel when you didn't have access to use ntp and you need to make another change when you rebooted and have access to ntp, you must to run "make mrproper" and even it don't fix it properly.

[Matti_Kurkela]

Which Linux distribution and which kernel version you're using?

The RTC is one of the oldest parts of the PC "standard". It hasn't changed much from the days of the ISA bus, and should be still accessible the same way as with them.

The hwclock command has the option "--directisa", which forces it to skip the newer methods to access the RTC, and use the old method instead. If it works, you might edit the startup scripts to use this option to work around the problem.

By a quick Googling, it appears that the problem might be avoided with a "acpi=off" boot option. With a notebook computer, that might be acceptable during the OS installation, but disabling the power management features of a notebook computer during normal use is kind of missing the point of having a portable computer.

If "acpi=off" makes the problem go away, it would suggest the problem may be with the ACPI power management system. There might be several alternatives:

- is there a BIOS update available for your notebook? It might contain an ACPI firmware fix to solve your problem.

- can you try a newer version of the Linux kernel? The ACPI subsystem code in the Linux kernel is very complex and constantly being updated to solve or work around any known problems.