1. 20 3月, 2006 2 次提交
    • D
      [SPARC64]: Move away from virtual page tables, part 1. · 74bf4312
      David S. Miller 提交于
      We now use the TSB hardware assist features of the UltraSPARC
      MMUs.
      
      SMP is currently knowingly broken, we need to find another place
      to store the per-cpu base pointers.  We hid them away in the TSB
      base register, and that obviously will not work any more :-)
      
      Another known broken case is non-8KB base page size.
      
      Also noticed that flush_tlb_all() is not referenced anywhere, only
      the internal __flush_tlb_all() (local cpu only) is used by the
      sparc64 port, so we can get rid of flush_tlb_all().
      
      The kernel gets it's own 8KB TSB (swapper_tsb) and each address space
      gets it's own private 8K TSB.  Later we can add code to dynamically
      increase the size of per-process TSB as the RSS grows.  An 8KB TSB is
      good enough for up to about a 4MB RSS, after which the TSB starts to
      incur many capacity and conflict misses.
      
      We even accumulate OBP translations into the kernel TSB.
      
      Another area for refinement is large page size support.  We could use
      a secondary address space TSB to handle those.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74bf4312
    • B
      [SPARC64]: fix sparc_floppy_irq's auxio_register reseting · 94bbc176
      Bernhard R Link 提交于
      The patch "[SPARC64]: Get rid of fast IRQ feature"
      moved the the code from arch/sparc64/kernel/entry.S:
            lduba           [%g7] ASI_PHYS_BYPASS_EC_E, %g5
            or              %g5, AUXIO_AUX1_FTCNT, %g5
            stba            %g5, [%g7] ASI_PHYS_BYPASS_EC_E
            andn            %g5, AUXIO_AUX1_FTCNT, %g5
            stba            %g5, [%g7] ASI_PHYS_BYPASS_EC_E
      to arch/sparc64/kernel/irq.c:
                    val = readb(auxio_register);
                    val |= AUXIO_AUX1_FTCNT;
                    writeb(val, auxio_register);
                    val &= AUXIO_AUX1_FTCNT;
                    writeb(val, auxio_register);
      This looks like it it missing a bitwise not, which is reintroduced
      by this patch.
      
      Due to lack of a floppy device, I could not test it, but it looks
      evident.
      Signed-off-by: NBernhard R Link <brlink@debian.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94bbc176
  2. 05 3月, 2006 1 次提交
  3. 27 2月, 2006 2 次提交
  4. 13 2月, 2006 1 次提交
  5. 10 2月, 2006 1 次提交
  6. 08 2月, 2006 2 次提交
  7. 05 2月, 2006 2 次提交
  8. 30 1月, 2006 1 次提交
  9. 23 1月, 2006 1 次提交
  10. 20 1月, 2006 1 次提交
  11. 19 1月, 2006 6 次提交
  12. 18 1月, 2006 1 次提交
    • R
      [SPARC64]: Eliminate race condition reading Hummingbird STICK register · 9eb3394b
      Richard Mortimer 提交于
      Ensure a consistent value is read from the STICK register by ensuring
      that both high and low are read without high changing due to a roll
      over of the low register.
      
      Various Debian/SPARC users (myself include) have noticed problems with
      Hummingbird based systems. The symptoms are that the system time is
      seen to jump forward 3 days, 6 hours, 11 minutes give or take a few
      seconds. In many cases the system then hangs some time afterwards.
      
      I've spotted a race condition in the code to read the STICK register.
      I could not work out why 3d, 6h, 11m is important but guess that it is
      due to the 2^32 jump of STICK (forwards on one read and then the next
      read will seem to be backwards) during a timer interrupt. I'm guessing
      that a change of -2^32 will get converted to a large unsigned
      increment after the arithmetic manipulation between STICK,
      nanoseconds, jiffies etc.
      
      I did a test where I modified __hbird_read_stick to artificially
      inject rollover faults forcefully every few seconds. With this I saw
      the clock jump over 6 times in 12 hours compared to once every month
      or so.
      Signed-off-by: NRichard Mortimer <richm@oldelvet.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9eb3394b
  13. 13 1月, 2006 3 次提交
  14. 12 1月, 2006 3 次提交
  15. 11 1月, 2006 5 次提交
  16. 10 1月, 2006 5 次提交
  17. 09 1月, 2006 2 次提交
  18. 29 12月, 2005 1 次提交
反馈
建议
客服 返回
顶部