kernel-packages team mailing list archive

[Konrad Zapałowicz <konrad.zapalowicz@xxxxxxxxxxxxx>]

This is reported against an old version of Ubuntu and many things has
changed since then. Because of that we won't fix this issue however if
this behavior repeats on a modern version please fill a bug report
against it and we will take it from there.

** Changed in: bluez (Ubuntu)
       Status: New => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/310734

Title:
  rfcomm does not release its devices sometimes

Status in bluez package in Ubuntu:
  Invalid

Bug description:
  I use rfcomm to connect to bluetooth GPS receiver.
  /etc/bluetooth/rfcomm.conf is configured to bind four devices
  (rfcomm0..3) to the same bt-addr and channel. There are these four
  devices in /dev/. Sometimes it works perfectly: cat /dev/rfcomm0
  connects to gps-device and prints data. Also 'gpsbabel' is used to
  download mtk-log via this serial port.

  But sometimes something inside the system locks this device. And since then it is impossible to connect to rfcomm0. It says:
    cat: /dev/rfcomm0: Connection timed out
  OR, less often, silently exits with no error message (and no data being transfered). Using rfcomm1, rfcomm2, rfcomm3 solves the problem for a while, until they will be locked too. These devices never unlock on their own. Only rebooting helps.

  During device being locked, `lsof` says nothing on them. After
  releasing all rfcomms (`sudo rfcomm release all`) and ensuring all of
  them really were released (`rfcomm -a`), `lsmod` says module rfcomm is
  still used 2-4 times with no dependencies. Number of dependencies
  seems to always be even (2,4,6), never odd. Removing module rfcomm or
  bluetooth or any other from bluez stack is impossible (they are being
  "used").

  I suggest, this is some kind of kernel-side locking; maybe because the device is not released properly or something like that.
  There is no any strict way to reproduce this behavior. Only intensive using (opening-closing) sometimes makes rfcomm devices 
  "used to death".

  
  Ubuntu Intrepid 8.10 (updated from 8.04) with all up-to-date updates.

  $ lsb_release -rd
  Description:	Ubuntu 8.10
  Release:	8.10

  $ uname -a
  Linux Nolar-XPS 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux

  $ dpkg-query -l | grep bluez
  ii  bluez                                      4.12-0ubuntu5                           Bluetooth tools and daemons
  ii  bluez-alsa                                 4.12-0ubuntu5                           Bluetooth audio support
  rc  bluez-audio                                3.36-1ubuntu2                           Bluetooth audio support
  ii  bluez-btsco                                1:0.50-0ubuntu3                         Bluez Bluetooth SCO tool
  ii  bluez-cups                                 4.12-0ubuntu5                           Bluetooth printer driver for CUPS
  ii  bluez-gnome                                1.8-0ubuntu1                            Bluetooth utilities for GNOME
  ii  bluez-gstreamer                            4.12-0ubuntu5                           Bluetooth gstreamer support
  ii  bluez-hcidump                              1.42-1build1                            Analyses Bluetooth HCI packets
  rc  bluez-network                              3.36-1ubuntu2                           Bluetooth network support
  ii  bluez-utils                                4.12-0ubuntu5                           Transitional package
  ii  python-bluez                               0.15-1build1                            Python wrappers around BlueZ for rapid bluet


  Write what to check if you need more info.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/310734/+subscriptions