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

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

[rae l]

from this address, I know util-linux-2.12r is the latest:
http://www.kernel.org/pub/linux/utils/util-linux/util-linux-2.12r.lsm

My Dell OptiPlex 320 has 4 HPET timers and no RTC, so the execution of
hwclock has errors:

gektop@tux ~ $ /sbin/hwclock --show
select() to /dev/rtc to wait for clock tick timed out
gektop@tux ~ $ /sbin/hwclock --version
hwclock from util-linux-2.12r

I wonder is there (kernel.org) a specific description of hwclock and util-linux?

-- 
Denis Cheng
Linux Application Developer

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

[Ismail Dönmez]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

On Monday 02 July 2007 13:15:40 rae l wrote:
> from this address, I know util-linux-2.12r is the latest:
> http://www.kernel.org/pub/linux/utils/util-linux/util-linux-2.12r.lsm

util-linux is now maintained @ http://userweb.kernel.org/~kzak/util-linux-ng/

/ismail

-- 
Perfect is the enemy of good

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

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

[Luca Tettamanti]

rae l <crquan@gmail.com> ha scritto:
> from this address, I know util-linux-2.12r is the latest:
> http://www.kernel.org/pub/linux/utils/util-linux/util-linux-2.12r.lsm
> 
> My Dell OptiPlex 320 has 4 HPET timers and no RTC, so the execution of
> hwclock has errors:
> 
> gektop@tux ~ $ /sbin/hwclock --show
> select() to /dev/rtc to wait for clock tick timed out
> gektop@tux ~ $ /sbin/hwclock --version
> hwclock from util-linux-2.12r

I think that the problem is that HPET and the CMOS RTC (list in CC)
share the same interrupt line.
I suppose that you should enable CONFIG_HPET_RTC_IRQ (my hardware has
the same "feature"); in this way /dev/rtc correcly reports that it
cannot deliver the interrupt (when HPET is enabled) and hwclock uses
direct ISA access.

Luca
-- 
Windows NT crashed.
I'm the Blue Screen of Death.
No one hears your screams.

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

[rae l]

On 7/3/07, Luca Tettamanti <kronos.it@gmail.com> wrote:
> rae l <crquan@gmail.com> ha scritto:
> > from this address, I know util-linux-2.12r is the latest:
> > http://www.kernel.org/pub/linux/utils/util-linux/util-linux-2.12r.lsm
> >
> > My Dell OptiPlex 320 has 4 HPET timers and no RTC, so the execution of
> > hwclock has errors:
> >
> > gektop@tux ~ $ /sbin/hwclock --show
> > select() to /dev/rtc to wait for clock tick timed out
> > gektop@tux ~ $ /sbin/hwclock --version
> > hwclock from util-linux-2.12r
>
> I think that the problem is that HPET and the CMOS RTC (list in CC)
> share the same interrupt line.
> I suppose that you should enable CONFIG_HPET_RTC_IRQ (my hardware has
> the same "feature"); in this way /dev/rtc correcly reports that it
> cannot deliver the interrupt (when HPET is enabled) and hwclock uses
> direct ISA access.
I searched the CONFIG_HPET_RTC_IRQ, it's conflict with
HPET_EMULATE_RTC, that I've enabled.
so while HPET_RTC_IRQ is the good way, EMULATE_RTC is a bad way.

>
> Luca
> --
> Windows NT crashed.
> I'm the Blue Screen of Death.
> No one hears your screams.
>


-- 
Denis Cheng
Linux Application Developer

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

[David Brownell]

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