"hwclock --directisa" in rc.S and rc.6

pdi · 12-08-2014, 06:33 AM

This is rather obscure and perhaps insignificant, but here goes.

In both rc.S and rc.6, when the call is made to hwclock, there is a test first:

Code:

# Check for a broken motherboard RTC clock (where ioports for rtc are
# unknown) to prevent hwclock causing a hang:
if ! grep -q -w rtc /proc/ioports ; then
    CLOCK_OPT="--directisa"
fi

Slackware's kernels seem to use the newer "RTC Class" drivers (see rtc.txt in the kernel documentation) which result in /dev/rtcN, rather than /dev/rtc, and the symlink of /dev/rtc to /dev/rtc0 supports this. As a consequence of this, the rtc line in /proc/ioports reads rtc0 and not rtc. So the test grep -w rtc /proc/ioports will never be true, and --directisa will always be set.

According to hwclock(8), the --directisa "is meaningful only on an ISA machine or an Alpha [...]. For other machines, it has no effect."

So one way might be to skip the test altogether, and hardcode the --directisa to the hwclock line no matter what.

And another would be to retain the test, adjusted to something like grep -w "rtc[0-9]*" /proc/ioports.

As always, there is the possibility I'm missing the obvious, so feel free to let me know

GazL · 12-08-2014, 07:31 AM

I suggested modernising hwclock over a year ago, but it fell on deaf ears. I didn't realise that the existing implementation was quite as broken as you've shown though. Thanks for posting.

Xsane · 12-08-2014, 11:35 AM

This is one of many Slackware date-time problems. I have been working to resolve all
of them and hope to post solutions here on LQ soon. This issue was to be included, but
I may as well address it here and scratch it off my list.

The problem with this test was brought up before in this thread:
hwclock --directisa in /etc/rc.d/rc.S, and Pat replied to it there.

Pat's position is that if we cannot give a specific example that this is breaking
something he does not want to change it.

Quote:

Originally Posted by volkerdi

I'd consider it harmless unless you can tell me that it's
causing problems on your system. Removing it now might not be so harmless.

Pat, Although I cannot offer a reproducible problem related to this broken test, I do
believe that it should be fixed.

Quote:

Originally Posted by volkerdi

As the man page says states that this option "has no effect" on non-ISA machines I'd consider it harmless...

I would argue that it is not harmless. Under linux all x86 machines are assumed to be
backward compatible with ISA and __i386__ is set. This causes hwclock to use direct
access when it is called with --directisa. If not for a bug in util-linux hwclock(which
I intend to fix soon), x86_64 machines will as well.

Direct ISA access is intended as a last resort for hwclock and should be avoided
whenever possible. Direct hardware access from user-space is asking for trouble,
especially when it involves interrupts as the ISA persistent clock does. I'm sure you
have experienced the bazaar problems interrupts can inflict, do we really want to be
screwing with them from user-space at boot if it can be avoided?

Actually, I can think of something this breaks. Direct access has far less precision
then using the rtc device driver. It therefore breaks systems not using NTP and
wanting to have their time kept as accurate as possible.

Quote:

Originally Posted by volkerdi

I've been burned by removing old workarounds in the past. Looks like this one was added in 2004 by Piter Punk, well past the ISA era, and likely fixed something then. I don't have specific notes about what we were trying to find in /proc/ioports, but rtc0 (or rtc*) could well have been what we were trying to match. The nature of voodoo workarounds (especially for borken hardware) tends to be that something fixes a bug, but does not always make logical sense.

Slackware was not using udev then and the test worked properly. The test is broken
under udev and will always pass. As stated in the OP, if your position is to not fix
the test, then --directisa may as well be hard coded into the command. However, that
would not be a harmless thing to do, neither is leaving it broken.

I cannot think of any reason to not fix this test so that it will work with udev AND
still satisfy its original intent if udev is not used.

I'm currently using this:

Code:

if ! grep -q -w "rtc.\?" /proc/ioports ; then

It has been working well on my x86 machines and will still fail
for 'rtc' as originally intended.

GazL,

I would not recommend switching to --systz as I have made some valuable improvements to
--hctosys in utli-linux v2.26(not yet released), with more to come in future releases.

pdi · 12-08-2014, 11:23 PM

First, my apologies for not locating and acknowledging the thread indicated by Xsane, I was so focused on being accurate that searching for "prior art" entirely slipped my mind.

