1. 11 7月, 2006 1 次提交
  2. 04 7月, 2006 1 次提交
  3. 03 7月, 2006 1 次提交
  4. 01 7月, 2006 1 次提交
  5. 24 6月, 2006 1 次提交
  6. 20 6月, 2006 1 次提交
    • D
      [SPARC]: Kill __irq_itoa(). · c6387a48
      David S. Miller 提交于
      This ugly hack was long overdue to die.
      
      It was a way to print out Sparc interrupts in a more freindly format,
      since IRQ numbers were arbitrary opaque 32-bit integers which vectored
      into PIL levels.  These 32-bit integers were not necessarily in the
      0-->NR_IRQS range, but the PILs they vectored to were.
      
      The idea now is that we will increase NR_IRQS a little bit and use a
      virtual<-->real IRQ number mapping scheme similar to PowerPC.
      
      That makes this IRQ printing hack irrelevant, and furthermore only a
      handful of drivers actually used __irq_itoa() making it even less
      useful.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6387a48
  7. 12 1月, 2006 1 次提交
  8. 07 11月, 2005 1 次提交
  9. 06 9月, 2005 1 次提交
  10. 05 8月, 2005 1 次提交
    • P
      [PATCH] rtc: msleep() cannot be used from interrupt · 403fe5ae
      Petr Vandrovec 提交于
      Since the beginning of July my Opteron box was randomly crashing and
      being rebooted by hardware watchdog.  Today it finally did it in front
      of me, and this patch will hopefully fix it.
      
      The problem is that at the end of June (the 28th, to be exact: commit
      47f176fd, "[PATCH] Using msleep()
      instead of HZ") rtc_get_rtc_time was converted to use msleep() instead
      of busy waiting.  But rtc_get_rtc_time is used by hpet_rtc_interrupt,
      and scheduling is not allowed during interrupt.  So I'm reverting this
      part of original change, replacing msleep() back with busy loop.
      
      The original code was busy waiting for up to 20ms, but on my hardware in
      the worst case update-in-progress bit was asserted for at most 363
      passes through loop (on 2GHz dual Opteron), much less than even one
      jiffie, not even talking about 20ms.  So I changed code to just wait
      only as long as necessary.  Otherwise when RTC was set to generate
      8192Hz timer, it stopped doing anything for 20ms (160 pulses were
      skipped!) from time to time, and this is rather suboptimal as far as I
      can tell.
      Signed-off-by: NPetr Vandrovec <vandrove@vc.cvut.cz>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      403fe5ae
  11. 29 6月, 2005 1 次提交
  12. 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
新手
引导
客服 返回
顶部