1. 30 10月, 2013 37 次提交
  2. 27 10月, 2013 1 次提交
    • H
      parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM · 54e181e0
      Helge Deller 提交于
      Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
      not able to bring up other CPUs than the monarch CPU and instead crashed the
      kernel.  The reason was unclear, esp. since it involved various machines (e.g.
      J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
      when less than 4GB were installed, or if a 32bit Linux kernel was booted.
      
      In the end, the fix for those SMP problems is trivial:
      During the early phase of the initialization of the CPUs, including the monarch
      CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
      It's documented that this firmware function may clobber various registers, and
      one one of those possibly clobbered registers is %cr30 which holds the task
      thread info pointer.
      
      Now, if %cr30 would always have been clobbered, then this bug would have been
      detected much earlier. But lots of testing finally showed, that - at least for
      %cr30 - on some machines only the upper 32bits of the 64bit register suddenly
      turned zero after the firmware call.
      
      So, after finding the root cause, the explanation for the various crashes
      became clear:
      - On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
        problem.
      - Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
        thread info pointer was below 4GB.
      - Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
        the upper 32bit were zero anyay.
      - Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
        info pointer was located above the 4GB boundary.
      
      Finally, the patch to fix this problem is trivial by saving the %cr30 register
      before the firmware call and restoring it afterwards.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Cc: <stable@vger.kernel.org> # 2.6.12+
      Signed-off-by: NHelge Deller <deller@gmx.de>
      54e181e0
  3. 22 10月, 2013 1 次提交
    • M
      s390/time: correct use of store clock fast · 8c071b0f
      Martin Schwidefsky 提交于
      The result of the store-clock-fast (STCKF) instruction is a bit fuzzy.
      It can happen that the value stored on one CPU is smaller than the value
      stored on another CPU, although the order of the stores is the other
      way around. This can cause deltas of get_tod_clock() values to become
      negative when they should not be.
      
      We need to be more careful with store-clock-fast, this patch partially
      reverts git commit e4b7b4238e666682555461fa52eecd74652f36bb "time:
      always use stckf instead of stck if available". The get_tod_clock()
      function now uses the store-clock-extended (STCKE) instruction.
      get_tod_clock_fast() can be used if the fuzziness of store-clock-fast
      is acceptable e.g. for wait loops local to a CPU.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      8c071b0f
  4. 20 10月, 2013 1 次提交
新手
引导
客服 返回
顶部