1. 11 Aug, 2008 5 commits
    • Jeremy Fitzhardinge's avatar
      x86: work around gcc 3.4.x bug · cf3e5050
      Jeremy Fitzhardinge authored
      Simon Horman reported that gcc-3.4.x crashes when compiling
      pgd_prepopulate_pmd() when PREALLOCATED_PMDS == 0 and CONFIG_DEBUG_INFO
      is enabled.
      
      Adding an extra check for PREALLOCATED_PMDS == 0 [which is compiled out
      by gcc] seems to avoid the problem.
      Reported-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Acked-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cf3e5050
    • Rene Herman's avatar
      x86: make "apic" an early_param() on 32-bit · fb6bef80
      Rene Herman authored
      On 32-bit, "apic" is a __setup() param meaning it is parsed rather
      late in the game. Make it an early_param() for apic_printk() use
      by arch/x86/kernel/mpparse.c.
      
      On 64-bit, it already is an early_param().
      Signed-off-by: default avatarRene Herman <rene.herman@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      fb6bef80
    • Rene Herman's avatar
      x86, debug: tone down arch/x86/kernel/mpparse.c debugging printk · eeb0d7d1
      Rene Herman authored
      commit 11a62a05 turns some formerly
      nopped debugging printks in arch/x86/kernel/mppparse.c into regular
      ones. The one at the top of smp_scan_config() in particular also
      prints on !CONFIG_SMP/CONFIG_X86_LOCAL_APIC kernels and UP machines
      without anything resembling MP tables which makes their lowly UP
      owners wonder...
      
      Turn the former Dprintk()s into apic_printk()s instead meaning that
      their printing is dependent on passing the apic=verbose (or =debug)
      command line param.
      
      On 32-bit, "apic" is a __setup() param which isn't early enough
      for this code and therefore needs a followup changing it into an
      early_param(). On 64-bit, it already is.
      Signed-off-by: default avatarRene Herman <rene.herman@gmail.com>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      eeb0d7d1
    • Eric W. Biederman's avatar
      x86_64: restore the proper NR_IRQS define so larger systems work. · 3c7569b2
      Eric W. Biederman authored
      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: default avatarEric W. Biederman <ebiederm@xmission.com>
      Acked-by: default avatarYinghai 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: default avatarIngo Molnar <mingo@elte.hu>
      3c7569b2
    • Eric W. Biederman's avatar
      x86: Restore proper vector locking during cpu hotplug · d388e5fd
      Eric W. Biederman authored
      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: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      d388e5fd
  2. 08 Aug, 2008 1 commit
  3. 31 Jul, 2008 1 commit
    • Krzysztof Helt's avatar
      x86: fdiv bug detection fix · e0d22d03
      Krzysztof Helt authored
      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: default avatarKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e0d22d03
  4. 29 Jul, 2008 8 commits
  5. 28 Jul, 2008 25 commits