RE: [Bluez-devel] Rfcomm use count

["Daryl Van Vorst" <daryl@wideray.com>]

[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]

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:daryl@wideray.com] 
> 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.
> 
> 

[-- Attachment #2: messages.gz --]
[-- Type: application/x-gzip, Size: 3161 bytes --]