Bug 11111 - Explanation of HPET_RTC_IRQ confusing, leading to bad configs
Explanation of HPET_RTC_IRQ confusing, leading to bad configs
Status: CLOSED WILL_NOT_FIX
Product: Drivers
Classification: Unclassified
Component: Other
All Linux
: P1 normal
Assigned To: drivers_other
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-17 13:55 UTC by W Unruh
Modified: 2010-01-19 19:48 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.26
Tree: Mainline
Regression: No


Attachments
remove that obsolete option (1.60 KB, patch)
2008-07-18 21:10 UTC, David Brownell
Details | Diff

Description W Unruh 2008-07-17 13:55:40 UTC
The explanation of the HPET_RTC_IRQ config variable in drivers/char/Kconfig is very confusing. While the recent changes to the default in 2.6.26 helps, the explanation
     If you say Y here, you will disable RTC_IRQ in drivers/char/rtc.c. It
     is assumed the platform called hpet_alloc with the RTC IRQ values for
     the HPET timers.

makes it seem that a Y answer disables RTC's ability to handle inpterrupts entirely. What is I assume meant is that if HPET_EMULATE_RTC is enabled, then the HPET takes over the interrupts and handles the RTC interrupts. In that case answering Y here is the proper thing to do a as otherwise there is a battle between the HPET and the RTC code over the interrupts and on certain hardware, this can freeze the system or programs using the RTC. 

The second sentence could be changed to something like

If Y is answered it is assumed that the HPET code has taken over the RTC interrupt handling under the HPET_EMULATE_RTC or that the platform called hpet_alloc to tell the hpet code to handle the rtc interrupts.

This confusion is severe since for example Mandriva 2008.1 has HPET_EMULATE_RTC as Y but HPET_RTC_IRQ is no, leading to problems on certain PC harware.
Comment 1 David Brownell 2008-07-17 16:22:17 UTC
The comment actually looks correct, in terms of the legacy RTC driver.  It doesn't look like drivers/char/rtc.c actually cares whether the target system really has HPET hardware or not ... if that support is built in, the legacy RTC will only use IRQs provided by the HPET.

I think that Mandriva release should either not enable HPET, or should be using more current rtc-cmos code instead of that legacy driver.

I'll be sending a patch to eliminate this obsolete Kconfig option.
Comment 2 David Brownell 2008-07-18 21:10:59 UTC
Created attachment 16884 [details]
remove that obsolete option

Removes that needless Kconfig option.  Note that the legacy RTC code has a misfeature:  if HPET is enabled but not actually present, its IRQs don't
work except for the UIE emulation.
Comment 3 W Unruh 2008-07-19 10:14:51 UTC
The relation between hpet and rtc (new or old) is still obscure to me. 
The hpet driver intercepts and deals with all int 8 interrupts if it is
installed. Does this mean that if the HPET driver is installed, one MUST
also use the HPET_EMULATES_RTC in order for the interupts for the rtc to
work? Or, if one installs both the HPET driver and the rtc-cmos driver (
and lets assume the motherboard has a tradition rtc on it which the
rtc-cmos can use), do things work without the HPET_EMULATES_RTC?

I realise that my system is a 2.6.24 system and things have changed by the
2.6.27 kernel, but the evidence in the 2.6.24 kernel is that on SOME
motherboards, the rtc-cmos code does not work with the hpet code-- the
interrupts are not actually seen (my system DG33BU Intel motherboard),
  the rtc is very flaky (times changing
randomly-- from other reports on usenet or in the Mandriva bugs).

So, should HPET_EMULATES_RTC be automatically switched on if HPET driver
is included, or is it supposed to be turned off if the rtc-cmos driver is
loaded.

Note that this is critial for distributions, since they cannot examine each
machine they are run on and recompile the kernel for that particular
machine. And if the HPET_EMULATES_RTC is to work, the HPET driver MUST be
compiled into the kernel and not as a module.

Ie, the interaction between HPET and the new rtc drivers is still obscure
to me, and I suspect many others. (Note that this also means that both the
hpet.txt and rtc.txt Documentation really need some rewriting)

On Fri, 18 Jul 2008, bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=11111
>
>
>
>
>
> ------- Comment #2 from dbrownell@users.sourceforge.net  2008-07-18 21:10 -------
> Created an attachment (id=16884)
> --> (http://bugzilla.kernel.org/attachment.cgi?id=16884&action=view)
> remove that obsolete option
>
> Removes that needless Kconfig option.  Note that the legacy RTC code has a
> misfeature:  if HPET is enabled but not actually present, its IRQs don't
> work except for the UIE emulation.
>
>
>

Comment 4 David Brownell 2008-07-29 12:31:56 UTC
> The relation between hpet and rtc (new or old) is still obscure to me. 
> The hpet driver intercepts and deals with all int 8 interrupts if it is
> installed. Does this mean that if the HPET driver is installed, one MUST
> also use the HPET_EMULATES_RTC in order for the interupts for the rtc to
> work? 

Depends what you mean by "installed".  If it's configured into the kernel
the legacy RTC driver becomes incapable of handling IRQs by itself, so you
MUST run on HPET-aware hardware ... that's true regardless of whether that
HPET driver is active at runtime (which is what I'd mean by "installed").


> Or, if one installs both the HPET driver and the rtc-cmos driver (
> and lets assume the motherboard has a tradition rtc on it which the
> rtc-cmos can use), do things work without the HPET_EMULATES_RTC?

The rtc-cmos driver checks to see if HPET is *active* so it works
regardless of whether HPET is (a) not configured, or (b1) configured
but inactive, or (b2) configured and active.  That is, on current
kernels ... some bugs have been fixed in that area since 2.6.24,
which as I recall didn't have HPET support in rtc-cmos.


> So, should HPET_EMULATES_RTC be automatically switched on if HPET driver
> is included,

See above.  Current kernels *ONLY* support the broken "legacy replacement
mode" IRQ routing, which implies HPET_EMULATES_RTC with HPET configured.

On a 2.6.24 kernel I'd probably suggest just not enabling HPET, since
I don't know what works there (or doesn't).


Note You need to log in before you can comment on or make changes to this bug.