Ok, this also confirms that the board had issues *before* any changes
were made to the RTC core. I'd push the board vendor to update the BIOS
to avoid this issue.
Even so, I'm curious as to what exactly trips it up. Maybe we can
provide a module option for the rtc-cmos driver to disable the alarm
functionality, so you can at least avoid the issue until the board
vendor fixes the problem (if ever).
Assuming its the alarm being set, could you try the following on a
current kernel and let me know if it still shows the problem? hwclock
might throw some odd messages with this test patch, but those can be
ignored.
John,
I apllied the patch to 2.6.38 and tested the patched kernel - it is
"bad", i.e. it exhibits the strange behavior the same way as unpatched
2.6.38.
I understand that BIOS is bad, but I am also very curious what exactly
in the kernel reveals the problem. Please let's go on with testing.
By the way, why do you think the problem appeared only when "halt" was
called after running rtctest, and did not appear when "reboot" was
called after running rtctest?
Best regards,
Jiri
thanks
-john
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 05beb6c..d9814aa 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -305,8 +305,8 @@ static void cmos_irq_enable(struct cmos_rtc *cmos, unsigned
char mask)
cmos_checkintr(cmos, rtc_control);
rtc_control |= mask;
- CMOS_WRITE(rtc_control, RTC_CONTROL);
- hpet_set_rtc_irq_bit(mask);
+// CMOS_WRITE(rtc_control, RTC_CONTROL);
+// hpet_set_rtc_irq_bit(mask);
cmos_checkintr(cmos, rtc_control);
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
