linux-kernel - Re: Does the kernel HPET support has problems or the hwclock from util-linux?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 Jul 2007 23:02:52 -0700
From:	David Brownell <david-b@...bell.net>
To:	rtc-linux@...glegroups.com
Cc:	Luca Tettamanti <kronos.it@...il.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: Does the kernel HPET support has problems or the hwclock from util-linux?

Not that I think it matters, but I understand that util-linux-ng
now has a 2.13-rc1 release out, so you're not using the latest
version of "hwclock".  That shouldn't affect HPET though.

That said, this situation is likely going to be a mess until
some new HPET support gets merged.  Issues include:

 - There are two drivers for the "cmos rtc" ... the legacy
   version (/dev/rtc), and the one using the new RTC framework
   ("rtc-cmos" driver, likely /dev/rtc0 on your system).

   To use the new one, you'll probably want the latest hwclock,
   which understands that not ever RTC uses /dev/rtc0.  (Or you
   can symlink /dev/rtc to /dev/rtc0 ...)

 - HPET itself has two modes.  I think of them as "break things
   mode" and "sane mode"; but I think they have official names
   that make the first one sound like it might be reasonable to
   use.  (Yet it isn't; and I suspect that's a big reason why
   HPET isn't enabled by default on most systems.)

   The difference is that the "break things" mode overrides
   the RTC interrupt line so the RTC can't use it, where the
   "sane" mode just routes HPET irqs like other IRQs.

 - Until the new HPET stuff gets merged (and I don't know what
   schedule that's on), Linux uses the "break things" mode.
   Which means that it breaks rtc-cmos ... but the legacy RTC
   driver has some fairly ugly hacks to cope with it.

   The new HPET stuff will among other things let HPET be used
   to provide per-CPU clockevent sources (assuming there are as
   many HPET instances as there are CPUs).  That's on top of
   other advantages, like "not breaking things".

So for the short term, I think there might be some set of config
options using the legacy (drivers/char/rtc.c) driver that will
let you enable HPET, with minimal breakage.  I don't know what
those options are, or what hwclock would need to do (or not do).

And longer term, the rtc framework version (rtc-cmos) will work
just fine with new HPET code, since Linux will be able to use
HPET in "sane mode" not "break things" mode.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/