Hi,
Here is patch for rfcomm to keep rfcomm device in list until it's really
unused.
--
Ville
Hi Marcel,
On 6/4/07, Marcel Holtmann <[email protected]> wrote:
> it was attached to Ville's email. And it doesn't solve the issue with
Hmm... sorry, but I don't see it. Which e-mail from Ville? Maybe I'm
having problems with the list?
Regards,
-- Ulisses
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Ville,
> > do you have a simple re-producer for it. I need to test this on my Quad
> > G5 before pushing this upstream.
>
> Nope. Claudio said that he had some way to reproduce the bug with some
> cvs version. I haven't tried that yet. I need to install some distro to
> test machine first. However I tested this with N800 and it works fine on
> arm.
but I need to make sure that this is also working on SMP systems and all
other desktops.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> Hi Ville,
>
> do you have a simple re-producer for it. I need to test this on my Quad
> G5 before pushing this upstream.
Nope. Claudio said that he had some way to reproduce the bug with some
cvs version. I haven't tried that yet. I need to install some distro to
test machine first. However I tested this with N800 and it works fine on
arm.
1. utils/serial/port.c comment line 151 "g_io_channel_close"
2. comment the last line of utils/serial/test-serial : "serial.DisconnectService(device)"
call "test-serial address channel" the first time, after establish
the connection press ctrl+c and execute the same command again
--
Ville
Hi Ville,
> > > > > Here is patch for rfcomm to keep rfcomm device in list until it's really
> > > > > unused.
> > > >
> > > > dev = __rfcomm_dev_get(id);
> > > > +
> > > > + if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> > > > + dev = NULL;
> > > > +
> > > > if (dev)
> > > > rfcomm_dev_hold(dev);
> > > >
> > > > a test_bit() and then return NULL at the beginning makes more sense. No
> > > > need to take the lock since test_bit() is atomic anyway.
> > >
> > > How do I get flags then? Function only gets device id.
> >
> > good point. I overlooked that part.
> >
> > > I noticed another bug. If __rfcomm_dev_get returns null we end up using
> > > NULL pointer. Fixed version attached.
> >
> > Please remove this part:
> >
> > -#ifndef CONFIG_BT_RFCOMM_DEBUG
> > +#ifdef CONFIG_BT_RFCOMM_DEBUG
>
> Removed.
>
> >
> > And use this code:
> >
> > if (dev) {
> > if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> > dev = NULL;
> > else
> > rfcomm_dev_hold(dev);
> > }
> >
> > It makes it a little bit more readable and easier to understand what we
> > are doing there.
>
> Agreed. New version attached.
do you have a simple re-producer for it. I need to test this on my Quad
G5 before pushing this upstream.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, Jun 04, 2007 at 10:49:04AM +0200, ext Marcel Holtmann wrote:
> Hi Ville,
>
> > > > Here is patch for rfcomm to keep rfcomm device in list until it's really
> > > > unused.
> > >
> > > dev = __rfcomm_dev_get(id);
> > > +
> > > + if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> > > + dev = NULL;
> > > +
> > > if (dev)
> > > rfcomm_dev_hold(dev);
> > >
> > > a test_bit() and then return NULL at the beginning makes more sense. No
> > > need to take the lock since test_bit() is atomic anyway.
> >
> > How do I get flags then? Function only gets device id.
>
> good point. I overlooked that part.
>
> > I noticed another bug. If __rfcomm_dev_get returns null we end up using
> > NULL pointer. Fixed version attached.
>
> Please remove this part:
>
> -#ifndef CONFIG_BT_RFCOMM_DEBUG
> +#ifdef CONFIG_BT_RFCOMM_DEBUG
Removed.
>
> And use this code:
>
> if (dev) {
> if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> dev = NULL;
> else
> rfcomm_dev_hold(dev);
> }
>
> It makes it a little bit more readable and easier to understand what we
> are doing there.
Agreed. New version attached.
--
Ville
Hi Ulisses,
> > > > > Here is patch for rfcomm to keep rfcomm device in list until it's really
> > > > > unused.
> > > >
> > > > dev = __rfcomm_dev_get(id);
> > > > +
> > > > + if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> > > > + dev = NULL;
> > > > +
> > > > if (dev)
> > > > rfcomm_dev_hold(dev);
> > > >
> > > > a test_bit() and then return NULL at the beginning makes more sense. No
> > > > need to take the lock since test_bit() is atomic anyway.
> > >
> > > How do I get flags then? Function only gets device id.
> >
> > good point. I overlooked that part.
> >
> > > I noticed another bug. If __rfcomm_dev_get returns null we end up using
> > > NULL pointer. Fixed version attached.
> >
> > Please remove this part:
> >
> > -#ifndef CONFIG_BT_RFCOMM_DEBUG
> > +#ifdef CONFIG_BT_RFCOMM_DEBUG
> >
> > And use this code:
> >
> > if (dev) {
> > if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> > dev = NULL;
> > else
> > rfcomm_dev_hold(dev);
> > }
> >
> > It makes it a little bit more readable and easier to understand what we
> > are doing there.
>
> Where is this patch? I couldn't find it. Does it solve that problem we
> had with RFCOMM_HANGUP_NOW flag?
it was attached to Ville's email. And it doesn't solve the issue with
setting RFCOMM_HANGUP_NOW flag, but that should already be solved and
the patch for that is upstream in 2.6.22-rc3.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On 6/4/07, Marcel Holtmann <[email protected]> wrote:
> Hi Ville,
>
> > > > Here is patch for rfcomm to keep rfcomm device in list until it's really
> > > > unused.
> > >
> > > dev = __rfcomm_dev_get(id);
> > > +
> > > + if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> > > + dev = NULL;
> > > +
> > > if (dev)
> > > rfcomm_dev_hold(dev);
> > >
> > > a test_bit() and then return NULL at the beginning makes more sense. No
> > > need to take the lock since test_bit() is atomic anyway.
> >
> > How do I get flags then? Function only gets device id.
>
> good point. I overlooked that part.
>
> > I noticed another bug. If __rfcomm_dev_get returns null we end up using
> > NULL pointer. Fixed version attached.
>
> Please remove this part:
>
> -#ifndef CONFIG_BT_RFCOMM_DEBUG
> +#ifdef CONFIG_BT_RFCOMM_DEBUG
>
> And use this code:
>
> if (dev) {
> if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> dev = NULL;
> else
> rfcomm_dev_hold(dev);
> }
>
> It makes it a little bit more readable and easier to understand what we
> are doing there.
Where is this patch? I couldn't find it. Does it solve that problem we
had with RFCOMM_HANGUP_NOW flag?
Regards,
-- Ulisses
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Ville,
> > > Here is patch for rfcomm to keep rfcomm device in list until it's really
> > > unused.
> >
> > dev = __rfcomm_dev_get(id);
> > +
> > + if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> > + dev = NULL;
> > +
> > if (dev)
> > rfcomm_dev_hold(dev);
> >
> > a test_bit() and then return NULL at the beginning makes more sense. No
> > need to take the lock since test_bit() is atomic anyway.
>
> How do I get flags then? Function only gets device id.
good point. I overlooked that part.
> I noticed another bug. If __rfcomm_dev_get returns null we end up using
> NULL pointer. Fixed version attached.
Please remove this part:
-#ifndef CONFIG_BT_RFCOMM_DEBUG
+#ifdef CONFIG_BT_RFCOMM_DEBUG
And use this code:
if (dev) {
if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
dev = NULL;
else
rfcomm_dev_hold(dev);
}
It makes it a little bit more readable and easier to understand what we
are doing there.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> > Here is patch for rfcomm to keep rfcomm device in list until it's really
> > unused.
>
> dev = __rfcomm_dev_get(id);
> +
> + if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
> + dev = NULL;
> +
> if (dev)
> rfcomm_dev_hold(dev);
>
> a test_bit() and then return NULL at the beginning makes more sense. No
> need to take the lock since test_bit() is atomic anyway.
How do I get flags then? Function only gets device id.
I noticed another bug. If __rfcomm_dev_get returns null we end up using
NULL pointer. Fixed version attached.
--
Ville
Hi Ville,
> Here is patch for rfcomm to keep rfcomm device in list until it's really
> unused.
dev = __rfcomm_dev_get(id);
+
+ if (test_bit(RFCOMM_TTY_RELEASED, &dev->flags))
+ dev = NULL;
+
if (dev)
rfcomm_dev_hold(dev);
a test_bit() and then return NULL at the beginning makes more sense. No
need to take the lock since test_bit() is atomic anyway.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel