Re: Other problem/regression with b9c61b70075c87a8612624736faf4a2de5b1ed30

[ebiederm@xmission.com (Eric W. Biederman)]

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