1. 04 Oct, 2006 11 commits
    • Eric W. Biederman's avatar
      [PATCH] msi: refactor and move the msi irq_chip into the arch code · 3b7d1921
      Eric W. Biederman authored
      
      
      It turns out msi_ops was simply not enough to abstract the architecture
      specific details of msi.  So I have moved the resposibility of constructing
      the struct irq_chip to the architectures, and have two architecture specific
      functions arch_setup_msi_irq, and arch_teardown_msi_irq.
      
      For simple architectures those functions can do all of the work.  For
      architectures with platform dependencies they can call into the appropriate
      platform code.
      
      With this msi.c is finally free of assuming you have an apic, and this
      actually takes less code.
      
      The helpers for the architecture specific code are declared in the linux/msi.h
      to keep them separate from the msi functions used by drivers in linux/pci.h
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Greg KH <greg@kroah.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3b7d1921
    • Eric W. Biederman's avatar
      [PATCH] Initial generic hypertransport interrupt support · 8b955b0d
      Eric W. Biederman authored
      
      
      This patch implements two functions ht_create_irq and ht_destroy_irq for
      use by drivers.  Several other functions are implemented as helpers for
      arch specific irq_chip handlers.
      
      The driver for the card I tested this on isn't yet ready to be merged.
      However this code is and hypertransport irqs are in use in a few other
      places in the kernel.  Not that any of this will get merged before 2.6.19
      
      Because the ipath-ht400 is slightly out of spec this code will need to be
      generalized to work there.
      
      I think all of the powerpc uses are for a plain interrupt controller in a
      chipset so support for native hypertransport devices is a little less
      interesting.
      
      However I think this is a half way decent model on how to separate arch
      specific and generic helper code, and I think this is a functional model of
      how to get the architecture dependencies out of the msi code.
      
      [akpm@osdl.org: Kconfig fix]
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8b955b0d
    • Eric W. Biederman's avatar
      [PATCH] genirq: x86_64 irq: Kill irq compression · cd1182f5
      Eric W. Biederman authored
      
      
      With more irqs in the system we don't need this.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      cd1182f5
    • Eric W. Biederman's avatar
      [PATCH] genirq: x86_64 irq: Kill gsi_irq_sharing · f023d764
      Eric W. Biederman authored
      
      
      After raising the number of irqs the system supports this function is no
      longer necessary.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f023d764
    • Eric W. Biederman's avatar
      [PATCH] genirq: x86_64 irq: make vector_irq per cpu · 550f2299
      Eric W. Biederman authored
      
      
      This refactors the irq handling code to make the vectors a per cpu resource so
      the same vector number can be simultaneously used on multiple cpus for
      different irqs.
      
      This should make systems that were hitting limits on the total number of irqs
      much more livable.
      
      [akpm@osdl.org: build fix]
      [akpm@osdl.org: __target_IO_APIC_irq is unneeded on UP]
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      550f2299
    • Eric W. Biederman's avatar
      [PATCH] genirq: x86_64 irq: Make the external irq handlers report their vector, not the irq number · e500f574
      Eric W. Biederman authored
      
      
      This is a small pessimization but it paves the way for making this information
      per cpu.  Which allows the the maximum number of IRQS to become NR_CPUS*224.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e500f574
    • Eric W. Biederman's avatar
      [PATCH] genirq: x86_64 irq: Remove the msi assumption that irq == vector · 04b9267b
      Eric W. Biederman authored
      
      
      This patch removes the change in behavior of the irq allocation code when
      CONFIG_PCI_MSI is defined.  Removing all instances of the assumption that irq
      == vector.
      
      create_irq is rewritten to first allocate a free irq and then to assign that
      irq a vector.
      
      assign_irq_vector is made static and the AUTO_ASSIGN case which allocates an
      vector not bound to an irq is removed.
      
      The ioapic vector methods are removed, and everything now works with irqs.
      
      The definition of NR_IRQS no longer depends on CONFIG_PCI_MSI
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      04b9267b
    • Eric W. Biederman's avatar
      [PATCH] genirq: x86_64 irq: Move msi message composition into io_apic.c · 589e367f
      Eric W. Biederman authored
      
      
      This removes the hardcoded assumption that irq == vector in the msi
      composition code, and it allows the msi message composition to setup logical
      mode, or lowest priorirty delivery mode as we do for other apic interrupts,
      and with the same selection criteria.
      
      Basically this moves the problem of what is in the msi message into the
      architecture irq management code where it belongs.  Not in a generic layer
      that doesn't have enough information to compose msi messages properly.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      589e367f
    • Eric W. Biederman's avatar
      [PATCH] genirq: x86_64 irq: Dynamic irq support · c4fa0bbf
      Eric W. Biederman authored
      
      
      The current implementation of create_irq() is a hack but it is the current
      hack that msi.c uses, and unfortunately the ``generic'' apic msi ops depend on
      this hack.  Thus we are this hack of assuming irq == vector until the
      depencencies in the generic irq code are removed.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c4fa0bbf
    • Eric W. Biederman's avatar
      [PATCH] genirq: x86_64 irq: Reenable migrating irqs to other cpus · 0be6652f
      Eric W. Biederman authored
      
      
      In the latest changes the code for migrating x86_64 irqs was dropped.  This
      reads it in a fashion that will work even if we change the vector on level
      triggered irqs when we migrate them.
      
      [akpm@osdl.org: build fix]
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0be6652f
    • Ingo Molnar's avatar
      [PATCH] genirq: convert the x86_64 architecture to irq-chips · f29bd1ba
      Ingo Molnar authored
      
      
      This patch converts all the x86_64 PIC controllers layers to the new and
      simpler irq-chip interrupt handling layer.
      
      [mingo@elte.hu: The patch also enables the fasteoi handler for x86_64]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Roland Dreier <rolandd@cisco.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f29bd1ba
  2. 26 Sep, 2006 8 commits
  3. 30 Jun, 2006 1 commit
  4. 29 Jun, 2006 2 commits
    • Ingo Molnar's avatar
      [PATCH] genirq: add ->retrigger() irq op to consolidate hw_irq_resend() · c0ad90a3
      Ingo Molnar authored
      
      
      Add ->retrigger() irq op to consolidate hw_irq_resend() implementations.
      (Most architectures had it defined to NOP anyway.)
      
      NOTE: ia64 needs testing. i386 and x86_64 tested.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c0ad90a3
    • Ingo Molnar's avatar
      [PATCH] genirq: rename desc->handler to desc->chip · d1bef4ed
      Ingo Molnar authored
      
      
      This patch-queue improves the generic IRQ layer to be truly generic, by adding
      various abstractions and features to it, without impacting existing
      functionality.
      
      While the queue can be best described as "fix and improve everything in the
      generic IRQ layer that we could think of", and thus it consists of many
      smaller features and lots of cleanups, the one feature that stands out most is
      the new 'irq chip' abstraction.
      
      The irq-chip abstraction is about describing and coding and IRQ controller
      driver by mapping its raw hardware capabilities [and quirks, if needed] in a
      straightforward way, without having to think about "IRQ flow"
      (level/edge/etc.) type of details.
      
      This stands in contrast with the current 'irq-type' model of genirq
      architectures, which 'mixes' raw hardware capabilities with 'flow' details.
      The patchset supports both types of irq controller designs at once, and
      converts i386 and x86_64 to the new irq-chip design.
      
      As a bonus side-effect of the irq-chip approach, chained interrupt controllers
      (master/slave PIC constructs, etc.) are now supported by design as well.
      
      The end result of this patchset intends to be simpler architecture-level code
      and more consolidation between architectures.
      
      We reused many bits of code and many concepts from Russell King's ARM IRQ
      layer, the merging of which was one of the motivations for this patchset.
      
      This patch:
      
      rename desc->handler to desc->chip.
      
      Originally i did not want to do this, because it's a big patch.  But having
      both "desc->handler", "desc->handle_irq" and "action->handler" caused a
      large degree of confusion and made the code appear alot less clean than it
      truly is.
      
      I have also attempted a dual approach as well by introducing a
      desc->chip alias - but that just wasnt robust enough and broke
      frequently.
      
      So lets get over with this quickly.  The conversion was done automatically
      via scripts and converts all the code in the kernel.
      
      This renaming patch is the first one amongst the patches, so that the
      remaining patches can stay flexible and can be merged and split up
      without having some big monolithic patch act as a merge barrier.
      
      [akpm@osdl.org: build fix]
      [akpm@osdl.org: another build fix]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d1bef4ed
  5. 26 Jun, 2006 5 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: Rename IOMMU option, fix help and mark option embedded. · a813ce43
      Andi Kleen authored
      
      
       - Rename the GART_IOMMU option to IOMMU to make clear it's not
         just for AMD
       - Rewrite the help text to better emphatise this fact
       - Make it an embedded option because too many people get it wrong.
      
      To my astonishment I discovered the aacraid driver tests this
      symbol directly. This looks quite broken to me - it's an internal
      implementation detail of the PCI DMA API. Can the maintainer
      please clarify what this test was intended to do?
      
      Cc: linux-scsi@vger.kernel.org
      Cc: alan@redhat.com
      Cc: markh@osdl.org
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a813ce43
    • Ingo Molnar's avatar
      [PATCH] x86_64: fix vector_lock deadlock in io_apic.c · 26a3c49c
      Ingo Molnar authored
      
      
      Fix a potential deadlock scenario introduced by io_apic.c's new vector_lock
      on i386 and x86_64.
      
      Found by the locking correctness validator. The patch was boot-tested on
      x86. For details of the deadlock scenario, see the validator output:
      
        ======================================================
        [ BUG: hard-safe -> hard-unsafe lock order detected! ]
        ------------------------------------------------------
        idle/1 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
         (msi_lock){....}, at: [<c04ff8d2>] startup_msi_irq_wo_maskbit+0x10/0x35
      
        and this task is already holding:
         (&irq_desc[i].lock){++..}, at: [<c015b924>] probe_irq_on+0x36/0x107
        which would create a new lock dependency:
         (&irq_desc[i].lock){++..} -> (msi_lock){....}
      
        but this new dependency connects a hard-irq-safe lock:
         (&irq_desc[i].lock){++..}
        ... which became hard-irq-safe at:
          [<c01468c4>] lockdep_acquire+0x68/0x84
          [<c10485e9>] _spin_lock+0x21/0x2f
          [<c015aff5>] __do_IRQ+0x3d/0x113
          [<c01062d3>] do_IRQ+0x8c/0xad
      
        to a hard-irq-unsafe lock:
         (vector_lock){--..}
        ... which became hard-irq-unsafe at:
        ...  [<c01468c4>] lockdep_acquire+0x68/0x84
          [<c10485e9>] _spin_lock+0x21/0x2f
          [<c011b5e8>] assign_irq_vector+0x34/0xc8
          [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff
          [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa
          [<c010033f>] init+0x32/0x2cb
          [<c0102005>] kernel_thread_helper+0x5/0xb
      
        which could potentially lead to deadlocks!
      
        other info that might help us debug this:
      
        3 locks held by idle/1:
         #0:  (port_mutex){--..}, at: [<c067070d>] uart_add_one_port+0x61/0x289
         #1:  (&state->mutex){--..}, at: [<c067071f>] uart_add_one_port+0x73/0x289
         #2:  (&irq_desc[i].lock){++..}, at: [<c015b924>] probe_irq_on+0x36/0x107
      
        the hard-irq-safe lock's dependencies:
        -> (&irq_desc[i].lock){++..} ops: 9861 {
           initial-use  at:
                                [<c01468c4>] lockdep_acquire+0x68/0x84
                                [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                                [<c015b415>] setup_irq+0x9b/0x14d
                                [<c1aaa4c4>] time_init_hook+0xf/0x11
                                [<c1a9f320>] time_init+0x44/0x46
                                [<c1a9955f>] start_kernel+0x191/0x38f
                                [<c0100210>] 0xc0100210
           in-hardirq-W at:
                                [<c01468c4>] lockdep_acquire+0x68/0x84
                                [<c10485e9>] _spin_lock+0x21/0x2f
                                [<c015aff5>] __do_IRQ+0x3d/0x113
                                [<c01062d3>] do_IRQ+0x8c/0xad
           in-softirq-W at:
                                [<c01468c4>] lockdep_acquire+0x68/0x84
                                [<c10485e9>] _spin_lock+0x21/0x2f
                                [<c015aff5>] __do_IRQ+0x3d/0x113
                                [<c01062d3>] do_IRQ+0x8c/0xad
         }
         ... key      at: [<c1ea31e0>] irq_desc_lock_type+0x0/0x20
          -> (i8259A_lock){++..} ops: 5149 {
             initial-use  at:
                              [<c01468c4>] lockdep_acquire+0x68/0x84
                              [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                              [<c0108090>] init_8259A+0x11/0x8f
                              [<c1aa0d22>] init_ISA_irqs+0x12/0x4d
                              [<c1aaa4f0>] pre_intr_init_hook+0x8/0xa
                              [<c1aa0cb9>] init_IRQ+0xe/0x65
                              [<c1a99546>] start_kernel+0x178/0x38f
                              [<c0100210>] 0xc0100210
             in-hardirq-W at:
                              [<c01468c4>] lockdep_acquire+0x68/0x84
                              [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                              [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc
                              [<c015b007>] __do_IRQ+0x4f/0x113
                              [<c01062d3>] do_IRQ+0x8c/0xad
             in-softirq-W at:
                              [<c01468c4>] lockdep_acquire+0x68/0x84
                              [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                              [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc
                              [<c015b007>] __do_IRQ+0x4f/0x113
                              [<c01062d3>] do_IRQ+0x8c/0xad
           }
           ... key      at: [<c142f174>] i8259A_lock+0x14/0x40
         ... acquired at:
           [<c01468c4>] lockdep_acquire+0x68/0x84
           [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
           [<c0107eb2>] enable_8259A_irq+0x10/0x47
           [<c0107f12>] startup_8259A_irq+0x8/0xc
           [<c015b45e>] setup_irq+0xe4/0x14d
           [<c1aaa4c4>] time_init_hook+0xf/0x11
           [<c1a9f320>] time_init+0x44/0x46
           [<c1a9955f>] start_kernel+0x191/0x38f
           [<c0100210>] 0xc0100210
      
          -> (ioapic_lock){+...} ops: 122 {
             initial-use  at:
                              [<c01468c4>] lockdep_acquire+0x68/0x84
                              [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                              [<c1aa71db>] io_apic_get_version+0x16/0x55
                              [<c1aa5c73>] mp_register_ioapic+0xc6/0x127
                              [<c1aa382e>] acpi_parse_ioapic+0x2d/0x39
                              [<c1abe031>] acpi_table_parse_madt_family+0xb4/0x100
                              [<c1abe093>] acpi_table_parse_madt+0x16/0x18
                              [<c1aa3c8a>] acpi_boot_init+0x132/0x251
                              [<c1aa08ea>] setup_arch+0xd36/0xe37
                              [<c1a99434>] start_kernel+0x66/0x38f
                              [<c0100210>] 0xc0100210
             in-hardirq-W at:
                              [<c01468c4>] lockdep_acquire+0x68/0x84
                              [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                              [<c011bce1>] mask_IO_APIC_irq+0x11/0x31
                              [<c011c5cc>] ack_edge_ioapic_vector+0x31/0x41
                              [<c015b007>] __do_IRQ+0x4f/0x113
                              [<c01062d3>] do_IRQ+0x8c/0xad
           }
           ... key      at: [<c1432514>] ioapic_lock+0x14/0x3c
            -> (i8259A_lock){++..} ops: 5149 {
               initial-use  at:
                               [<c01468c4>] lockdep_acquire+0x68/0x84
                               [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                               [<c0108090>] init_8259A+0x11/0x8f
                               [<c1aa0d22>] init_ISA_irqs+0x12/0x4d
                               [<c1aaa4f0>] pre_intr_init_hook+0x8/0xa
                               [<c1aa0cb9>] init_IRQ+0xe/0x65
                               [<c1a99546>] start_kernel+0x178/0x38f
                               [<c0100210>] 0xc0100210
               in-hardirq-W at:
                               [<c01468c4>] lockdep_acquire+0x68/0x84
                               [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                               [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc
                               [<c015b007>] __do_IRQ+0x4f/0x113
                               [<c01062d3>] do_IRQ+0x8c/0xad
               in-softirq-W at:
                               [<c01468c4>] lockdep_acquire+0x68/0x84
                               [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                               [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc
                               [<c015b007>] __do_IRQ+0x4f/0x113
                               [<c01062d3>] do_IRQ+0x8c/0xad
             }
             ... key      at: [<c142f174>] i8259A_lock+0x14/0x40
           ... acquired at:
           [<c01468c4>] lockdep_acquire+0x68/0x84
           [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
           [<c0107e6b>] disable_8259A_irq+0x10/0x47
           [<c011bdbd>] startup_edge_ioapic_vector+0x31/0x58
           [<c015b45e>] setup_irq+0xe4/0x14d
           [<c015b5a1>] request_irq+0xda/0xf9
           [<c1ac983a>] rtc_init+0x6a/0x1a7
           [<c0100457>] init+0x14a/0x2cb
           [<c0102005>] kernel_thread_helper+0x5/0xb
      
         ... acquired at:
           [<c01468c4>] lockdep_acquire+0x68/0x84
           [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
           [<c011bce1>] mask_IO_APIC_irq+0x11/0x31
           [<c011c5cc>] ack_edge_ioapic_vector+0x31/0x41
           [<c015b007>] __do_IRQ+0x4f/0x113
           [<c01062d3>] do_IRQ+0x8c/0xad
      
        the hard-irq-unsafe lock's dependencies:
        -> (vector_lock){--..} ops: 31 {
           initial-use  at:
                                [<c01468c4>] lockdep_acquire+0x68/0x84
                                [<c10485e9>] _spin_lock+0x21/0x2f
                                [<c011b5e8>] assign_irq_vector+0x34/0xc8
                                [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff
                                [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa
                                [<c010033f>] init+0x32/0x2cb
                                [<c0102005>] kernel_thread_helper+0x5/0xb
           softirq-on-W at:
                                [<c01468c4>] lockdep_acquire+0x68/0x84
                                [<c10485e9>] _spin_lock+0x21/0x2f
                                [<c011b5e8>] assign_irq_vector+0x34/0xc8
                                [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff
                                [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa
                                [<c010033f>] init+0x32/0x2cb
                                [<c0102005>] kernel_thread_helper+0x5/0xb
           hardirq-on-W at:
                                [<c01468c4>] lockdep_acquire+0x68/0x84
                                [<c10485e9>] _spin_lock+0x21/0x2f
                                [<c011b5e8>] assign_irq_vector+0x34/0xc8
                                [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff
                                [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa
                                [<c010033f>] init+0x32/0x2cb
                                [<c0102005>] kernel_thread_helper+0x5/0xb
         }
         ... key      at: [<c1432574>] vector_lock+0x14/0x3c
      
        stack backtrace:
         [<c0104f36>] show_trace+0xd/0xf
         [<c010543e>] dump_stack+0x17/0x19
         [<c0144e34>] check_usage+0x1f6/0x203
         [<c0146395>] __lockdep_acquire+0x8c2/0xaa5
         [<c01468c4>] lockdep_acquire+0x68/0x84
         [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
         [<c04ff8d2>] startup_msi_irq_wo_maskbit+0x10/0x35
         [<c015b932>] probe_irq_on+0x44/0x107
         [<c0673d58>] serial8250_config_port+0x84b/0x986
         [<c06707b1>] uart_add_one_port+0x105/0x289
         [<c1ace54b>] serial8250_init+0xc3/0x10a
         [<c0100457>] init+0x14a/0x2cb
         [<c0102005>] kernel_thread_helper+0x5/0xb
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      26a3c49c
    • Don Zickus's avatar
      [PATCH] x86_64: nmi watchdog header cleanup · 3e4ff115
      Don Zickus authored
      
      
      Misc header cleanup for nmi watchdog.
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3e4ff115
    • Jan Beulich's avatar
      [PATCH] i386/x86-64: simplify ioapic_register_intr() · 6ebcc00e
      Jan Beulich authored
      
      
      Simplify (remove duplication of) code in ioapic_register_intr().
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6ebcc00e
    • Jan Beulich's avatar
      [PATCH] x86_64: serialize assign_irq_vector() use of static variables · 0a1ad60d
      Jan Beulich authored
      
      
      Since assign_irq_vector() can be called at runtime, its access of static
      variables should be protected by a lock.
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0a1ad60d
  6. 08 Jun, 2006 1 commit
    • Andy Currid's avatar
      [PATCH] Fix HPET operation on 64-bit NVIDIA platforms · a2ef3a50
      Andy Currid authored
      
      
      From: "Andy Currid" <ACurrid@nvidia.com>
      
      This patch fixes a kernel panic during boot that occurs on NVIDIA platforms
      that have HPET enabled.
      
      When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2 and is
      advertised as such in the ACPI APIC table - but an earlier workaround in the
      kernel was ignoring this override.  The fix is to honor timer IRQ overrides
      from ACPI when HPET is detected on an NVIDIA platform.
      Signed-off-by: default avatarAndy Currid <acurrid@nvidia.com>
      Cc: "Brown, Len" <len.brown@intel.com>
      Cc: "Yu, Luming" <luming.yu@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a2ef3a50
  7. 08 May, 2006 1 commit
    • Kimball Murray's avatar
      [PATCH] x86_64: avoid IRQ0 ioapic pin collision · e0c1e9bf
      Kimball Murray authored
      
      
      The patch addresses a problem with ACPI SCI interrupt entry, which gets
      re-used, and the IRQ is assigned to another unrelated device.  The patch
      corrects the code such that SCI IRQ is skipped and duplicate entry is
      avoided.  Second issue came up with VIA chipset, the problem was caused by
      original patch assigning IRQs starting 16 and up.  The VIA chipset uses
      4-bit IRQ register for internal interrupt routing, and therefore cannot
      handle IRQ numbers assigned to its devices.  The patch corrects this
      problem by allowing PCI IRQs below 16.
      
      Cc: len.brown@intel.com
      
      Signed-off by: Natalie Protasevich <Natalie.Protasevich@unisys.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e0c1e9bf
  8. 25 Mar, 2006 3 commits
  9. 26 Feb, 2006 2 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: Better ATI timer fix · ab9b32ee
      Andi Kleen authored
      
      
      The previous experiment for using apicmaintimer on ATI systems didn't
      work out very well.  In particular laptops with C2/C3 support often
      don't let it tick during idle, which makes it useless.  There were also
      some other bugs that made the apicmaintimer often not used at all.
      
      I tried some other experiments - running timer over RTC and some other
      things but they didn't really work well neither.
      
      I rechecked the specs now and it turns out this simple change is
      actually enough to avoid the double ticks on the ATI systems.  We just
      turn off IRQ 0 in the 8254 and only route it directly using the IO-APIC.
      
      I tested it on a few ATI systems and it worked there.  In fact it worked
      on all chipsets (NVidia, Intel, AMD, ATI) I tried it on.
      
      According to the ACPI spec routing should always work through the
      IO-APIC so I think it's the correct thing to do anyways (and most of the
      old gunk in check_timer should be thrown away for x86-64).
      
      But for 2.6.16 it's best to do a fairly minimal change:
       - Use the known to be working everywhere-but-ATI IRQ0 both over 8254
         and IO-APIC setup everywhere
       - Except on ATI disable IRQ0 in the 8254
       - Remove the code to select apicmaintimer on ATI chipsets
       - Add some boot options to allow to override this (just paranoia)
      
      In 2.6.17 I hope to switch the default over to this for everybody.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ab9b32ee
    • Chris McDermott's avatar
      [PATCH] x86_64: Fix NMI watchdog on x460 · 1f992153
      Chris McDermott authored
      
      
      [description from AK]
      
      Old check for the IO-APIC watchdog during the timer check was wrong -
      it obviously should only drop into this if the IO-APIC watchdog is used.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1f992153
  10. 17 Feb, 2006 1 commit
  11. 04 Feb, 2006 1 commit
  12. 11 Jan, 2006 4 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: Some housekeeping in local APIC code · 11a8e778
      Andi Kleen authored
      
      
      Remove support for obsolete hardware and cleanup.
      
      - Remove checks for non integrated APICs
      - Replace apic_write_around with apic_write.
      - Remove apic_read_around
      - Remove APIC version reads used by old workarounds
      - Remove old workaround for Simics
      - Fix indentation
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      11a8e778
    • Vivek Goyal's avatar
      [PATCH] x86_64: ioapic virtual wire mode fix · af5b9804
      Vivek Goyal authored
      
      
      o Currently, during kexec reboot, IOAPIC is re-programmed back to virtual
        wire mode if there was an i8259 connected to it. This enables getting
        timer interrupts in second kernel in legacy mode.
      
      o After putting into virtual wire mode, IOAPIC delivers the i8259 interrupts
        to CPU0. This works well for kexec but not for kdump as we might crash
        on a different CPU and second kernel will not see timer interrupts.
      
      o This patch modifies the redirection table entry to deliver the timer
        interrupts to the cpu we are rebooting (instead of hardcoding to zero).
        This ensures that second kernel receives timer interrupts even on a
        non-boot cpu.
      Signed-off-by: default avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      af5b9804
    • Eric W. Biederman's avatar
      [PATCH] x86_64: Memorize location of i8259 for reboots. · 1008fddc
      Eric W. Biederman authored
      
      
      Currently we attempt to restore virtual wire mode on reboot, which only
      works if we can figure out where the i8259 is connected.  This is very
      useful when we are kexec another kernel and likely helpful to an peculiar
      BIOS that make assumptions about how the system is setup.
      
      Since the acpi MADT table does not provide the location where the i8259 is
      connected we have to look at the hardware to figure it out.
      
      Most systems have the i8259 connected the local apic of the cpu so won't be
      affected but people running Opteron and some serverworks chipsets should be
      able to use kexec now.
      
      In addition this patch removes the hard coded assumption that the io_apic
      that delivers isa interrups is always known to the kernel as io_apic 0.
      There does not appear to be anything to guarantee that assumption is true.
      
      And From: Vivek Goyal <vgoyal@in.ibm.com>
      
        A minor fix to the patch which remembers the location of where i8259 is
        connected.  Now counter i has been replaced by apic.  counter i is having
        some junk value which was leading to non-detection of i8259 connected to
        IOAPIC.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1008fddc
    • Andi Kleen's avatar
      [PATCH] x86_64: Fix off by one in IOMMU check · ca8642f6
      Andi Kleen authored
      
      
      Fix off by one when checking if the machine has enougn memory to need IOMMU
      This caused the IOMMUs to be needlessly enabled for mem=4G
      
      Based on a patch from Jon Mason
      
      Signed-off-by: jdmason@us.ibm.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ca8642f6