hwclock can break the RTC

Bug #274402 reported by Tim Gardner on 2008-09-25
6
Affects Status Importance Assigned to Milestone
Belmont
High
Steve Magoun
Ubuntu Netbook Remix
High
Debbie Beliveau
util-linux (Ubuntu)
High
Tim Gardner
Hardy
High
Tim Gardner
Intrepid
High
Tim Gardner

Bug Description

Binary package hint: util-linux

If multiple copies of hwclock are run simultaneously the RTC can become non-functional.

TESTCASE:
$ sudo bash -c 'for ((i = 0; i < 10; i++)) ; do ( hwclock &) ; done'

Tim Gardner (timg-tpi) wrote :

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.

Tim Gardner (timg-tpi) wrote :

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

Tim Gardner (timg-tpi) wrote :

Uploaded Hardy util-linux_2.13.1-5ubuntu3

Changed in util-linux:
assignee: nobody → timg-tpi
importance: Undecided → High
milestone: none → ubuntu-8.04.2
status: New → Fix Committed
Tim Gardner (timg-tpi) wrote :

Uploaded Intrepid util-linux_2.13.1-5ubuntu2

Changed in util-linux:
assignee: nobody → timg-tpi
importance: Undecided → Medium
milestone: none → ubuntu-8.10-beta
status: New → Fix Committed
importance: Medium → High

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>

Steve Langasek (vorlon) wrote :

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

Changed in util-linux:
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

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?

Martin Pitt (pitti) wrote :

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!

Changed in belmont:
assignee: nobody → smagoun
importance: Undecided → High
milestone: none → rc2
status: New → Confirmed
Bill Filler (bfiller) wrote :

this has been fixed for UNR, correct?

Changed in netbook-remix:
assignee: nobody → debbie-beliveau
importance: Undecided → High
milestone: none → 1.0.1
status: New → Triaged
Bill Filler (bfiller) on 2008-11-10
Changed in netbook-remix:
milestone: 1.0.1 → 1.2.0
Steve Langasek (vorlon) 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?

David Mandala (davidm) wrote :

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

Pete Graner (pgraner) wrote :

David is correct this is only an i386 problem.

Steve Beattie (sbeattie) wrote :

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

description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in util-linux:
status: Fix Committed → Fix Released
Changed in belmont:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers