1. 15 5月, 2008 1 次提交
  2. 13 5月, 2008 7 次提交
  3. 12 5月, 2008 3 次提交
  4. 09 5月, 2008 6 次提交
  5. 08 5月, 2008 2 次提交
  6. 07 5月, 2008 2 次提交
  7. 06 5月, 2008 2 次提交
  8. 05 5月, 2008 12 次提交
  9. 04 5月, 2008 3 次提交
  10. 02 5月, 2008 2 次提交
    • P
      [POWERPC] Bolt in SLB entry for kernel stack on secondary cpus · 3b575064
      Paul Mackerras 提交于
      This fixes a regression reported by Kamalesh Bulabel where a POWER4
      machine would crash because of an SLB miss at a point where the SLB
      miss exception was unrecoverable.  This regression is tracked at:
      
      http://bugzilla.kernel.org/show_bug.cgi?id=10082
      
      SLB misses at such points shouldn't happen because the kernel stack is
      the only memory accessed other than things in the first segment of the
      linear mapping (which is mapped at all times by entry 0 of the SLB).
      The context switch code ensures that SLB entry 2 covers the kernel
      stack, if it is not already covered by entry 0.  None of entries 0
      to 2 are ever replaced by the SLB miss handler.
      
      Where this went wrong is that the context switch code assumes it
      doesn't have to write to SLB entry 2 if the new kernel stack is in the
      same segment as the old kernel stack, since entry 2 should already be
      correct.  However, when we start up a secondary cpu, it calls
      slb_initialize, which doesn't set up entry 2.  This is correct for
      the boot cpu, where we will be using a stack in the kernel BSS at this
      point (i.e. init_thread_union), but not necessarily for secondary
      cpus, whose initial stack can be allocated anywhere.  This doesn't
      cause any immediate problem since the SLB miss handler will just
      create an SLB entry somewhere else to cover the initial stack.
      
      In fact it's possible for the cpu to go quite a long time without SLB
      entry 2 being valid.  Eventually, though, the entry created by the SLB
      miss handler will get overwritten by some other entry, and if the next
      access to the stack is at an unrecoverable point, we get the crash.
      
      This fixes the problem by making slb_initialize create a suitable
      entry for the kernel stack, if we are on a secondary cpu and the stack
      isn't covered by SLB entry 0.  This requires initializing the
      get_paca()->kstack field earlier, so I do that in smp_create_idle
      where the current field is initialized.  This also abstracts a bit of
      the computation that mk_esid_data in slb.c does so that it can be used
      in slb_initialize.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3b575064
    • G
      [POWERPC] PS3: Update ps3_defconfig · d9f2f3f5
      Geoff Levand 提交于
      Update ps3_defconfig.
      Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d9f2f3f5