1. 18 12月, 2009 1 次提交
    • S
      x86, irq: Allow 0xff for /proc/irq/[n]/smp_affinity on an 8-cpu system · 18374d89
      Suresh Siddha 提交于
      John Blackwood reported:
      > on an older Dell PowerEdge 6650 system with 8 cpus (4 are hyper-threaded),
      > and  32 bit (x86) kernel, once you change the irq smp_affinity of an irq
      > to be less than all cpus in the system, you can never change really the
      > irq smp_affinity back to be all cpus in the system (0xff) again,
      > even though no error status is returned on the "/bin/echo ff >
      > /proc/irq/[n]/smp_affinity" operation.
      >
      > This is due to that fact that BAD_APICID has the same value as
      > all cpus (0xff) on 32bit kernels, and thus the value returned from
      > set_desc_affinity() via the cpu_mask_to_apicid_and() function is treated
      > as a failure in set_ioapic_affinity_irq_desc(), and no affinity changes
      > are made.
      
      set_desc_affinity() is already checking if the incoming cpu mask
      intersects with the cpu online mask or not. So there is no need
      for the apic op cpu_mask_to_apicid_and() to check again
      and return BAD_APICID.
      
      Remove the BAD_APICID return value from cpu_mask_to_apicid_and()
      and also fix set_desc_affinity() to return -1 instead of using BAD_APICID
      to represent error conditions (as cpu_mask_to_apicid_and() can return
      logical or physical apicid values and BAD_APICID is really to represent
      bad physical apic id).
      Reported-by: NJohn Blackwood <john.blackwood@ccur.com>
      Root-caused-by: NJohn Blackwood <john.blackwood@ccur.com>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <1261103386.2535.409.camel@sbs-t61>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      18374d89
  2. 02 11月, 2009 1 次提交
    • S
      x86: Remove move_cleanup_count from irq_cfg · 23359a88
      Suresh Siddha 提交于
      move_cleanup_count for each irq in irq_cfg is keeping track of
      the total number of cpus that need to free the corresponding
      vectors associated with the irq which has now been migrated to
      new destination. As long as this move_cleanup_count is non-zero
      (i.e., as long as we have n't freed the vector allocations on
      the old destinations) we were preventing the irq's further
      migration.
      
      This cleanup count is unnecessary and it is enough to not allow
      the irq migration till we send the cleanup vector to the
      previous irq destination, for which we already have irq_cfg's
      move_in_progress.  All we need to make sure is that we free the
      vector at the old desintation but we don't need to wait till
      that gets freed.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: NGary Hade <garyhade@us.ibm.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <20091026230001.752968906@sbs-t61.sc.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      23359a88
  3. 15 10月, 2009 1 次提交
  4. 14 10月, 2009 2 次提交
    • I
      x86, apic: Fix prototype in hw_irq.h · 7ec13187
      Ingo Molnar 提交于
      This warning:
      
       In file included from arch/x86/include/asm/ipi.h:23,
                        from arch/x86/kernel/apic/apic_noop.c:27:
       arch/x86/include/asm/hw_irq.h:105: warning: ‘struct irq_desc’ declared inside parameter list
       arch/x86/include/asm/hw_irq.h:105: warning: its scope is only this definition or declaration, which is probably not what you want
      
      triggers because irq_desc is defined after hw_irq.h is included
      in irq.h. Since it's pointer reference only, a forward declaration
      of the type will solve the problem.
      
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7ec13187
    • D
      x86, apic: Move SGI UV functionality out of generic IO-APIC code · 9338ad6f
      Dimitri Sivanich 提交于
      Move UV specific functionality out of the generic IO-APIC code.
      Signed-off-by: NDimitri Sivanich <sivanich@sgi.com>
      LKML-Reference: <20091013203236.GD20543@sgi.com>
      [ Cleaned up the code some more in their new places. ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9338ad6f
  5. 04 6月, 2009 2 次提交
    • A
      x86: fix panic with interrupts off (needed for MCE) · 4ef702c1
      Andi Kleen 提交于
      For some time each panic() called with interrupts disabled
      triggered the !irqs_disabled() WARN_ON in smp_call_function(),
      producing ugly backtraces and confusing users.
      
      This is a common situation with machine checks for example which
      tend to call panic with interrupts disabled, but will also hit
      in other situations e.g. panic during early boot.  In fact it
      means that panic cannot be called in many circumstances, which
      would be bad.
      
      This all started with the new fancy queued smp_call_function,
      which is then used by the shutdown path to shut down the other
      CPUs.
      
      On closer examination it turned out that the fancy RCU
      smp_call_function() does lots of things not suitable in a panic
      situation anyways, like allocating memory and relying on complex
      system state.
      
      I originally tried to patch this over by checking for panic
      there, but it was quite complicated and the original patch
      was also not very popular.  This also didn't fix some of the
      underlying complexity problems.
      
      The new code in post 2.6.29 tries to patch around this by
      checking for oops_in_progress, but that is not enough to make
      this fully safe and I don't think that's a real solution
      because panic has to be reliable.
      
      So instead use an own vector to reboot.  This makes the reboot
      code extremly straight forward, which is definitely a big plus
      in a panic situation where it is important to avoid relying on
      too much kernel state.  The new simple code is also safe to be
      called from interupts off region because it is very very simple.
      
      There can be situations where it is important that panic
      is reliable.  For example on a fatal machine check the panic
      is needed to get the system up again and running as quickly
      as possible.  So it's important that panic is reliable and
      all function it calls simple.
      
      This is why I came up with this simple vector scheme.
      It's very hard to beat in simplicity.  Vectors are not
      particularly precious anymore since all big systems are
      using per CPU vectors.
      
      Another possibility would have been to use an NMI similar
      to kdump, but there is still the problem that NMIs don't
      work reliably on some systems due to BIOS issues.  NMIs
      would have been able to stop CPUs running with interrupts
      off too.  In the sake of universal reliability I opted for
      using a non NMI vector for now.
      
      I put the reboot vector into the highest priority bucket of
      the APIC vectors and moved the 64bit UV_BAU message down
      instead into the next lower priority.
      
      [ Impact: bug fix, fixes an old regression ]
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      4ef702c1
    • A
      x86, mce: implement bootstrapping for machine check wakeups · ccc3c319
      Andi Kleen 提交于
      Machine checks support waking up the mcelog daemon quickly.
      
      The original wake up code for this was pretty ugly, relying on
      a idle notifier and a special process flag. The reason it did
      it this way is that the machine check handler is not subject
      to normal interrupt locking rules so it's not safe
      to call wake_up().  Instead it set a process flag
      and then either did the wakeup in the syscall return
      or in the idle notifier.
      
      This patch adds a new "bootstraping" method as replacement.
      
      The idea is that the handler checks if it's in a state where
      it is unsafe to call wake_up(). If it's safe it calls it directly.
      When it's not safe -- that is it interrupted in a critical
      section with interrupts disables -- it uses a new "self IPI" to trigger
      an IPI to its own CPU. This can be done safely because IPI
      triggers are atomic with some care. The IPI is raised
      once the interrupts are reenabled and can then safely call
      wake_up().
      
      When APICs are disabled the event is just queued and will be picked up
      eventually by the next polling timer. I think that's a reasonable
      compromise, since it should only happen quite rarely.
      
      Contains fixes from Ying Huang.
      
      [ solve conflict on irqinit, make it work on 32bit (entry_arch.h) - HS ]
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      ccc3c319
  6. 03 6月, 2009 1 次提交
    • Y
      perf_counter/x86: Remove the IRQ (non-NMI) handling bits · a3288106
      Yong Wang 提交于
      Remove the IRQ (non-NMI) handling bits as NMI will be used always.
      Signed-off-by: NYong Wang <yong.y.wang@intel.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <20090603051255.GA2791@ywang-moblin2.bj.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a3288106
  7. 18 5月, 2009 1 次提交
    • Y
      x86, apic: introduce io_apic_irq_attr · e5198075
      Yinghai Lu 提交于
      according to Ingo, io_apic irq-setup related functions have too many
      parameters with a repetitive signature.
      
      So reduce related funcs to get less params by passing a pointer
      to a newly defined io_apic_irq_attr structure.
      
      v2: io_apic_irq ==> irq_attr
          triggering ==> trigger
      
      v3: add set_io_apic_irq_attr
      
      [ Impact: cleanup ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <4A08ACD3.2070401@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e5198075
  8. 11 5月, 2009 1 次提交
  9. 12 4月, 2009 1 次提交
    • J
      x86: clean up declarations and variables · 2c1b284e
      Jaswinder Singh Rajput 提交于
      Impact: cleanup, no code changed
      
       - syscalls.h       update declarations due to unifications
       - irq.c            declare smp_generic_interrupt() before it gets used
       - process.c        declare sys_fork() and sys_vfork() before they get used
       - tsc.c            rename tsc_khz shadowed variable
       - apic/probe_32.c  declare apic_default before it gets used
       - apic/nmi.c       prev_nmi_count should be unsigned
       - apic/io_apic.c   declare smp_irq_move_cleanup_interrupt() before it gets used
       - mm/init.c        declare direct_gbpages and free_initrd_mem before they get used
      Signed-off-by: NJaswinder Singh Rajput <jaswinder@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2c1b284e
  10. 07 4月, 2009 1 次提交
  11. 05 3月, 2009 1 次提交
  12. 10 2月, 2009 1 次提交
  13. 09 2月, 2009 1 次提交
  14. 06 2月, 2009 1 次提交
  15. 31 1月, 2009 1 次提交
  16. 29 1月, 2009 2 次提交
    • I
      x86: replace CONFIG_X86_SMP with CONFIG_SMP · 3e5095d1
      Ingo Molnar 提交于
      The x86/Voyager subarch used to have this distinction between
       'x86 SMP support' and 'Voyager SMP support':
      
       config X86_SMP
      	bool
      	depends on SMP && ((X86_32 && !X86_VOYAGER) || X86_64)
      
      This is a pointless distinction - Voyager can (and already does) use
      smp_ops to implement various SMP quirks it has - and it can be extended
      more to cover all the specialities of Voyager.
      
      So remove this complication in the Kconfig space.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3e5095d1
    • I
      x86, apic: untangle the send_IPI_*() jungle · dac5f412
      Ingo Molnar 提交于
      Our send_IPI_*() methods and definitions are a twisted mess: the same
      symbol is defined to different things depending on .config details,
      in a non-transparent way.
      
       - spread out the quirks into separately named per apic driver methods
      
       - prefix the standard PC methods with default_
      
       - get rid of wrapper macro obfuscation
      
       - clean up various details
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dac5f412
  17. 08 12月, 2008 1 次提交
    • I
      performance counters: x86 support · 241771ef
      Ingo Molnar 提交于
      Implement performance counters for x86 Intel CPUs.
      
      It's simplified right now: the PERFMON CPU feature is assumed,
      which is available in Core2 and later Intel CPUs.
      
      The design is flexible to be extended to more CPU types as well.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      241771ef
  18. 12 11月, 2008 2 次提交
    • H
      x86: 64 bits: shrink and align IRQ stubs · 939b7871
      H. Peter Anvin 提交于
      Move the IRQ stub generation to assembly to simplify it and for
      consistency with 32 bits.  Doing it in a C file with asm() statements
      doesn't help clarity, and it prevents some optimizations.
      
      Shrink the IRQ stubs down to just over four bytes per (we fit seven
      into a 32-byte chunk.)  This shrinks the total icache consumption of
      the IRQ stubs down to an even kilobyte, if all of them are in active
      use.
      
      The downside is that we end up with a double jump, which could have a
      negative effect on some pipelines.  The double jump is always inside
      the same cacheline on any modern chips.
      
      To get the most effect, cache-align the IRQ stubs.
      
      This makes the 64-bit code match changes already done to the 32-bit
      code, and should open up irqinit*.c for unification.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      939b7871
    • H
      x86: 32 bit: interrupt stub consistency with 64 bit · 4687518c
      H. Peter Anvin 提交于
      Don't generate interrupt stubs for interrupt vectors below
      FIRST_EXTERNAL_VECTOR, and make the table of interrupt vectors
      (interrupt[]) __initconst.  Both of these changes both conserve memory
      and improve consistency with 64 bits.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      4687518c
  19. 23 10月, 2008 2 次提交
  20. 16 10月, 2008 3 次提交
  21. 11 8月, 2008 1 次提交
  22. 25 7月, 2008 2 次提交
  23. 24 7月, 2008 1 次提交
    • M
      x86: PIC, L-APIC and I/O APIC debug information · 32f71aff
      Maciej W. Rozycki 提交于
       Dump all the PIC, local APIC and I/O APIC information at the
      fs_initcall() level, which is after ACPI (if used) has initialised PCI
      information, making the point of invocation consistent across MP-table and
      ACPI platforms.  Remove explicit calls to print_IO_APIC() from elsewhere.
      Make the interface of all the functions involved consistent between 32-bit
      and 64-bit versions and make them all static by default by the means of a
      New-and-Improved(TM) __apicdebuginit() macro.
      
       Note that like print_IO_APIC() all these only output anything if
      "apic=debug" has been passed to the kernel through the command line.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      32f71aff
  24. 23 7月, 2008 2 次提交
  25. 12 7月, 2008 1 次提交
  26. 08 7月, 2008 1 次提交
  27. 13 5月, 2008 5 次提交