From: "Mika Penttilä" <mika.penttila@kolumbus.fi>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Andi Kleen <ak@muc.de>, Om Narasimhan <om.turyx@gmail.com>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
linux-kernel@vger.kernel.org, randy.dunlap@oracle.com,
clemens@ladisch.de, bob.picco@hp.com
Subject: Re: HPET : Legacy Routing Replacement Enable - 3rd try.
Date: Fri, 27 Oct 2006 09:29:44 +0300 [thread overview]
Message-ID: <4541A758.9010504@kolumbus.fi> (raw)
In-Reply-To: <20061027055708.GA20270@suse.cz>
Vojtech Pavlik wrote:
> On Fri, Oct 27, 2006 at 04:42:38AM +0200, Andi Kleen wrote:
>
>
>> On Wed, Oct 25, 2006 at 02:20:22PM -0700, Om Narasimhan wrote:
>>
>>> I tested against five different bioses (some with 8132, some with
>>> CK-804 ..etc) and I observed three different patterns.
>>>
>>> 1. HW is LRR capable, HPET ACPI it is 1, timer interrupt is on INT2.
>>> Before the fix: Linux cannot get timer interrupts on INT0, goes for ACPI
>>> timer.
>>>
>> What ACPI timer? I don't think we have any fallback for int 0.
>>
>> Not sure what you mean with INT2. Pin2 on ioapic 0 perhaps?
>>
>>
>>> After the fix : Works fine. This is according to hpet spec.
>>>
>> On what exact motherboard was that?
>>
>>
>>> To handle case 3, I removed all references to acpi_hpet_lrr, explained
>>> this case in the code and decided to solely rely on the command line
>>> parameter for LRR capability. Rational for this approach is ,
>>>
>> This means the systems which you said fixes this would need the command
>> line parameter to work?
>>
>>
>>> 1. At present, there are not many BIOSes which implement LRR (correctly)
>>> 2. People would see the bootup message (MP-BIOS bug...) if LRR is
>>> enabled and no timer interrupt on INT0. They can pass the hpet_lrr=1
>>> to make everything work fine.
>>> Is it the right approach?
>>>
>> Generally we try to work everywhere without command line parameter
>> unless something is terminally broken.
>>
>
> JFYI: The new per-cpu timekeeping code doesn't need the HPET legacy bit,
> thus not replacing IRQ0 (PIT) and IRQ13 (RTC). It still can do that, but
> will work just as well without it.
>
>
There seems to be lot of confusion here. Current code isn't using hpet
as tick source if legacy is not supported. This patch adds
hpet_lrr_force but it's not clear how it interacts with hpet_use_timer -
in some places it is hpet_use_timer and some (hpet_use_timer &&
hpet_lrr_force).
The timer is routed to ioapic pin 2 which is irq0 with source override.
With this patch with hpet_lrr_force=1 timer irq is set to 2 for x86_64
and 0 for i386, that can't be right?
--Mika
next prev parent reply other threads:[~2006-10-27 6:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-25 20:21 HPET : Legacy Routing Replacement Enable - 3rd try Pallipadi, Venkatesh
2006-10-25 21:20 ` Om Narasimhan
2006-10-27 2:42 ` Andi Kleen
2006-10-27 5:57 ` Vojtech Pavlik
2006-10-27 6:29 ` Mika Penttilä [this message]
2006-10-27 7:03 ` Vojtech Pavlik
2006-10-27 22:31 ` Om Narasimhan
2006-10-27 6:11 ` Om Narasimhan
2006-10-27 14:59 ` Andi Kleen
2006-10-28 17:49 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2006-10-25 7:13 Om Narasimhan
2006-10-25 18:53 ` Andi Kleen
2006-10-25 20:09 ` Om Narasimhan
2006-10-25 20:13 ` Om Narasimhan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4541A758.9010504@kolumbus.fi \
--to=mika.penttila@kolumbus.fi \
--cc=ak@muc.de \
--cc=bob.picco@hp.com \
--cc=clemens@ladisch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=om.turyx@gmail.com \
--cc=randy.dunlap@oracle.com \
--cc=venkatesh.pallipadi@intel.com \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox