1. 11 9月, 2009 25 次提交
  2. 06 9月, 2009 1 次提交
  3. 04 9月, 2009 1 次提交
    • D
      sparc64: Fix bootup with mcount in some configs. · bd4352ca
      David S. Miller 提交于
      Functions invoked early when booting up a cpu can't use
      tracing because mcount requires a valid 'current_thread_info()'
      and TLB mappings to be setup.
      
      The code path of sun4v_register_mondo_queues --> register_one_mondo
      is one such case.  sun4v_register_mondo_queues already has the
      necessary 'notrace' annotation, but register_one_mondo does not.
      
      Normally register_one_mondo is inlined so the bug doesn't trigger,
      but with some config/compiler combinations, it won't be so we
      must properly mark it notrace.
      
      While we're here, add 'notrace' annoations to prom_printf and
      prom_halt so that early error handling won't have the same problem.
      Reported-by: NAlexander Beregalov <a.beregalov@gmail.com>
      Reported-by: NLeif Sawyer <lsawyer@gci.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd4352ca
  4. 03 9月, 2009 4 次提交
    • D
      sparc64: Kill spurious NMI watchdog triggers by increasing limit to 30 seconds. · e6617c6e
      David S. Miller 提交于
      This is a compromise and a temporary workaround for bootup NMI
      watchdog triggers some people see with qla2xxx devices present.
      
      This happens when, for example:
      
      CPU 0 is in the driver init and looping submitting mailbox commands to
      load the firmware, then waiting for completion.
      
      CPU 1 is receiving the device interrupts.  CPU 1 is where the NMI
      watchdog triggers.
      
      CPU 0 is submitting mailbox commands fast enough that by the time CPU
      1 returns from the device interrupt handler, a new one is pending.
      This sequence runs for more than 5 seconds.
      
      The problematic case is CPU 1's timer interrupt running when the
      barrage of device interrupts begin.  Then we have:
      
      	timer interrupt
      	return for softirq checking
      	pending, thus enable interrupts
      
      		 qla2xxx interrupt
      		 return
      		 qla2xxx interrupt
      		 return
      		 ... 5+ seconds pass
      		 final qla2xxx interrupt for fw load
      		 return
      
      	run timer softirq
      	return
      
      At some point in the multi-second qla2xxx interrupt storm we trigger
      the NMI watchdog on CPU 1 from the NMI interrupt handler.
      
      The timer softirq, once we get back to running it, is smart enough to
      run the timer work enough times to make up for the missed timer
      interrupts.
      
      However, the NMI watchdogs (both x86 and sparc) use the timer
      interrupt count to notice the cpu is wedged.  But in the above
      scenerio we'll receive only one such timer interrupt even if we last
      all the way back to running the timer softirq.
      
      The default watchdog trigger point is only 5 seconds, which is pretty
      low (the softwatchdog triggers at 60 seconds).  So increase it to 30
      seconds for now.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e6617c6e
    • P
      perf_counter/powerpc: Fix cache event codes for POWER7 · a3df6f7d
      Paul Mackerras 提交于
      I had the codes for L1 D-cache load accesses and misses swapped
      around, and the wrong codes for LL-cache accesses and misses.
      This corrects them.
      Reported-by: NCorey Ashford <cjashfor@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: <stable@kernel.org>
      LKML-Reference: <19103.8514.709300.585484@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a3df6f7d
    • J
      [IA64] fix csum_ipv6_magic() · 5afe18d2
      Jiri Bohac 提交于
      The 32-bit parameters (len and csum) of csum_ipv6_magic() are passed in 64-bit
      registers in2 and in4. The high order 32 bits of the registers were never
      cleared, and garbage was sometimes calculated into the checksum.
      
      Fix this by clearing the high order 32 bits of these registers.
      Signed-off-by: NJiri Bohac <jbohac@suse.cz>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      5afe18d2
    • L
      [IA64] Fix warning in dma-mapping.c · f2486f26
      Luck, Tony 提交于
      arch/ia64/kernel/dma-mapping.c:14: warning: control reaches end of non-void function
      arch/ia64/kernel/dma-mapping.c:14: warning: no return statement in function returning non-void
      
      This warning was introduced by commit: 390bd132
      	Add dma_debug_init() for ia64
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      f2486f26
  5. 29 8月, 2009 1 次提交
  6. 27 8月, 2009 6 次提交
  7. 26 8月, 2009 2 次提交
    • Y
      x86: Fix vSMP boot crash · 295594e9
      Yinghai Lu 提交于
      2.6.31-rc7 does not boot on vSMP systems:
      
      [    8.501108] CPU31: Thermal monitoring enabled (TM1)
      [    8.501127] CPU 31 MCA banks SHD:2 SHD:3 SHD:5 SHD:6 SHD:8
      [    8.650254] CPU31: Intel(R) Xeon(R) CPU           E5540  @ 2.53GHz stepping 04
      [    8.710324] Brought up 32 CPUs
      [    8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
      [    8.721489] ERROR: parent span is not a superset of domain->span
      [    8.727686] ERROR: domain->groups does not contain CPU0
      [    8.733091] ERROR: groups don't span domain->span
      [    8.737975] ERROR: domain->cpu_power not set
      [    8.742416]
      
      Ravikiran Thirumalai bisected it to:
      
      | commit 2759c328
      | x86: don't call read_apic_id if !cpu_has_apic
      
      The problem is that on vSMP systems the CPUID derived
      initial-APICIDs are overlapping - so we need to fall
      back on hard_smp_processor_id() which reads the local
      APIC.
      
      Both come from the hardware (influenced by firmware
      though) so it's a tough call which one to trust.
      
      Doing the quirk expresses the vSMP property properly
      and also does not affect other systems, so we go for
      this solution instead of a revert.
      Reported-and-Tested-by: NRavikiran Thirumalai <kiran@scalex86.org>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Shai Fultheim <shai@scalex86.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <4A944D3C.5030100@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      295594e9
    • H
      x86, xen: Initialize cx to suppress warning · 7adb4df4
      H. Peter Anvin 提交于
      Initialize cx before calling xen_cpuid(), in order to suppress the
      "may be used uninitialized in this function" warning.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      7adb4df4