1. 04 Oct, 2006 5 commits
    • 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: i386 irq: Remove the msi assumption that irq == vector · ace80ab7
      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
      
      [akpm@osdl.org: cleanup]
      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>
      ace80ab7
    • Eric W. Biederman's avatar
      [PATCH] genirq: i386 irq: Move msi message composition into io_apic.c · 2d3fcc1c
      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>
      2d3fcc1c
    • Eric W. Biederman's avatar
      [PATCH] genirq: i386 irq: Dynamic irq support · 3fc471ed
      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 stuck this hack of assuming irq == vector until the
      depencencies in the generic msi 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>
      3fc471ed
    • Ingo Molnar's avatar
      [PATCH] genirq: convert the i386 architecture to irq-chips · f5b9ed7a
      Ingo Molnar authored
      
      
      This patch converts all the i386 PIC controllers (except VisWS and Voyager,
      which I could not test - but which should still work as old-style IRQ layers)
      to the new and simpler irq-chip interrupt handling layer.
      
      [akpm@osdl.org: build fix]
      [mingo@elte.hu: enable fasteoi handler for i386 level-triggered IO-APIC irqs]
      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>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f5b9ed7a
  2. 26 Sep, 2006 3 commits
    • Rusty Russell's avatar
      [PATCH] i386: Replace i386 open-coded cmdline parsing with · 1a3f239d
      Rusty Russell authored
      
      
      This patch replaces the open-coded early commandline parsing
      throughout the i386 boot code with the generic mechanism (already used
      by ppc, powerpc, ia64 and s390).  The code was inconsistent with
      whether it deletes the option from the cmdline or not, meaning some of
      these will get passed through the environment into init.
      
      This transformation is mainly mechanical, but there are some notable
      parts:
      
      1) Grammar: s/linux never set's it up/linux never sets it up/
      
      2) Remove hacked-in earlyprintk= option scanning.  When someone
         actually implements CONFIG_EARLY_PRINTK, then they can use
         early_param().
      [AK: actually it is implemented, but I'm adding the early_param it in the next
      x86-64 patch]
      
      3) Move declaration of generic_apic_probe() from setup.c into asm/apic.h
      
      4) Various parameters now moved into their appropriate files (thanks Andi).
      
      5) All parse functions which examine arg need to check for NULL,
         except one where it has subtle humor value.
      
      AK: readded acpi_sci handling which was completely dropped
      AK: moved some more variables into acpi/boot.c
      
      Cc: len.brown@intel.com
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      1a3f239d
    • Andi Kleen's avatar
      [PATCH] i386: Factor out common io apic routing entry access · cf4c6a2f
      Andi Kleen authored
      
      
      The IO APIC code had lots of duplicated code to read/write 64bit
      routing entries into the IO-APIC. Factor this out int common read/write
      functions
      
      In a few cases the IO APIC lock is taken more often now, but this
      isn't a problem because it's all initialization/shutdown only
      slow path code.
      
      Similar to earlier x86-64 patch.
      
      Includes a fix by Jiri Slaby for a mistake that broke resume
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      cf4c6a2f
    • Andi Kleen's avatar
      [PATCH] i386: Allow to use GENERICARCH for UP kernels · 874c4fe3
      Andi Kleen authored
      
      
      There are some machines around (large xSeries or Unisys ES7000) that
      need physical IO-APIC destination mode to access all of their IO
      devices. This currently doesn't work in UP kernels as used in
      distribution installers.
      
      This patch allows to compile even UP kernels as GENERICARCH which
      allows to use physical or clustered APIC mode.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      874c4fe3
  3. 30 Jun, 2006 1 commit
  4. 29 Jun, 2006 3 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: cleanup: merge pending_irq_cpumask[] into irq_desc[] · cd916d31
      Ingo Molnar authored
      
      
      Consolidation: remove the pending_irq_cpumask[NR_IRQS] array and move it into
      the irq_desc[NR_IRQS].pending_mask field.
      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>
      cd916d31
    • 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 4 commits
    • 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. 23 Jun, 2006 1 commit
    • Zhang Yanmin's avatar
      [PATCH] x86: kernel irq balance doesn't work · 1b61b910
      Zhang Yanmin authored
      
      
      On i386, kernel irq balance doesn't work.
      
      1) In function do_irq_balance, after kernel finds the min_loaded cpu but
         before calling set_pending_irq to really pin the selected_irq to the
         target cpu, kernel does a cpus_and with irq_affinity[selected_irq].
         Later on, when the irq is acked, kernel would calls
         move_native_irq=>desc->handler->set_affinity to change the irq affinity.
          However, every function pointed by
         hw_interrupt_type->set_affinity(unsigned int irq, cpumask_t cpumask)
         always changes irq_affinity[irq] to cpumask.  Next time when recalling
         do_irq_balance, it has to do cpu_ands again with
         irq_affinity[selected_irq], but irq_affinity[selected_irq] already
         becomes one cpu selected by the first irq balance.
      
      2) Function balance_irq in file arch/i386/kernel/io_apic.c has the same
         issue.
      
      [akpm@osdl.org: cleanups]
      Signed-off-by: default avatarZhang Yanmin <yanmin.zhang@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1b61b910
  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. 31 Mar, 2006 1 commit
    • OGAWA Hirofumi's avatar
      [PATCH] Don't pass boot parameters to argv_init[] · 9b41046c
      OGAWA Hirofumi authored
      
      
      The boot cmdline is parsed in parse_early_param() and
      parse_args(,unknown_bootoption).
      
      And __setup() is used in obsolete_checksetup().
      
      	start_kernel()
      		-> parse_args()
      			-> unknown_bootoption()
      				-> obsolete_checksetup()
      
      If __setup()'s callback (->setup_func()) returns 1 in
      obsolete_checksetup(), obsolete_checksetup() thinks a parameter was
      handled.
      
      If ->setup_func() returns 0, obsolete_checksetup() tries other
      ->setup_func().  If all ->setup_func() that matched a parameter returns 0,
      a parameter is seted to argv_init[].
      
      Then, when runing /sbin/init or init=app, argv_init[] is passed to the app.
      If the app doesn't ignore those arguments, it will warning and exit.
      
      This patch fixes a wrong usage of it, however fixes obvious one only.
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9b41046c
  9. 28 Mar, 2006 1 commit
  10. 23 Mar, 2006 2 commits
    • Andrew Morton's avatar
      [PATCH] more for_each_cpu() conversions · 394e3902
      Andrew Morton authored
      
      
      When we stop allocating percpu memory for not-possible CPUs we must not touch
      the percpu data for not-possible CPUs at all.  The correct way of doing this
      is to test cpu_possible() or to use for_each_cpu().
      
      This patch is a kernel-wide sweep of all instances of NR_CPUS.  I found very
      few instances of this bug, if any.  But the patch converts lots of open-coded
      test to use the preferred helper macros.
      
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Acked-by: default avatarKyle McMartin <kyle@parisc-linux.org>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Christian Zankel <chris@zankel.net>
      Cc: Philippe Elie <phil.el@wanadoo.fr>
      Cc: Nathan Scott <nathans@sgi.com>
      Cc: Jens Axboe <axboe@suse.de>
      Cc: Eric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      394e3902
    • Shaohua Li's avatar
      [PATCH] x86: deterine xapic using apic version · 7c5c1e42
      Shaohua Li authored
      
      
      Checking APIC version instead of CPU family to determine XAPIC. Family 6
      CPU could have xapic as well.
      
      Signed-off-by: Shaohua Li<shaohua.li@intel.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Cc: "Seth, Rohit" <rohit.seth@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>
      7c5c1e42
  11. 08 Mar, 2006 1 commit
    • Andi Kleen's avatar
      [PATCH] i386: port ATI timer fix from x86_64 to i386 II · f9262c12
      Andi Kleen authored
      
      
      ATI chipsets tend to generate double timer interrupts for the local APIC
      timer when both the 8254 and the IO-APIC timer pins are enabled.  This is
      because they route it to both and the result is anded together and the CPU
      ends up processing it twice.
      
      This patch changes check_timer to disable the 8254 routing for interrupt 0.
      
      I think it would be safe on all chipsets actually (i tested it on a couple
      and it worked everywhere) and Windows seems to do it in a similar way, but
      to be conservative this patch only enables this mode on ATI (and adds
      options to enable/disable too)
      
      Ported over from a similar x86-64 change.
      
      I reused the ACPI earlyquirk infrastructure for the ATI bridge check, but
      tweaked it a bit to work even without ACPI.
      
      Inspired by a patch from Chuck Ebbert, but redone.
      
      Cc: Chuck Ebbert <76306.1226@compuserve.com>
      Cc: "Brown, Len" <len.brown@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f9262c12
  12. 26 Feb, 2006 1 commit
  13. 11 Jan, 2006 1 commit
    • 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
  14. 06 Jan, 2006 1 commit
    • Vivek Goyal's avatar
      [PATCH] i386: ioapic virtual wire mode fix · 76865c3f
      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>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Seth, Rohit" <rohit.seth@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      76865c3f
  15. 29 Nov, 2005 1 commit
  16. 31 Oct, 2005 1 commit
  17. 30 Oct, 2005 2 commits
    • Eric W. Biederman's avatar
      [PATCH] i386: move apic init in init_IRQs · f2b36db6
      Eric W. Biederman authored
      
      
      All kinds of ugliness exists because we don't initialize
      the apics during init_IRQs.
      - We calibrate jiffies in non apic mode even when we are using apics.
      - We have to have special code to initialize the apics when non-smp.
      - The legacy i8259 must exist and be setup correctly, even
        when we won't use it past initialization.
      - The kexec on panic code must restore the state of the io_apics.
      - init/main.c needs a special case for !smp smp_init on x86
      
      In addition to pure code movement I needed a couple
      of non-obvious changes:
      - Move setup_boot_APIC_clock into APIC_late_time_init for
        simplicity.
      - Use cpu_khz to generate a better approximation of loops_per_jiffies
        so I can verify the timer interrupt is working.
      - Call setup_apic_nmi_watchdog again after cpu_khz is initialized on
        the boot cpu.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f2b36db6
    • Eric W. Biederman's avatar
      [PATCH] i386 io_apic.c: Memorize at bootup where the i8259 is connected · fcfd636a
      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 kexec another kernel and likely helpful when dealing with a
      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.  As
      there does not appear to be anything to guarantee that assumption is true.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      fcfd636a
  18. 26 Sep, 2005 1 commit
  19. 12 Sep, 2005 1 commit
  20. 10 Sep, 2005 1 commit
  21. 09 Sep, 2005 1 commit
  22. 07 Sep, 2005 2 commits
  23. 24 Aug, 2005 1 commit
  24. 30 Jun, 2005 1 commit
  25. 25 Jun, 2005 2 commits