From: Marcel Holtmann <marcel@holtmann.org>
To: Daryl Van Vorst <daryl@wideray.com>
Cc: "'BlueZ Mailing List'" <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Rfcomm use count
Date: Sun, 12 Sep 2004 16:15:15 +0200 [thread overview]
Message-ID: <1094998515.5695.28.camel@pegasus> (raw)
In-Reply-To: <001601c48fa7$38cce900$1a01010a@baked>
Hi Daryl,
> Any suggestions you have regarding the following would be greatly
> appreciated.
>
> I have a server program which does the following:
>
> 1. Intializes and attaches two modules via serial port (CSR 18.1)
> 2. Has SPP and OPP servers
> 3. Does some HCI-level stuff to monitor connections and close connections to
> misbehaving devices.
>
> The program will initiate rfcomm connections to devices which do not allow
> role switches.
>
> If I kill the program while several devices are connected (or are in the
> process of connecting/disconnecting), sometimes the rfcomm use count is left
> above 0 (I've seen it as high as 4). Killing the program detaches the
> modules (this is verified by hcid's log output). Killing sdpd and hcid
> doesn't reduce the use count. No other bluetooth programs are running,
> except a kernel thread krfcommd.
>
> Re-starting the program produces the error "Address already in us(98)" when
> trying to bind the SPP server socket. The only remedy I've found is to
> reboot the device.
>
> Could sending an hci_disconnect directly, rather than using close(), be
> confusing the stack? I realize this isn't the ideal way of closing
> connections... It only gets used if the normal process is taking longer than
> is desired when a device is forcing the server to be a slave.
>
> The kernel version is 2.4.21-mh10, with various ARM patches (which, as far
> as I can tell, do not touch any bluetooth related code). I have a very
> similar program running on 2.4.18-mh8 and have never noticed this problem.
>
> This doesn't seem to be related, but just in case it is: I'm also seeing
> "hci_cmd_task: hci0 command tx timeout" errors. I am able to get the above
> situation to happen without a timeout error.
I haven't had time to look at your problem in the last two weeks and
dealing with ARM related stuff still not fits into my left free time for
the next weeks. Is this behaviour reproduceable on x86 machines and do
you have a small text program to trigger this effect? And what I really
care about, is this problem also available with a 2.6 kernel?
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2004-09-12 14:15 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-31 22:09 [Bluez-devel] Rfcomm use count Daryl Van Vorst
2004-09-08 22:48 ` Daryl Van Vorst
2004-09-08 23:10 ` Daryl Van Vorst
2004-09-12 14:15 ` Marcel Holtmann [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-09-13 19:06 Daryl Van Vorst
2004-09-13 20:48 ` Daryl Van Vorst
2004-09-13 23:54 ` Daryl Van Vorst
2004-09-14 9:18 ` Marcel Holtmann
2004-09-14 21:58 ` Daryl Van Vorst
2004-09-17 0:10 [Bluez-devel] Rfcomm Use Count Daryl Van Vorst
2004-09-17 8:58 ` Marcel Holtmann
2004-09-20 17:58 ` Daryl Van Vorst
2004-09-20 18:32 ` Marcel Holtmann
2004-09-20 18:52 ` Daryl Van Vorst
2004-09-20 19:48 ` Marcel Holtmann
2004-09-20 20:52 ` Daryl Van Vorst
2004-09-20 18:37 ` Daryl Van Vorst
2004-09-20 19:50 ` Marcel Holtmann
2004-09-20 20:11 ` Daryl Van Vorst
2004-09-20 20:34 ` Marcel Holtmann
2004-09-20 21:03 ` Daryl Van Vorst
2004-09-20 21:28 ` Marcel Holtmann
2004-09-20 22:38 ` Daryl Van Vorst
2004-09-20 23:33 ` Marcel Holtmann
2004-09-21 20:14 ` Daryl Van Vorst
2004-09-21 20:32 ` Marcel Holtmann
2004-09-21 20:39 ` Daryl Van Vorst
2004-09-21 21:26 ` Daryl Van Vorst
2004-09-21 22:07 ` Marcel Holtmann
2004-09-21 22:26 ` Marcel Holtmann
2004-09-21 22:44 ` Daryl Van Vorst
2004-09-22 11:08 ` Marcel Holtmann
2004-09-22 13:53 ` Marcel Holtmann
2004-09-22 17:57 ` Daryl Van Vorst
2004-09-22 18:12 ` Marcel Holtmann
2004-09-22 19:05 ` Daryl Van Vorst
2004-09-22 19:33 ` Marcel Holtmann
2004-09-22 19:52 ` Daryl Van Vorst
2004-09-22 19:57 ` Marcel Holtmann
2004-09-22 20:05 ` Daryl Van Vorst
[not found] ` <1096471423.20392.444.camel@igno>
2004-10-02 9:26 ` Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1094998515.5695.28.camel@pegasus \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
--cc=daryl@wideray.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox