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

This is a discussion on [PATCH] x86: Don't allow nr_irqs > NR_IRQS - Kernel ; On some systems probe_nr_irqs() can return a value larger than NR_IRQS. This will lead to probe_irq_on() overrunning the irq_desc array. Signed-off-by: Ben Hutchings --- arch/x86/kernel/io_apic.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)  I hit this when ...

+ Reply to Thread
Results 1 to 12 of 12

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

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

    On some systems probe_nr_irqs() can return a value larger than
    NR_IRQS. This will lead to probe_irq_on() overrunning the irq_desc
    array.

    Signed-off-by: Ben Hutchings
    ---
    arch/x86/kernel/io_apic.c | 2 ++
    1 files changed, 2 insertions(+), 0 deletions(-)
    
    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
    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

    Ben.

    diff --git a/arch/x86/kernel/io_apic.c b/arch/x86/kernel/io_apic.c
    index b764d74..c8482fb 100644
    --- a/arch/x86/kernel/io_apic.c
    +++ b/arch/x86/kernel/io_apic.c
    @@ -3611,6 +3611,8 @@ int __init probe_nr_irqs(void)
    /* something wrong ? */
    if (nr < nr_min)
    nr = nr_min;
    + if (nr > NR_IRQS)
    + nr = NR_IRQS;

    return nr;
    }

    --
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

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

    [...]
    > 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    [Ben Hutchings - Tue, Nov 04, 2008 at 05:18:22PM +0000]
    | On some systems probe_nr_irqs() can return a value larger than
    | NR_IRQS. This will lead to probe_irq_on() overrunning the irq_desc
    | array.
    |
    | Signed-off-by: Ben Hutchings
    | ---
    | arch/x86/kernel/io_apic.c | 2 ++
    | 1 files changed, 2 insertions(+), 0 deletions(-)
    | 
    | 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
    | 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
    |
    | Ben.
    |
    | diff --git a/arch/x86/kernel/io_apic.c b/arch/x86/kernel/io_apic.c
    | index b764d74..c8482fb 100644
    | --- a/arch/x86/kernel/io_apic.c
    | +++ b/arch/x86/kernel/io_apic.c
    | @@ -3611,6 +3611,8 @@ int __init probe_nr_irqs(void)
    | /* something wrong ? */
    | if (nr < nr_min)
    | nr = nr_min;
    | + if (nr > NR_IRQS)
    | + nr = NR_IRQS;
    |
    | return nr;
    | }
    |

    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?

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

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

    On Tue, Nov 4, 2008 at 10:36 AM, Ben Hutchings
    wrote:
    > 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:
    >> |

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


    Yes. it should the same as setting to 64bit. we will cost some extra ram...

    We can not make sparseirq/dyn_array to 2.6.28..., maybe 2.6.29 later.

    Ingo,
    Maybe we can put back dyn_array at first, that will still be 1:1
    mapping..., and not waste memory..

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

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

    [Ben Hutchings - Tue, Nov 04, 2008 at 06:36:47PM +0000]
    | 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
    | > | 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
    | [...]
    | > 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.

    Hmm... wich means the problem in area of detecting IOAPICs but this number
    we got from ACPI... have to check.

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

    Ben, how could I know that you're using 32bit version, unfortunately
    I don't recite in my mind "NR_IRQS is 224 on x86-32" every minute

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

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

    On Tue, 2008-11-04 at 22:46 +0300, Cyrill Gorcunov wrote:
    [...]
    > Ben, I'll take a look on ACPI code tomorrow. If I understand you
    > correctly your Xeon machine has a few cores and only one IO-APIC
    > (on physical side)? Am I right?


    It has 2 single-core processors (family 15 model 4). Here's the lspci
    output:

    00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 0c)
    00:00.1 Class ff00: Intel Corporation E7525/E7520 Error Reporting Registers (rev 0c)
    00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 0c)
    00:03.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A1 (rev 0c)
    00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 0c)
    00:06.0 PCI bridge: Intel Corporation E7520 PCI Express Port C (rev 0c)
    00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
    00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
    00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
    00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02)
    00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
    00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
    00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
    00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
    00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
    02:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09)
    02:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09)
    02:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09)
    02:00.3 PIC: Intel Corporation 6700PXH I/OxAPIC Interrupt Controller B (rev 09)
    04:02.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    04:02.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    05:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09)
    05:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09)
    05:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09)
    05:00.3 PIC: Intel Corporation 6700PXH I/OxAPIC Interrupt Controller B (rev 09)
    07:02.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)
    08:00.0 Ethernet controller: Solarflare Communications SFC4000 rev B [Solarstorm] (rev 02)
    09:01.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)

    I see 4 PICs there; no idea where the 5th is hiding.

    I switched to an RHEL 5 (2.6.18-53) kernel and found that that also
    detects 5 IOAPICs, so there's no recent change in that.

    This is the commit that made nr_irqs dynamic:

    commit 71f521bbaf375b685aeea20c6b0ed8600cd6edfe
    Author: Yinghai Lu
    Date: Tue Aug 19 20:50:03 2008 -0700

    x86, irq: get nr_irqs from madt

    Until now, NR_IRQS was derived from black magic defines that had to
    be "large enough" to both accomodate NR_CPUS and MAX_NR_IO_APICs.

    This resulted in a way too large irq_desc[] array on most x86 systems.
    Especially with larger CPU masks, the size of irq_desc can spiral out
    of control quickly.

    So be smarter about it and use precise allocation instead: determine the
    default maximum possible IRQ number from the ACPI MADT. Use a minimum limit
    of at least 32 IRQs for broken BIOSes.

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar

    That was fine at the time because the irq_desc array was allocated
    dynamically. But now that irq_desc has been reverted to a static array,
    the probe function needs to apply the upper limit. Alternately nr_irqs
    could be set to NR_IRQS unconditionally; the probing for nr_irqs is
    fairly pointless if it isn't used for dynamic allocation.

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. [PATCH v2] x86: Don't allow nr_irqs > NR_IRQS

    On some systems probe_nr_irqs() can return a value larger than
    NR_IRQS. This will lead to probe_irq_on() overrunning the irq_desc
    array.

    Signed-off-by: Ben Hutchings
    ---
    arch/x86/kernel/io_apic.c | 2 ++
    1 files changed, 2 insertions(+), 0 deletions(-)
    
    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 have added a WARN_ON() as suggested by Yinghai Lu.

    Ben.

    diff --git a/arch/x86/kernel/io_apic.c b/arch/x86/kernel/io_apic.c
    --- a/arch/x86/kernel/io_apic.c
    +++ b/arch/x86/kernel/io_apic.c
    @@ -3611,6 +3611,8 @@ int __init probe_nr_irqs(void)
    /* something wrong ? */
    if (nr < nr_min)
    nr = nr_min;
    + if (WARN_ON(nr > NR_IRQS))
    + nr = NR_IRQS;

    return nr;
    }

    --
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    [Ben Hutchings - Wed, Nov 05, 2008 at 12:04:46PM +0000]
    | On some systems probe_nr_irqs() can return a value larger than
    | NR_IRQS. This will lead to probe_irq_on() overrunning the irq_desc
    | array.
    |
    | Signed-off-by: Ben Hutchings
    | ---
    | arch/x86/kernel/io_apic.c | 2 ++
    | 1 files changed, 2 insertions(+), 0 deletions(-)
    |
    | 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 have added a WARN_ON() as suggested by Yinghai Lu.
    |
    | Ben.
    |
    | diff --git a/arch/x86/kernel/io_apic.c b/arch/x86/kernel/io_apic.c
    | --- a/arch/x86/kernel/io_apic.c
    | +++ b/arch/x86/kernel/io_apic.c
    | @@ -3611,6 +3611,8 @@ int __init probe_nr_irqs(void)
    | /* something wrong ? */
    | if (nr < nr_min)
    | nr = nr_min;
    | + if (WARN_ON(nr > NR_IRQS))
    | + nr = NR_IRQS;
    |
    | return nr;
    | }
    |
    | --
    | 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.
    |

    My Ack if you need it, Ingo CC'ed
    Acked-by: Cyrill Gorcunov

    ---

    Ben I didn't manage to get a look over ACPI related changes
    (ie to find the reason why the kernel is able to reveal 5 IO-APICs
    now but this patch is needed anyway as Yinghai already mentioned
    and should solve your problem. FWIW, I don't see neither apics on
    my laptop by lspci except that ICH is notified so I suspect the
    ACPI parsing is right)

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

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

    On Wed, 2008-11-05 at 22:11 +0300, Cyrill Gorcunov wrote:
    [...]
    > Ben I didn't manage to get a look over ACPI related changes
    > (ie to find the reason why the kernel is able to reveal 5 IO-APICs
    > now

    [...]

    I was mistaken; that *isn't* a recent change. A default RHEL 5 kernel
    (based on 2.6.18) also finds 5 IOAPICs.

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    [Ben Hutchings - Wed, Nov 05, 2008 at 07:15:31PM +0000]
    | On Wed, 2008-11-05 at 22:11 +0300, Cyrill Gorcunov wrote:
    | [...]
    | > Ben I didn't manage to get a look over ACPI related changes
    | > (ie to find the reason why the kernel is able to reveal 5 IO-APICs
    | > now
    | [...]
    |
    | I was mistaken; that *isn't* a recent change. A default RHEL 5 kernel
    | (based on 2.6.18) also finds 5 IOAPICs.
    |
    | Ben.
    |

    So, these io-apics was there for a long time and recent dyn-irq
    tricks just bared the problem of NR_IRQS for which Yinghai already
    sent a patch. Lets wait until they're merged.

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

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


    * Ben Hutchings wrote:

    > On some systems probe_nr_irqs() can return a value larger than
    > NR_IRQS. This will lead to probe_irq_on() overrunning the irq_desc
    > array.
    >
    > Signed-off-by: Ben Hutchings


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


    applied to tip/x86/urgent, thanks Ben!

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

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


    * Ben Hutchings wrote:

    > On Wed, 2008-11-05 at 22:11 +0300, Cyrill Gorcunov wrote:
    > [...]
    > > Ben I didn't manage to get a look over ACPI related changes
    > > (ie to find the reason why the kernel is able to reveal 5 IO-APICs
    > > now

    > [...]
    >
    > I was mistaken; that *isn't* a recent change. A default RHEL 5
    > kernel (based on 2.6.18) also finds 5 IOAPICs.


    yes - it's simply a box with a lot of IO-APICs. That's not bad at all,
    it spreads out IRQ processing amongst devices.

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

+ Reply to Thread