ok here goes...

1) you use setwakeup.sh to store the time-to-wake into /tmp/alarm

then when hwclock.sh executes
2) you set ACPITIME from the /tmp/alarm
3) set the system clock (using hwclock --systohc)
4) set /proc/acpi/alarm from the ACPITIME

then some fussy bios stuff
5) you set ACPITIME from the /proc/acpi/alarm
6) set the system clock (using hwclock --systohc)
7) set /proc/acpi/alarm from the ACPITIME

Is there any reason that the same block of code is cutnpaste twice?
From memory, when i edited the hwclock.sh script i just made two changes according to the fussy bios section at this page http://www.mythtv.org/wiki/index.php/ACPI_Wakeup
The key difference is that i made the changes in the stop|restart|reload|force-reload) section, not appending it at the bottom.



Does that make any sense.... who knows, but your hwclock.sh modification appear to be significant, while i made only two changes.

Funny things seem to happen to the time-to-wake once you put it in /proc/acpi/alarm, so i would remove step 5) and see if that makes any difference. My logic is that currently
1) you set ACPITIME at the start,
2) then you set that value into the /proc/acpi/alarm,
3) then you set ACPITIME from the /proc/acpi/alarm (which could be funny numbers)
4) then you set the system time using ACPITIME (which could be funny numbers)

If i remember, i'll post my hwclock.sh in its entirety tonight?

Cheers,

Nathan

_________________
LinHES: R6 | MB: Asus M3N-H/HDMI | CPU: AMD ??Mhz
Capture: 2xHDHR DVB-T
Graphics: Onboard 8300|PSU: Corsair vx450w
Cooling: Zalman cu?,
Display: Benq xx projector

just noticed they have updated the wiki.... i'm not sure what version the kernel is for KM, but we might have to change our approach sometime soon?

Kernel 2.6.22 and higher use
ls /sys/class/rtc/rtc0/wakealarm
Older kernels
ls /proc/acpi/alarm

_________________
LinHES: R6 | MB: Asus M3N-H/HDMI | CPU: AMD ??Mhz
Capture: 2xHDHR DVB-T
Graphics: Onboard 8300|PSU: Corsair vx450w
Cooling: Zalman cu?,
Display: Benq xx projector

Nathan,

Thanks for your input. The fussy bios code I put in is as per grasky's post mentioned in my first post. I will try your idea of leaving out step 5 and I might also try commenting out the entire fussy bios section and see if that makes a difference. I will be interested in seeing you hwclock.sh.

Richard

_________________
Intel DG965WH, Dvico DVB-T Lite x2, HDHR, Gigabyte GT220, KingstonSSD, WD20EARS version=latest

I tried deleted step 5 with the same result.

I also did a bit more investigation using diagnostic statements to see how far through hwclock.sh I get. I still need to do some more work on it but it appears only the very first part of script is executing. I have compared the script lines against a version of Ubuntu I have running and it seems OK.

It would be good if I could find a log that stores any problems the script had while executing.

_________________
Intel DG965WH, Dvico DVB-T Lite x2, HDHR, Gigabyte GT220, KingstonSSD, WD20EARS version=latest

Success!

You were right that the machine does wake up correctly and the date is reset after starting. I should have ignored /proc/acpi/alarm and tried a real wake-up test. I now have to clean up my /etc/init.d/hwclock.sh to get rid of all my debugging statements.

Thanks to all who helped.

_________________
Intel DG965WH, Dvico DVB-T Lite x2, HDHR, Gigabyte GT220, KingstonSSD, WD20EARS version=latest

excellent news!

just remember to document what you did, coz i have to re-remember it everytime i upgrade

Theres clever restore scripty stuff you can do, but it doesnt include any mods to the
1) hwclock.sh (i dont think it is wise to restore those system scripts, it might be wrong)...
2) sudoers

My setwakeup.sh script is in a restored location, so it appears again after an upgrade which is cool...

Cheers,

Nathan

_________________
LinHES: R6 | MB: Asus M3N-H/HDMI | CPU: AMD ??Mhz
Capture: 2xHDHR DVB-T
Graphics: Onboard 8300|PSU: Corsair vx450w
Cooling: Zalman cu?,
Display: Benq xx projector