1. 05 8月, 2011 6 次提交
    • A
      powerpc: pseries: Fix kexec on machines with more than 4TB of RAM · bed9a315
      Anton Blanchard 提交于
      On a box with 8TB of RAM the MMU hashtable is 64GB in size. That
      means we have 4G PTEs. pSeries_lpar_hptab_clear was using a signed
      int to store the index which will overflow at 2G.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: <stable@kernel.org>
      Acked-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      bed9a315
    • A
      powerpc: Jump label misalignment causes oops at boot · c113a3ae
      Anton Blanchard 提交于
      I hit an oops at boot on the first instruction of timer_cpu_notify:
      
      NIP [c000000000722f88] .timer_cpu_notify+0x0/0x388
      
      The code should look like:
      
      c000000000722f78:       eb e9 00 30     ld      r31,48(r9)
      c000000000722f7c:       2f bf 00 00     cmpdi   cr7,r31,0
      c000000000722f80:       40 9e ff 44     bne+    cr7,c000000000722ec4
      c000000000722f84:       4b ff ff 74     b       c000000000722ef8
      
      c000000000722f88 <.timer_cpu_notify>:
      c000000000722f88:       7c 08 02 a6     mflr    r0
      c000000000722f8c:       2f a4 00 07     cmpdi   cr7,r4,7
      c000000000722f90:       fb c1 ff f0     std     r30,-16(r1)
      c000000000722f94:       fb 61 ff d8     std     r27,-40(r1)
      
      But the oops output shows:
      
      eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 7c0803a6 ebe1fff8 4e800020
      00000000 ebe90030 c0000000 00ad0a28 00000000 2fa40007 fbc1fff0 fb61ffd8
      
      So we scribbled over our instructions with c000000000ad0a28, which
      is an address inside the jump_table ELF section.
      
      It turns out the jump_table section is only aligned to 8 bytes but
      we are aligning our entries within the section to 16 bytes. This
      means our entries are offset from the table:
      
      c000000000acd4a8 <__start___jump_table>:
              ...
      c000000000ad0a10:       c0 00 00 00     lfs     f0,0(0)
      c000000000ad0a14:       00 70 cd 5c     .long 0x70cd5c
      c000000000ad0a18:       c0 00 00 00     lfs     f0,0(0)
      c000000000ad0a1c:       00 70 cd 90     .long 0x70cd90
      c000000000ad0a20:       c0 00 00 00     lfs     f0,0(0)
      c000000000ad0a24:       00 ac a4 20     .long 0xaca420
      
      And the jump table sort code gets very confused and writes into the
      wrong spot. Remove the alignment, and also remove the padding since
      we it saves some space and we shouldn't need it.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c113a3ae
    • A
      powerpc: Clean up some panic messages in prom_init · fbafd728
      Anton Blanchard 提交于
      Add a newline to the panic messages in make_room. Also fix a
      comment that suggested our chunk size is 4Mb. It's 1MB.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      fbafd728
    • A
      powerpc: Fix device tree claim code · 966728dd
      Anton Blanchard 提交于
      I have a box that fails in OF during boot with:
      
      DEFAULT CATCH!, exception-handler=fff00400
      at   %SRR0: 49424d2c4c6f6768   %SRR1: 800000004000b002
      
      ie "IBM,Logh". OF got corrupted with a device tree string.
      
      Looking at make_room and alloc_up, we claim the first chunk (1 MB)
      but we never claim any more. mem_end is always set to alloc_top
      which is the top of our available address space, guaranteeing we will
      never call alloc_up and claim more memory.
      
      Also alloc_up wasn't setting alloc_bottom to the bottom of the
      available address space.
      
      This doesn't help the box to boot, but we at least fail with
      an obvious error. We could relocate the device tree in a future
      patch.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: <stable@kernel.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      966728dd
    • S
      powerpc: Return the_cpu_ spec from identify_cpu · 26ee9767
      Scott Wood 提交于
      Commit af9eef3c caused cpu_setup to see
      the_cpu_spec, rather than the source struct.  However, on 32-bit, the
      return value of identify_cpu was being used for feature fixups, and
      identify_cpu was returning the source struct.  So if cpu_setup patches
      the feature bits, the update won't affect the fixups.
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      26ee9767
    • S
      powerpc: mtspr/mtmsr should take an unsigned long · 326ed6a9
      Scott Wood 提交于
      Add a cast in case the caller passes in a different type, as it would
      if mtspr/mtmsr were functions.
      
      Previously, if a 64-bit type was passed in on 32-bit, GCC would bind the
      constraint to a pair of registers, and would substitute the first register
      in the pair in the asm code.  This corresponds to the upper half of the
      64-bit register, which is generally not the desired behavior.
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      326ed6a9
  2. 04 8月, 2011 9 次提交
  3. 03 8月, 2011 13 次提交
  4. 01 8月, 2011 9 次提交
  5. 31 7月, 2011 3 次提交