1. 08 6月, 2010 1 次提交
  2. 16 5月, 2010 3 次提交
  3. 15 5月, 2010 4 次提交
    • H
      x86, mrst: Don't blindly access extended config space · e9b1d5d0
      H. Peter Anvin 提交于
      Do not blindly access extended configuration space unless we actively
      know we're on a Moorestown platform.  The fixed-size BAR capability
      lives in the extended configuration space, and thus is not applicable
      if the configuration space isn't appropriately sized.
      
      This fixes booting certain VMware configurations with CONFIG_MRST=y.
      
      Moorestown will add a fake PCI-X 266 capability to advertise the
      presence of extended configuration space.
      Reported-and-tested-by: NPetr Vandrovec <petr@vandrovec.name>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Acked-by: NJacob Pan <jacob.jun.pan@intel.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      LKML-Reference: <AANLkTiltKUa3TrKR1M51eGw8FLNoQJSLT0k0_K5X3-OJ@mail.gmail.com>
      e9b1d5d0
    • F
      x86, cacheinfo: Turn off L3 cache index disable feature in virtualized environments · 7f284d3c
      Frank Arnold 提交于
      When running a quest kernel on xen we get:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
      IP: [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x2ca/0x3df
      PGD 0
      Oops: 0000 [#1] SMP
      last sysfs file:
      CPU 0
      Modules linked in:
      
      Pid: 0, comm: swapper Tainted: G        W  2.6.34-rc3 #1 /HVM domU
      RIP: 0010:[<ffffffff8142f2fb>]  [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x
      2ca/0x3df
      RSP: 0018:ffff880002203e08  EFLAGS: 00010046
      RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000060
      RDX: 0000000000000000 RSI: 0000000000000040 RDI: 0000000000000000
      RBP: ffff880002203ed8 R08: 00000000000017c0 R09: ffff880002203e38
      R10: ffff8800023d5d40 R11: ffffffff81a01e28 R12: ffff880187e6f5c0
      R13: ffff880002203e34 R14: ffff880002203e58 R15: ffff880002203e68
      FS:  0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000038 CR3: 0000000001a3c000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a44020)
      Stack:
       ffffffff810d7ecb ffff880002203e20 ffffffff81059140 ffff880002203e30
      <0> ffffffff810d7ec9 0000000002203e40 000000000050d140 ffff880002203e70
      <0> 0000000002008140 0000000000000086 ffff880040020140 ffffffff81068b8b
      Call Trace:
       <IRQ>
       [<ffffffff810d7ecb>] ? sync_supers_timer_fn+0x0/0x1c
       [<ffffffff81059140>] ? mod_timer+0x23/0x25
       [<ffffffff810d7ec9>] ? arm_supers_timer+0x34/0x36
       [<ffffffff81068b8b>] ? hrtimer_get_next_event+0xa7/0xc3
       [<ffffffff81058e85>] ? get_next_timer_interrupt+0x19a/0x20d
       [<ffffffff8142fa23>] get_cpu_leaves+0x5c/0x232
       [<ffffffff8106a7b1>] ? sched_clock_local+0x1c/0x82
       [<ffffffff8106a9a0>] ? sched_clock_tick+0x75/0x7a
       [<ffffffff8107748c>] generic_smp_call_function_single_interrupt+0xae/0xd0
       [<ffffffff8101f6ef>] smp_call_function_single_interrupt+0x18/0x27
       [<ffffffff8100a773>] call_function_single_interrupt+0x13/0x20
       <EOI>
       [<ffffffff8143c468>] ? notifier_call_chain+0x14/0x63
       [<ffffffff810295c6>] ? native_safe_halt+0xc/0xd
       [<ffffffff810114eb>] ? default_idle+0x36/0x53
       [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
       [<ffffffff81423a9a>] rest_init+0x7e/0x80
       [<ffffffff81b10dd2>] start_kernel+0x40e/0x419
       [<ffffffff81b102c8>] x86_64_start_reservations+0xb3/0xb7
       [<ffffffff81b103c4>] x86_64_start_kernel+0xf8/0x107
      Code: 14 d5 40 ff ae 81 8b 14 02 31 c0 3b 15 47 1c 8b 00 7d 0e 48 8b 05 36 1c 8b
       00 48 63 d2 48 8b 04 d0 c7 85 5c ff ff ff 00 00 00 00 <8b> 70 38 48 8d 8d 5c ff
       ff ff 48 8b 78 10 ba c4 01 00 00 e8 eb
      RIP  [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x2ca/0x3df
       RSP <ffff880002203e08>
      CR2: 0000000000000038
      ---[ end trace a7919e7f17c0a726 ]---
      
      The L3 cache index disable feature of AMD CPUs has to be disabled if the
      kernel is running as guest on top of a hypervisor because northbridge
      devices are not available to the guest. Currently, this fixes a boot
      crash on top of Xen. In the future this will become an issue on KVM as
      well.
      
      Check if northbridge devices are present and do not enable the feature
      if there are none.
      
      [ hpa: backported to 2.6.34 ]
      Signed-off-by: NFrank Arnold <frank.arnold@amd.com>
      LKML-Reference: <1271945222-5283-3-git-send-email-bp@amd64.org>
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: <stable@kernel.org>
      7f284d3c
    • B
      x86, k8: Fix build error when K8_NB is disabled · ade029e2
      Borislav Petkov 提交于
      K8_NB depends on PCI and when the last is disabled (allnoconfig) we fail
      at the final linking stage due to missing exported num_k8_northbridges.
      Add a header stub for that.
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <20100503183036.GJ26107@aftab>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: <stable@kernel.org>
      ade029e2
    • S
      DA830: fix USB 2.0 clock entry · b9af5ddf
      Sergei Shtylyov 提交于
      DA8xx OHCI driver fails to load due to failing clk_get() call for the USB 2.0
      clock. Arrange matching USB 2.0 clock by the clock name instead of the device.
      (Adding another CLK() entry for "ohci.0" device won't do -- in the future I'll
      also have to enable USB 2.0 clock to configure CPPI 4.1 module, in which case
      I won't have any device at all.)
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      b9af5ddf
  4. 14 5月, 2010 2 次提交
  5. 13 5月, 2010 10 次提交
  6. 12 5月, 2010 4 次提交
  7. 11 5月, 2010 1 次提交
    • M
      kprobes/x86: Fix removed int3 checking order · 829e9245
      Masami Hiramatsu 提交于
      Fix kprobe/x86 to check removed int3 when failing to get kprobe
      from hlist. Since we have a time window between checking int3
      exists on probed address and getting kprobe on that address,
      we can have following scenario:
      
       -------
       CPU1                     CPU2
       hit int3
       check int3 exists
                                remove int3
                                remove kprobe from hlist
       get kprobe from hlist
       no kprobe->OOPS!
       -------
      
      This patch moves int3 checking if there is no kprobe on that
      address for fixing this problem as follows:
      
       ------
       CPU1                     CPU2
       hit int3
                                remove int3
                                remove kprobe from hlist
       get kprobe from hlist
       no kprobe->check int3 exists
                ->rollback&retry
       ------
      Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Acked-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: systemtap <systemtap@sources.redhat.com>
      Cc: DLE <dle-develop@lists.sourceforge.net>
      Cc: Dave Anderson <anderson@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <20100427223348.2322.9112.stgit@localhost6.localdomain6>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      829e9245
  8. 08 5月, 2010 5 次提交
  9. 07 5月, 2010 1 次提交
  10. 06 5月, 2010 9 次提交
    • D
      x86: Fix fake apicid to node mapping for numa emulation · b0c4d952
      David Rientjes 提交于
      With NUMA emulation, it's possible for a single cpu to be bound
      to multiple nodes since more than one may have affinity if
      allocated on a physical node that is local to the cpu.
      
      APIC ids must therefore be mapped to the lowest node ids to
      maintain generic kernel use of functions such as cpu_to_node()
      that determine device affinity.  For example, if a device has
      proximity to physical node 1, for instance, and a cpu happens to
      be mapped to a higher emulated node id 8, the proximity may not
      be correctly determined by comparison in generic code even
      though the cpu may be truly local and allocated on physical node 1.
      
      When this happens, the true topology of the machine isn't
      accurately represented in the emulated environment; although
      this isn't critical to the system's uptime, any generic code
      that is NUMA aware benefits from the physical topology being
      accurately represented.
      
      This can affect any system that maps multiple APIC ids to a
      single node and is booted with numa=fake=N where N is greater
      than the number of physical nodes.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <alpine.DEB.2.00.1005060224140.19473@chino.kir.corp.google.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b0c4d952
    • M
      microblaze: Defconfig update · 65134121
      Michal Simek 提交于
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      65134121
    • M
      microblaze: Optimize CACHE_LOOP_LIMITS and CACHE_RANGE_LOOP macros · 3274c570
      Michal Simek 提交于
      1. Remove CACHE_ALL_LOOP2 macro because it is identical to CACHE_ALL_LOOP
      2. Change BUG_ON to WARN_ON
      3. Remove end aligned from CACHE_LOOP_LIMITS.
      C implementation do not need aligned end address and ASM code do aligned
      in their macros
      4. ASM optimized  CACHE_RANGE_LOOP_1/2 macros needs to get aligned end address.
      Because end address is compound from start + size, end address is the first address
      which is exclude.
      
      Here is the corresponding code which describe it.
      +       int align = ~(line_length - 1);
      +       end = ((end & align) == end) ? end - line_length : end & align;
      
      a) end is aligned:
      it is necessary to subtruct line length because we don't want to work with
      next cacheline
      b) end address is not aligned:
      Just align it to be ready for ASM code.
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      3274c570
    • M
      microblaze: Fix consistent-sync code · 385e1efa
      Michal Simek 提交于
      PCI_DMA_FROMDEVICE should call invalidation not flushing.
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      385e1efa
    • M
      microblaze: Define correct L1_CACHE_SHIFT value · 598acab4
      Michal Simek 提交于
      Microblaze cacheline length is configurable and current cpu
      uses two cacheline length 4 and 8.
      
      We are taking conservative maximum value to be sure that cacheline
      alignment is satisfied for all cases.
      
      Here is the calculation for cacheline lenght 8  32bit=4Byte values
      which is corresponding with SHIFT 5.
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      598acab4
    • M
      microblaze: cpuinfo shows cache line length · 77543ceb
      Michal Simek 提交于
      Show cache line length in /proc/cpuinfo.
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      77543ceb
    • M
      microblaze: Fix kmalloc alignment on non-coherent DMA platforms · de925d9d
      Michal Simek 提交于
      Based on PowerPC patche 52142e75
      
      PowerPC description:
      On platforms doing non-coherent DMA (4xx, 8xx, ...), it's important
      that the kmalloc minimum alignment is set to the cache line size, to
      avoid sharing cache lines between different objects, so that DMA to
      one of the objects doesn't corrupt the other.
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      de925d9d
    • M
      microblaze: Fix typo fault in cache code · c17e1a1c
      Michal Simek 提交于
      Copy & paste error.
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      c17e1a1c
    • M
      microblaze: Fix consistent code · f1525765
      Michal Simek 提交于
      This patch fix consistent code which had problems with consistent_free
      function.
      I am not sure if we need to call flush_tlb_all after it but it keeps
      tlbs synced.
      I added noMMU and MMU version together.
      
      Uncached shadow feature is not tested.
      Signed-off-by: NMichal Simek <monstr@monstr.eu>
      f1525765