1. 23 6月, 2006 1 次提交
  2. 22 6月, 2006 1 次提交
  3. 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
  4. 12 6月, 2006 1 次提交
    • P
      [PATCH] Fix for the PPTP hangs that have been reported · 289a1e99
      Paul Mackerras 提交于
      People have been reporting that PPP connections over ptys, such as
      used with PPTP, will hang randomly when transferring large amounts of
      data, for instance in http://bugzilla.kernel.org/show_bug.cgi?id=6530.
      I have managed to reproduce the problem, and the patch below fixes the
      actual cause.
      
      The problem is not in fact in ppp_async.c but in n_tty.c.  What
      happens is that when pptp reads from the pty, we call read_chan() in
      drivers/char/n_tty.c on the master side of the pty.  That copies all
      the characters out of its buffer to userspace and then calls
      check_unthrottle(), which calls the pty unthrottle routine, which
      calls tty_wakeup on the slave side, which calls ppp_asynctty_wakeup,
      which calls tasklet_schedule.  So far so good.  Since we are in
      process context, the tasklet runs immediately and calls
      ppp_async_process(), which calls ppp_async_push, which calls the
      tty->driver->write function to send some more output.
      
      However, tty->driver->write() returns zero, because the master
      tty->receive_room is still zero.  We haven't returned from
      check_unthrottle() yet, and read_chan() only updates tty->receive_room
      _after_ calling check_unthrottle.  That means that the driver->write
      call in ppp_async_process() returns 0.  That would be fine if we were
      going to get a subsequent wakeup call, but we aren't (we just had it,
      and the buffer is now empty).
      
      The solution is for n_tty.c to update tty->receive_room _before_
      calling the driver unthrottle routine.  The patch below does this.
      With this patch I was able to transfer a 900MB file over a PPTP
      connection (taking about 25 minutes), whereas without the patch the
      connection would always stall in under a minute.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      289a1e99
  5. 11 6月, 2006 1 次提交
  6. 09 6月, 2006 4 次提交
    • M
      [PATCH] powerpc: Cleanup hvc_rtas.c a little · 6b81e800
      Michael Ellerman 提交于
      A few cleanups in hvc_rtas.c:
       1. Remove unused RTASCONS_PUT_ATTEMPTS
       2. Remove unused rtascons_put_delay.
       3. Use i as a loop counter like everyone else on earth.
       4. Remove pointless variables, eg. x = foo; if (x) return something_else;
       5. Whitespace cleanups and formatting.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      6b81e800
    • M
      [PATCH] powerpc: Make rtas console _much_ faster · b5374461
      Michael Ellerman 提交于
      Currently the hvc_rtas driver is painfully slow to use. Our "benchmark" is
      ls -R /etc, which spits out about 27866 characters. The theoretical maximum
      speed would be about 2.2 seconds, the current code takes ~50 seconds.
      
      The core of the problem is that sometimes when the tty layer asks us to push
      characters the firmware isn't able to handle some or all of them, and so
      returns an error. The current code sees this and just returns to the tty code
      with the buffer half sent.
      
      The khvcd thread will eventually wake up and try to push more characters, which
      will usually work because by then the firmware's had time to make room. But
      the khvcd thread only wakes up every 10 milliseconds, which isn't fast enough.
      
      So change the khvcd thread logic so that if there's an incomplete write we
      yield() and then immediately try writing again. Doing so makes POLL_QUICK and
      POLL_WRITE synonymous, so remove POLL_QUICK.
      
      With this patch our "benchmark" takes ~2.8 seconds.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b5374461
    • A
      [AGPGART] alpha-agp warning fix · 81c24669
      Andrew Morton 提交于
      drivers/char/agp/alpha-agp.c:138: warning: initialization from incompatible pointer type
      drivers/char/agp/alpha-agp.c:139: warning: initialization from incompatible pointer type
      
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Richard Henderson <rth@twiddle.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      81c24669
    • A
      [AGPGART] uninorth-agp warning fixes · b07cd518
      Andrew Morton 提交于
      drivers/char/agp/uninorth-agp.c: In function `agp_uninorth_suspend':
      drivers/char/agp/uninorth-agp.c:332: warning: cast to pointer from integer of different size
      drivers/char/agp/uninorth-agp.c: In function `agp_uninorth_resume':
      drivers/char/agp/uninorth-agp.c:354: warning: cast from pointer to integer of different size
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      b07cd518
  7. 02 6月, 2006 1 次提交
  8. 01 6月, 2006 4 次提交
  9. 31 5月, 2006 2 次提交
  10. 27 5月, 2006 10 次提交
  11. 24 5月, 2006 1 次提交
  12. 23 5月, 2006 1 次提交
  13. 22 5月, 2006 2 次提交
  14. 19 5月, 2006 1 次提交
  15. 16 5月, 2006 7 次提交
  16. 11 5月, 2006 1 次提交
  17. 02 5月, 2006 1 次提交