1. 21 May, 2010 18 commits
    • Anton Blanchard's avatar
      powerpc/numa: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim · 56608209
      Anton Blanchard authored
      I noticed /proc/sys/vm/zone_reclaim_mode was 0 on a ppc64 NUMA box. It gets
      enabled via this:
      
              /*
               * If another node is sufficiently far away then it is better
               * to reclaim pages in a zone before going off node.
               */
              if (distance > RECLAIM_DISTANCE)
                      zone_reclaim_mode = 1;
      
      Since we use the default value of 20 for REMOTE_DISTANCE and 20 for
      RECLAIM_DISTANCE it never kicks in.
      
      The local to remote bandwidth ratios can be quite large on System p
      machines so it makes sense for us to reclaim clean pagecache locally before
      going off node.
      
      The patch below sets a smaller value for RECLAIM_DISTANCE and thus enables
      zone reclaim.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      56608209
    • Anton Blanchard's avatar
      powerpc: Use smt_snooze_delay=-1 to always busy loop · b878dc00
      Anton Blanchard authored
      Right now if we want to busy loop and not give up any time to the hypervisor
      we put a very large value into smt_snooze_delay. This is sometimes useful
      when running a single partition and you want to avoid any latencies due
      to the hypervisor or CPU power state transitions. While this works, it's a bit
      ugly - how big a number is enough now we have NO_HZ and can be idle for a very
      long time.
      
      The patch below makes smt_snooze_delay signed, and a negative value means loop
      forever:
      
      echo -1 > /sys/devices/system/cpu/cpu0/smt_snooze_delay
      
      This change shouldn't affect the existing userspace tools (eg ppc64_cpu), but
      I'm cc-ing Nathan just to be sure.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b878dc00
    • Anton Blanchard's avatar
      powerpc: Remove check of ibm,smt-snooze-delay OF property · dd04c63c
      Anton Blanchard authored
      I'm not sure why we have code for parsing an ibm,smt-snooze-delay OF
      property. Since we have a smt-snooze-delay= boot option and we can
      also set it at runtime via sysfs, it should be safe to get rid of
      this code.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      dd04c63c
    • Michael Neuling's avatar
      powerpc/kdump: Fix race in kdump shutdown · 60adec62
      Michael Neuling authored
      When we are crashing, the crashing/primary CPU IPIs the secondaries to
      turn off IRQs, go into real mode and wait in kexec_wait.  While this
      is happening, the primary tears down all the MMU maps.  Unfortunately
      the primary doesn't check to make sure the secondaries have entered
      real mode before doing this.
      
      On PHYP machines, the secondaries can take a long time shutting down
      the IRQ controller as RTAS calls are need.  These RTAS calls need to
      be serialised which resilts in the secondaries contending in
      lock_rtas() and hence taking a long time to shut down.
      
      We've hit this on large POWER7 machines, where some secondaries are
      still waiting in lock_rtas(), when the primary tears down the HPTEs.
      
      This patch makes sure all secondaries are in real mode before the
      primary tears down the MMU.  It uses the new kexec_state entry in the
      paca.  It times out if the secondaries don't reach real mode after
      10sec.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      60adec62
    • Michael Neuling's avatar
      powerpc/kexec: Fix race in kexec shutdown · 1fc711f7
      Michael Neuling authored
      In kexec_prepare_cpus, the primary CPU IPIs the secondary CPUs to
      kexec_smp_down().  kexec_smp_down() calls kexec_smp_wait() which sets
      the hw_cpu_id() to -1.  The primary does this while leaving IRQs on
      which means the primary can take a timer interrupt which can lead to
      the IPIing one of the secondary CPUs (say, for a scheduler re-balance)
      but since the secondary CPU now has a hw_cpu_id = -1, we IPI CPU
      -1... Kaboom!
      
      We are hitting this case regularly on POWER7 machines.
      
      There is also a second race, where the primary will tear down the MMU
      mappings before knowing the secondaries have entered real mode.
      
      Also, the secondaries are clearing out any pending IPIs before
      guaranteeing that no more will be received.
      
      This changes kexec_prepare_cpus() so that we turn off IRQs in the
      primary CPU much earlier.  It adds a paca flag to say that the
      secondaries have entered the kexec_smp_down() IPI and turned off IRQs,
      rather than overloading hw_cpu_id with -1.  This new paca flag is
      again used to in indicate when the secondaries has entered real mode.
      
      It also ensures that all CPUs have their IRQs off before we clear out
      any pending IPI requests (in kexec_cpu_down()) to ensure there are no
      trailing IPIs left unacknowledged.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1fc711f7
    • Michael Neuling's avatar
      powerpc/kexec: Speedup kexec hash PTE tear down · d504bed6
      Michael Neuling authored
      Currently for kexec the PTE tear down on 1TB segment systems normally
      requires 3 hcalls for each PTE removal. On a machine with 32GB of
      memory it can take around a minute to remove all the PTEs.
      
      This optimises the path so that we only remove PTEs that are valid.
      It also uses the read 4 PTEs at once HCALL.  For the common case where
      a PTEs is invalid in a 1TB segment, this turns the 3 HCALLs per PTE
      down to 1 HCALL per 4 PTEs.
      
      This gives an > 10x speedup in kexec times on PHYP, taking a 32GB
      machine from around 1 minute down to a few seconds.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d504bed6
    • Michael Neuling's avatar
      powerpc/pseries: Add hcall to read 4 ptes at a time in real mode · f90ece28
      Michael Neuling authored
      This adds plpar_pte_read_4_raw() which can be used read 4 PTEs from
      PHYP at a time, while in real mode.
      
      It also creates a new hcall9 which can be used in real mode.  It's the
      same as plpar_hcall9 but minus the tracing hcall statistics which may
      require variables outside the RMO.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f90ece28
    • Anton Blanchard's avatar
      powerpc: Use more accurate limit for first segment memory allocations · 095c7965
      Anton Blanchard authored
      Author: Milton Miller <miltonm@bga.com>
      
      On large machines we are running out of room below 256MB. In some cases we
      only need to ensure the allocation is in the first segment, which may be
      256MB or 1TB.
      
      Add slb0_limit and use it to specify the upper limit for the irqstack and
      emergency stacks.
      
      On a large ppc64 box, this fixes a panic at boot when the crashkernel=
      option is specified (previously we would run out of memory below 256MB).
      Signed-off-by: default avatarMilton Miller <miltonm@bga.com>
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      095c7965
    • Anton Blanchard's avatar
      powerpc/kdump: Use chip->shutdown to disable IRQs · 5d7a8721
      Anton Blanchard authored
      I saw this in a kdump kernel:
      
      IOMMU table initialized, virtual merging enabled
      Interrupt 155954 (real) is invalid, disabling it.
      Interrupt 155953 (real) is invalid, disabling it.
      
      ie we took some spurious interrupts. default_machine_crash_shutdown tries
      to disable all interrupt sources but uses chip->disable which maps to
      the default action of:
      
      static void default_disable(unsigned int irq)
      {
      }
      
      If we use chip->shutdown, then we actually mask the IRQ:
      
      static void default_shutdown(unsigned int irq)
      {
              struct irq_desc *desc = irq_to_desc(irq);
      
              desc->chip->mask(irq);
              desc->status |= IRQ_MASKED;
      }
      
      Not sure why we don't implement a ->disable action for xics.c, or why
      default_disable doesn't mask the interrupt.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5d7a8721
    • Anton Blanchard's avatar
      powerpc/kdump: CPUs assume the context of the oopsing CPU · 06440794
      Anton Blanchard authored
      We wrap the crash_shutdown_handles[] calls with longjmp/setjmp, so if any
      of them fault we can recover. The problem is we add a hook to the debugger
      fault handler hook which calls longjmp unconditionally.
      
      This first part of kdump is run before we marshall the other CPUs, so there
      is a very good chance some CPU on the box is going to page fault. And when
      it does it hits the longjmp code and assumes the context of the oopsing CPU.
      The machine gets very confused when it has 10 CPUs all with the same stack,
      all thinking they have the same CPU id. I get even more confused trying
      to debug it.
      
      The patch below adds crash_shutdown_cpu and uses it to specify which cpu is
      in the protected region. Since it can only be -1 or the oopsing CPU, we don't
      need to use memory barriers since it is only valid on the local CPU - no other
      CPU will ever see a value that matches it's local CPU id.
      
      Eventually we should switch the order and marshall all CPUs before doing the
      crash_shutdown_handles[] calls, but that is a bigger fix.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      06440794
    • Maxim Uvarov's avatar
    • Anton Blanchard's avatar
      powerpc/eeh: Fix oops when probing in early boot · ce47c1c4
      Anton Blanchard authored
      If we take an EEH error early enough, we oops:
      
      Call Trace:
      [c000000010483770] [c000000000013ee4] .show_stack+0xd8/0x218 (unreliable)
      [c000000010483850] [c000000000658940] .dump_stack+0x28/0x3c
      [c0000000104838d0] [c000000000057a68] .eeh_dn_check_failure+0x2b8/0x304
      [c000000010483990] [c0000000000259c8] .rtas_read_config+0x120/0x168
      [c000000010483a40] [c000000000025af4] .rtas_pci_read_config+0xe4/0x124
      [c000000010483af0] [c00000000037af18] .pci_bus_read_config_word+0xac/0x104
      [c000000010483bc0] [c0000000008fec98] .pcibios_allocate_resources+0x7c/0x220
      [c000000010483c90] [c0000000008feed8] .pcibios_resource_survey+0x9c/0x418
      [c000000010483d80] [c0000000008fea10] .pcibios_init+0xbc/0xf4
      [c000000010483e20] [c000000000009844] .do_one_initcall+0x98/0x1d8
      [c000000010483ed0] [c0000000008f0560] .kernel_init+0x228/0x2e8
      [c000000010483f90] [c000000000031a08] .kernel_thread+0x54/0x70
      EEH: Detected PCI bus error on device <null>
      EEH: This PCI device has failed 1 times in the last hour:
      EEH: location=U78A5.001.WIH8464-P1 driver= pci addr=0001:00:01.0
      EEH: of node=/pci@800000020000209/usb@1
      EEH: PCI device/vendor: 00351033
      EEH: PCI cmd/status register: 12100146
      
      Unable to handle kernel paging request for data at address 0x00000468
      Oops: Kernel access of bad area, sig: 11 [#1]
      ....
      NIP [c000000000057610] .rtas_set_slot_reset+0x38/0x10c
      LR [c000000000058724] .eeh_reset_device+0x5c/0x124
      Call Trace:
      [c00000000bc6bd00] [c00000000005a0e0] .pcibios_remove_pci_devices+0x7c/0xb0 (unreliable)
      [c00000000bc6bd90] [c000000000058724] .eeh_reset_device+0x5c/0x124
      [c00000000bc6be40] [c0000000000589c0] .handle_eeh_events+0x1d4/0x39c
      [c00000000bc6bf00] [c000000000059124] .eeh_event_handler+0xf0/0x188
      [c00000000bc6bf90] [c000000000031a08] .kernel_thread+0x54/0x70
      
      We called rtas_set_slot_reset while scanning the bus and before the pci_dn
      to pcidev mapping has been created. Since we only need the pcidev to work
      out the type of reset and that only gets set after the module for the
      device loads, lets just do a hot reset if the pcidev is NULL.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Acked-by: default avatarLinas Vepstas <linasvepstas@gmail.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ce47c1c4
    • Sonny Rao's avatar
      powerpc/pci: Check devices status property when scanning OF tree · 5b339bdf
      Sonny Rao authored
      We ran into an issue where it looks like we're not properly ignoring a
      pci device with a non-good status property when we walk the device tree
      and instanciate the Linux side PCI devices.
      
      However, the EEH init code does look for the property and disables EEH
      on these devices. This leaves us in an inconsistent where we are poking
      at a supposedly bad piece of hardware and RTAS will block our config
      cycles because EEH isn't enabled anyway.
      Signed-of-by: default avatarSonny Rao <sonnyrao@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5b339bdf
    • Brian King's avatar
      powerpc/vio: Switch VIO Bus PM to use generic helpers · a1263c71
      Brian King authored
      Switch to use the generic power management helpers.
      Signed-off-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a1263c71
    • Paul Mackerras's avatar
      powerpc: Avoid bad relocations in iSeries code · e62cee42
      Paul Mackerras authored
      Subrata Modak reported that building a CONFIG_RELOCATABLE kernel with
      CONFIG_ISERIES enabled gives the following warnings:
      
      WARNING: 4 bad relocations
      c00000000007216e R_PPC64_ADDR16_HIGHEST  __ksymtab+0x00000000009dcec8
      c000000000072172 R_PPC64_ADDR16_HIGHER  __ksymtab+0x00000000009dcec8
      c00000000007217a R_PPC64_ADDR16_HI  __ksymtab+0x00000000009dcec8
      c00000000007217e R_PPC64_ADDR16_LO  __ksymtab+0x00000000009dcec8
      
      The reason is that decrementer_iSeries_masked is using
      LOAD_REG_IMMEDIATE to get the address of a kernel symbol, which
      creates relocations that aren't handled by the kernel relocator code.
      
      Instead of reading the tb_ticks_per_jiffy variable, we can just set
      the decrementer to its maximum value (0x7fffffff) and that will work
      just as well.  In fact timer_interrupt sets the decrementer to that
      value initially anyway, and we are sure to get into timer_interrupt
      once interrupts are reenabled because we store 1 to the decrementer
      interrupt flag in the lppaca (LPPACADECRINT(r12) here).
      Reported-by: default avatarSubrata Modak <subrata@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e62cee42
    • Milton Miller's avatar
      powerpc: Use common cpu_die (fixes SMP+SUSPEND build) · abb17f9c
      Milton Miller authored
      Configuring a powerpc 32 bit kernel for both SMP and SUSPEND turns on
      CPU_HOTPLUG to enable disable_nonboot_cpus to be called by the common
      suspend code.  Previously the definition of cpu_die for ppc32 was in
      the powermac platform code, causing it to be undefined if that platform
      as not selected.
      
      arch/powerpc/kernel/built-in.o: In function 'cpu_idle':
      arch/powerpc/kernel/idle.c:98: undefined reference to 'cpu_die'
      
      Move the code from setup_64 to smp.c and rename the power mac
      versions to their specific names.
      
      Note that this does not setup the cpu_die pointers in either
      smp_ops (request a given cpu die) or ppc_md (make this cpu die),
      for other platforms but there are generic versions in smp.c.
      Reported-by: default avatarMatt Sealey <matt@genesi-usa.com>
      Reported-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarMilton Miller <miltonm@bga.com>
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@mvista.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      abb17f9c
    • Andreas Schwab's avatar
      powerpc: Fix string library functions · ca5d0674
      Andreas Schwab authored
      The powerpc strncmp implementation does not correctly handle a zero
      length, despite the claim in 0119536c
      (Add hand-coded assembly strcmp).
      
      Additionally, all the length arguments are size_t, not int, so use
      PPC_LCMPI and eq instead of cmpwi and le throughout.
      Signed-off-by: default avatarAndreas Schwab <schwab@linux-m68k.org>
      Acked-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ca5d0674
    • Michael Ellerman's avatar
      powerpc/rtasd: Don't start event scan if scan rate is zero · 7358650e
      Michael Ellerman authored
      There appear to be Pegasos systems which have the rtas-event-scan
      RTAS tokens, but on which the event scan always fails. They also
      have an event-scan-rate property containing 0, which means call
      event scan 0 times per minute.
      
      So interpret a scan rate of 0 to mean don't scan at all. This fixes
      the problem on the Pegasos machines and makes sense as well.
      Signed-off-by: default avatarMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      7358650e
  2. 17 May, 2010 8 commits
  3. 07 May, 2010 1 commit
  4. 06 May, 2010 13 commits