RE: [PATCH] 2.6.5- es7000 subarch update

From: Protasevich, Natalie
Date: Tue Apr 06 2004 - 10:12:02 EST

Hi Andrew,

The only line that is outside the es7000 code and could cause this is:

> --- linux6.5/arch/i386/kernel/mpparse.c 2004-04-04 18:22:39.000000000 -0400
> +++ linux-2.6.5/arch/i386/kernel/mpparse.c 2004-04-05 00:07:13.000000000 -0400
> @@ -969,7 +969,7 @@
> */
> for (i = 0; i < mp_irq_entries; i++) {
> if ((mp_irqs[i].mpc_srcbus == intsrc.mpc_srcbus)
> - && (mp_irqs[i].mpc_srcbusirq == intsrc.mpc_srcbusirq)) {
> + && (mp_irqs[i].mpc_dstirq == intsrc.mpc_dstirq)) {
> mp_irqs[i] = intsrc;
> found = 1;

(The one that Martin asked me about)
The code is for the legacy/overwrites, and used to have this line (and I am researching it now).
ES7000 has pretty extensive overrides:
ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 12 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 13 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 15 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 16 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 17 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 18 low edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 19 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 20 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 23 high level)

The only device that fails to set the line correctly with the code as it is now is the IDE (line 4) and works fine with the suggested line. In the case below, the clock gets mapped to the cascade...
I will do more testing on the generic Xeon then, it should be a good solution there. Maybe, this is something that the hook might be needed for es7000.
Thanks,
--Natalie

-----Original Message-----
From: Andrew Morton [mailto:akpm@xxxxxxxx]
Sent: Tuesday, April 06, 2004 12:30 AM
To: Protasevich, Natalie
Cc: linux-kernel@xxxxxxxxxxxxxxx; lse-tech@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [PATCH] 2.6.5- es7000 subarch update


"Protasevich, Natalie" <Natalie.Protasevich@xxxxxxxxxx> wrote:
>
> ES7000 was failing to boot since first couple revisions of 2.6. The patch fixes the boot problem.
> In the patch, some maintenance and cleanup was done for es7000 subarch, such as APIC destinations were corrected, missing initialization for the variable was added, extraneous file was removed, etc.
> The patch was created against 2.6.5, compiled cleanly, and tested on the ES7000 system.

This patch appears to cause the local-apic based time interrupts to run too
fast on my old 4-way Xeon server. A `sleep 10' takes about five seconds.

Diffing the dmesg output shows the changes which your patch caused:

--- without 2004-04-05 22:18:41.061198208 -0700
+++ with 2004-04-05 22:17:15.000000000 -0700
@@ -1,4 +1,4 @@
- IO-APIC (apicid-pin) 4-0, 4-16, 4-17, 4-18, 4-19, 4-20, 4-21, 4-22, 4-23, 4-24, 4-25, 4-26, 4-27, 4-28, 4-29, 4-30, 4-31, 4-32, 4-33, 4-34, 4-35, 4-36, 4-37, 4-38, 4-39, 4-40, 4-41, 4-42, 4-43, 4-44, 4-45, 4-46, 4-47, 4-48, 4-49, 4-50, 4-51, 4-52, 4-53, 4-54, 4-55, 4-56, 4-57, 4-58, 4-59, 4-60, 4-61, 4-62, 4-63 not connected.
-..TIMER: vector=0x31 pin1=2 pin2=-1
+ IO-APIC (apicid-pin) 4-16, 4-17, 4-18, 4-19, 4-20, 4-21, 4-22, 4-23, 4-24, 4-25, 4-26, 4-27, 4-28, 4-29, 4-30, 4-31, 4-32, 4-33, 4-34, 4-35, 4-36, 4-37, 4-38, 4-39, 4-40, 4-41, 4-42, 4-43, 4-44, 4-45, 4-46, 4-47, 4-48, 4-49, 4-50, 4-51, 4-52, 4-53, 4-54, 4-55, 4-56, 4-57, 4-58, 4-59, 4-60, 4-61, 4-62, 4-63 not connected.
+..TIMER: vector=0x31 pin1=0 pin2=-1


-number of MP IRQ sources: 15.
+number of MP IRQ sources: 16.


.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
- 00 000 00 1 0 0 0 0 0 0 00
+ 00 00F 0F 0 0 0 0 0 1 1 31
01 00F 0F 0 0 0 0 0 1 1 39
02 00F 0F 0 0 0 0 0 1 1 31
03 00F 0F 0 0 0 0 0 1 1 41
@@ -368,7 +368,7 @@
3e 000 00 1 0 0 0 0 0 0 00
3f 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
-IRQ0 -> 0:2
+IRQ0 -> 0:0-> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/