Messages in this thread |  | | | From | (Eric W. Biederman) | | Date | Tue, 23 Feb 2010 12:17:11 -0800 | | Subject | Re: Other problem/regression with b9c61b70075c87a8612624736faf4a2de5b1ed30 |
| |
Yinghai Lu <yinghai@kernel.org> writes:
> On 02/23/2010 01:07 AM, Yinghai Lu wrote: >> Gary, >> >> can you check this patch on your x3950? > > Subject: [PATCH -v2] x86: fix out of order of gsi > > found IBM x3950 will have problem after > > |commit b9c61b70075c87a8612624736faf4a2de5b1ed30 > | > | x86/pci: update pirq_enable_irq() to setup io apic routing > > The problem is that with the patch, the machine freezes when > console=ttyS0,... kernel serial parameter is passed. > It seem to freeze at DVD initialization and the whole problem seem > to be DVD/pata related, but somehow exposed through the serial > parameter. > Such apic problems can expose really weird behavior.. > > <6>ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) > <6>IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 > <6>ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) > <6>IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 > <6>ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) > <6>IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) > <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) > > it turns out that system have three io apic controller. but put boot ioapic > routing in second one. and that gsi_base is not 0. it is using bunch of INT_SRC_OVR... > > recent changes > 1. one set routing for first io apic controller > 2. assume irq = gsi > will break theat system. > > so try to remap those gsi, need to seperate boot_ioapic_id detection out of enable_IO_APIC > and call them early. > introduce boot_ioapic_id, and remap_ioapic_gsi... > > -v2: shift gsi with delta instead of gsi_base of boot_ioapic_idx > > Reported-by: Iranna D Ankad <iranna.ankad@in.ibm.com> > Bisected-by: Iranna D Ankad <iranna.ankad@in.ibm.com> > Cc: Thomas Renninger <trenn@suse.de> > Cc: stable@kernel.org > Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> +int remap_ioapic_gsi(int ioapic, u32 gsi) > +{ > + int base_boot = mp_gsi_routing[boot_ioapic_idx].gsi_base; > + int base_x; > + > + if (!base_boot) > + return gsi; > + > + base_x = mp_gsi_routing[ioapic].gsi_base; > + if (base_x < base_boot) { > + int delta; > + delta = mp_gsi_routing[boot_ioapic_idx].gsi_end + 1; > + delta -= base_boot; > + gsi += delta; > + } else if (base_x == base_boot) > + gsi -= base_boot; > + > + return gsi; > +}
This looks like it is doing something very different from implementing a one irq at a time override, and after the nasties remapping gsi have caused in the past I find this function very scary.
Eric
|  |