|Summary:||[rtc] [patch] AT realtime clock support routines fail on some RTC hardware.|
|Product:||Base System||Reporter:||Ian Lepore <freebsd>|
|Component:||i386||Assignee:||freebsd-i386 (Nobody) <i386>|
|Severity:||Affects Only Me|
Description Ian Lepore 2012-08-17 15:50:02 UTC
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. http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037217.html http://lists.freebsd.org/pipermail/freebsd-current/2012-August/035868.html 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).
Comment 1 Ian Lepore 2012-09-04 22:12:47 UTC
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.
Comment 2 Marek Salwerowicz 2012-10-04 23:19:45 UTC
Patch included in PR 170705 hangs booting the 9.1 kernel on Virtual Machines under ESXi 4.1, 5.1 and VirtualBox 4.2 -- Marek Salwerowicz
Comment 3 Eitan Adler 2017-12-31 08:00:56 UTC
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