1. 11 Jun, 2006 9 commits
    • Aki M Nyrhinen's avatar
      [TCP]: continued: reno sacked_out count fix · 79320d7e
      Aki M Nyrhinen authored
      From: Aki M Nyrhinen <anyrhine@cs.helsinki.fi>
      IMHO the current fix to the problem (in_flight underflow in reno)
      is incorrect.  it treats the symptons but ignores the problem. the
      problem is timing out packets other than the head packet when we
      don't have sack. i try to explain (sorry if explaining the obvious).
      with sack, scanning the retransmit queue for timed out packets is
      fine because we know which packets in our retransmit queue have been
      acked by the receiver.
      without sack, we know only how many packets in our retransmit queue the
      receiver has acknowledged, but no idea which packets.
      think of a "typical" slow-start overshoot case, where for example
      every third packet in a window get lost because a router buffer gets
      with sack, we check for timeouts on those every third packet (as the
      rest have been sacked). the packet counting works out and if there
      is no reordering, we'll retransmit exactly the packets that were 
      without sack, however, we check for timeout on every packet and end up
      retransmitting consecutive packets in the retransmit queue. in our
      slow-start example, 2/3 of those retransmissions are unnecessary. these
      unnecessary retransmissions eat the congestion window and evetually
      prevent fast recovery from continuing, if enough packets were lost.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Andrea Bittau's avatar
      [DCCP] Ackvec: fix soft lockup in ackvec handling code · afec35e3
      Andrea Bittau authored
      A soft lockup existed in the handling of ack vector records.
      Specifically, when a tail of the list of ack vector records was
      removed, it was possible to end up iterating infinitely on an element
      of the tail.
      Signed-off-by: default avatarAndrea Bittau <a.bittau@cs.ucl.ac.uk>
      Signed-off-by: default avatarIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Paul Mackerras's avatar
      [PATCH] Fix for the PPTP hangs that have been reported · 289a1e99
      Paul Mackerras authored
      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: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Linus Torvalds's avatar
      Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6 · dc4967e7
      Linus Torvalds authored
      * master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6:
        [PATCH] PCI: reverse pci config space restore order
        [PATCH] PCI: Improve PCI config space writeback
        [PATCH] PCI: Error handling on PCI device resume
        [PATCH] PCI: fix pciehp compile issue when CONFIG_ACPI is not enabled
    • Christoph Lameter's avatar
      [PATCH] typo in vmscan.c · c0bbbc73
      Christoph Lameter authored
      From: Christoph Lameter <clameter@sgi.com>
      Looks like a comma was left from the conversion from a struct to an
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Yu, Luming's avatar
      [PATCH] PCI: reverse pci config space restore order · 8b8c8d28
      Yu, Luming authored
      According to Intel ICH spec, there are several rules that Base Address
      should be programmed before IOSE  (PCICMD register ) enabled.
      For example ICH7:
      12.1.3  SATA : the base address register for the bus master register
                     should be programmed before this bit is set.
      11.1.3:  PCICMD (USB): The base address register for USB should be
                             programmed before this bit is set.
      To make sure kernel code follow this rule , and prevent unnecessary
      confusion. I proposal this patch.
      Signed-off-by: default avatarLuming Yu <luming.yu@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Dave Jones's avatar
      [PATCH] PCI: Improve PCI config space writeback · 04d9c1a1
      Dave Jones authored
      At least one laptop blew up on resume from suspend with a black screen due
      to a lack of this patch.  By only writing back config space that is
      different, we minimise the possibility of accidents like this.
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Jean Delvare's avatar
      [PATCH] PCI: Error handling on PCI device resume · 8d92bc22
      Jean Delvare authored
      We currently don't handle errors properly when resuming a PCI device:
      * In pci_default_resume() we capture the error code returned by
        pci_enable_device() but don't pass it up to the caller.
        Introduced by commit 95a62965
      * In pci_resume_device(), the errors possibly returned by the driver's
        .resume method or by the generic pci_default_resume() function are
      This patch fixes both issues.
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • akpm@osdl.org's avatar
      [PATCH] PCI: fix pciehp compile issue when CONFIG_ACPI is not enabled · 0ce03039
      akpm@osdl.org authored
      Fix build error when CONFIG_ACPI not defined
      Signed-off-by: default avatarKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  2. 10 Jun, 2006 9 commits
  3. 09 Jun, 2006 3 commits
  4. 08 Jun, 2006 16 commits
  5. 05 Jun, 2006 3 commits