1. 12 12月, 2009 1 次提交
  2. 04 12月, 2009 1 次提交
  3. 18 11月, 2009 2 次提交
    • F
      USB: cdc_acm: Fix memory leak after hangup · 051522bb
      Francesco Lavra 提交于
      Am Donnerstag, 10. September 2009 15:43:53 schrieb Dietmar Hilbrich:
      > Hello,
      >
      > i have the following problem with the cdc-acm - driver:
      >
      > I'm using the driver with an "Ericsson F3507G" on a Thinkpad T400.
      >
      > If a disable the device (with the RFKill-Switch) while it is used by a
      > programm like ppp, the driver doesn't seem to correctly clean up the tty,
      > even after the program has been closed)
      >
      > The tty is still active (e.g. there still exists an entry in
      > /sys/dev/char/166:0 if ttyACM0 was used) and if a reacticate the device,
      > this device entry will be skipped and the Device-Nodes ttyACM1, ttyACM2
      > and ttyACM3 will be used.
      >
      > This problem was introduced with the commit
      > 10077d4a (before 2.6.31-rc1) and still
      > exists in 2.6.31.
      >
      > I was able the fix this problem with the following patch:
      >
      > diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
      > index 2bfc41e..0970d2f 100644
      > --- a/drivers/usb/class/cdc-acm.c
      > +++ b/drivers/usb/class/cdc-acm.c
      > @@ -676,6 +676,7 @@ static void acm_tty_hangup(struct tty_struct *tty)
      >         struct acm *acm = tty->driver_data;
      >         tty_port_hangup(&acm->port);
      >         acm_port_down(acm, 0);
      > +       acm_tty_unregister(acm);
      >  }
      
      I have the same problem with cdc-acm (I'm using a Samsung SGH-U900): when I
      unplug it from the USB port during a PPP connection, the ppp daemon gets the
      hangup correctly (and closes the device), but the struct acm corresponding to
      the device disconnected is not freed. Hence reconnecting the device results in
      creation of /dev/ttyACM(x+1). The same happens when the system is hibernated
      during a PPP connection.
      
      This memory leak is due to the fact that when the tty is hung up,
      tty_port_close_start() returns always zero, and acm_tty_close() never reaches
      the point where acm_tty_unregister() is called.
      
      Here is a fix for this.
      Signed-off-by: NFrancesco Lavra <francescolavra@interfree.it>
      Acked-by: NOliver Neukum <oliver@neukum.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      051522bb
    • H
      USB: cdc_acm: Fix race condition when opening tty · 18a77b5d
      Henry Gebhardt 提交于
      If acm_rx_tasklet() gets called before tty_port_block_til_ready()
      returns, then bulk IN urbs may not be sent. This fixes it.
      Signed-off-by: NHenry Gebhardt <gebhardt@astro.uni-tuebingen.de>
      Acked-by: NOliver Neukum <oliver@neukum.org>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      18a77b5d
  4. 10 10月, 2009 1 次提交
  5. 02 10月, 2009 1 次提交
  6. 23 9月, 2009 10 次提交
  7. 21 9月, 2009 1 次提交
  8. 20 9月, 2009 2 次提交
  9. 08 8月, 2009 1 次提交
  10. 21 7月, 2009 1 次提交
  11. 13 7月, 2009 3 次提交
  12. 26 6月, 2009 2 次提交
  13. 16 6月, 2009 4 次提交
  14. 11 6月, 2009 3 次提交
  15. 29 5月, 2009 1 次提交
  16. 24 4月, 2009 1 次提交
  17. 18 4月, 2009 1 次提交
  18. 14 4月, 2009 1 次提交
  19. 07 4月, 2009 2 次提交
  20. 25 3月, 2009 1 次提交
    • P
      usblp: continuously poll for status · dd44be6b
      Pete Zaitcev 提交于
      The usblp in 2.6.18 polled for status regardless if we actually needed it.
      At some point I dropped it, to save the batteries if nothing else.
      As it turned out, printers exist (e.g. Canon BJC-3000) that need prodding
      this way or else they stop. This patch restores the old behaviour.
      If you want to save battery, don't leave jobs in the print queue.
      
      I tested this on my printers by printing and examining usbmon traces
      to make sure status is being requested and printers continue to print.
      Tuomas Jäntti verified the fix on BJC-3000.
      Signed-off-by: NPete Zaitcev <zaitcev@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      dd44be6b