On some RTC hardware, the RTC interrupt handler (rtcintr() in x86/isa/clock.c)
can get stuck in its loop waiting for the RTCIR_PERIOD status bit to become
de-asserted in the hardware register.
To read RTC hardware registers you first set the index register at port 0x70
to select the register to read, then you read the value from port 0x71. On
most hardware you can write to the index register once, then issue multiple
subsequent reads to port 0x71 to continuously read new values from the
selected register. At some point, the atrtc.c code was enhanced to avoid
the expensive outb(0x70,) if it would re-select the same index as last time.
It appears that on some hardware, the value in the selected register is
latched at the time you select it with a write to 0x70, and then any number of
subsequent reads of 0x71 will keep returning the same latched value forever.
This is known to happen on systems based on the AMD Geode 500 and CS5536
companion chipset, used on a variety of single-board computers, including
the Soekris net5501 series.
The atrtc code also contains a delay (implemented by a dummy read of port 0x84)
after each access to ports rx70-71, which is expensive (about 1uS per read) and
is not required by modern hardware. The attached patch eliminates this extra
IO unless it is specifically enabled with hint.atrtc.0.use_iodelay=1.
Finally, the attached patch adds a new routine, atrtc_nmi_enable(), which
can be used by drivers which need to enable nmi interrupts. Without this
routine, it's possible that a driver directly manipulating the nmi enable
bit will conflict with the atrtc driver reading and writing the same port
to change rtc index register.
There was some mailing-list discussion of this in January 2012, when I first
ran into the problem on an industrial single-board computer, and again in August
2012 when the attached patch was shown to fix a problem on a Soekris system.
Fix: Here is the patch for -current and 9. I can provide a patch to 8-stable
as well; it's essentially the same patch with small context differences.
I've tested this using -current on several systems, recent and old
hardware, including manually bumping up the quality score for the rtc
event timer to force it to get used, and it seems to work without
trouble (and of course I've been testing the same patch at work in 8.2 for
a while on a bunch of different hardware).
Some testing by Michael Moll reveals that this patch causes a lockup
when running under VirtualBox. Please don't commit the original patch
in this PR until I have time to investigate and resolve that.
Patch included in PR 170705 hangs booting the 9.1 kernel on Virtual
Machines under ESXi 4.1, 5.1 and VirtualBox 4.2
For bugs matching the following criteria:
Status: In Progress Changed: (is less than) 2014-06-01
Reset to default assignee and clear in-progress tags.
Mail being skipped