1. 20 12月, 2007 1 次提交
    • M
      [POWERPC] Push down or eliminate smp_processor_id calls in xics code · d7cf0edb
      Milton Miller 提交于
      The per-processor interrupt request register and current processor
      priority register are only accessed on the current cpu.  In fact the
      hypervisor doesn't even let us choose which cpu's registers to access.
      
      The only function to use cpu twice is xics_migrate_irqs_away, not a fast
      path.  But we can cache the result of get_hard_processor_id() instead of
      calling get_hard_smp_processor_id(cpu) in a loop across the call to rtas.
      
      Years ago the irq code passed smp_processor_id into get_irq, I thought
      we might initialize the CPPR third party at boot as an extra measure of
      saftey, and it made the code symmetric with the qirr (queued interrupt
      for software generated interrupts), but now it is just extra and
      sometimes unneeded work to pass it down.
      Signed-off-by: NMilton Miller <miltonm@bga.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d7cf0edb
  2. 11 12月, 2007 4 次提交
  3. 03 12月, 2007 6 次提交
  4. 20 11月, 2007 1 次提交
    • L
      [POWERPC] Fix RTAS os-term usage on kernel panic · a2b51812
      Linas Vepstas 提交于
      The rtas_os_term() routine was being called at the wrong time.
      The actual rtas call "os-term" will not ever return, and so
      calling it from the panic notifier is too early.  Instead,
      call it from the machine_reset() call.
      
      This splits the rtas_os_term() routine into two: one part to capture
      the kernel panic message, invoked during the panic notifier, and
      another part that is invoked during machine_reset().
      
      Prior to this patch, the os-term call was never being made,
      because panic_timeout was always non-zero.  Calling os-term
      helps keep the hypervisor happy!  We have to keep the hypervisor
      happy to avoid service, dump and error reporting problems.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a2b51812
  5. 19 11月, 2007 1 次提交
  6. 08 11月, 2007 6 次提交
  7. 20 10月, 2007 1 次提交
    • S
      pid namespaces: define is_global_init() and is_container_init() · b460cbc5
      Serge E. Hallyn 提交于
      is_init() is an ambiguous name for the pid==1 check.  Split it into
      is_global_init() and is_container_init().
      
      A cgroup init has it's tsk->pid == 1.
      
      A global init also has it's tsk->pid == 1 and it's active pid namespace
      is the init_pid_ns.  But rather than check the active pid namespace,
      compare the task structure with 'init_pid_ns.child_reaper', which is
      initialized during boot to the /sbin/init process and never changes.
      
      Changelog:
      
      	2.6.22-rc4-mm2-pidns1:
      	- Use 'init_pid_ns.child_reaper' to determine if a given task is the
      	  global init (/sbin/init) process. This would improve performance
      	  and remove dependence on the task_pid().
      
      	2.6.21-mm2-pidns2:
      
      	- [Sukadev Bhattiprolu] Changed is_container_init() calls in {powerpc,
      	  ppc,avr32}/traps.c for the _exception() call to is_global_init().
      	  This way, we kill only the cgroup if the cgroup's init has a
      	  bug rather than force a kernel panic.
      
      [akpm@linux-foundation.org: fix comment]
      [sukadev@us.ibm.com: Use is_global_init() in arch/m32r/mm/fault.c]
      [bunk@stusta.de: kernel/pid.c: remove unused exports]
      [sukadev@us.ibm.com: Fix capability.c to work with threaded init]
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Signed-off-by: NSukadev Bhattiprolu <sukadev@us.ibm.com>
      Acked-by: NPavel Emelianov <xemul@openvz.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Herbert Poetzel <herbert@13thfloor.at>
      Cc: Kirill Korotaev <dev@sw.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b460cbc5
  8. 12 10月, 2007 1 次提交
    • P
      [POWERPC] Use 1TB segments · 1189be65
      Paul Mackerras 提交于
      This makes the kernel use 1TB segments for all kernel mappings and for
      user addresses of 1TB and above, on machines which support them
      (currently POWER5+, POWER6 and PA6T).
      
      We detect that the machine supports 1TB segments by looking at the
      ibm,processor-segment-sizes property in the device tree.
      
      We don't currently use 1TB segments for user addresses < 1T, since
      that would effectively prevent 32-bit processes from using huge pages
      unless we also had a way to revert to using 256MB segments.  That
      would be possible but would involve extra complications (such as
      keeping track of which segment size was used when HPTEs were inserted)
      and is not addressed here.
      
      Parts of this patch were originally written by Ben Herrenschmidt.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1189be65
  9. 11 10月, 2007 2 次提交
  10. 03 10月, 2007 3 次提交
  11. 02 10月, 2007 2 次提交
    • L
      [POWERPC] pseries: device node status can be "ok" or "okay" · a7fb7ea7
      Linas Vepstas 提交于
      It seems that some versions of firmware will report a device
      node status as the string "okay". As we are not expecting this
      string, the device node will be ignored by the EEH subsystem.
      Which means EEH will not be enabled.
      
      When EEH is not enabled, PCI errors will be converted into
      Machine Check exceptions, and we'll have a very unhappy system.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a7fb7ea7
    • A
      [POWERPC] Fix xics set_affinity code · e48395f1
      Anton Blanchard 提交于
      On a POWER6 machine running 2.6.23-rc8 I sometimes see the following error:
      
      xics_set_affinity: No online cpus in the mask 00000000,00000000,00000000,00000001 for irq 20
      
      In a desperate attempt to get a changelog entry in 2.6.23, I took a look
      into it.
      
      It turns out we are passing a real and not a virtual irq into
      get_irq_server.  This works for the case where hwirq < NR_IRQS and we
      set virq = hwirq.  In my case however hwirq = 590082 and we try and
      access irq_desc[590082], slightly past the end at 512 entries.
      
      Lucky we ship lots of memory with our machines.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e48395f1
  12. 13 9月, 2007 1 次提交
  13. 17 8月, 2007 10 次提交
  14. 22 7月, 2007 1 次提交