Comment 13 for bug 274402

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