Re: [PATCH] x86: Don't allow nr_irqs > NR_IRQS

From: Ben Hutchings
Date: Tue Nov 04 2008 - 13:37:01 EST

Next message: Török Edwin: "Re: [PATCH] Identify which executable object the userspace addressbelongs to. Store thread group leader id, and use it to lookup the addressin the process's map. We could have looked up the address on thread's map,but the thread might not exist by the time we are called. The process mightnot exist either, but if you are reading trace_pipe, that is unlikely."
Previous message: Sergei Shtylyov: "Re: [PATCH 6/6] ide: rework handling of serialized ports"
In reply to: Cyrill Gorcunov: "Re: [PATCH] x86: Don't allow nr_irqs > NR_IRQS"
Next in thread: Yinghai Lu: "Re: [PATCH] x86: Don't allow nr_irqs > NR_IRQS"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Tue, 2008-11-04 at 21:00 +0300, Cyrill Gorcunov wrote:
[...]
> | I hit this when running net-next-2.6 (close to 2.6.28-rc3) on a
> | Supermicro dual Xeon system. NR_IRQS is 224 but probe_nr_irqs() detects
> | 5 IOAPICs (!) and returns 240. Here are the log messages:
> |
> | Tue Nov 4 16:53:47 2008 ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
> | Tue Nov 4 16:53:47 2008 IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
> | Tue Nov 4 16:53:47 2008 ACPI: IOAPIC (id[0x02] address[0xfec81000] gsi_base[24])
> | Tue Nov 4 16:53:47 2008 IOAPIC[1]: apic_id 2, version 32, address 0xfec81000, GSI 24-47
> | Tue Nov 4 16:53:47 2008 ACPI: IOAPIC (id[0x03] address[0xfec81400] gsi_base[48])
> | Tue Nov 4 16:53:47 2008 IOAPIC[2]: apic_id 3, version 32, address 0xfec81400, GSI 48-71
> | Tue Nov 4 16:53:47 2008 ACPI: IOAPIC (id[0x04] address[0xfec82000] gsi_base[72])
> | Tue Nov 4 16:53:47 2008 IOAPIC[3]: apic_id 4, version 32, address 0xfec82000, GSI 72-95
> | Tue Nov 4 16:53:47 2008 ACPI: IOAPIC (id[0x05] address[0xfec82400] gsi_base[96])
> | Tue Nov 4 16:53:47 2008 IOAPIC[4]: apic_id 5, version 32, address 0xfec82400, GSI 96-119
> | Tue Nov 4 16:53:47 2008 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
> | Tue Nov 4 16:53:47 2008 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> | Tue Nov 4 16:53:47 2008 Enabling APIC mode: Flat. Using 5 I/O APICs
> |
> | ïI think this has become possible since:
> |
> | commit d6c88a507ef0b6afdb013cba4e7804ba7324d99a
> | Author: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> | Date: Wed Oct 15 15:27:23 2008 +0200
> |
> | genirq: revert dynarray
> |
> | Revert the dynarray changes. They need more thought and polishing.
> |
> | Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
[...]
> Hi Ben,
>
> I don't think that is because of Thomas' commit. If we've got
> number of pins larger then we expect it means something wrong
> with our NR_IRQS. Is it possible to get your .config?

Well there must have been an earlier change that resulted in detecting 5
IOAPICs instead of just 1, but that presumably would work as long as the
irq_desc array was dynamically allocated. This reversion breaks that.

You don't really need to see the config; NR_IRQS is *always* 224 on
normal x86-32 systems.

Ben.

--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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/