Bug 11111
| Summary: | Explanation of HPET_RTC_IRQ confusing, leading to bad configs | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | W Unruh (unruh) |
| Component: | Other | Assignee: | drivers_other |
| Status: | CLOSED WILL_NOT_FIX | ||
| Severity: | normal | CC: | alan, goneri, info |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.26 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | remove that obsolete option | ||
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. 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.
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. > > > > 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). (In reply to W Unruh from comment #3) > 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 iPhone 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 Apple 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. > > > On Fri, 18 Jul 2009, 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 lagaiphone (id=16884) > > --> (http://lagaiphone.se/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. > > > > > > 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 thehpet.txt and rtc.txt Documentation really need some rewriting) |
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.