1. 17 2月, 2009 1 次提交
  2. 16 2月, 2009 7 次提交
  3. 15 2月, 2009 4 次提交
    • Y
      x86: make 32bit to call enable_IO_APIC early like 64bit · 88d0f550
      Yinghai Lu 提交于
      Impact: cleanup
      
      So we remove some #ifdefs.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      88d0f550
    • T
      x86, vm86: fix preemption bug · be716615
      Thomas Gleixner 提交于
      Commit 3d2a71a5 ("x86, traps: converge
      do_debug handlers") changed the preemption disable logic of do_debug()
      so vm86_handle_trap() is called with preemption disabled resulting in:
      
       BUG: sleeping function called from invalid context at include/linux/kernel.h:155
       in_atomic(): 1, irqs_disabled(): 0, pid: 3005, name: dosemu.bin
       Pid: 3005, comm: dosemu.bin Tainted: G        W  2.6.29-rc1 #51
       Call Trace:
        [<c050d669>] copy_to_user+0x33/0x108
        [<c04181f4>] save_v86_state+0x65/0x149
        [<c0418531>] handle_vm86_trap+0x20/0x8f
        [<c064e345>] do_debug+0x15b/0x1a4
        [<c064df1f>] debug_stack_correct+0x27/0x2c
        [<c040365b>] sysenter_do_call+0x12/0x2f
       BUG: scheduling while atomic: dosemu.bin/3005/0x10000001
      
      Restore the original calling convention and reenable preemption before
      calling handle_vm86_trap().
      Reported-by: NMichal Suchanek <hramrach@centrum.cz>
      Cc: stable@kernel.org
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      be716615
    • Y
      x86: fix typo in filter_cpuid_features() · f6db44df
      Yinghai Lu 提交于
      Impact: fix wrong disabling of cpu features
      
      an amd system got this strange output:
      
       CPU: CPU feature monitor disabled due to lack of CPUID level 0x5
      
      but in /proc/cpuinfo I have:
      
       cpuid level	: 5
      
      on intel system:
      
       CPU: CPU feature monitor disabled due to lack of CPUID level 0x5
       CPU: CPU feature dca disabled due to lack of CPUID level 0x9
      
      but in /proc/cpuinfo i have:
      
       cpuid level     : 11
      
      Tt turns out there is a typo, and we should use level member in df.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f6db44df
    • C
      x86, olpc: fix model detection without OFW · e49590b6
      Chris Ball 提交于
      Impact: fix "garbled display, laptop is unusable" bug
      
      Commit e51a1ac2 ("x86, olpc: fix endian
      bug in openfirmware workaround") breaks model comparison on OLPC; the value
      0xc2 needs to be scaled up by olpc_board().
      
      The pre-patch version was wrong, but accidentally worked anyway
      (big-endian 0xc2 is big enough to satisfy all other board revisions,
      but little endian 0xc2 is not).
      Signed-off-by: NChris Ball <cjb@laptop.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Acked-by: NAndres Salomon <dilinger@queued.net>
      Cc: Harvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e49590b6
  4. 14 2月, 2009 2 次提交
  5. 13 2月, 2009 9 次提交
    • I
      xen: fix xen_flush_tlb_others · 694aa960
      Ian Campbell 提交于
      The commit
          commit 4595f962
          Author: Rusty Russell <rusty@rustcorp.com.au>
          Date:   Sat Jan 10 21:58:09 2009 -0800
      
              x86: change flush_tlb_others to take a const struct cpumask
      
      causes xen_flush_tlb_others to allocate a multicall and then issue it
      without initializing it in the case where the cpumask is empty,
      leading to:
      
              [    8.354898] 1 multicall(s) failed: cpu 1
              [    8.354921] Pid: 2213, comm: bootclean Not tainted 2.6.29-rc3-x86_32p-xenU-tip #135
              [    8.354937] Call Trace:
              [    8.354955]  [<c01036e3>] xen_mc_flush+0x133/0x1b0
              [    8.354971]  [<c0105d2a>] ? xen_force_evtchn_callback+0x1a/0x30
              [    8.354988]  [<c0105a60>] xen_flush_tlb_others+0xb0/0xd0
              [    8.355003]  [<c0126643>] flush_tlb_page+0x53/0xa0
              [    8.355018]  [<c0176a80>] do_wp_page+0x2a0/0x7c0
              [    8.355034]  [<c0238f0a>] ? notify_remote_via_irq+0x3a/0x70
              [    8.355049]  [<c0178950>] handle_mm_fault+0x7b0/0xa50
              [    8.355065]  [<c0131a3e>] ? wake_up_new_task+0x8e/0xb0
              [    8.355079]  [<c01337b5>] ? do_fork+0xe5/0x320
              [    8.355095]  [<c0121919>] do_page_fault+0xe9/0x240
              [    8.355109]  [<c0121830>] ? do_page_fault+0x0/0x240
              [    8.355125]  [<c032457a>] error_code+0x72/0x78
              [    8.355139]   call  1/1: op=2863311530 arg=[aaaaaaaa] result=-38     xen_flush_tlb_others+0x41/0xd0
      
      Since empty cpumasks are rare and undoing an xen_mc_entry() is tricky
      just issue such requests normally.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      694aa960
    • I
      x86 headers: protect page_32.h via __ASSEMBLY__ · beb6943d
      Ingo Molnar 提交于
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      beb6943d
    • I
      x86 headers: include page_types.h in pgtable_types.h · e43623b4
      Ingo Molnar 提交于
      To properly pick up details like PTE_FLAGS_MASK.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e43623b4
    • I
      x86 headers: include linux/types.h · 56cefcea
      Ingo Molnar 提交于
      To properly pick up types relied on by prototypes like 'bool'.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      56cefcea
    • I
      x86 headers: remove duplicate pud_large() definition · 999c7880
      Ingo Molnar 提交于
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      999c7880
    • J
      x86, hpet: fix for LS21 + HPET = boot hang · b13e2464
      john stultz 提交于
      Between 2.6.23 and 2.6.24-rc1 a change was made that broke IBM LS21
      systems that had the HPET enabled in the BIOS, resulting in boot hangs
      for x86_64.
      
      Specifically commit b8ce3359, which
      merges the i386 and x86_64 HPET code.
      
      Prior to this commit, when we setup the HPET timers in x86_64, we did
      the following:
      
      	hpet_writel(HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
                          HPET_TN_32BIT, HPET_T0_CFG);
      
      However after the i386/x86_64 HPET merge, we do the following:
      
      	cfg = hpet_readl(HPET_Tn_CFG(timer));
      	cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC |
      			HPET_TN_SETVAL | HPET_TN_32BIT;
      	hpet_writel(cfg, HPET_Tn_CFG(timer));
      
      However on LS21s with HPET enabled in the BIOS, the HPET_T0_CFG register
      boots with Level triggered interrupts (HPET_TN_LEVEL) enabled. This
      causes the periodic interrupt to be not so periodic, and that results in
      the boot time hang I reported earlier in the delay calibration.
      
      My fix: Always disable HPET_TN_LEVEL when setting up periodic mode.
      Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b13e2464
    • T
      x86: CPA avoid repeated lazy mmu flush · 7ad9de6a
      Thomas Gleixner 提交于
      Impact: Flush the lazy MMU only once
      
      Pending mmu updates only need to be flushed once to bring the
      in-memory pagetable state up to date.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      7ad9de6a
    • T
      x86: warn if arch_flush_lazy_mmu_cpu is called in preemptible context · 34b0900d
      Thomas Gleixner 提交于
      Impact: Catch cases where lazy MMU state is active in a preemtible context
      
      arch_flush_lazy_mmu_cpu() has been changed to disable preemption so
      the checks in enter/leave will never trigger. Put the preemtible()
      check into arch_flush_lazy_mmu_cpu() to catch such cases.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      34b0900d
    • J
      x86/paravirt: make arch_flush_lazy_mmu/cpu disable preemption · d85cf93d
      Jeremy Fitzhardinge 提交于
      Impact: avoid access to percpu vars in preempible context
      
      They are intended to be used whenever there's the possibility
      that there's some stale state which is going to be overwritten
      with a queued update, or to force a state change when we may be
      in lazy mode.  Either way, we could end up calling it with
      preemption enabled, so wrap the functions in their own little
      preempt-disable section so they can be safely called in any
      context (though preemption should never be enabled if we're actually
      in a lazy state).
      
      (Move out of line to avoid #include dependencies.)
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      d85cf93d
  6. 12 2月, 2009 17 次提交