I have incorporated Randy's comments.
CC-ing HPET developers.
Patch here.
Signed-off-by: Om Narasimhan <[email protected]>
Documentation/hpet.txt | 56 +++++++++++++++++++++++++++++++++++
Documentation/kernel-parameters.txt | 9 ++++++
arch/i386/kernel/acpi/boot.c | 18 +++++++++++
arch/i386/kernel/time_hpet.c | 3 +-
arch/x86_64/kernel/time.c | 16 +++++++---
include/asm-x86_64/hpet.h | 1 +
include/linux/acpi.h | 1 +
include/linux/hpet.h | 7 ++++
8 files changed, 105 insertions(+), 6 deletions(-)
diff --git a/Documentation/hpet.txt b/Documentation/hpet.txt
index b7a3dc3..ca62b69 100644
--- a/Documentation/hpet.txt
+++ b/Documentation/hpet.txt
@@ -298,3 +298,59 @@ members of the hpet_task structure befor
hpet_control simply vectors to the hpet_ioctl routine and has the same
commands and respective arguments as the user API. hpet_unregister
is used to terminate usage of the HPET timer reserved by hpet_register.
+
+ HPET Legacy Replacement Route option (hpet_lrr)
+
+HPET is capable of replacing the IRQ0 (connected INT0 PIN) routing for
+timer interrupt. The capability register (at offset 0 of HPET
+base address) has a bit specifying if HPET chip is capbale of doing
+this. OS can read the bit either from HW or ACPI table. (HPET ACPI
+description table -> Event Timer block -> bit 15, page 30 of HPET
+spec). Ideally (I think so!) BIOS should set the ACPI table than letting
+the OS read H/W, which gives the BIOS a way to configure either legacy
+or Legacy replacement modes.
+
+Typically the motherboard has BIOS configured / hardwired IRQ0 to INT0
+(pin of APIC) connection. Linux assumes IRQ0 connected to INT0 unless it is
+supplied using an override parameter in the MPTable. Some NVidia chipsets /
+BIOS initialization code had configured to override IRQ0 -> INT0 connection
+and later a parameter was introduce (acpi_skip_timer_override) to get IRQ0 ->
+INT0 connection right.
+
+But a number of bioses (both phoenix and AMI) are not working as
+expected. (I have an AMI BIOS which sets ACPI table bit 15 to 0 and then
+connect IRQ0 -> INT2 internally, Another bios I have sets the ACPI table bit
+15 to 0, but does not connect IRQ0 -> INT2. Both would result in a hang in
+calibrate_delay() since there would not be any timer interrupts So I have
+provided a command line parameter which overrides
+the BIOS ACPI entry. So, irrespctive of the BIOS' HPET ACPI Descriptor
+table settings, if the parameter hpet_lrr=[0,1] is specified, it takes
+precedence.
+
+* When to use this parameter?
+
+Some latest versions CK-804 (e.g),(Actually the code initializes the
+CK804 in the BIOS), would correctly set the HPET such that there would not
+be any interrupts on INT0. Linux does not handle this situation very well
+because in linux, if HW is LRR capable, it is enabled from the OS. Still the
+timer interrupt handler is setup for IRQ0. Under this situation, you can
+force the parameter hpet_lrr=1, so that IRQ2 is timer interrupts.
+
+[root@mophia ~]# cat /proc/interrupts | grep 2:
+ 2: 163 0 0 0 1 7
+207 955341 IO-APIC-edge timer
+
+[root@mophia ~]# uptime
+ 22:52:38 up 15 min, 2 users, load average: 0.00, 0.01, 0.02
+
+[root@mophia ~]# dmesg | grep -i MP-BIOS
+
+For 15 mts (900 sec), around 95k interrupts on timer looks kinda fine.
+
+* Known Bugs:
+I have tested it only with Nvidia CK-804. There seem to be some kind of timing
+issue between enabling the HPET with LRR set and start of tinerrupts. As a
+result of which, calibrate_delay() hangs because there are no interrupts. If
+you run into such a case, pass lpj=<bogomips * 500> as a work around. i.e, if
+your bogomips is 5000, pass lpj=2500000
+
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index dd00fd5..7916ff5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -366,6 +366,15 @@ and is between 256 and 4096 characters.
hpet= [IA-32,HPET] option to disable HPET and use PIT.
Format: disable
+ hpet_lrr= [IA32,X86_64,HPET] Option to enable/disable the HPET
+ Legacy replacement route. Please read Documentation/
+ hpet.txt for more info.
+ Format : {"0" | "1"}
+ 0 -> Disables Legacy Route Replacement. (Default)
+ 1 -> Enables LRR. Please consult your BIOS
+ documentation before doing this.
+
+
cm206= [HW,CD]
Format: { auto | [<io>,][<irq>] }
diff --git a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c
index ab974ff..2c5a798 100644
--- a/arch/i386/kernel/acpi/boot.c
+++ b/arch/i386/kernel/acpi/boot.c
@@ -82,6 +82,17 @@ EXPORT_SYMBOL(acpi_strict);
acpi_interrupt_flags acpi_sci_flags __initdata;
int acpi_sci_override_gsi __initdata;
int acpi_skip_timer_override __initdata;
+/* HPET Legacy routing replacement option passed through ACPI Table */
+int acpi_hpet_lrr;
+/* cmdline opt. for faulty bioses not setting ACPI HPET entry right */
+int hpet_lrr_force;
+
+static int hpet_lrr_setup (char *str)
+{
+ get_option(&str, &hpet_lrr_force);
+ return 1;
+}
+__setup ("hpet_lrr=", hpet_lrr_setup);
#ifdef CONFIG_X86_LOCAL_APIC
static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
@@ -669,6 +680,13 @@ #define HPET_RESOURCE_NAME_SIZE 9
"HPET %u", hpet_tbl->number);
hpet_res->end = (1 * 1024) - 1;
}
+ acpi_hpet_lrr = (hpet_tbl->id & ACPI_HPET_LRR_CAP) ? 1 : 0;
+ /* Print a message about the bios HPET ACPI Desc Table passed.
+ * LRR bit should not be set in the table unless IRQ0->INT2 is
+ * connected. But BIOS may be faulty ...
+ */
+ printk(KERN_INFO PREFIX "HPET id: %#x. ACPI LRR bit %s SET\n",
+ hpet_tbl->id, acpi_hpet_lrr ? "": "NOT");
#ifdef CONFIG_X86_64
vxtime.hpet_address = hpet_tbl->addr.addrl |
diff --git a/arch/i386/kernel/time_hpet.c b/arch/i386/kernel/time_hpet.c
index 1a2a979..01b2f67 100644
--- a/arch/i386/kernel/time_hpet.c
+++ b/arch/i386/kernel/time_hpet.c
@@ -94,7 +94,8 @@ static int hpet_timer_stop_set_go(unsign
* Go!
*/
cfg = hpet_readl(HPET_CFG);
- if (hpet_use_timer)
+ /* Ideally the following should be &&(acpi_hpet_lrr || hpet_lrr_force) */
+ if (hpet_use_timer && hpet_lrr_force)
cfg |= HPET_CFG_LEGACY;
cfg |= HPET_CFG_ENABLE;
hpet_writel(cfg, HPET_CFG);
diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
index 1ba5a44..0f5d990 100644
--- a/arch/x86_64/kernel/time.c
+++ b/arch/x86_64/kernel/time.c
@@ -46,9 +46,6 @@ #include <asm/apic.h>
#ifdef CONFIG_CPU_FREQ
static void cpufreq_delayed_get(void);
#endif
-extern void i8254_timer_resume(void);
-extern int using_apic_timer;
-
static char *timename = NULL;
DEFINE_SPINLOCK(rtc_lock);
@@ -783,7 +780,10 @@ static int hpet_timer_stop_set_go(unsign
HPET_TN_32BIT, HPET_T0_CFG);
hpet_writel(hpet_tick, HPET_T0_CMP); /* next interrupt */
hpet_writel(hpet_tick, HPET_T0_CMP); /* period */
- cfg |= HPET_CFG_LEGACY;
+ /* Ideal value (acpi_hpet_lrr || hpet_lrr_force) */
+ if (hpet_lrr_force)
+ cfg |= HPET_CFG_LEGACY;
+
}
/*
* Go!
@@ -887,6 +887,7 @@ time_cpu_notifier(struct notifier_block
void __init time_init(void)
{
+ int timer_irq = 0;
if (nohpet)
vxtime.hpet_address = 0;
@@ -906,6 +907,10 @@ void __init time_init(void)
tick_nsec = TICK_NSEC_HPET;
cpu_khz = hpet_calibrate_tsc();
timename = "HPET";
+ /* Ideal value is (acpi_hpet_lrr || hpet_lrr_force) */
+ if (hpet_lrr_force)
+ timer_irq = HPET_TIMER_LRR_IRQ;
+
#ifdef CONFIG_X86_PM_TIMER
} else if (pmtmr_ioport && !vxtime.hpet_address) {
vxtime_hz = PM_TIMER_FREQUENCY;
@@ -924,7 +929,8 @@ #endif
vxtime.tsc_quot = (USEC_PER_MSEC << US_SCALE) / cpu_khz;
vxtime.last_tsc = get_cycles_sync();
set_cyc2ns_scale(cpu_khz);
- setup_irq(0, &irq0);
+ printk(KERN_WARNING PREFIX "Registering Timer IRQ = %d\n", timer_irq);
+ setup_irq(timer_irq, &irq0);
hotcpu_notifier(time_cpu_notifier, 0);
time_cpu_notifier(NULL, CPU_ONLINE, (void *)(long)smp_processor_id());
diff --git a/include/asm-x86_64/hpet.h b/include/asm-x86_64/hpet.h
index b390984..2d18b39 100644
--- a/include/asm-x86_64/hpet.h
+++ b/include/asm-x86_64/hpet.h
@@ -37,6 +37,7 @@ #define HPET_CFG_ENABLE 0x001
#define HPET_CFG_LEGACY 0x002
#define HPET_LEGACY_8254 2
#define HPET_LEGACY_RTC 8
+#define HPET_TIMER_LRR_IRQ 2
#define HPET_TN_LEVEL 0x0002
#define HPET_TN_ENABLE 0x0004
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 2b0c955..62dab08 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -220,6 +220,7 @@ enum acpi_interrupt_id {
};
#define ACPI_SPACE_MEM 0
+#define ACPI_HPET_LRR_CAP 0x8000
struct acpi_gen_regaddr {
u8 space_id;
diff --git a/include/linux/hpet.h b/include/linux/hpet.h
index 707f7cb..6c31473 100644
--- a/include/linux/hpet.h
+++ b/include/linux/hpet.h
@@ -119,6 +119,13 @@ int hpet_register(struct hpet_task *, in
int hpet_unregister(struct hpet_task *);
int hpet_control(struct hpet_task *, unsigned int, unsigned long);
+
+/* these are used by time.c */
+extern void i8254_timer_resume(void);
+extern int using_apic_timer;
+extern int acpi_hpet_lrr;
+extern int hpet_lrr_force;
+
#endif /* __KERNEL__ */
struct hpet_info {
Om Narasimhan <[email protected]> writes:
> I have incorporated Randy's comments.
> CC-ing HPET developers.
Can you please:
- split it up in i386/x86-64/generic
- write a full description for each piece
- give a rationale why you're implementing this
Thanks
-Andi
Hi,
Thanks for comments. I have split the patches into three.
Rationale:
Some enterprise servers' (e.g, SunFire 4600 series) BIOS sets up the
IRQ0 -> INT2 mapping as per HPET specifications. (BIOS engineers
explained that this routing is required for another major commercial
OS's forthcoming version to work).
Linux currently assumes timer interrupt is at IRQ0 (implying
IRQ0->INT0) connection setup by the bios. In this scenario, IRQ0 would
not generate any interrupts and we get the following message :
........
Boot done.
..MP-BIOS bug: 8254 timer not connected to IO-APIC
failed.
timer doesn't work through the IO-APIC - disabling NMI Watchdog!
Using local APIC timer interrupts.
........
When AMD Powernow (TM) is enabled, APIC interrupt does not work as
expected and we observe strange behaviour like lost ticks...etc and
occasional crashes.
I expect that more and more BIOSes would start implementing the
routing as per specifications and linux kernel might face this problem
sooner or later.
Regards,
Om.
Patch 01/03 : Arch specific (i386 and x86_64)
Signed-Off-by : Om Narasimhan <[email protected]>
arch/i386/kernel/acpi/boot.c | 18 ++++++++++++++++++
arch/i386/kernel/time_hpet.c | 3 ++-
arch/x86_64/kernel/time.c | 16 +++++++++++-----
3 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c
index 92f79cd..3d30e2f 100644
--- a/arch/i386/kernel/acpi/boot.c
+++ b/arch/i386/kernel/acpi/boot.c
@@ -82,6 +82,17 @@ EXPORT_SYMBOL(acpi_strict);
acpi_interrupt_flags acpi_sci_flags __initdata;
int acpi_sci_override_gsi __initdata;
int acpi_skip_timer_override __initdata;
+/* HPET Legacy routing replacement option passed through ACPI Table */
+int acpi_hpet_lrr;
+/* cmdline opt. for faulty bioses not setting ACPI HPET entry right */
+int hpet_lrr_force;
+
+static int hpet_lrr_setup (char *str)
+{
+ get_option(&str, &hpet_lrr_force);
+ return 1;
+}
+__setup ("hpet_lrr=", hpet_lrr_setup);
#ifdef CONFIG_X86_LOCAL_APIC
static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
@@ -669,6 +680,13 @@ #define HPET_RESOURCE_NAME_SIZE 9
"HPET %u", hpet_tbl->number);
hpet_res->end = (1 * 1024) - 1;
}
+ acpi_hpet_lrr = (hpet_tbl->id & ACPI_HPET_LRR_CAP) ? 1 : 0;
+ /* Print a message about the bios HPET ACPI Desc Table passed.
+ * LRR bit should not be set in the table unless IRQ0->INT2 is
+ * connected. But BIOS may be faulty ...
+ */
+ printk(KERN_INFO PREFIX "HPET id: %#x. ACPI LRR bit %s SET\n",
+ hpet_tbl->id, acpi_hpet_lrr ? "": "NOT");
#ifdef CONFIG_X86_64
vxtime.hpet_address = hpet_tbl->addr.addrl |
diff --git a/arch/i386/kernel/time_hpet.c b/arch/i386/kernel/time_hpet.c
index 1a2a979..01b2f67 100644
--- a/arch/i386/kernel/time_hpet.c
+++ b/arch/i386/kernel/time_hpet.c
@@ -94,7 +94,8 @@ static int hpet_timer_stop_set_go(unsign
* Go!
*/
cfg = hpet_readl(HPET_CFG);
- if (hpet_use_timer)
+ /* Ideally the following should be &&(acpi_hpet_lrr || hpet_lrr_force) */
+ if (hpet_use_timer && hpet_lrr_force)
cfg |= HPET_CFG_LEGACY;
cfg |= HPET_CFG_ENABLE;
hpet_writel(cfg, HPET_CFG);
diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
index 1ba5a44..0f5d990 100644
--- a/arch/x86_64/kernel/time.c
+++ b/arch/x86_64/kernel/time.c
@@ -46,9 +46,6 @@ #include <asm/apic.h>
#ifdef CONFIG_CPU_FREQ
static void cpufreq_delayed_get(void);
#endif
-extern void i8254_timer_resume(void);
-extern int using_apic_timer;
-
static char *timename = NULL;
DEFINE_SPINLOCK(rtc_lock);
@@ -783,7 +780,10 @@ static int hpet_timer_stop_set_go(unsign
HPET_TN_32BIT, HPET_T0_CFG);
hpet_writel(hpet_tick, HPET_T0_CMP); /* next interrupt */
hpet_writel(hpet_tick, HPET_T0_CMP); /* period */
- cfg |= HPET_CFG_LEGACY;
+ /* Ideal value (acpi_hpet_lrr || hpet_lrr_force) */
+ if (hpet_lrr_force)
+ cfg |= HPET_CFG_LEGACY;
+
}
/*
* Go!
@@ -887,6 +887,7 @@ time_cpu_notifier(struct notifier_block
void __init time_init(void)
{
+ int timer_irq = 0;
if (nohpet)
vxtime.hpet_address = 0;
@@ -906,6 +907,10 @@ void __init time_init(void)
tick_nsec = TICK_NSEC_HPET;
cpu_khz = hpet_calibrate_tsc();
timename = "HPET";
+ /* Ideal value is (acpi_hpet_lrr || hpet_lrr_force) */
+ if (hpet_lrr_force)
+ timer_irq = HPET_TIMER_LRR_IRQ;
+
#ifdef CONFIG_X86_PM_TIMER
} else if (pmtmr_ioport && !vxtime.hpet_address) {
vxtime_hz = PM_TIMER_FREQUENCY;
@@ -924,7 +929,8 @@ #endif
vxtime.tsc_quot = (USEC_PER_MSEC << US_SCALE) / cpu_khz;
vxtime.last_tsc = get_cycles_sync();
set_cyc2ns_scale(cpu_khz);
- setup_irq(0, &irq0);
+ printk(KERN_WARNING PREFIX "Registering Timer IRQ = %d\n", timer_irq);
+ setup_irq(timer_irq, &irq0);
hotcpu_notifier(time_cpu_notifier, 0);
time_cpu_notifier(NULL, CPU_ONLINE, (void *)(long)smp_processor_id());
Patch 03/03 : Documentation
------
Signed-Off-by : Om Narasimhan <[email protected]>
Documentation/hpet.txt | 56 +++++++++++++++++++++++++++++++++++
Documentation/kernel-parameters.txt | 9 ++++++
2 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/Documentation/hpet.txt b/Documentation/hpet.txt
index b7a3dc3..0b1b9d9 100644
--- a/Documentation/hpet.txt
+++ b/Documentation/hpet.txt
@@ -298,3 +298,59 @@ members of the hpet_task structure befor
hpet_control simply vectors to the hpet_ioctl routine and has the same
commands and respective arguments as the user API. hpet_unregister
is used to terminate usage of the HPET timer reserved by hpet_register.
+
+ HPET Legacy Replacement Route option (hpet_lrr)
+
+HPET is capable of replacing the IRQ0 (connected INT0 PIN) routing for
+timer interrupt. The capability register (at offset 0 of HPET
+base address) has a bit specifying if HPET chip is capbale of doing
+this. OS can read the bit either from HW or ACPI table. (HPET ACPI
+description table -> Event Timer block -> bit 15, page 30 of HPET
+spec). Ideally (I think so!) BIOS should set the ACPI table than letting
+the OS read H/W, which gives the BIOS a way to configure either legacy
+or Legacy replacement modes.
+
+Typically the motherboard has BIOS configured / hardwired IRQ0 to INT0
+(pin of APIC) connection. Linux assumes IRQ0 connected to INT0 unless it is
+supplied using an override parameter in the MPTable. Some NVidia chipsets /
+BIOS initialization code had configured to override IRQ0 -> INT0 connection
+and later a parameter was introduce (acpi_skip_timer_override) to get IRQ0 ->
+INT0 connection right.
+
+But a number of bioses (both phoenix and AMI) are not working as
+expected. (I have an AMI BIOS which sets ACPI table bit 15 to 0 and then
+connect IRQ0 -> INT2 internally, Another bios I have sets the ACPI table bit
+15 to 0, but does not connect IRQ0 -> INT2. Both would result in a hang in
+calibrate_delay() since there would not be any timer interrupts So I have
+provided a command line parameter which overrides
+the BIOS ACPI entry. So, irrespctive of the BIOS' HPET ACPI Descriptor
+table settings, if the parameter hpet_lrr=[0,1] is specified, it takes
+precedence.
+
+* When to use this parameter?
+
+Some latest versions CK-804 (e.g),(Actually the code initializes the
+CK804 in the BIOS), would correctly set the HPET such that there would not
+be any interrupts on INT0. Linux does not handle this situation very well
+because in linux, if HW is LRR capable, it is enabled from the OS. Still the
+timer interrupt handler is setup for IRQ0. Under this situation, you can
+force the parameter hpet_lrr=1, so that IRQ2 is timer interrupts.
+
+[root@mophia ~]# cat /proc/interrupts | grep 2:
+ 2: 163 0 0 0 1 7
+207 955341 IO-APIC-edge timer
+
+[root@mophia ~]# uptime
+ 22:52:38 up 15 min, 2 users, load average: 0.00, 0.01, 0.02
+
+[root@mophia ~]# dmesg | grep -i MP-BIOS
+
+For 15 mts (900 sec), around 95k interrupts on timer looks kinda fine.
+
+* Known Bugs:
+I have tested it only with Nvidia CK-804. There seem to be some kind of timing
+issue between enabling the HPET with LRR set and start of tinerrupts. As a
+result of which, calibrate_delay() hangs because there are no interrupts. If
+you run into such a case, pass lpj=<bogomips * 500> as a work around. i.e, if
+your bogomips is 5000, pass lpj=2500000
+
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index ff571f9..36e469c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -366,6 +366,15 @@ and is between 256 and 4096 characters.
hpet= [IA-32,HPET] option to disable HPET and use PIT.
Format: disable
+ hpet_lrr= [IA32,X86_64,HPET] Option to enable/disable the HPET
+ Legacy replacement route. Please read Documentation/
+ hpet.txt for more info.
+ Format : {"0" | "1"}
+ 0 -> Disables Legacy Route Replacement. (Default)
+ 1 -> Enables LRR. Please consult your BIOS
+ documentation before doing this.
+
+
cm206= [HW,CD]
Format: { auto | [<io>,][<irq>] }
General comment. I guess this patch will conflict with timer cleanups
and hrt timer patches. This patch being smaller, it may be easier to
rebase this against hrt timer patches.
Other comments inlined below...
>-----Original Message-----
>From: Om Narasimhan [mailto:[email protected]]
>Sent: Wednesday, October 25, 2006 12:14 AM
>To: [email protected]
>Cc: [email protected]; [email protected];
>[email protected]; [email protected]; [email protected];
>[email protected]; Pallipadi, Venkatesh; [email protected]
>Subject: HPET : Legacy Routing Replacement Enable - 3rd try.
>
>I have incorporated Randy's comments.
>CC-ing HPET developers.
>
>Patch here.
>Signed-off-by: Om Narasimhan <[email protected]>
>
>
> Documentation/hpet.txt | 56
>+++++++++++++++++++++++++++++++++++
> Documentation/kernel-parameters.txt | 9 ++++++
> arch/i386/kernel/acpi/boot.c | 18 +++++++++++
> arch/i386/kernel/time_hpet.c | 3 +-
> arch/x86_64/kernel/time.c | 16 +++++++---
> include/asm-x86_64/hpet.h | 1 +
> include/linux/acpi.h | 1 +
> include/linux/hpet.h | 7 ++++
> 8 files changed, 105 insertions(+), 6 deletions(-)
>
>diff --git a/Documentation/hpet.txt b/Documentation/hpet.txt
>index b7a3dc3..ca62b69 100644
>--- a/Documentation/hpet.txt
>+++ b/Documentation/hpet.txt
>@@ -298,3 +298,59 @@ members of the hpet_task structure befor
> hpet_control simply vectors to the hpet_ioctl routine and has the same
> commands and respective arguments as the user API. hpet_unregister
> is used to terminate usage of the HPET timer reserved by
>hpet_register.
>+
>+ HPET Legacy Replacement Route option (hpet_lrr)
>+
>+HPET is capable of replacing the IRQ0 (connected INT0 PIN) routing for
>+timer interrupt. The capability register (at offset 0 of HPET
>+base address) has a bit specifying if HPET chip is capbale of doing
>+this. OS can read the bit either from HW or ACPI table. (HPET ACPI
>+description table -> Event Timer block -> bit 15, page 30 of HPET
>+spec). Ideally (I think so!) BIOS should set the ACPI table
>than letting
>+the OS read H/W, which gives the BIOS a way to configure either legacy
>+or Legacy replacement modes.
>+
>+Typically the motherboard has BIOS configured / hardwired IRQ0 to INT0
>+(pin of APIC) connection. Linux assumes IRQ0 connected to
>INT0 unless it is
>+supplied using an override parameter in the MPTable. Some
>NVidia chipsets /
>+BIOS initialization code had configured to override IRQ0 ->
>INT0 connection
>+and later a parameter was introduce
>(acpi_skip_timer_override) to get IRQ0 ->
>+INT0 connection right.
>+
>+But a number of bioses (both phoenix and AMI) are not working as
>+expected. (I have an AMI BIOS which sets ACPI table bit 15 to
>0 and then
>+connect IRQ0 -> INT2 internally, Another bios I have sets the
>ACPI table bit
>+15 to 0, but does not connect IRQ0 -> INT2. Both would result
>in a hang in
>+calibrate_delay() since there would not be any timer
>interrupts So I have
>+provided a command line parameter which overrides
>+the BIOS ACPI entry. So, irrespctive of the BIOS' HPET ACPI Descriptor
>+table settings, if the parameter hpet_lrr=[0,1] is specified, it takes
>+precedence.
>+
>+* When to use this parameter?
>+
>+Some latest versions CK-804 (e.g),(Actually the code initializes the
>+CK804 in the BIOS), would correctly set the HPET such that
>there would not
>+be any interrupts on INT0. Linux does not handle this
>situation very well
>+because in linux, if HW is LRR capable, it is enabled from
>the OS. Still the
>+timer interrupt handler is setup for IRQ0. Under this
>situation, you can
>+force the parameter hpet_lrr=1, so that IRQ2 is timer interrupts.
>+
>+[root@mophia ~]# cat /proc/interrupts | grep 2:
>+ 2: 163 0 0 0 1 7
>+207 955341 IO-APIC-edge timer
>+
>+[root@mophia ~]# uptime
>+ 22:52:38 up 15 min, 2 users, load average: 0.00, 0.01, 0.02
>+
>+[root@mophia ~]# dmesg | grep -i MP-BIOS
>+
>+For 15 mts (900 sec), around 95k interrupts on timer looks kinda fine.
>+
>+* Known Bugs:
>+I have tested it only with Nvidia CK-804. There seem to be
>some kind of timing
>+issue between enabling the HPET with LRR set and start of
>tinerrupts. As a
>+result of which, calibrate_delay() hangs because there are no
>interrupts. If
>+you run into such a case, pass lpj=<bogomips * 500> as a work
>around. i.e, if
>+your bogomips is 5000, pass lpj=2500000
>+
>diff --git a/Documentation/kernel-parameters.txt
>b/Documentation/kernel-parameters.txt
>index dd00fd5..7916ff5 100644
>--- a/Documentation/kernel-parameters.txt
>+++ b/Documentation/kernel-parameters.txt
>@@ -366,6 +366,15 @@ and is between 256 and 4096 characters.
> hpet= [IA-32,HPET] option to disable HPET and use PIT.
> Format: disable
>
>+ hpet_lrr= [IA32,X86_64,HPET] Option to
>enable/disable the HPET
>+ Legacy replacement route. Please read
>Documentation/
>+ hpet.txt for more info.
>+ Format : {"0" | "1"}
>+ 0 -> Disables Legacy Route Replacement.
>(Default)
>+ 1 -> Enables LRR. Please consult your BIOS
>+ documentation before doing this.
>+
>+
> cm206= [HW,CD]
> Format: { auto | [<io>,][<irq>] }
>
>diff --git a/arch/i386/kernel/acpi/boot.c
>b/arch/i386/kernel/acpi/boot.c
>index ab974ff..2c5a798 100644
>--- a/arch/i386/kernel/acpi/boot.c
>+++ b/arch/i386/kernel/acpi/boot.c
>@@ -82,6 +82,17 @@ EXPORT_SYMBOL(acpi_strict);
> acpi_interrupt_flags acpi_sci_flags __initdata;
> int acpi_sci_override_gsi __initdata;
> int acpi_skip_timer_override __initdata;
>+/* HPET Legacy routing replacement option passed through ACPI Table */
>+int acpi_hpet_lrr;
>+/* cmdline opt. for faulty bioses not setting ACPI HPET entry right */
>+int hpet_lrr_force;
>+
>+static int hpet_lrr_setup (char *str)
>+{
>+ get_option(&str, &hpet_lrr_force);
>+ return 1;
>+}
>+__setup ("hpet_lrr=", hpet_lrr_setup);
>
> #ifdef CONFIG_X86_LOCAL_APIC
> static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
>@@ -669,6 +680,13 @@ #define HPET_RESOURCE_NAME_SIZE 9
> "HPET %u", hpet_tbl->number);
> hpet_res->end = (1 * 1024) - 1;
> }
>+ acpi_hpet_lrr = (hpet_tbl->id & ACPI_HPET_LRR_CAP) ? 1 : 0;
>+ /* Print a message about the bios HPET ACPI Desc Table passed.
>+ * LRR bit should not be set in the table unless IRQ0->INT2 is
>+ * connected. But BIOS may be faulty ...
>+ */
>+ printk(KERN_INFO PREFIX "HPET id: %#x. ACPI LRR bit %s SET\n",
>+ hpet_tbl->id, acpi_hpet_lrr ? "": "NOT");
I don't see acpi_hpet_lrr getting used anywhere in the patch? Are you
planning to change it in any subsequent patches?
>
> #ifdef CONFIG_X86_64
> vxtime.hpet_address = hpet_tbl->addr.addrl |
>diff --git a/arch/i386/kernel/time_hpet.c
>b/arch/i386/kernel/time_hpet.c
>index 1a2a979..01b2f67 100644
>--- a/arch/i386/kernel/time_hpet.c
>+++ b/arch/i386/kernel/time_hpet.c
>@@ -94,7 +94,8 @@ static int hpet_timer_stop_set_go(unsign
> * Go!
> */
> cfg = hpet_readl(HPET_CFG);
>- if (hpet_use_timer)
>+ /* Ideally the following should be &&(acpi_hpet_lrr ||
>hpet_lrr_force) */
>+ if (hpet_use_timer && hpet_lrr_force)
What will be the value of hpet_lrr_force if no boot parameter was used.
It will end up coming from uninitialized data section. Right?
So, CFG_LEGACY will not be set on any platforms unless lrr_force
parameter is used? Is that the intention or am I missing something?
> cfg |= HPET_CFG_LEGACY;
> cfg |= HPET_CFG_ENABLE;
> hpet_writel(cfg, HPET_CFG);
>diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
>index 1ba5a44..0f5d990 100644
>--- a/arch/x86_64/kernel/time.c
>+++ b/arch/x86_64/kernel/time.c
>@@ -46,9 +46,6 @@ #include <asm/apic.h>
> #ifdef CONFIG_CPU_FREQ
> static void cpufreq_delayed_get(void);
> #endif
>-extern void i8254_timer_resume(void);
>-extern int using_apic_timer;
>-
> static char *timename = NULL;
>
> DEFINE_SPINLOCK(rtc_lock);
>@@ -783,7 +780,10 @@ static int hpet_timer_stop_set_go(unsign
> HPET_TN_32BIT, HPET_T0_CFG);
> hpet_writel(hpet_tick, HPET_T0_CMP); /* next
>interrupt */
> hpet_writel(hpet_tick, HPET_T0_CMP); /* period */
>- cfg |= HPET_CFG_LEGACY;
>+ /* Ideal value (acpi_hpet_lrr || hpet_lrr_force) */
>+ if (hpet_lrr_force)
>+ cfg |= HPET_CFG_LEGACY;
>+
> }
> /*
> * Go!
>@@ -887,6 +887,7 @@ time_cpu_notifier(struct notifier_block
>
> void __init time_init(void)
> {
>+ int timer_irq = 0;
> if (nohpet)
> vxtime.hpet_address = 0;
>
>@@ -906,6 +907,10 @@ void __init time_init(void)
> tick_nsec = TICK_NSEC_HPET;
> cpu_khz = hpet_calibrate_tsc();
> timename = "HPET";
>+ /* Ideal value is (acpi_hpet_lrr || hpet_lrr_force) */
>+ if (hpet_lrr_force)
>+ timer_irq = HPET_TIMER_LRR_IRQ;
>+
> #ifdef CONFIG_X86_PM_TIMER
> } else if (pmtmr_ioport && !vxtime.hpet_address) {
> vxtime_hz = PM_TIMER_FREQUENCY;
>@@ -924,7 +929,8 @@ #endif
> vxtime.tsc_quot = (USEC_PER_MSEC << US_SCALE) / cpu_khz;
> vxtime.last_tsc = get_cycles_sync();
> set_cyc2ns_scale(cpu_khz);
>- setup_irq(0, &irq0);
>+ printk(KERN_WARNING PREFIX "Registering Timer IRQ =
>%d\n", timer_irq);
Why is this an unconditional warning?
Thanks,
Venki
On 10/25/06, Pallipadi, Venkatesh <[email protected]> wrote:
>
> General comment. I guess this patch will conflict with timer cleanups
> and hrt timer patches. This patch being smaller, it may be easier to
> rebase this against hrt timer patches.
Thanks for comments.
Rebasing against hrt and other cleanups is a good idea. I would wait
till they make it into mainline.
>
> >+ */
> >+ printk(KERN_INFO PREFIX "HPET id: %#x. ACPI LRR bit %s SET\n",
> >+ hpet_tbl->id, acpi_hpet_lrr ? "": "NOT");
>
> I don't see acpi_hpet_lrr getting used anywhere in the patch? Are you
> planning to change it in any subsequent patches?
No. Let me explain what I observed.
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.
After the fix : Works fine. This is according to hpet spec.
2. HW is LRR capable, HPET ACPI bit is set to 0. timer interrupt is on INT2.
Before the fix : Linux cannot get timer interrupts on INT0, goes for
ACPI timer.
After the fix: Faulty BIOS behavior. Introduced parameter
hpet_lrr_force to handle this situation.
3. HW is LRR capable, HPET ACPI bit is set to 1. timer interrupt is on INT0.
Before the fix: Linux works fine.
After the fix : Faulty BIOS. No way to know which INT timer is connected to.
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 ,
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?
>
> >
> > #ifdef CONFIG_X86_64
> > vxtime.hpet_address = hpet_tbl->addr.addrl |
> >diff --git a/arch/i386/kernel/time_hpet.c
> >b/arch/i386/kernel/time_hpet.c
> >index 1a2a979..01b2f67 100644
> >--- a/arch/i386/kernel/time_hpet.c
> >+++ b/arch/i386/kernel/time_hpet.c
> >@@ -94,7 +94,8 @@ static int hpet_timer_stop_set_go(unsign
> > * Go!
> > */
> > cfg = hpet_readl(HPET_CFG);
> >- if (hpet_use_timer)
> >+ /* Ideally the following should be &&(acpi_hpet_lrr ||
> >hpet_lrr_force) */
> >+ if (hpet_use_timer && hpet_lrr_force)
>
> What will be the value of hpet_lrr_force if no boot parameter was used.
zero.
> It will end up coming from uninitialized data section. Right?
Since it is a global variable, I assumed it would be automatically
initialized to zero, and zero is the expected default. Did I miss
something obvious?
>
> So, CFG_LEGACY will not be set on any platforms unless lrr_force
> parameter is used? Is that the intention or am I missing something?
Yes. That is the way I could think of to handle faulty bios implementations.
>
> >- setup_irq(0, &irq0);
> >+ printk(KERN_WARNING PREFIX "Registering Timer IRQ =
> >%d\n", timer_irq);
>
> Why is this an unconditional warning?
hmm... That is not required. I should have removed it.
Thanks,
Om.
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.
-Andi
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.
--
Vojtech Pavlik
Director SuSE Labs
Andi Kleen wrote:
>> 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.
Sorry, Mea Culpa, I should have written APIC timer.
>
> Not sure what you mean with INT2. Pin2 on ioapic 0 perhaps?
Yes. PIN2 on IOAPIC #0.
>
>> After the fix : Works fine. This is according to hpet spec.
>
> On what exact motherboard was that?
SunFire X4600
>
>> 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?
I feel I do not make things clear enough.
The command line parameter can be avoided entirely if majority of the BIOSes implement LRR routing correctly. I would rewrite the patch to avoid cmdline parameter and according to Andrew Morton's suggestions.
Thanks,
Om.
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
On Fri, Oct 27, 2006 at 09:29:44AM +0300, Mika Penttil? wrote:
> >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).
Sorry about my share of confusion introduced: Jiri Bohac
([email protected]) is currently working on a new timekeeping code for
x86-64 that takes a significantly different approach that allows for
precise and fast gettimeofday even on CPUs with unsynchronized TSCs.
This rewrite depends even less on hpet_use_timer than the current code.
The current code can cope with hpet_use_timer == 0, but that mode of
operation is far from optimal.
> 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?
It doesn't seem right to me, unless someone at Sun really misread the
specification when designing the mainboard.
--
Vojtech Pavlik
Director SuSE Labs
On Thu, Oct 26, 2006 at 11:11:49PM -0700, Om Narasimhan wrote:
> Andi Kleen wrote:
> >>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.
> Sorry, Mea Culpa, I should have written APIC timer.
> >
> >Not sure what you mean with INT2. Pin2 on ioapic 0 perhaps?
> Yes. PIN2 on IOAPIC #0.
> >
> >>After the fix : Works fine. This is according to hpet spec.
> >
> >On what exact motherboard was that?
> SunFire X4600
> >
> >>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?
> I feel I do not make things clear enough.
> The command line parameter can be avoided entirely if majority of the
> BIOSes implement LRR routing correctly. I would rewrite the patch to avoid
> cmdline parameter and according to Andrew Morton's suggestions.
But on SunFire X4600 it would need to be set to work, correct?
I guess that would make the users of that machine unhappy because
users usually don't want to set weird parameters to make their
system boot.
Actually in theory the HPET driver should ignore the HPET if legacy
replacement is not supported and fall back to PIT. Or are you saying
that PIT doesn't work on that system either?
Anyways I think we need some heuristics to do this all automatically
without user involvement.
-Andi
>
> Thanks,
> Om.
> >
> >
> 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?
Hmm... if hpet_lrr_force=1, timer irq should be set to 2 both in
x86_64 as well as i386.
This is my mistake. I should test more thoroughly :-(
Thanks for comments.
Om.
>
> --Mika
>
>
>
On Thu, Oct 26, 2006 at 11:11:49PM -0700, Om Narasimhan wrote:
> Andi Kleen wrote:
> >>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.
> Sorry, Mea Culpa, I should have written APIC timer.
> >
> >Not sure what you mean with INT2. Pin2 on ioapic 0 perhaps?
> Yes. PIN2 on IOAPIC #0.
> >
> >>After the fix : Works fine. This is according to hpet spec.
> >
> >On what exact motherboard was that?
> SunFire X4600
> >
> >>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?
> I feel I do not make things clear enough.
> The command line parameter can be avoided entirely if majority of the
> BIOSes implement LRR routing correctly. I would rewrite the patch to avoid
But they don't.
> cmdline parameter and according to Andrew Morton's suggestions.
What was that suggestion again? (sorry can't find it)
Anyways the goal is really to just work everywhere without command line
parameters. Can we somehow detect the SunFire condition and only enable
it there?
-Andi (who must admit he still doesn't quite understand why the Sun machine
needs this anyways)