1. 12 8月, 2008 7 次提交
  2. 11 8月, 2008 2 次提交
    • E
      x86_64: restore the proper NR_IRQS define so larger systems work. · 3c7569b2
      Eric W. Biederman 提交于
      As pointed out and tracked by Yinghai Lu <yhlu.kernel@gmail.com>:
      
       Dhaval Giani got:
       kernel BUG at arch/x86/kernel/io_apic_64.c:357!
       invalid opcode: 0000 [1] SMP
       CPU 24
       ...
      
      his system (x3950) has 8 ioapic, irq > 256
      
      This was caused by:
      
             commit 9b7dc567
             Author: Thomas Gleixner <tglx@linutronix.de>
             Date:   Fri May 2 20:10:09 2008 +0200
      
                x86: unify interrupt vector defines
      
                The interrupt vector defines are copied 4 times around with minimal
                differences. Move them all into asm-x86/irq_vectors.h
      
      It appears that Thomas did not notice that x86_64 does something
      completely different when he merge irq_vectors.h
      
      We can solve this for 2.6.27 by simply reintroducing the old heuristic
      for setting NR_IRQS on x86_64 to a usable value, which trivially removes
      the regression.
      
      Long term it would be nice to harmonize the handling of ioapic interrupts
      of x86_32 and x86_64 so we don't have this kind of confusion.
      
      Dhaval Giani <dhaval@linux.vnet.ibm.com> tested an earlier version of
      this patch by YH which confirms simply increasing NR_IRQS fixes the
      problem.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Acked-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3c7569b2
    • E
      x86: Restore proper vector locking during cpu hotplug · d388e5fd
      Eric W. Biederman 提交于
      Having cpu_online_map change during assign_irq_vector can result
      in some really nasty and weird things happening.  The one that
      bit me last time was accessing non existent per cpu memory for non
      existent cpus.
      
      This locking was removed in a sloppy x86_64 and x86_32 merge patch.
      
      Guys can we please try and avoid subtly breaking x86 when we are
      merging files together?
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      d388e5fd
  3. 09 8月, 2008 1 次提交
  4. 01 8月, 2008 1 次提交
    • K
      x86: fdiv bug detection fix · e0d22d03
      Krzysztof Helt 提交于
      The fdiv detection code writes s32 integer into
      the boot_cpu_data.fdiv_bug.
      However, the boot_cpu_data.fdiv_bug is only char (s8)
      field so the detection overwrites already set fields for
      other bugs, e.g. the f00f bug field.
      
      Use local s32 variable to receive result.
      
      This is a partial fix to Bugzilla #9928  - fixes wrong
      information about the f00f bug (tested) and probably
      for coma bug (I have no cpu to test this).
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e0d22d03
  5. 29 7月, 2008 29 次提交