Hi Marcel,
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.
Thanks,
-Daryl.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
That didn't work, but I think I found the problem. Not sure what the =
correct
solution is though.
Rfcomm_sock_cleanup_listen() calls bluez_accept_dequeue() in a loop =
until
bluez_accept_dequeue() has no more sockets to return. For each socket =
that
bluez_accept_dequeue() returns, rfcomm_sock_cleanup_listen() closes and
kills it. Killing it unlinks it from rfcomm_sk_list.
But if the socket is already closed (sk->state =3D=3D BT_CLOSED), then
bluez_accept_dequeue() does not return the socket (it just continues to =
the
next one in the queue). Bluez_accept_dequeue() does unlink it from the
accept queue, but not from rfcomm_sk_list.
I suppose the first question is: Is the bug in cleanup/dequeue, or is =
the
bug elsewhere (i.e.: things shouldn't ever be in quite that state when
cleanup_listen is called)?
Also, should rfcomm_sock_destruct() be called to decrement the use =
count?
-Daryl.
> -----Original Message-----
> From: Marcel Holtmann [mailto:[email protected]]=20
> Sent: September 14, 2004 2:18 AM
> To: Daryl Van Vorst
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Rfcomm use count
>=20
>=20
> Hi Daryl,
>=20
> > I just noticed that bluez_accept_unlink() was called with a=20
> socked that was
> > in state BT_CLOSED, so it can't be the second if(). It=20
> would have been
> > called from the first if().
> >=20
> > Clearly, I'm on glue.
> >=20
> > Still, does the order of bluez_accept_unlink() and=20
> sock_release() matter?
>=20
> I haven't done a full audit yet, but try to switch the order and see
> what happens. From a first look at it it makes sense to only=20
> release the
> socket when all the work is done, because otherwise=20
> lock_sock() makes no
> sense.
>=20
> Regards
>=20
> Marcel
>=20
>=20
>=20
Hi Daryl,
> I just noticed that bluez_accept_unlink() was called with a socked that was
> in state BT_CLOSED, so it can't be the second if(). It would have been
> called from the first if().
>
> Clearly, I'm on glue.
>
> Still, does the order of bluez_accept_unlink() and sock_release() matter?
I haven't done a full audit yet, but try to switch the order and see
what happens. From a first look at it it makes sense to only release the
socket when all the work is done, because otherwise lock_sock() makes no
sense.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
I just noticed that bluez_accept_unlink() was called with a socked that was
in state BT_CLOSED, so it can't be the second if(). It would have been
called from the first if().
Clearly, I'm on glue.
Still, does the order of bluez_accept_unlink() and sock_release() matter?
-Daryl.
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Daryl Van Vorst
> Sent: September 13, 2004 1:49 PM
> To: 'Marcel Holtmann'
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Rfcomm use count
>
>
> Marcel,
>
> Turned on debugging in af_bluetooth.c, and it may reveal the issue...
>
> This time the socket left in /proc is: c39bb6a0
> The syslog messages are attached.
>
> Snippet from /var/log/messages (I added a debug line in
> rfcomm_sock_accept
> to print the error code):
> May 28 11:26:06 jack-00000000 syslog.info klogd:
> bluez_accept_dequeue_R6c5dc344: parent c3a81060
> May 28 11:26:06 jack-00000000 syslog.info klogd:
> bluez_accept_unlink: sk
> c39bb6a0 state 9
> May 28 11:26:06 jack-00000000 syslog.info klogd:
> rfcomm_sock_sendmsg: sock
> c399c910, sk c3ad43e0
> May 28 11:26:06 jack-00000000 syslog.info klogd:
> rfcomm_sock_accept: error
> -512
>
> So bluez_accept_unlink() is getting called. But if the socket
> was really
> unlinked, it wouldn't be in /proc, would it?
>
> Could the problem be the order of release_sock() and
> bluez_accept_unlink()
> in the second if() in the code snippet from af_bluetooth.c below?
> Specifically, does bluez_accept_unlink() need to be called on
> an unlocked
> socket?
>
> Thanks,
>
> -Daryl.
>
> struct sock *bluez_accept_dequeue(struct sock *parent, struct socket
> *newsock)
> {
> struct list_head *p, *n;
> struct bluez_pinfo *pi;
> struct sock *sk;
>
> BT_DBG("parent %p", parent);
>
> list_for_each_safe(p, n, &bluez_pi(parent)->accept_q) {
> pi = list_entry(p, struct bluez_pinfo, accept_q);
> sk = bluez_sk(pi);
>
> lock_sock(sk);
> if (sk->state == BT_CLOSED) {
> release_sock(sk);
> bluez_accept_unlink(sk);
> continue;
> }
>
> if (sk->state == BT_CONNECTED || !newsock) {
> bluez_accept_unlink(sk);
> if (newsock)
> sock_graft(sk, newsock);
> release_sock(sk);
> return sk;
> }
> release_sock(sk);
> }
> return NULL;
> }
>
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of
> > Daryl Van Vorst
> > Sent: September 13, 2004 12:06 PM
> > To: 'Marcel Holtmann'
> > Cc: 'BlueZ Mailing List'
> > Subject: RE: [Bluez-devel] Rfcomm use count
> >
> >
> > Hi Marcel,
> >
> > I have attached a log for you to look at if you have some
> > time. If not,
> > maybe just answer my question below. :)
> >
> > Here's what I see:
> >
> > One stray socket. I added the socket pointer to the proc output.
> > Proc/bluetooth/rfcomm:
> > sk 2C:02:5F:16:05:00 3A:A4:58:16:05:00 9 1 c3b69340
> >
> > I have a setup where I kill my app after a random time
> interval while
> > several devices are connecting, disconnecting, and
> > transfering data, etc.
> >
> > Here's a brief version of the log:
> >
> > 1. Program gets kill signal (time 15:09:30)
> > 2. HCI devices get shut down
> > 3. Some data remaining for transmission is sent.
> > 4. One listen socket is closed (I think this is the one which
> > is not being
> > used)
> > 5. Some sockets/dlcs get closed
> > 6. An incomming connection is received (rfcomm_connect_ind is
> > called, and a
> > socket is created which matches the one in proc)
> > 7. Some more sockets/dlcs get closed
> > 8. The listen (probably the one which is being used) gets closed
> >
> > I don't see any lines from rfcomm_sock_accept after the
> > rfcomm_connect_ind
> > line. And rfcomm_sock_release is never called for the new
> connection.
> >
> > My knowledge here is limited, and I may be mis-interpreting
> > the log. But it
> > appears that a socket is allocated for the new connection as
> > long as there
> > is room in the wait queue. And if that connection is never
> > accepted, is it
> > the job of rfcomm_sock_cleanup_listen() to deal with it? That
> > is, it is not
> > the kernel's duty (outside of the rfcomm module) to deal with
> > the allocated
> > socket?
> >
> > So, I think, it appears that rfcomm_sock_cleanup_listen isn't
> > working right.
> >
> > Not sure if rfcomm_sock_accept is still looping or not while
> > this is going
> > on.
> >
> > More digging needed...
> >
> > Thanks,
> >
> > -Daryl.
> >
> > > -----Original Message-----
> > > From: Daryl Van Vorst [mailto:[email protected]]
> > > Sent: September 13, 2004 9:37 AM
> > > To: 'Marcel Holtmann'
> > > Subject: RE: [Bluez-devel] Rfcomm use count
> > >
> > >
> > > Hi Marcel,
> > >
> > > > 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?
> > >
> > > Thanks for the response.
> > >
> > > I have not yet tried to reproduce it on an x86. And
> > > unfortunately I don't have a good way to trigger the effect.
> > > I have spent quite a lot of time trying to come up with a
> > > simple way (or any way) to reliably reproduce the problem.
> > > Depending on how the next while plays out, I may try to
> > > reproduce it on an x86.
> > >
> > > I would like to be working with a 2.6 kernel, but time
> > > constraints have prevented moving to it (would require
> > > porting drivers). Maybe on an x86 if time permits.
> > >
> > > I'm currently sifting through RFCOMM debug output. When I get
> > > something interesting I'll send it along. I should have
> > > something shortly.
> > >
> > > -Daryl.
> > >
> > >
> >
>
Marcel,
Turned on debugging in af_bluetooth.c, and it may reveal the issue...
This time the socket left in /proc is: c39bb6a0
The syslog messages are attached.
Snippet from /var/log/messages (I added a debug line in rfcomm_sock_accept
to print the error code):
May 28 11:26:06 jack-00000000 syslog.info klogd:
bluez_accept_dequeue_R6c5dc344: parent c3a81060
May 28 11:26:06 jack-00000000 syslog.info klogd: bluez_accept_unlink: sk
c39bb6a0 state 9
May 28 11:26:06 jack-00000000 syslog.info klogd: rfcomm_sock_sendmsg: sock
c399c910, sk c3ad43e0
May 28 11:26:06 jack-00000000 syslog.info klogd: rfcomm_sock_accept: error
-512
So bluez_accept_unlink() is getting called. But if the socket was really
unlinked, it wouldn't be in /proc, would it?
Could the problem be the order of release_sock() and bluez_accept_unlink()
in the second if() in the code snippet from af_bluetooth.c below?
Specifically, does bluez_accept_unlink() need to be called on an unlocked
socket?
Thanks,
-Daryl.
struct sock *bluez_accept_dequeue(struct sock *parent, struct socket
*newsock)
{
struct list_head *p, *n;
struct bluez_pinfo *pi;
struct sock *sk;
BT_DBG("parent %p", parent);
list_for_each_safe(p, n, &bluez_pi(parent)->accept_q) {
pi = list_entry(p, struct bluez_pinfo, accept_q);
sk = bluez_sk(pi);
lock_sock(sk);
if (sk->state == BT_CLOSED) {
release_sock(sk);
bluez_accept_unlink(sk);
continue;
}
if (sk->state == BT_CONNECTED || !newsock) {
bluez_accept_unlink(sk);
if (newsock)
sock_graft(sk, newsock);
release_sock(sk);
return sk;
}
release_sock(sk);
}
return NULL;
}
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Daryl Van Vorst
> Sent: September 13, 2004 12:06 PM
> To: 'Marcel Holtmann'
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Rfcomm use count
>
>
> Hi Marcel,
>
> I have attached a log for you to look at if you have some
> time. If not,
> maybe just answer my question below. :)
>
> Here's what I see:
>
> One stray socket. I added the socket pointer to the proc output.
> Proc/bluetooth/rfcomm:
> sk 2C:02:5F:16:05:00 3A:A4:58:16:05:00 9 1 c3b69340
>
> I have a setup where I kill my app after a random time interval while
> several devices are connecting, disconnecting, and
> transfering data, etc.
>
> Here's a brief version of the log:
>
> 1. Program gets kill signal (time 15:09:30)
> 2. HCI devices get shut down
> 3. Some data remaining for transmission is sent.
> 4. One listen socket is closed (I think this is the one which
> is not being
> used)
> 5. Some sockets/dlcs get closed
> 6. An incomming connection is received (rfcomm_connect_ind is
> called, and a
> socket is created which matches the one in proc)
> 7. Some more sockets/dlcs get closed
> 8. The listen (probably the one which is being used) gets closed
>
> I don't see any lines from rfcomm_sock_accept after the
> rfcomm_connect_ind
> line. And rfcomm_sock_release is never called for the new connection.
>
> My knowledge here is limited, and I may be mis-interpreting
> the log. But it
> appears that a socket is allocated for the new connection as
> long as there
> is room in the wait queue. And if that connection is never
> accepted, is it
> the job of rfcomm_sock_cleanup_listen() to deal with it? That
> is, it is not
> the kernel's duty (outside of the rfcomm module) to deal with
> the allocated
> socket?
>
> So, I think, it appears that rfcomm_sock_cleanup_listen isn't
> working right.
>
> Not sure if rfcomm_sock_accept is still looping or not while
> this is going
> on.
>
> More digging needed...
>
> Thanks,
>
> -Daryl.
>
> > -----Original Message-----
> > From: Daryl Van Vorst [mailto:[email protected]]
> > Sent: September 13, 2004 9:37 AM
> > To: 'Marcel Holtmann'
> > Subject: RE: [Bluez-devel] Rfcomm use count
> >
> >
> > Hi Marcel,
> >
> > > 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?
> >
> > Thanks for the response.
> >
> > I have not yet tried to reproduce it on an x86. And
> > unfortunately I don't have a good way to trigger the effect.
> > I have spent quite a lot of time trying to come up with a
> > simple way (or any way) to reliably reproduce the problem.
> > Depending on how the next while plays out, I may try to
> > reproduce it on an x86.
> >
> > I would like to be working with a 2.6 kernel, but time
> > constraints have prevented moving to it (would require
> > porting drivers). Maybe on an x86 if time permits.
> >
> > I'm currently sifting through RFCOMM debug output. When I get
> > something interesting I'll send it along. I should have
> > something shortly.
> >
> > -Daryl.
> >
> >
>
Hi Marcel,
I have attached a log for you to look at if you have some time. If not,
maybe just answer my question below. :)
Here's what I see:
One stray socket. I added the socket pointer to the proc output.
Proc/bluetooth/rfcomm:
sk 2C:02:5F:16:05:00 3A:A4:58:16:05:00 9 1 c3b69340
I have a setup where I kill my app after a random time interval while
several devices are connecting, disconnecting, and transfering data, etc.
Here's a brief version of the log:
1. Program gets kill signal (time 15:09:30)
2. HCI devices get shut down
3. Some data remaining for transmission is sent.
4. One listen socket is closed (I think this is the one which is not being
used)
5. Some sockets/dlcs get closed
6. An incomming connection is received (rfcomm_connect_ind is called, and a
socket is created which matches the one in proc)
7. Some more sockets/dlcs get closed
8. The listen (probably the one which is being used) gets closed
I don't see any lines from rfcomm_sock_accept after the rfcomm_connect_ind
line. And rfcomm_sock_release is never called for the new connection.
My knowledge here is limited, and I may be mis-interpreting the log. But it
appears that a socket is allocated for the new connection as long as there
is room in the wait queue. And if that connection is never accepted, is it
the job of rfcomm_sock_cleanup_listen() to deal with it? That is, it is not
the kernel's duty (outside of the rfcomm module) to deal with the allocated
socket?
So, I think, it appears that rfcomm_sock_cleanup_listen isn't working right.
Not sure if rfcomm_sock_accept is still looping or not while this is going
on.
More digging needed...
Thanks,
-Daryl.
> -----Original Message-----
> From: Daryl Van Vorst [mailto:[email protected]]
> Sent: September 13, 2004 9:37 AM
> To: 'Marcel Holtmann'
> Subject: RE: [Bluez-devel] Rfcomm use count
>
>
> Hi Marcel,
>
> > 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?
>
> Thanks for the response.
>
> I have not yet tried to reproduce it on an x86. And
> unfortunately I don't have a good way to trigger the effect.
> I have spent quite a lot of time trying to come up with a
> simple way (or any way) to reliably reproduce the problem.
> Depending on how the next while plays out, I may try to
> reproduce it on an x86.
>
> I would like to be working with a 2.6 kernel, but time
> constraints have prevented moving to it (would require
> porting drivers). Maybe on an x86 if time permits.
>
> I'm currently sifting through RFCOMM debug output. When I get
> something interesting I'll send it along. I should have
> something shortly.
>
> -Daryl.
>
>
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
One more thing possibly of interest:
cat /proc/bluetooth/l2cap:
00:00:00:00:00:00 00:00:00:00:00:00 4 3 0x0000 0x0000 1024 0 0x0
-Daryl.
> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of=20
> Daryl Van Vorst
> Sent: September 8, 2004 3:48 PM
> To: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Rfcomm use count
>=20
>=20
> Marcel,
>=20
> I've been able to get the rfcomm use count to stick above 0 using a
> single-threaded app which only does RFCOMM socket calls. After killing
> hciattach and all bluetooth related programs, I have this:
>=20
> lsmod:
> Module Size Used by Not tainted
> rfcomm 23268 2 (autoclean)
> hci_uart 5656 0 (autoclean)
> l2cap 17028 1 (autoclean) [rfcomm]
> bluez 32392 0 (autoclean) [rfcomm hci_uart l2cap]
>=20
> cat /proc/bluetooth/rfcomm:
> sk 3A:A4:58:16:05:00 26:02:5F:16:05:00 9 4
> sk 3A:A4:58:16:05:00 26:02:5F:16:05:00 9 10
>=20
> This shows, I think, two sockets in the BT_CLOSED state which=20
> aren't getting
> cleaned up. Kernel is 2.4.21-mh10 running on an ARM (with ARM=20
> patches, which
> as far as I can tell don't touch any bluetooth code).
>=20
> The test program loops, doing the following, in pseudo code:
>=20
> While(1) {
> 1. Connect to remote device via rfcomm
> 2. send a few 100 bytes of data
> 3. Attempt to receive, but the remote side closes the=20
> connection.
> 4. creates a socket, binds, listens, and accepts an=20
> incomming rfcomm
> connection
> 5. closes the listening socket (continues to use the=20
> socket return
> by accept)
> 6. sends a few 100 bytes and receives ~100kB.
> 7. closes the socket
> }
>=20
> Unfortunately the problem is not easily reproduced. It can=20
> take all day for
> it to happen, with the test program being re-run many times=20
> (and stopped
> with ctrl-c).
>=20
> There are two modules connected via serial. On the device two=20
> copies of this
> program are run, each one specifying a local bluetooth device=20
> in the bind
> calls for connect and listen/accept. i.e. each program works=20
> with its own
> local device and does not do anything with the other device.
>=20
> Any thoughts?
>=20
> -Daryl.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>=20
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
I've been able to get the rfcomm use count to stick above 0 using a
single-threaded app which only does RFCOMM socket calls. After killing
hciattach and all bluetooth related programs, I have this:
lsmod:
Module Size Used by Not tainted
rfcomm 23268 2 (autoclean)
hci_uart 5656 0 (autoclean)
l2cap 17028 1 (autoclean) [rfcomm]
bluez 32392 0 (autoclean) [rfcomm hci_uart l2cap]
cat /proc/bluetooth/rfcomm:
sk 3A:A4:58:16:05:00 26:02:5F:16:05:00 9 4
sk 3A:A4:58:16:05:00 26:02:5F:16:05:00 9 10
This shows, I think, two sockets in the BT_CLOSED state which aren't =
getting
cleaned up. Kernel is 2.4.21-mh10 running on an ARM (with ARM patches, =
which
as far as I can tell don't touch any bluetooth code).
The test program loops, doing the following, in pseudo code:
While(1) {
1. Connect to remote device via rfcomm
2. send a few 100 bytes of data
3. Attempt to receive, but the remote side closes the connection.
4. creates a socket, binds, listens, and accepts an incomming rfcomm
connection
5. closes the listening socket (continues to use the socket return
by accept)
6. sends a few 100 bytes and receives ~100kB.
7. closes the socket
}
Unfortunately the problem is not easily reproduced. It can take all day =
for
it to happen, with the test program being re-run many times (and stopped
with ctrl-c).
There are two modules connected via serial. On the device two copies of =
this
program are run, each one specifying a local bluetooth device in the =
bind
calls for connect and listen/accept. i.e. each program works with its =
own
local device and does not do anything with the other device.
Any thoughts?
-Daryl.
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel