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: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAndi Kleen <ak@suse.de>

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: NAndi Kleen <ak@suse.de>

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: NAndi Kleen <ak@suse.de>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

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: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Consolidation: remove the pending_irq_cpumask[NR_IRQS] array and move it into
the irq_desc[NR_IRQS].pending_mask field.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NIngo Molnar <mingo@elte.hu>
Cc: Jan Beulich <jbeulich@novell.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Misc header cleanup for nmi watchdog.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Simplify (remove duplication of) code in ioapic_register_intr().
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Since assign_irq_vector() can be called at runtime, its access of static
variables should be protected by a lock.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NZhang Yanmin <yanmin.zhang@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NAndi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch replaces for_each_cpu with for_each_possible_cpu.

under arch/i386.
Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NKyle 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: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

[description from AK]

This fixes booting in APIC mode on some ACER laptops. x86-64
did a similar change some time ago.

See http://bugzilla.kernel.org/show_bug.cgi?id=4700 for details
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NVivek Goyal <vgoyal@in.ibm.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Seth, Rohit" <rohit.seth@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Setting irq affinity stops working when MSI is enabled.  With MSI, move_irq
is empty, so we can't change irq affinity.  It appears a typo in Ashok's
original commit for this issue.  X86_64 actually is using move_native_irq.
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Commit f2b36db6 causes a bootup hang on
at least one machine.  Revert for now until we understand why.  The old
code may be ugly, but it works.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

	Most of these guys are simply not needed (pulled by other stuff
via asm-i386/hardirq.h).  One that is not entirely useless is hilarious -
arch/i386/oprofile/nmi_timer_int.c includes linux/irq.h... as a way to
get linux/errno.h
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Original patch from Bertro Simul

This is probably still not quite correct, but seems to be
the best solution so far.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Use schedule_timeout_interruptible() instead of
set_current_state()/schedule_timeout() to reduce kernel size.
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The legacy PIC's name is "i8259".
Signed-off-by: NKarsten Wiese <annabellesgarden@yahoo.de>
Signed-off-by: NVojtech Pavlik <vojtech@suse.cz>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Mark variables which are usually accessed for reads with __readmostly.
Signed-off-by: NAlok N Kataria <alokk@calsoftinc.com>
Signed-off-by: NShai Fultheim <shai@scalex86.org>
Signed-off-by: NRavikiran Thirumalai <kiran@scalex86.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When handling writes to /proc/irq, current code is re-programming rte
entries directly. This is not recommended and could potentially cause
chipset's to lockup, or cause missing interrupts.

CONFIG_IRQ_BALANCE does this correctly, where it re-programs only when the
interrupt is pending. The same needs to be done for /proc/irq handling as well.
Otherwise user space irq balancers are really not doing the right thing.

- Changed pending_irq_balance_cpumask to pending_irq_migrate_cpumask for
  lack of a generic name.
- added move_irq out of IRQ_BALANCE, and added this same to X86_64
- Added new proc handler for write, so we can do deferred write at irq
  handling time.
- Display of /proc/irq/XX/smp_affinity used to display CPU_MASKALL, instead
  it now shows only active cpu masks, or exactly what was set.
- Provided a common move_irq implementation, instead of duplicating
  when using generic irq framework.

Tested on i386/x86_64 and ia64 with CONFIG_PCI_MSI turned on and off.
Tested UP builds as well.

MSI testing: tbd: I have cards, need to look for a x-over cable, although I
did test an earlier version of this patch.  Will test in a couple days.
Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Acked-by: NZwane Mwaikambo <zwane@holomorphy.com>
Grudgingly-acked-by: NAndi Kleen <ak@muc.de>
Signed-off-by: NCoywolf Qi Hunt <coywolf@lovecn.org>
Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

it has been a synonym for CONFIG_ACPI since 2.6.12
Signed-off-by: NLen Brown <len.brown@intel.com>

Introduce proper declarations for i8253_lock and i8259A_lock.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

1. Establish a simple API for process freezing defined in linux/include/sched.h:

   frozen(process)		Check for frozen process
   freezing(process)		Check if a process is being frozen
   freeze(process)		Tell a process to freeze (go to refrigerator)
   thaw_process(process)	Restart process
   frozen_process(process)	Process is frozen now

2. Remove all references to PF_FREEZE and PF_FROZEN from all
   kernel sources except sched.h

3. Fix numerous locations where try_to_freeze is manually done by a driver

4. Remove the argument that is no longer necessary from two function calls.

5. Some whitespace cleanup

6. Clear potential race in refrigerator (provides an open window of PF_FREEZE
   cleared before setting PF_FROZEN, recalc_sigpending does not check
   PF_FROZEN).

This patch does not address the problem of freeze_processes() violating the rule
that a task may only modify its own flags by setting PF_FREEZE. This is not clean
in an SMP environment. freeze(process) is therefore not SMP safe!
Signed-off-by: NChristoph Lameter <christoph@lameter.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When coming out of apic mode attempt to set the appropriate
apic back into virtual wire mode.  This improves on previous versions
of this patch by by never setting bot the local apic and the ioapic
into veritual wire mode.

This code looks at data from the mptable to see if an ioapic has
an ExtInt input to make this decision.  A future improvement
is to figure out which apic or ioapic was in virtual wire mode
at boot time and to remember it.  That is potentially a more accurate
method, of selecting which apic to place in virutal wire mode.
Signed-off-by: NEric Biederman <ebiederm@xmission.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

(The i386 CPU hotplug patch provides infrastructure for some work which Pavel
is doing as well as for ACPI S3 (suspend-to-RAM) work which Li Shaohua
<shaohua.li@intel.com> is doing)

The following provides i386 architecture support for safely unregistering and
registering processors during runtime, updated for the current -mm tree.  In
order to avoid dumping cpu hotplug code into kernel/irq/* i dropped the
cpu_online check in do_IRQ() by modifying fixup_irqs().  The difference being
that on cpu offline, fixup_irqs() is called before we clear the cpu from
cpu_online_map and a long delay in order to ensure that we never have any
queued external interrupts on the APICs.  There are additional changes to s390
and ppc64 to account for this change.

1) Add CONFIG_HOTPLUG_CPU
2) disable local APIC timer on dead cpus.
3) Disable preempt around irq balancing to prevent CPUs going down.
4) Print irq stats for all possible cpus.
5) Debugging check for interrupts on offline cpus.
6) Hacky fixup_irqs() to redirect irqs when cpus go off/online.
7) play_dead() for offline cpus to spin inside.
8) Handle offline cpus set in flush_tlb_others().
9) Grab lock earlier in smp_call_function() to prevent CPUs going down.
10) Implement __cpu_disable() and __cpu_die().
11) Enable local interrupts in cpu_enable() after fixup_irqs()
12) Don't fiddle with NMI on dead cpu, but leave intact on other cpus.
13) Program IRQ affinity whilst cpu is still in cpu_online_map on offline.
Signed-off-by: NZwane Mwaikambo <zwane@linuxpower.ca>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

* EXPORT_SYMBOL's moved to other files
* #include <linux/config.h>, <linux/module.h> where needed
* #include's in i386_ksyms.c cleaned up
* After copy-paste, redundant due to Makefiles rules preprocessor directives
  removed:

	#ifdef CONFIG_FOO
	EXPORT_SYMBOL(foo);
	#endif

	obj-$(CONFIG_FOO) += foo.o

* Tiny reformat to fit in 80 columns
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch is per Andi's request to remove NO_IOAPIC_CHECK from genapic and
use heuristics to prevent unique I/O APIC ID check for systems that don't
need it.  The patch disables unique I/O APIC ID check for Xeon-based and
other platforms that don't use serial APIC bus for interrupt delivery.
Andi stated that AMD systems don't need unique IO_APIC_IDs either.
Signed-off-by: NNatalie Protasevich <Natalie.Protasevich@unisys.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

A bug against an xSeries system showed up recently noting that the
check_nmi_watchdog() test was failing.

I have been investigating it and discovered in both i386 and x86_64 the
recent change to the routine to use the cpu_callin_map has uncovered a
problem.  Prior to that change, on an SMP box, the test was trivally
passing because all cpu's were found to not yet be online, but now with the
callin_map they are discovered, it goes on to test the counter and they
have not yet begun to increment, so it announces a CPU is stuck and bails
out.

On all the systems I have access to test, the announcement of failure is
also bougs...  by the time you can login and check /proc/interrupts, the
NMI count is happily incrementing on all CPUs.  Its just that the test is
being done too early.

I have tried moving the call to the test around a bit, and it was always
too early.  I finally hit on this proposed solution, it delays the routine
via a late_initcall(), seems like the right solution to me.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>