1. 02 3月, 2018 1 次提交
    • H
      parisc: Check if secondary CPUs want own PDC calls · 0ed1fe4a
      Helge Deller 提交于
      The architecture specification says (for 64-bit systems): PDC is a per
      processor resource, and operating system software must be prepared to
      manage separate pointers to PDCE_PROC for each processor.  The address
      of PDCE_PROC for the monarch processor is stored in the Page Zero
      location MEM_PDC. The address of PDCE_PROC for each non-monarch
      processor is passed in gr26 when PDCE_RESET invokes OS_RENDEZ.
      
      Currently we still use one PDC for all CPUs, but in case we face a
      machine which is following the specification let's warn about it.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      0ed1fe4a
  2. 14 4月, 2016 1 次提交
  3. 22 11月, 2015 1 次提交
  4. 15 4月, 2015 1 次提交
  5. 01 12月, 2013 1 次提交
    • H
      parisc: fix kernel memory layout in vmlinux.ld.S · 161bd3bf
      Helge Deller 提交于
      When building a 64bit kernel sometimes functions in the .init section were not
      able to reach the standard kernel function. Main reason for this problem is,
      that the linkage tables (.plt, .opd, .dlt) tend to become pretty huge and thus
      the distance gets too big for short calls.
      
      One option to avoid this is to use the -mlong-calls compiler option, but this
      increases the binary size and introduces a performance penalty.
      
      Instead, with this patch we just lay out the binary differently.  Init code is
      stored first, followed by text, R/O and finally R/W data. This means, that init
      and text code is now much closer to each other, which is sufficient to reach
      each other by short calls.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      161bd3bf
  6. 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
  7. 16 4月, 2011 1 次提交
    • J
      [PARISC] only make executable areas executable · d7dd2ff1
      James Bottomley 提交于
      Currently parisc has the whole kernel marked as RWX, meaning any
      kernel page at all is eligible to be executed.  This can cause a
      theoretical problem on systems with combined I/D TLB because the act
      of referencing a page causes a TLB insertion with an executable bit.
      This TLB entry may be used by the CPU as the basis for speculating the
      page into the I-Cache.  If this speculated page is subsequently used
      for a user process, there is the possibility we will get a stale
      I-cache line picked up as the binary executes.
      
      As a point of good practise, only mark actual kernel text pages as
      executable.  The same has to be done for init_text pages, but they're
      converted to data pages (and the I-Cache flushed) when the init memory
      is released.
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      d7dd2ff1
  8. 31 3月, 2011 1 次提交
  9. 03 3月, 2010 1 次提交
  10. 11 10月, 2008 1 次提交
    • K
      parisc: hijack jump to start_kernel · 089d5528
      Kyle McMartin 提交于
      Bang in our own start_parisc call, which initializes the PDC
      width, and turns on the FPU.
      
      Previously, if CONFIG_PRINTK_TIME was on, we'd attempt to use
      the FPU before we had enabled it, resulting in a difficult
      to diagnose panic.
      
      This patch causes init_per_cpu to redundantly set these for
      cpu0, but this is harmless.
      089d5528
  11. 13 6月, 2008 2 次提交
  12. 15 5月, 2008 1 次提交
  13. 16 3月, 2008 1 次提交
    • H
      [PARISC] head.S: section mismatch fixes · 0c634cc6
      Helge Deller 提交于
      - move boot_args[] into the init section
      - move $global$ into the read_mostly section
      - fix the following two section mismatches:
      WARNING: vmlinux.o(.text+0x9c): Section mismatch: reference to .init.text:start_kernel (between '$pgt_fill_loop' and '$is_pa20')
      WARNING: vmlinux.o(.text+0xa0): Section mismatch: reference to .init.text:start_kernel (between '$pgt_fill_loop' and '$is_pa20')
      Signed-off-by: NHelge Deller <deller@gmx.de>
      SIgned-off-by: NKyle McMartin <kyle@mcmartin.ca>
      0c634cc6
  14. 18 10月, 2007 2 次提交
  15. 17 2月, 2007 1 次提交
  16. 04 10月, 2006 1 次提交
  17. 22 4月, 2006 1 次提交
  18. 22 10月, 2005 2 次提交
  19. 10 9月, 2005 1 次提交
  20. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4