Second, my intention was for shared (finding), not stirred (hornet's nest). It seems I stumbled unaware upon a little controversy. Had I done my homework I would have trod more carefully.

Third, I was about to thank GazL for his reply and say that, based on hwclock(8), "broken" might be too strong a word for something that has no serious consequence, when Xsane's post made me pause and wonder at my ignorance. My thanks still stand :-)

Fourth, Xsane, I like your regex "rtc.\?" better as it covers both rtc and rtcN. I don't know enough to fathom what would happen if N ever gets two digits.

Fifth, --directisa is an odd option. Judging only by hwclock(8), and I'll explain further down why I underline this, it seems that it doesn't matter if one uses it or not. It is "meaningful" only for ISAs or Alphas, but if left out and /dev/rtc can't be read it is silently implied; and for other machines it has no effect. Notice it only mentions /dev/rtc, not /dev/rtcN, but is this to be taken literally? Only the code will tell.

Quote:

--directisa
is meaningful only on an ISA machine or an Alpha (which implements enough of ISA to be, roughly speaking, an ISA machine for hwclock's purposes). For other machines, it has no effect. This option tells hwclock to use explicit I/O instructions to access the Hardware Clock. Without this option, hwclock will try to use the /dev/rtc device (which it assumes to be driven by the rtc device driver). If it is unable to open the device (for read), it will use the explicit I/O instructions anyway.

Sixth, and this is by way of a small diversion to explain what I underlined, hwclock(8), in spite of a last update in 2008, fails to mention the 24 hour rule, ie that it will not calibrate the hardware clock at intervals of less than 24 hours. You only get a glimpse of that if you use the --debug option. And yet, while the warning is for 24 hours, the test in the code is for 23. So to come back to the fifth point, only the code will tell.

Seventh, while we're on the subject or hwclock, I wonder if it might make more sense to pull the code from rc.S and rc.6 into an rc.hwclock. This is not an entirely cosmetic suggestion, for it would facilitate easier overview of the code and highlight such minor differences as this:

Code:

rc.S
[...]
if grep -wq "^UTC" /etc/hardwareclock ; then
[...]

Code:

rc.6
[...]
if grep -q "^UTC" /etc/hardwareclock 2> /dev/null ; then
[...]

GazL, Xsane, thanks both for your input.

GazL · 12-09-2014, 04:56 AM

Quote:

Originally Posted by pdi

Third, I was about to thank GazL for his reply and say that, based on hwclock(8), "broken" might be too strong a word for something that has no serious consequence, when Xsane's post made me pause and wonder at my ignorance. My thanks still stand :-)

Yep, I hesitated myself while typing that word, but there didn't seem to be a better way to describe a conditional expression that always evaluates 'true': even if the end result doesn't hurt anything. However, you're right, the overall tone was probably a bit strong.

Xsane, thanks for the reply. If you have time, I'd appreciate it if you could give me an idea about the advantages you alluded to of using --hctosys over --systz.

Xsane · 12-09-2014, 11:42 AM

Quote:

Originally Posted by pdi

First, my apologies for not locating and acknowledging the thread indicated by Xsane, I was so focused on being accurate that searching for "prior art" entirely slipped my mind.

Second, my intention was for shared (finding), not stirred (hornet's nest). It seems I stumbled unaware upon a little controversy. Had I done my homework I would have trod more carefully.

No worries pdi! We cannot keep track of all the topics here, and search fails us at times anyway... or perhaps we fail search? I do not think this is a nest of hornets, just typical discourse.

Quote:

Originally Posted by pdi

Fourth, Xsane, I like your regex "rtc.\?" better as it covers both rtc and rtcN. I don't know enough to fathom what would happen if N ever gets two digits.

I cannot imagine a machine with more that 10 hardware clocks, but we really
only need to find one to discard --directisa. Testing just for rtc and rtc0 would
probably be sufficient.

Quote:

Originally Posted by pdi

Fifth, --directisa is an odd option. Judging only by hwclock(8), and I'll explain further down why I underline this, it seems that it doesn't matter if one uses it or not. It is "meaningful" only for ISAs or Alphas, but if left out and /dev/rtc can't be read it is silently implied; and for other machines it has no effect. Notice it only mentions /dev/rtc, not /dev/rtcN, but is this to be taken literally? Only the code will tell.

Well, unfortunately the manual was poorly written. It makes it sound like ISA
is a far off mythical thing, when as far as Linux is concerned it includes any
x86/x86_64.

Date-time under Linux is so disjointed between kernel, system calls, adjtimex, hwclock,
ntp, ... Documentation is equally fragmented, often contradicting each other. It is
on my todo list to rewrite the hwclock.8, but it is not at the top by a long shot.

The reason this test was put in place is because on some machines hwclock would hang
while attempting to use /dev/rtc, so it never reached the fallback to direct ISA.

It is debatable whether this old hardware is still relevant, but I have no problem
keeping the test as long as it works as it was originally intended. Right now it is
broken, and yes that is the appropriate word to use. Unless udev is turned off, and
/dev/rtc is created, it will always evaluate to true. Bad.. bad... bad...

Quote:

Originally Posted by pdi

Sixth, and this is by way of a small diversion to explain what I underlined, hwclock(8), in spite of a last update in 2008, fails to mention the 24 hour rule, ie that it will not calibrate the hardware clock at intervals of less than 24 hours. You only get a glimpse of that if you use the --debug option. And yet, while the warning is for 24 hours, the test in the code is for 23. So to come back to the fifth point, only the code will tell.

2008? What version are you using? This was fixed in v2.24 and will be further
shortened when v2.26 is released.

Quote:

Originally Posted by pdi

Seventh, while we're on the subject or hwclock, I wonder if it might make more sense to pull the code from rc.S and rc.6 into an rc.hwclock. This is not an entirely cosmetic suggestion, for it would facilitate easier overview of the code and highlight such minor differences as this:

Yes, you have hit on another of the topics I was to address regarding Slackware
date-time; there are many more and they all work together. I really do not want
to fragment this discussion any more. I probably should not have replied here.

I have to finish some testing and hope to have a comprehensive post tying this all
together soon.

Quote:

Originally Posted by GazL

Xsane, thanks for the reply. If you have time, I'd appreciate it if you could give me an idea about the advantages you alluded to of using --hctosys over --systz.

Hey GazL,
Well, for starts, if you are using util-linux from Stable or Current then --systz is
broken. It was broken for the first 3 1/2 years it was in hwclock. It was fixed as of
v2.23 I believe, but I never liked the concept from the beginning. I plan to add a
--fast switch for --hctosys that should obsolete --systz.

As to the improvements in hctosys when v2.26 is released, as I mentioned above I would
rather not fragment this discussion any further and speak to all the date-time issues
at once. I hope you don't mind that... it is not officially available yet anyway.

GazL · 12-09-2014, 12:02 PM

Fair enough.

mlslk31 · 12-09-2014, 12:05 PM

--directisa can work when other options are broken...at least on x86 boat anchors. It's happened before and might happen again one day.

If it's such a point of contention, maybe it should be commented out and left there for a while. If I need it, I'll un-comment it and use it. I leave hwclock there in case Linux throws fits about the timers or the hardware clock, which has also happened before and might happen again one day. At least I know that one method is there to set the hardware clock.

Xsane · 12-09-2014, 03:49 PM

Quote:

Originally Posted by mlslk31

--directisa can work when other options are broken...at least on x86 boat anchors. It's happened before and might happen again one day.

If it's such a point of contention, maybe it should be commented out and left there for a while. If I need it, I'll un-comment it and use it. I leave hwclock there in case Linux throws fits about the timers or the hardware clock, which has also happened before and might happen again one day. At least I know that one method is there to set the hardware clock.

This thread is not against --directisa. In fact, a patch was recently submitted to
util-linux to remove hwclock-cmos.c (which implements --directisa), and I argued in
favor of keeping it.

This discussion is regarding that when udev was added to Slackware the test was not
updated and now Slackware ALWAYS uses --directisa. Direct access is not as dependable,
nor as precise, as using the RTC driver. It could cause any number of boot/shutdown
issues that do not even seem related to calling hwclock, because direct access to
hardware from user-space can do that.

I would also add that Sys-admins should be made aware when this is happening by adding
$CLOCK_OPT to the echo messages.

mlslk31 · 12-09-2014, 08:17 PM

Quote:

Originally Posted by Xsane

This thread is not against --directisa. In fact, a patch was recently submitted to
util-linux to remove hwclock-cmos.c (which implements --directisa), and I argued in
favor of keeping it.

This discussion is regarding that when udev was added to Slackware the test was not
updated and now Slackware ALWAYS uses --directisa. Direct access is not as dependable,
nor as precise, as using the RTC driver. It could cause any number of boot/shutdown
issues that do not even seem related to calling hwclock, because direct access to
hardware from user-space can do that.

I would also add that Sys-admins should be made aware when this is happening by adding
$CLOCK_OPT to the echo messages.

Ah, point taken! I'll have to look again at my own system, how it works, whether I run udev on boot (probably not) and whether it makes a difference. Thanks for the correction.

pdi · 12-10-2014, 04:27 AM

Xsane, thank you for your time and detailed reply.

Quote:

Originally Posted by Xsane

2008? What version are you using? This was fixed in v2.24 and will be further
shortened when v2.26 is released.

Ah! I'm to 'n' froing between a 13.37 and a 14.1 (both hwclock versions earlier than 2.24, but this fix is good news).

Let me highlight here two excerpts from hwclock(8) and adjtimex(8) regarding --directisa that are on the same wavelength and in agreement with Xsane's earlier post.

Quote:

hwclock(8)
On an ISA system, hwclock can directly access the "CMOS memory" registers that constitute the clock, by doing I/O to Ports 0x70 and 0x71. It does this with actual I/O instructions and consequently can only do it if running with superuser effective userid. [...]
This is a really poor method of accessing the clock, for all the reasons that user space programs are generally not supposed to do direct I/O and disable interrupts. Hwclock provides it because it is the only method available on ISA and Alpha systems which don't have working rtc device drivers available.

Quote:

adjtimex(8)
Note that the /dev/rtc interrupt method is more accurate, less sensible to perturbations due to system load, cleaner, cheaper, and is generally better than the direct access method. It is advisable to not use the --directisa switch, unless the CMOS chip or the motherboard don't properly provide the necessary interrupt.

Being on the subject of hwclock I have two questions, but I'll open a new thread and edit in the link here.

Edit: here's the link.