1. 08 12月, 2011 8 次提交
    • A
      powerpc/nvram: Add spinlock to oops_to_nvram to prevent oops in compression code. · 120a52c3
      Anton Blanchard 提交于
      When issuing a system reset we almost always oops in the oops_to_nvram
      code because multiple CPUs are using the deflate work area. Add a
      spinlock to protect it.
      
      To play it safe I'm using trylock to avoid locking up if the NVRAM
      code oopses. This means we might miss multiple CPUs oopsing at exactly
      the same time but I think it's best to play it safe for now. Once we
      are happy with the reliability we can change it to a full spinlock.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Acked-by: NJim Keniston <jkenisto@us.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      120a52c3
    • F
      pmac_zilog: Fix unexpected irq · 7cf82b1b
      Finn Thain 提交于
      On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
      masked. This can be a problem when pmac_zilog starts up.
      
      For example, the serial debugging code in arch/m68k/kernel/head.S may be
      used beforehand. It disables the SCC interrupts at the chip but doesn't
      ack them. Then when a pmac_zilog port is used, the machine locks up with
      "unexpected interrupt".
      
      This can happen in pmz_shutdown() since the irq is freed before the
      channel interrupts are disabled.
      
      Fix this by clearing interrupt enable bits before the handler is
      uninstalled. Also move the interrupt control bit flipping into a separate
      pmz_interrupt_control() routine. Replace all instances of these operations
      with calls to this routine. Omit the zssync() calls that seem to serve no
      purpose.
      Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7cf82b1b
    • P
      powerpc: Provide a way for KVM to indicate that NV GPR values are lost · 2fde6d20
      Paul Mackerras 提交于
      This fixes a problem where a CPU thread coming out of nap mode can
      think it has valid values in the nonvolatile GPRs (r14 - r31) as saved
      away in power7_idle, but in fact the values have been trashed because
      the thread was used for KVM in the mean time.  The result is that the
      thread crashes because code that called power7_idle (e.g.,
      pnv_smp_cpu_kill_self()) goes to use values in registers that have
      been trashed.
      
      The bit field in SRR1 that tells whether state was lost only reflects
      the most recent nap, which may not have been the nap instruction in
      power7_idle.  So we need an extra PACA field to indicate that state
      has been lost even if SRR1 indicates that the most recent nap didn't
      lose state.  We clear this field when saving the state in power7_idle,
      we set it to a non-zero value when we use the thread for KVM, and we
      test it in power7_wakeup_noloss.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      2fde6d20
    • P
      powerpc/powernv: Fix problems in onlining CPUs · cba313da
      Paul Mackerras 提交于
      At present, on the powernv platform, if you off-line a CPU that was
      online, and then try to on-line it again, the kernel generates a
      warning message "OPAL Error -1 starting CPU n".  Furthermore, if the
      CPU is a secondary thread that was used by KVM while it was off-line,
      the CPU fails to come online.
      
      The first problem is fixed by only calling OPAL to start the CPU the
      first time it is on-lined, as indicated by the cpu_start field of its
      PACA being zero.  The second problem is fixed by restoring the
      cpu_start field to 1 instead of 0 when using the CPU within KVM.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      cba313da
    • A
      powerpc/pseries: Increase minimum RMO size from 64MB to 256MB · 33392640
      Anton Blanchard 提交于
      The minimum RMO size field in ibm,client-architecture is currently
      ignored, but a future firmware version will rectify that. Since we
      always get at least 128MB of RMO right now, asking for 64MB is
      likely to result in boot failures.
      
      We should bump it to at least 128MB, but considering all the boot
      issues we have on 128MB RMO boxes and all new machines have virtual
      RMO, we may as well set our minimum to 256MB.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      33392640
    • S
      powerpc: Punch a hole in /dev/mem for librtas · 8a3e3d31
      sukadev@linux.vnet.ibm.com 提交于
      With CONFIG_STRICT_DEVMEM=y, user space cannot read any part of /dev/mem.
      Since this breaks librtas, punch a hole in /dev/mem to allow access to the
      rmo_buffer that librtas needs.
      
      Anton Blanchard reported the problem and helped with the fix.
      
      A quick test for this patch:
      
             # cat /proc/rtas/rmo_buffer
             000000000f190000 10000
      
             # python -c "print 0x000000000f190000 / 0x10000"
             3865
      
             # dd if=/dev/mem of=/tmp/foo count=1 bs=64k skip=3865
             1+0 records in
             1+0 records out
             65536 bytes (66 kB) copied, 0.000205235 s, 319 MB/s
      
             # dd if=/dev/mem of=/tmp/foo
             dd: reading `/dev/mem': Operation not permitted
             0+0 records in
             0+0 records out
             0 bytes (0 B) copied, 0.00022519 s, 0.0 kB/s
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8a3e3d31
    • B
      powerpc: Add support for OpenBlockS 600 · 11eab297
      Benjamin Herrenschmidt 提交于
      So I've had one of these for a while and it looks like the vendor never
      bothered submitting the support upstream.
      
      This adds it using ppc40x_simple and provides a device-tree.
      
      There are some changes to the boot wrapper because the way u-boot works
      on this thing, it seems to expect a multipart image with the kernel,
      initrd and dtb in it.
      
      The USB support is missing as it needs the yet unmerged driver for
      the DWC OTG part and the GPIOs may need further definition in the dts.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      11eab297
    • B
      Merge branch 'booke-hugetlb' into next · faa8bf88
      Benjamin Herrenschmidt 提交于
      faa8bf88
  2. 07 12月, 2011 28 次提交
  3. 28 11月, 2011 4 次提交