Bug 551245

Hm. I wonder if we can always assume that rtc0 is the device that would have the wakealarm.

I guess that I don't know... 

Saving it likely wouldn't -hurt- but I suppose missing other rtcX might be bad.

Maybe I should do some digging to find out if the wakealarm clearing is a feature or a bug, first.

I think some BIOS reset the wakealarm because they assume that if the time has changed then the alarm's not going to be at the right time anymore so it's better not to have it? My BIOS doesn't reset wakealarm times, for what it's worth.

To cater for rtc1 etc, why not use something like:

--- /etc/rc.d/init.d/halt	2009-12-05 11:14:29.000000000 +1030
+++ halt	2010-01-17 12:02:59.094091031 +1030
@@ -103,10 +103,22 @@ fi
 touch /var/lib/random-seed
 chmod 600 /var/lib/random-seed
 action $"Saving random seed: " dd if=/dev/urandom of=/var/lib/random-seed count=1 bs=512 2>/dev/null
 
+# Save wakealarm times as some BIOS clear this when the hw clock is set
+restore_wake=""
+for f in /sys/class/rtc/*/wakealarm; do
+	[ -f "$f" ] || continue
+	waketime=`< "$f"`
+	[ -n "$waketime" ] || continue
+	restore_wake="$restore_wake echo '$waketime' > '$f';"
+done
+
 [ -x /sbin/hwclock ] && action $"Syncing hardware clock to system time" /sbin/hwclock --systohc
 
+# Restore wakealarm times
+[ -x /sbin/hwclock -a -n "$restore_wake" ] && eval "$restore_wake"
+
 # Try to unmount tmpfs filesystems to avoid swapping them in.  Ignore failures.
 tmpfs=$(awk '$2 ~ /^\/($|proc|dev)/ { next; }
 	     $3 == "tmpfs" { print $2; }' /proc/mounts | sort -r)
 [ -n "$tmpfs" ] && fstab-decode $UMOUNT $tmpfs 2>/dev/null

Hah, when thinking about it, the --systohc is only done on the default RTC (i.e., /dev/rtc or /dev/rtc0). So, we shouldn't need to handle non-default wakealarms, as only the default clock is getting reset.

(It does point out that there could be a minor hole in that we're *not* writing back the clock for any non-default RTC, but that hasn't been an issue so far.)

Yes, good point.

Hmm, one thing I just noticed on my hardware is that trying to set the wakealarm when it's already set gives you an error like:
# echo +300 > /sys/class/rtc/rtc0/wakealarm
# echo +300 > /sys/class/rtc/rtc0/wakealarm
echo: write error: Device or resource busy

So you have to clear it manually before setting it again:
# echo 0 > wakealarm

Arguably sysfs should handle this better, but just in case we should probably reset it.

--- /etc/rc.d/init.d/halt	2009-12-05 11:14:29.000000000 +1030
+++ halt	2010-01-19 04:31:11.384837255 +1030
@@ -103,9 +103,25 @@ fi
 touch /var/lib/random-seed
 chmod 600 /var/lib/random-seed
 action $"Saving random seed: " dd if=/dev/urandom of=/var/lib/random-seed count=1 bs=512 2>/dev/null
 
-[ -x /sbin/hwclock ] && action $"Syncing hardware clock to system time" /sbin/hwclock --systohc
+if [ -x /sbin/hwclock ]; then
+    # Save wakealarm times; some BIOS clear this when the clock is set
+    # As hwclock only touches rtc0, we shouldn't need to touch rtc1...
+    restore_wake=""
+    if [ -f /sys/class/rtc/rtc0/wakealarm ]; then
+        restore_wake=`< /sys/class/rtc/rtc0/wakealarm`
+    fi
+
+    action $"Syncing hardware clock to system time" /sbin/hwclock --systohc
+
+    # Restore wakealarm times if necessary
+    if [ -n "$restore_wake" ]; then
+	# Unset wakealarm, then set it again
+	echo 0 > /sys/class/rtc/rtc0/wakealarm
+	echo "$restore_wake" > /sys/class/rtc/rtc0/wakealarm
+    fi
+fi
 
 # Try to unmount tmpfs filesystems to avoid swapping them in.  Ignore failures.
 tmpfs=$(awk '$2 ~ /^\/($|proc|dev)/ { next; }
 	     $3 == "tmpfs" { print $2; }' /proc/mounts | sort -r)

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Wow, blast from the past.  I really don't care about this bug anymore, if you want to just close it.  Actually I'll just do that.  Feel free to re-open if you care about it.  It's crazy to have bugs open for 8 years.

Hello Eric! :)

Sorry for pulling skeletons from the closet to the light again... :D I have started maintaining initscripts last year, so I'm keeping this BZ open, just to make sure later we no longe have this problem in Fedora. That's all. ;)

hah, 11 years later I guess I'll close this one.