1. 01 Dec, 2009 1 commit
    • Alan Stern's avatar
      USB: EHCI: don't send Clear-TT-Buffer following a STALL · c2f6595f
      Alan Stern authored
      This patch (as1304) fixes a regression in ehci-hcd.  Evidently some
      hubs don't handle Clear-TT-Buffer requests correctly, so we should
      avoid sending them when they don't appear to be absolutely necessary.
      The reported symptom is that output on a downstream audio device cuts
      out because the hub stops relaying isochronous packets.
      
      The patch prevents Clear-TT-Buffer requests from being sent following
      a STALL handshake.  In theory a STALL indicates either that the
      downstream device sent a STALL or that no matching TT buffer could be
      found.  In either case, the transfer is completed and the TT buffer
      does not remain busy, so it doesn't need to be cleared.
      
      Also, the patch fixes a minor flaw in the code that actually sends the
      Clear-TT-Buffer requests.  Although the pipe direction isn't really
      used for control transfers, it should be a Send rather than a Receive.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarJavier Kohen <jkohen@users.sourceforge.net>
      CC: David Brownell <david-b@pacbell.net>
      Cc: stable <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c2f6595f
  2. 30 Nov, 2009 36 commits
  3. 29 Nov, 2009 2 commits
    • Alan Stern's avatar
      PM: fix irq enable/disable in runtime PM code · 862f89b3
      Alan Stern authored
      This patch (as1305) fixes a bug in the irq-enable settings and removes
      some related overhead in the runtime PM code.
      
      	In __pm_runtime_resume(), within the scope of the original
      	spin_lock_irq(), we know that irqs are disabled.  There's no
      	reason to go through a pair of enable/disable cycles when
      	acquiring and releasing the parent's lock.
      
      	In __pm_runtime_set_status(), irqs are already disabled when
      	the parent's lock is acquired, and they must remain disabled
      	when it is released.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      862f89b3
    • Andrei Pelinescu-Onciul's avatar
      sctp: on T3_RTX retransmit all the in-flight chunks · 5fdd4bae
      Andrei Pelinescu-Onciul authored
      When retransmitting due to T3 timeout, retransmit all the
      in-flight chunks for the corresponding  transport/path, including
      chunks sent less then 1 rto ago.
      This is the correct behaviour according to rfc4960 section 6.3.3
      E3 and
      "Note: Any DATA chunks that were sent to the address for which the
       T3-rtx timer expired but did not fit in one MTU (rule E3 above)
       should be marked for retransmission and sent as soon as cwnd
       allows (normally, when a SACK arrives). ".
      
      This fixes problems when more then one path is present and the T3
      retransmission of the first chunk that timeouts stops the T3 timer
      for the initial active path, leaving all the other in-flight
      chunks waiting forever or until a new chunk is transmitted on the
      same path and timeouts (and this will happen only if the cwnd
      allows sending new chunks, but since cwnd was dropped to MTU by
      the timeout => it will wait until the first heartbeat).
      
      Example: 10 packets in flight, sent at 0.1 s intervals on the
      primary path. The primary path is down and the first packet
      timeouts. The first packet is retransmitted on another path, the
      T3 timer for the primary path is stopped and cwnd is set to MTU.
      All the other 9 in-flight packets will not be retransmitted
      (unless more new packets are sent on the primary path which depend
      on cwnd allowing it, and even in this case the 9 packets will be
      retransmitted only after a new packet timeouts which even in the
      best case would be more then RTO).
      
      This commit reverts d0ce9291 and
      also removes the now unused transport->last_rto, introduced in
       b6157d8e.
      
      p.s  The problem is not only when multiple paths are there.  It
      can happen in a single homed environment.  If the application
      stops sending data, it possible to have a hung association.
      Signed-off-by: default avatarAndrei Pelinescu-Onciul <andrei@iptel.org>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5fdd4bae
  4. 27 Nov, 2009 1 commit
    • Alan Cox's avatar
      V4L/DVB (13530): Fix wrong parameter order in memset · 361c9511
      Alan Cox authored
      Edwin Török found the following:
      
      In function ‘memset’,
      inlined from ‘ir_input_init’ at drivers/media/common/ir-functions.c:67:
      /home/edwin/builds/linux-2.6/arch/x86/include/asm/string_64.h:61:
      warning: call to ‘__warn_memset_zero_len’ declared with attribute
      warning: memset used with constant zero length parameter; this could be
      due to transposed parameters
      memset(ir->ir_codes, sizeof(ir->ir_codes), 0);
      
      In actual practice the only caller I can find happens to already have cleared
      the buffer before calling ir_input_init.
      Signed-off-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      361c9511