hwclock can break the RTC

During startup hwclock.sh is run more then once. In rare cases they overlap causing the PC RTC to become non-functional. This is because the second copy of hwclock falls back to using IOPL and direct I/O instructions after it fails to open /dev/rtc (already owned by the first copy of hwclock). The RTC hardware is not designed for such uncontrolled access.

SRU Justification

Impact: RTC can become non-functional

Patch Description: Disable the fallback clause in hwclock.c. It should never use direct I/O access unless explicitly requested as a command line option.

Patch: attached

Test Case:

#!/bin/bash
let i=0
while [ $i -lt 10 ]
do
hwclock &
let i=$i+1
done

Uploaded Hardy util-linux_2.13.1-5ubuntu3

Uploaded Intrepid util-linux_2.13.1-5ubuntu2

On Thu, 2008-09-25 at 13:34 +0000, Tim Gardner wrote:

> During startup hwclock.sh is run more then once.
>
This, in of itself, is a bug ;)

Scott
--
Scott James Remnant
<email address hidden>

As I understand it, the fix is uploaded, so this bug should be closed.

This patch looks a little weird to me, as in it only seems to disable the fallback on i386? Shouldn't that happen on amd64, too?

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

this has been fixed for UNR, correct?

Can someone who was seeing this bug confirm that the package in hardy-proposed fixes the problem, please? I don't seem to be able to reproduce the original problem, including with an i386 chroot running on an amd64 system; what's the behavior I should expect to see with the buggy version?

Steve Langasek wrote:
> Can someone who was seeing this bug confirm that the package in hardy-
> proposed fixes the problem, please? I don't seem to be able to
> reproduce the original problem, including with an i386 chroot running on
> an amd64 system; what's the behavior I should expect to see with the
> buggy version?
>
Steve,

Just to confirm, it is impossible to reproduce the problem on a 64bit
system, the actual hardware difference makes it quite impossible. The
bug can only be reproduced on true 32 bit hardware systems.

Cheers,

David
--
David Mandala <davidm at canonical dot com>
http://www.canonical.com/ Public Key id: 45B2D952
Murphy TX, 75094 +1.214.774.2569 O +1.972.693.4007 C

David is correct this is only an i386 problem.

I can confirm that on an i386 machine, repeatedly running the hwclock from util-linux in hardy-updates, version 2.13.1-5ubuntu2, can corrupt the rtc clock (enough so that the hw clock is corrupted). The version of util-linux in hardy-proposed, 2.13.1-5ubuntu3, provides a version that does not.

One oddity I do see is that the first time I run the test loop, I get slightly different output than subsequent runs through the loop. On subsequent runs, all instances of hwclock besides the first to be run by the loop report to stderr:

  Cannot access the Hardware Clock via any known method.
  Use the --debug option to see the details of our search for an access method.

However, the *first* time the loop is run after a fresh reboot, some of the hwclock executions will report to stderr:

  hwclock: open() of /dev/rtc failed, errno=16: Device or resource busy.

Running with --debug shows that the first time failure runs generate the following output:

  hwclock from util-linux-ng 2.13.1
  Using /dev interface to clock.
  Last drift adjustment done at 1231405767 seconds after 1969
  Last calibration done at 1231405767 seconds after 1969
  Hardware clock is on UTC time
  Assuming hardware clock is kept in UTC time.
  Waiting for clock tick...
  ...got clock tick
  hwclock: open() of /dev/rtc failedhwclock: open() of /dev/rtc failed, errno=16: Device or resource busy.

And that subsequent failure runs generate:

  hwclock from util-linux-ng 2.13.1
  No usable clock interface found.
  hwclock: Open of /dev/rtc failed, errno=16: Device or resource busy.
  Cannot access the Hardware Clock via any known method.

It's unclear why this happens, but at least with the -proposed util-linux, multiple hwclocks don't seem to corrupt the rtc, it's definitely no longer making the iopl() call. Marking verification-done

This bug was fixed in the package util-linux - 2.13.1-5ubuntu3

---------------
util-linux (2.13.1-5ubuntu3) hardy-proposed; urgency=low

  * Disable the fallback clause when /dev/rtc cannot be opened. hwclock
    should not access the x86 RTC using I/O instructions unless explicitly
    requested from the command line (--directisa).
    LP: #274402

 -- Tim Gardner <email address hidden> Thu, 25 Sep 2008 07:51:08 -0600