* Virtual cable unplug not supported in BlueZ?
From: Liang Bao @ 2010-07-20 9:30 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I have a question on "Virtual Cable Unplug" in current BlueZ version.
Currently BlueZ doesn't expose a D-Bus method in input/device.c for
virtually unplug cable which is a mandatory requirement to pass
TC_HOS_HCR_BV_03_I. Actually the support in kernel is already there.
Can anyone give some insight to why this is not exposed at the DBUS
API level like Connect/Disconnect/GetProperties? Can I think the
reason behind this design is we only need one of "Disconnect" and
"VirtualUnplug" to allow user to disconnect?
Thanks.
Regards,
Liang Bao
^ permalink raw reply
* obex-client: doesn't allways closes socket
From: Vitja Makarov @ 2010-07-20 7:12 UTC (permalink / raw)
To: linux-bluetooth
Hi!
Recently I've found that obex client doesn't allways close socket, I
was using obexd-0.29...
Even more sometimes it closes same socket twice using
g_io_channel_unref() and close()
When it comes to client/session.c:rfcomm_connect() with error,
session->sock is not set and socket is not closed on
session_shutdown()
Don't know why g_io_channel_unref() isn't called for that socket..
test-case:
./send-files xx:xx:xx:xx:xx xxx.xxx
ls /proc/`pgrep obexd-client`/fd | wc -l
then don't accept incoming connection on your phone, press no
When you press yes to receive file, see strace output obexd-client
closes socket twice...
vitja.
^ permalink raw reply
* Re: [PATCH] Bluetooth: Defer SCO setup if mode change is pending
From: Ron Shaffer @ 2010-07-20 4:44 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1279562776-12901-1-git-send-email-marcel@holtmann.org>
Marcel:
On 7/19/2010 1:06 PM, Marcel Holtmann wrote:
> @@ -385,10 +406,13 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8
> acl->power_save = 1;
> hci_conn_enter_active_mode(acl);
>
> - if (lmp_esco_capable(hdev))
> - hci_setup_sync(sco, acl->handle);
> - else
> - hci_add_sco(sco, acl->handle);
> + if (test_bit(HCI_CONN_MODE_CHANGE_PEND, &acl->pend)) {
> + /* defer SCO setup until mode change completed */
> + set_bit(HCI_CONN_SCO_SETUP_PEND, &acl->pend);
> + return sco;
> + }
> +
> + hci_sco_setup(acl, 0x00);
> }
Not in love with the "fake" status passed here, but the overall change
to centralize this functionality provides a nice cleanup from the
original patch and makes the code more readable and maintainable.
>
> return sco;
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 2069c3b..461413c 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -775,9 +775,6 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
>
> BT_DBG("%s status 0x%x", hdev->name, status);
>
> - if (!status)
> - return;
> -
> cp = hci_sent_cmd_data(hdev, HCI_OP_SNIFF_MODE);
> if (!cp)
> return;
> @@ -785,8 +782,13 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
> hci_dev_lock(hdev);
>
> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
> - if (conn)
> - clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> + if (conn) {
> + if (status)
> + clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> +
> + if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND, &conn->pend))
> + hci_sco_setup(conn, status);
Probably the subject for another patch, but has there been any reported
issue where idle_timeout is set short enough that the timer expires
after exit sniff mode has been requested but before the mode change
event has been received?
Got back from other duties late tonight, so I didn't get testing fully
finished. In particular, I need to see what happens when idle_timeout is
set very low ex < 10. I'll let you know the results first thing in the
morning. If everything is good, I'll regenerate the patch with original
hcidump log included
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* RE: [PATCH 1/3] Add BT3 AMP device support, by Atheros Linux BT3 team.
From: Dan Tian @ 2010-07-20 2:24 UTC (permalink / raw)
To: Marcel Holtmann, Haijun Liu, Gustavo F. Padovan
Cc: Luis Rodriguez, linux-bluetooth@vger.kernel.org
In-Reply-To: <1279296516.6282.76.camel@localhost.localdomain>
TWFyY2VsLA0KDQpXZSB3aWxsIHNwbGl0IGludG8gc21hbGwgcGF0Y2hlcyB0byBiZSBtb3JlIGVh
c3kgdG8gcmV2aWV3Lg0KDQpSZWdhcmRzDQpEYW4NCg0KDQo=
^ permalink raw reply
* RE: [PATCH 3/3] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Matt Wilson @ 2010-07-19 22:07 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Ron Shaffer, linux-bluetooth@vger.kernel.org
In-Reply-To: <1279174425.6282.60.camel@localhost.localdomain>
Hi Marcel,
> However what is up with the mode change. If that fails, we are still in
> sniff mode and can just proceed with the SCO setup attempt. With the
> broken hardware it will fail for sure, but with good behaving LM on the
> remote side it might just get the device out of sniff mode at that point
> and SCO setup can succeed.
>
> Why do you imply that a mode change event with a failure means that the
> ACL is no longer present?
I was thinking the Mode Change event would carry a LMP response timeout
or link supervision (LS) timeout status when the two devices lose
synchronization while in sniff just after sending exit sniff LMP PDU
(only baseband ACK). It is more clear when the LS timeout is greater
than the 30 second (immutable) LMP response timeout.
But reading the LMP spec (2.4.1) I conclude that the former cannot occur
in the exit sniff scenario and the Disconnection Complete event is the
only required event in the latter.
I agree to wait until we have a clear and real scenario and then discuss
further with those logs.
Best regards,
-Matt
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH] Bluetooth: Move bit-field var to data->flags
From: Gustavo F. Padovan @ 2010-07-19 19:48 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <AANLkTilbCpi-Dt-Pk1w3o7wahMNiAXIweC4xE1Y-skZ3@mail.gmail.com>
Hi Anderson,
* Anderson Lizardo <anderson.lizardo@openbossa.org> [2010-07-19 15:03:33 -0400]:
> On Mon, Jul 19, 2010 at 2:40 PM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> >> On Fri, Jul 16, 2010 at 4:20 PM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> >> > @@ -810,7 +810,7 @@ static void btusb_work(struct work_struct *work)
> >> > int err;
> >> >
> >> > if (hdev->conn_hash.sco_num > 0) {
> >> > - if (!data->did_iso_resume) {
> >> > + if (!test_bit(BTUSB_DID_ISO_RESUME, &data->flags)) {
> >> > err = usb_autopm_get_interface(data->isoc);
> >> > if (err < 0) {
> >> > clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
> >> > @@ -818,7 +818,7 @@ static void btusb_work(struct work_struct *work)
> >> > return;
> >> > }
> >> >
> >> > - data->did_iso_resume = 1;
> >> > + set_bit(BTUSB_DID_ISO_RESUME, &data->flags);
> >> > }
> >> > if (data->isoc_altsetting != 2) {
> >> > clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
> >>
> >> Just wondering ... could test_and_set_bit() be used here (instead of
> >> test_bit() + set_bit()) ?
> >
> > No, because usb_autopm_get_interface() can return a error. In that case
> > we shall not set the bit.
>
> Ok, but in this case looks like there is a clear_bit() already there.
No, the clear_bit() clears the BTUSB_ISOC_RUNNING and not
BTUSB_DID_ISO_RESUME that we are talking here.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH] Bluetooth: Move bit-field var to data->flags
From: Anderson Lizardo @ 2010-07-19 19:03 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20100719184017.GA13327@vigoh>
On Mon, Jul 19, 2010 at 2:40 PM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
>> On Fri, Jul 16, 2010 at 4:20 PM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
>> > @@ -810,7 +810,7 @@ static void btusb_work(struct work_struct *work)
>> > int err;
>> >
>> > if (hdev->conn_hash.sco_num > 0) {
>> > - if (!data->did_iso_resume) {
>> > + if (!test_bit(BTUSB_DID_ISO_RESUME, &data->flags)) {
>> > err = usb_autopm_get_interface(data->isoc);
>> > if (err < 0) {
>> > clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
>> > @@ -818,7 +818,7 @@ static void btusb_work(struct work_struct *work)
>> > return;
>> > }
>> >
>> > - data->did_iso_resume = 1;
>> > + set_bit(BTUSB_DID_ISO_RESUME, &data->flags);
>> > }
>> > if (data->isoc_altsetting != 2) {
>> > clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
>>
>> Just wondering ... could test_and_set_bit() be used here (instead of
>> test_bit() + set_bit()) ?
>
> No, because usb_autopm_get_interface() can return a error. In that case
> we shall not set the bit.
Ok, but in this case looks like there is a clear_bit() already there.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [HCI Events] Connection Event Processing
From: Shreesh Holla @ 2010-07-19 18:45 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Johan Hedberg, linux-bluetooth
In-Reply-To: <1279564755.4572.31.camel@localhost.localdomain>
--- On Mon, 7/19/10, Marcel Holtmann <marcel@holtmann.org> wrote:
> From: Marcel Holtmann <marcel@holtmann.org>
> Subject: Re: [HCI Events] Connection Event Processing
> To: "Shreesh Holla" <hshreesh@yahoo.com>
> Cc: "Johan Hedberg" <johan.hedberg@gmail.com>, linux-bluetooth@vger.kernel.org
> Date: Monday, July 19, 2010, 11:39 AM
> Hi Shreesh,
>
> > Firstly, my intention has not been to be rude etc - I
> really dont know what top posting is. But, if I have posted
> something that has offended anyone - please excuse that and
> as it was not intentional - only trying to figure out the
> best approach to our issue.
>
> and you did it again. Really? Just typing top-posting into
> Google or
> Wikipedia would have resulted in proper information:
>
> http://en.wikipedia.org/wiki/Top_Posting
>
> And while at it. Here is another nice read:
>
> http://www.catb.org/~esr/faqs/smart-questions.html
>
> And all of this is linked from bluez.org website:
>
> http://www.bluez.org/development/lists/
>
> Regards
>
> Marcel
>
>
>
Marcel,
I understand what it is now. I was really just using the default of Yahoo Mail. But shall follow this approach henceforth of bottom posting.
Thanks,
Shreesh
^ permalink raw reply
* Re: [PATCH] Bluetooth: Move bit-field var to data->flags
From: Gustavo F. Padovan @ 2010-07-19 18:40 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <AANLkTilHzxBXd2KemlUhfJPnqVjDS5eIbkC_JWc-aKwm@mail.gmail.com>
Hi Anderson,
* Anderson Lizardo <anderson.lizardo@openbossa.org> [2010-07-19 13:19:52 -0400]:
> Hi Gustavo,
>
> On Fri, Jul 16, 2010 at 4:20 PM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> > @@ -810,7 +810,7 @@ static void btusb_work(struct work_struct *work)
> > int err;
> >
> > if (hdev->conn_hash.sco_num > 0) {
> > - if (!data->did_iso_resume) {
> > + if (!test_bit(BTUSB_DID_ISO_RESUME, &data->flags)) {
> > err = usb_autopm_get_interface(data->isoc);
> > if (err < 0) {
> > clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
> > @@ -818,7 +818,7 @@ static void btusb_work(struct work_struct *work)
> > return;
> > }
> >
> > - data->did_iso_resume = 1;
> > + set_bit(BTUSB_DID_ISO_RESUME, &data->flags);
> > }
> > if (data->isoc_altsetting != 2) {
> > clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
>
> Just wondering ... could test_and_set_bit() be used here (instead of
> test_bit() + set_bit()) ?
No, because usb_autopm_get_interface() can return a error. In that case
we shall not set the bit.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [HCI Events] Connection Event Processing
From: Marcel Holtmann @ 2010-07-19 18:39 UTC (permalink / raw)
To: Shreesh Holla; +Cc: Johan Hedberg, linux-bluetooth
In-Reply-To: <828454.70868.qm@web56507.mail.re3.yahoo.com>
Hi Shreesh,
> Firstly, my intention has not been to be rude etc - I really dont know what top posting is. But, if I have posted something that has offended anyone - please excuse that and as it was not intentional - only trying to figure out the best approach to our issue.
and you did it again. Really? Just typing top-posting into Google or
Wikipedia would have resulted in proper information:
http://en.wikipedia.org/wiki/Top_Posting
And while at it. Here is another nice read:
http://www.catb.org/~esr/faqs/smart-questions.html
And all of this is linked from bluez.org website:
http://www.bluez.org/development/lists/
Regards
Marcel
^ permalink raw reply
* Re: [HCI Events] Connection Event Processing
From: Shreesh Holla @ 2010-07-19 18:30 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Johan Hedberg, linux-bluetooth
In-Reply-To: <1279563007.4572.24.camel@localhost.localdomain>
Marcel,=0A=0AFirstly, my intention has not been to be rude etc - I really d=
ont know what top posting is. But, if I have posted something that has offe=
nded anyone - please excuse that and as it was not intentional - only tryin=
g to figure out the best approach to our issue.=0A=0ABut, from your comment=
s below I do see that this connection hookup needs to happen in the kernel.=
And I shall explore the RAW mode - if it can work for us.=0A=0ABut thanks,=
=0AShreesh=0A=0A--- On Mon, 7/19/10, Marcel Holtmann <marcel@holtmann.org> =
wrote:=0A=0A> From: Marcel Holtmann <marcel@holtmann.org>=0A> Subject: Re: =
[HCI Events] Connection Event Processing=0A> To: "Shreesh Holla" <hshreesh=
@yahoo.com>=0A> Cc: "Johan Hedberg" <johan.hedberg@gmail.com>, linux-blueto=
oth@vger.kernel.org=0A> Date: Monday, July 19, 2010, 11:10 AM=0A> Hi Shress=
h,=0A> =0A> first of all, stop top posting. This is rude and we will=0A> ig=
nore further=0A> emails from you if you keep doing this.=0A> =0A> > ugh! I =
see the issues now. As you said - neither of=0A> those approaches would wor=
k for me since we need to=0A> conditionally handle the incoming connection =
really.=0A> > =0A> > Wonder if there is some design reason this was done=0A=
> i.e. hardcoding it in hci_event.c? Or is it for performance=0A> reasons?=
=A0=A0=A0Any plans on supporting this in=0A> the future? =0A> > =0A> > What=
I'm considering is plugging in our own handler=0A> inside hci_event.c.=0A>=
> =0A> > We can do this inside some custom hardware - but we=0A> are tryin=
g to avoid this since we already have other custom=0A> hardware we need to =
do in our device which is a wireless=0A> access control system.=0A> =0A> I =
really don't know what you are trying to achieve here,=0A> but you might=0A=
> better not use BlueZ if you wanna do something like this.=0A> The connect=
ion=0A> handling needs to be done in the kernel and it does this=0A> the ri=
ght way.=0A> =0A> Use your own Bluetooth stack or switch the device into RA=
W=0A> mode and=0A> program it as you like. As Johan mentioned RAW devices a=
re=0A> left alone by=0A> the kernel.=0A> =0A> Regards=0A> =0A> Marcel=0A> =
=0A> =0A>
^ permalink raw reply
* Re: [HCI Events] Connection Event Processing
From: Marcel Holtmann @ 2010-07-19 18:10 UTC (permalink / raw)
To: Shreesh Holla; +Cc: Johan Hedberg, linux-bluetooth
In-Reply-To: <128267.36461.qm@web56505.mail.re3.yahoo.com>
Hi Shressh,
first of all, stop top posting. This is rude and we will ignore further
emails from you if you keep doing this.
> ugh! I see the issues now. As you said - neither of those approaches would work for me since we need to conditionally handle the incoming connection really.
>
> Wonder if there is some design reason this was done i.e. hardcoding it in hci_event.c? Or is it for performance reasons? Any plans on supporting this in the future?
>
> What I'm considering is plugging in our own handler inside hci_event.c.
>
> We can do this inside some custom hardware - but we are trying to avoid this since we already have other custom hardware we need to do in our device which is a wireless access control system.
I really don't know what you are trying to achieve here, but you might
better not use BlueZ if you wanna do something like this. The connection
handling needs to be done in the kernel and it does this the right way.
Use your own Bluetooth stack or switch the device into RAW mode and
program it as you like. As Johan mentioned RAW devices are left alone by
the kernel.
Regards
Marcel
^ permalink raw reply
* [PATCH] Bluetooth: Defer SCO setup if mode change is pending
From: Marcel Holtmann @ 2010-07-19 18:06 UTC (permalink / raw)
To: linux-bluetooth
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/hci_core.h | 2 +
net/bluetooth/hci_conn.c | 32 ++++++++++++++++++++++++---
net/bluetooth/hci_event.c | 43 ++++++++++++++++---------------------
3 files changed, 49 insertions(+), 28 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 350b3e6..8b28962 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -256,6 +256,7 @@ enum {
HCI_CONN_ENCRYPT_PEND,
HCI_CONN_RSWITCH_PEND,
HCI_CONN_MODE_CHANGE_PEND,
+ HCI_CONN_SCO_SETUP_PEND,
};
static inline void hci_conn_hash_init(struct hci_dev *hdev)
@@ -336,6 +337,7 @@ void hci_acl_connect(struct hci_conn *conn);
void hci_acl_disconn(struct hci_conn *conn, __u8 reason);
void hci_add_sco(struct hci_conn *conn, __u16 handle);
void hci_setup_sync(struct hci_conn *conn, __u16 handle);
+void hci_sco_setup(struct hci_conn *conn, __u8 status);
struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst);
int hci_conn_del(struct hci_conn *conn);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index e9fef83..0b1e460 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -155,6 +155,27 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp);
}
+/* Device _must_ be locked */
+void hci_sco_setup(struct hci_conn *conn, __u8 status)
+{
+ struct hci_conn *sco = conn->link;
+
+ BT_DBG("%p", conn);
+
+ if (!sco)
+ return;
+
+ if (!status) {
+ if (lmp_esco_capable(conn->hdev))
+ hci_setup_sync(sco, conn->handle);
+ else
+ hci_add_sco(sco, conn->handle);
+ } else {
+ hci_proto_connect_cfm(sco, status);
+ hci_conn_del(sco);
+ }
+}
+
static void hci_conn_timeout(unsigned long arg)
{
struct hci_conn *conn = (void *) arg;
@@ -385,10 +406,13 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8
acl->power_save = 1;
hci_conn_enter_active_mode(acl);
- if (lmp_esco_capable(hdev))
- hci_setup_sync(sco, acl->handle);
- else
- hci_add_sco(sco, acl->handle);
+ if (test_bit(HCI_CONN_MODE_CHANGE_PEND, &acl->pend)) {
+ /* defer SCO setup until mode change completed */
+ set_bit(HCI_CONN_SCO_SETUP_PEND, &acl->pend);
+ return sco;
+ }
+
+ hci_sco_setup(acl, 0x00);
}
return sco;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 2069c3b..461413c 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -775,9 +775,6 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
BT_DBG("%s status 0x%x", hdev->name, status);
- if (!status)
- return;
-
cp = hci_sent_cmd_data(hdev, HCI_OP_SNIFF_MODE);
if (!cp)
return;
@@ -785,8 +782,13 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
- if (conn)
- clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+ if (conn) {
+ if (status)
+ clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+
+ if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND, &conn->pend))
+ hci_sco_setup(conn, status);
+ }
hci_dev_unlock(hdev);
}
@@ -798,9 +800,6 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
BT_DBG("%s status 0x%x", hdev->name, status);
- if (!status)
- return;
-
cp = hci_sent_cmd_data(hdev, HCI_OP_EXIT_SNIFF_MODE);
if (!cp)
return;
@@ -808,8 +807,13 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
- if (conn)
- clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+ if (conn) {
+ if (status)
+ clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+
+ if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND, &conn->pend))
+ hci_sco_setup(conn, status);
+ }
hci_dev_unlock(hdev);
}
@@ -915,20 +919,8 @@ static inline void hci_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *s
} else
conn->state = BT_CLOSED;
- if (conn->type == ACL_LINK) {
- struct hci_conn *sco = conn->link;
- if (sco) {
- if (!ev->status) {
- if (lmp_esco_capable(hdev))
- hci_setup_sync(sco, conn->handle);
- else
- hci_add_sco(sco, conn->handle);
- } else {
- hci_proto_connect_cfm(sco, ev->status);
- hci_conn_del(sco);
- }
- }
- }
+ if (conn->type == ACL_LINK)
+ hci_sco_setup(conn, ev->status);
if (ev->status) {
hci_proto_connect_cfm(conn, ev->status);
@@ -1481,6 +1473,9 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
else
conn->power_save = 0;
}
+
+ if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND, &conn->pend))
+ hci_sco_setup(conn, ev->status);
}
hci_dev_unlock(hdev);
--
1.7.1.1
^ permalink raw reply related
* Re: [HCI Events] Connection Event Processing
From: Shreesh Holla @ 2010-07-19 18:03 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20100718080229.GA30607@jh-x301>
Johan,
ugh! I see the issues now. As you said - neither of those approaches would work for me since we need to conditionally handle the incoming connection really.
Wonder if there is some design reason this was done i.e. hardcoding it in hci_event.c? Or is it for performance reasons? Any plans on supporting this in the future?
What I'm considering is plugging in our own handler inside hci_event.c.
We can do this inside some custom hardware - but we are trying to avoid this since we already have other custom hardware we need to do in our device which is a wireless access control system.
Thanks,
Shreesh
--- On Sun, 7/18/10, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> From: Johan Hedberg <johan.hedberg@gmail.com>
> Subject: Re: [HCI Events] Connection Event Processing
> To: "Shreesh Holla" <hshreesh@yahoo.com>
> Cc: linux-bluetooth@vger.kernel.org
> Date: Sunday, July 18, 2010, 1:02 AM
> Hi Shreesh,
>
> On Fri, Jul 16, 2010, Shreesh Holla wrote:
> > I'm trying to build a handler for a project and
> needed to process the
> > Connection Request Event.
> > I'm able to get that properly. But I tried
> adding a "reject Connection" -
> > command in the handler and invariably an "Accept
> Connection" command is
> > issued.This is what I can see from hcidump and
> my event handling code.
> >
> > I need to override that. So where is this done?
> In the Bluez library,
> > bluetoothd
> >
> > or btusb? Or somewhere else? Or is there some other
> kind of setup/hooks that
> > needs to be modified to insert my own event
> handler?
> >
> > Any help would be great here.
>
> The response to the connect request is more or less
> hardcoded into the
> hci_conn_request_evt function in net/bluetooth/hci_event.c.
> There's a
> patch[1] in the bluetooth-next-2.6 tree which adds
> blacklist support,
> but afaik it's only headed for 2.6.36. It's also only a
> static list of
> addresses to be rejected, so if you want something more
> dynamic it wont
> be of much help.
>
> Another way to avoid the kernel response to the connect
> request is to
> set the HCI device into RAW mode but then you also loose
> all other
> Bluetooth functionality provided by the kernel and
> userspace (i.e. you'd
> essentially need to implement a full host stack yourself).
>
> Johan
>
> [1] http://git.kernel.org/?p=linux/kernel/git/holtmann/bluetooth-next-2.6.git;a=commitdiff;h=a1e716eedbed0bac3e9b84b7f53de182e12345cb
>
^ permalink raw reply
* Re: [PATCH] Bluetooth: Move bit-field var to data->flags
From: Anderson Lizardo @ 2010-07-19 17:19 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <1279311633-12131-1-git-send-email-gustavo@padovan.org>
Hi Gustavo,
On Fri, Jul 16, 2010 at 4:20 PM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> @@ -810,7 +810,7 @@ static void btusb_work(struct work_struct *work)
> int err;
>
> if (hdev->conn_hash.sco_num > 0) {
> - if (!data->did_iso_resume) {
> + if (!test_bit(BTUSB_DID_ISO_RESUME, &data->flags)) {
> err = usb_autopm_get_interface(data->isoc);
> if (err < 0) {
> clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
> @@ -818,7 +818,7 @@ static void btusb_work(struct work_struct *work)
> return;
> }
>
> - data->did_iso_resume = 1;
> + set_bit(BTUSB_DID_ISO_RESUME, &data->flags);
> }
> if (data->isoc_altsetting != 2) {
> clear_bit(BTUSB_ISOC_RUNNING, &data->flags);
Just wondering ... could test_and_set_bit() be used here (instead of
test_bit() + set_bit()) ?
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH] Bluetooth: use __packed in drivers/bluetooth
From: Marcel Holtmann @ 2010-07-19 17:03 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, Gustavo F. Padovan
In-Reply-To: <1279558445-9910-1-git-send-email-gustavo@padovan.org>
Hi Gustavo,
> Use the __packed annotation instead of the __attribute__((packed)).
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> drivers/bluetooth/bpa10x.c | 2 +-
> drivers/bluetooth/btmrvl_drv.h | 4 ++--
> drivers/bluetooth/dtl1_cs.c | 2 +-
> drivers/bluetooth/hci_ll.c | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* [PATCH] Bluetooth: use __packed in drivers/bluetooth
From: Gustavo F. Padovan @ 2010-07-19 16:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo F. Padovan
From: Gustavo F. Padovan <padovan@profusion.mobi>
Use the __packed annotation instead of the __attribute__((packed)).
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
drivers/bluetooth/bpa10x.c | 2 +-
drivers/bluetooth/btmrvl_drv.h | 4 ++--
drivers/bluetooth/dtl1_cs.c | 2 +-
drivers/bluetooth/hci_ll.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/bpa10x.c b/drivers/bluetooth/bpa10x.c
index d945cd1..751b338 100644
--- a/drivers/bluetooth/bpa10x.c
+++ b/drivers/bluetooth/bpa10x.c
@@ -62,7 +62,7 @@ struct hci_vendor_hdr {
__u8 type;
__le16 snum;
__le16 dlen;
-} __attribute__ ((packed));
+} __packed;
static int bpa10x_recv(struct hci_dev *hdev, int queue, void *buf, int count)
{
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index 872cb6c..90bda50 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -119,13 +119,13 @@ struct btmrvl_cmd {
__le16 ocf_ogf;
u8 length;
u8 data[4];
-} __attribute__ ((packed));
+} __packed;
struct btmrvl_event {
u8 ec; /* event counter */
u8 length;
u8 data[4];
-} __attribute__ ((packed));
+} __packed;
/* Prototype of global function */
diff --git a/drivers/bluetooth/dtl1_cs.c b/drivers/bluetooth/dtl1_cs.c
index ef044d5..cbe9e44 100644
--- a/drivers/bluetooth/dtl1_cs.c
+++ b/drivers/bluetooth/dtl1_cs.c
@@ -104,7 +104,7 @@ typedef struct {
u8 type;
u8 zero;
u16 len;
-} __attribute__ ((packed)) nsh_t; /* Nokia Specific Header */
+} __packed nsh_t; /* Nokia Specific Header */
#define NSHL 4 /* Nokia Specific Header Length */
diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index fb8445c..5744aba 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -74,7 +74,7 @@ enum hcill_states_e {
struct hcill_cmd {
u8 cmd;
-} __attribute__((packed));
+} __packed;
struct ll_struct {
unsigned long rx_state;
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: Support for Atheros AR300x serial Bluetooth Chip
From: Marcel Holtmann @ 2010-07-19 16:44 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1279523047-4638-1-git-send-email-suraj@atheros.com>
Hi Suraj,
> Implements Atheros AR300x Serial HCI protocol.
> This protocol extends H4 serial protocol to implement enhanced power management
> features supported by Atheros AR300x serial Bluetooth chipsets.
>
> Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> ---
> drivers/bluetooth/Kconfig | 12 ++
> drivers/bluetooth/Makefile | 1 +
> drivers/bluetooth/hci_ath.c | 235 +++++++++++++++++++++++++++++++++++++++++
> drivers/bluetooth/hci_ldisc.c | 6 +
> drivers/bluetooth/hci_uart.h | 8 ++-
> 5 files changed, 261 insertions(+), 1 deletions(-)
> create mode 100755 drivers/bluetooth/hci_ath.c
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* [PATCH 2/2] Add function tracer formatter
From: Manuel Naranjo @ 2010-07-19 16:26 UTC (permalink / raw)
To: BlueZ
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
This patch adds the script available at
http://www.logix.cz/michal/devel/CygProfiler to the tools folder, I
don't know if it makes sense to install this into somewhere as this is
only developers only intendeed.
The way to use it is:
perl tools/cyg-resolve.pl src/.libs/bluetoothd bluetoothd-log.<PID>
Signed-off-by: Manuel Naranjo <manuel@aircable.net>
[-- Attachment #2: 0002-added-perl-script-to-resolve-symbols-on-tracing.patch --]
[-- Type: text/plain, Size: 3019 bytes --]
>From 43691108561e8e39226ccd9064a05690ba48bd66 Mon Sep 17 00:00:00 2001
From: Manuel Francisco Naranjo <manuel@aircable.net>
Date: Mon, 19 Jul 2010 13:18:43 -0300
Subject: [PATCH 2/2] added perl script to resolve symbols on tracing
---
tools/cyg-resolve.pl | 111 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 111 insertions(+), 0 deletions(-)
create mode 100644 tools/cyg-resolve.pl
diff --git a/tools/cyg-resolve.pl b/tools/cyg-resolve.pl
new file mode 100644
index 0000000..5d56bd3
--- /dev/null
+++ b/tools/cyg-resolve.pl
@@ -0,0 +1,111 @@
+#!/usr/bin/perl
+
+#
+# cyg-resolve.pl - CygProfiler resolver
+#
+# Michal Ludvig <michal@logix.cz>
+# http://www.logix.cz/michal/devel
+#
+# Use this script to parse the output of the CygProfile suite.
+#
+
+use strict;
+use warnings;
+no warnings 'portable';
+use diagnostics;
+use English;
+
+my %symtab;
+my ($binfile, $textfile, $levelcorr);
+
+$OUTPUT_AUTOFLUSH=1;
+
+&help() if($#ARGV < 1);
+$binfile=$ARGV[0];
+&help() if($binfile =~ /--help/);
+$textfile=($#ARGV > 0 ? $ARGV[1] : "cygprof.log");
+$levelcorr=($#ARGV > 1 ? $ARGV[2] : -1);
+
+&main();
+
+# ==== Subs
+
+sub help()
+{
+ printf("CygProgile parser, Michal Ludvig <michal\@logix.cz>, 2002-2003\n");
+ printf("Usage: %s <bin-file> <log-file> [<correction>]\n", $0);
+ printf("\t<bin-file> Program that generated the logfile.\n");
+ printf("\t<log-file> Logfile generated by the profiled program.\n");
+ printf("\t<correction> Correction of the nesting level.\n");
+ exit;
+}
+
+sub main()
+{
+ my($offset, $type, $function);
+ my($nsym, $nfunc);
+
+ $nsym=0;
+ $nfunc=0;
+
+ open(NM, "nm $binfile|") or die("Unable to run 'nm $binfile': $!\n");
+ printf("Loading symbols from $binfile ... ");
+
+ while(<NM>)
+ {
+ $nsym++;
+ next if(!/^([0-9A-F]+) (.) (.+)$/i);
+ $offset=hex($1); $type=$2; $function=$3;
+ next if($type !~ /[tT]/);
+ $nfunc++;
+ $symtab{$offset}=$function;
+ }
+ printf("OK\nSeen %d symbols, stored %d function offsets\n", $nsym, $nfunc);
+ close(NM);
+
+ open(TEXT, "$textfile")
+ or die("Unable to open '$textfile': $!\n");
+
+ if ($levelcorr == -1)
+ {
+ $levelcorr = 0;
+ while(<TEXT>)
+ {
+ if ((/^.*[+-] (-*\d+)/) && ($1 < -$levelcorr))
+ { $levelcorr = -$1; }
+ }
+ printf("Level correction set to %d\n", $levelcorr);
+ seek(TEXT, 0, 0);
+ }
+
+ while(<TEXT>)
+ {
+ # Change the pattern if the output format
+ # of __cyg_...() functions has changed.
+ if(!/(.*)([+-]) (-*\d+) 0x([[:xdigit:]]+) 0x([[:xdigit:]]+)\s*(\d*)/)
+ { print $_; next; }
+ else
+ {
+ my $prolog=$1;
+ my $type=$2;
+
+ my $level=$3 + $levelcorr;
+ my $off1=hex($4);
+ my $off2=hex($5);
+ my $pid=$6;
+
+ printf("$prolog\n") if ($prolog);
+
+ # Don't print exits
+ next if($type eq "-");
+ my $sym=(defined($symtab{$off1})?$symtab{$off1}:"???");
+
+ printf("\t%s %2d 0x%x (from 0x%x) %*s%s\n",
+ $type, $level, $off1, $off2,
+ $level+1, " ", "$sym()");
+ }
+ }
+ close(TEXT);
+
+ printf("done\n");
+}
--
1.6.4.4
^ permalink raw reply related
* [PATCH 1/2] Add function call tracing
From: Manuel Naranjo @ 2010-07-19 16:26 UTC (permalink / raw)
To: BlueZ
[-- Attachment #1: Type: text/plain, Size: 275 bytes --]
This patch adds all the necessary functions and code that allow function
tracing on the bluetoothd server. This should make race conditions and
seg faults easy to debug. Off course this is not intendeed for end users.
Signed-off-by: Manuel Naranjo <manuel@aircable.net>
[-- Attachment #2: 0001-Add-Function-call-tracing.patch --]
[-- Type: text/plain, Size: 8924 bytes --]
>From b0f4d8eeab8ee2dba77247b77ee6ce159b931d7b Mon Sep 17 00:00:00 2001
From: Manuel Francisco Naranjo <manuel@aircable.net>
Date: Mon, 19 Jul 2010 13:15:22 -0300
Subject: [PATCH 1/2] Add Function call tracing
modified: Makefile.am
modified: acinclude.m4
* Add an option so configure script can be tell to enable function tracing,
for good function tracing this options need to be used:
--enable-trace \
--enable-debug \
--disable-optimization \
--disable-fortify \
--disable-pie
new file: src/cyg-profile.c
new file: src/cyg-profile.h
* Based on code from http://www.logix.cz/michal/devel/CygProfiler this uses
-finstrument-functions from gcc and adds some function to store the tracing
to a file, which will be called as bluetoothd-log.$PID
modified: src/main.c
* Allow users to enable or disable tracing (only available when configured with
this option).
---
Makefile.am | 4 +
acinclude.m4 | 11 ++++
src/cyg-profile.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++
src/cyg-profile.h | 40 +++++++++++++
src/main.c | 15 +++++
5 files changed, 239 insertions(+), 0 deletions(-)
create mode 100644 src/cyg-profile.c
create mode 100644 src/cyg-profile.h
diff --git a/Makefile.am b/Makefile.am
index f4bf87d..b146f3f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -216,6 +216,10 @@ CLEANFILES += src/bluetooth.ver src/bluetooth.exp $(builtin_files)
man_MANS = src/bluetoothd.8
+if TRACE
+src_bluetoothd_SOURCES += src/cyg-profile.h src/cyg-profile.c
+endif
+
if CONFIGFILES
conf_DATA += src/main.conf
endif
diff --git a/acinclude.m4 b/acinclude.m4
index f5fdd66..99d9e4d 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -154,6 +154,7 @@ AC_DEFUN([AC_PATH_SNDFILE], [
AC_DEFUN([AC_ARG_BLUEZ], [
debug_enable=no
+ trace_enable=no
optimization_enable=yes
fortify_enable=yes
pie_enable=yes
@@ -288,6 +289,11 @@ AC_DEFUN([AC_ARG_BLUEZ], [
debug_enable=${enableval}
])
+ AC_ARG_ENABLE(trace, AC_HELP_STRING([--enable-trace], [enable compiling with function tracing information]), [
+ trace_enable=${enableval}
+ ])
+
+
AC_ARG_WITH(telephony, AC_HELP_STRING([--with-telephony=DRIVER], [select telephony driver]), [
telephony_driver=${withval}
])
@@ -311,6 +317,10 @@ AC_DEFUN([AC_ARG_BLUEZ], [
CFLAGS="$CFLAGS -g"
fi
+ if (test "${trace_enable}" = "yes" && test "${ac_cv_prog_cc_g}" = "yes"); then
+ CFLAGS="$CFLAGS -finstrument-functions -DTRACE"
+ fi
+
if (test "${optimization_enable}" = "no"); then
CFLAGS="$CFLAGS -O0"
fi
@@ -333,6 +343,7 @@ AC_DEFUN([AC_ARG_BLUEZ], [
AM_CONDITIONAL(ECHOPLUGIN, test "no" = "yes")
AM_CONDITIONAL(PNATPLUGIN, test "${pnat_enable}" = "yes")
AM_CONDITIONAL(TRACER, test "${tracer_enable}" = "yes")
+ AM_CONDITIONAL(TRACE, test "${trace_enable}" = "yes")
AM_CONDITIONAL(HIDD, test "${hidd_enable}" = "yes")
AM_CONDITIONAL(PAND, test "${pand_enable}" = "yes")
AM_CONDITIONAL(DUND, test "${dund_enable}" = "yes")
diff --git a/src/cyg-profile.c b/src/cyg-profile.c
new file mode 100644
index 0000000..20f5597
--- /dev/null
+++ b/src/cyg-profile.c
@@ -0,0 +1,169 @@
+/*
+ * cyg-profile.c - CygProfiler runtime functions.
+ *
+ * Michal Ludvig <michal@logix.cz>
+ * http://www.logix.cz/michal/devel
+ *
+ * cyg-profile.c
+ * - Compile your program with -finstrument-functions and link
+ * together with this code.
+ * - Logging is enabled as soon as your program calls
+ * cygprofile_enable() and disabled with cygprofile_disable().
+ * - Before logging was enabled you can change the name
+ * of a logfile by calling cygprofile_setfilename().
+ */
+
+/* Hint: -finstrument-functions, no_instrument_function */
+
+#include <errno.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <string.h>
+
+#include "cyg-profile.h"
+
+#ifdef TRACE
+
+#define FN_SIZE 100
+#define FN_DEFAULT "bluetoothd-log.%d"
+
+/* Private variables. */
+static int level=0;
+static FILE *logfile=NULL;
+static int cyg_profile_enabled=0;
+static char cyg_profile_filename[FN_SIZE+1];
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* Static functions. */
+static FILE *openlogfile (const char *filename)
+ __attribute__ ((no_instrument_function));
+static void closelogfile (void)
+ __attribute__ ((no_instrument_function));
+
+/* Note that these are linked internally by the compiler.
+ * Don't call them directly! */
+void __cyg_profile_func_enter (void *this_fn, void *call_site)
+ __attribute__ ((no_instrument_function));
+void __cyg_profile_func_exit (void *this_fn, void *call_site)
+ __attribute__ ((no_instrument_function));
+
+#ifdef __cplusplus
+};
+#endif
+
+void
+__cyg_profile_func_enter (void *this_fn, void *call_site)
+{
+ if(cyg_profile_enabled)
+ if (logfile || openlogfile(cyg_profile_filename))
+ fprintf(logfile, "+ %d %p %p\n", level++,
+ this_fn, call_site);
+}
+
+void
+__cyg_profile_func_exit (void *this_fn, void *call_site)
+{
+ if(cyg_profile_enabled)
+ if (logfile || openlogfile(cyg_profile_filename))
+ fprintf(logfile, "- %d %p %p\n", level--,
+ this_fn, call_site);
+}
+
+void
+cygprofile_enable (void)
+{
+ if (!cyg_profile_filename[0])
+ cygprofile_setfilename (FN_DEFAULT);
+ if (!openlogfile (cyg_profile_filename))
+ return;
+ cyg_profile_enabled = 1;
+}
+
+void
+cygprofile_disable (void)
+{
+ cyg_profile_enabled = 0;
+}
+
+int
+cygprofile_isenabled (void)
+{ return cyg_profile_enabled; }
+
+int
+cygprofile_setfilename (const char *filename)
+{
+ char *ptr;
+
+ if (cygprofile_isenabled ())
+ return -1;
+
+ if (strlen (filename) > FN_SIZE)
+ return -2;
+
+ ptr = strstr (filename, "%d");
+ if (ptr)
+ {
+ size_t len;
+ len = ptr - filename;
+ snprintf (cyg_profile_filename, len+1, "%s", filename);
+ snprintf (&cyg_profile_filename[len], FN_SIZE - len,
+ "%d", getpid ());
+ len = strlen (cyg_profile_filename);
+ snprintf (&cyg_profile_filename[len], FN_SIZE - len,
+ "%s", ptr + 2);
+ }
+ else
+ snprintf (cyg_profile_filename, FN_SIZE, "%s", filename);
+
+ if (logfile)
+ closelogfile ();
+
+ return 0;
+}
+
+char *
+cygprofile_getfilename (void)
+{
+ if (!cyg_profile_filename[0])
+ cygprofile_setfilename (FN_DEFAULT);
+ return cyg_profile_filename;
+}
+
+static FILE *
+openlogfile (const char *filename)
+{
+ static int complained = 0;
+ FILE *file;
+
+ if (complained)
+ return NULL;
+
+ if (logfile)
+ return logfile;
+
+ file = fopen(filename, "w");
+ if (!file)
+ {
+ fprintf (stderr, "WARNING: Can't open logfile '%s': %s\n",
+ filename, strerror (errno));
+ complained = 1;
+ return NULL;
+ }
+
+ setlinebuf (file);
+ logfile = file;
+
+ return file;
+}
+
+static void
+closelogfile (void)
+{
+ if (logfile)
+ fclose (logfile);
+}
+
+#endif //#ifdef TRACE
diff --git a/src/cyg-profile.h b/src/cyg-profile.h
new file mode 100644
index 0000000..97be613
--- /dev/null
+++ b/src/cyg-profile.h
@@ -0,0 +1,40 @@
+/*
+ * cyg-profile.h - Header file for CygProfiler
+ *
+ * Michal Ludvig <michal@logix.cz>
+ * http://www.logix.cz/michal/devel
+ *
+ * This source code is a public domain.
+ *
+ * See cyg-profile.c for details on usage.
+ */
+
+#ifndef CYG_PROFILE_H
+#define CYG_PROFILE_H
+
+/* Public functions. */
+
+#ifdef TRACE
+
+/* Enable/disable CygProfiler. */
+void cygprofile_enable (void)
+ __attribute__ ((no_instrument_function));
+void cygprofile_disable (void)
+ __attribute__ ((no_instrument_function));
+
+/* Tell whether CygProfiler is enabled/disabled. */
+int cygprofile_isenabled (void)
+ __attribute__ ((no_instrument_function));
+
+/* Set filename of a logfile. */
+int cygprofile_setfilename (const char *filename)
+ __attribute__ ((no_instrument_function));
+
+/* Query for a filename of a logfile. */
+char *cygprofile_getfilename (void)
+ __attribute__ ((no_instrument_function));
+
+
+#endif //#ifdef TRACE
+
+#endif
diff --git a/src/main.c b/src/main.c
index 6113217..23a649e 100644
--- a/src/main.c
+++ b/src/main.c
@@ -60,6 +60,10 @@
#include <cap-ng.h>
#endif
+#ifdef TRACE
+#include "cyg-profile.h"
+#endif
+
#define LAST_ADAPTER_EXIT_TIMEOUT 30
struct main_opts main_opts;
@@ -304,6 +308,7 @@ static gchar *option_debug = NULL;
static gboolean option_detach = TRUE;
static gboolean option_version = FALSE;
static gboolean option_udev = FALSE;
+static gboolean option_trace = FALSE;
static guint last_adapter_timeout = 0;
@@ -357,6 +362,10 @@ static GOptionEntry options[] = {
"Show version information and exit" },
{ "udev", 'u', 0, G_OPTION_ARG_NONE, &option_udev,
"Run from udev mode of operation" },
+#ifdef TRACE
+ { "trace", 't', 0, G_OPTION_ARG_NONE, &option_trace,
+ "Create trace function calls file" },
+#endif
{ NULL },
};
@@ -393,6 +402,12 @@ int main(int argc, char *argv[])
g_option_context_free(context);
+#ifdef TRACE
+ if (option_trace == TRUE) {
+ cygprofile_enable();
+ }
+#endif
+
if (option_version == TRUE) {
printf("%s\n", VERSION);
exit(0);
--
1.6.4.4
^ permalink raw reply related
* RE: Patches for kernel bluetooth
From: Waldemar.Rymarkiewicz @ 2010-07-19 16:07 UTC (permalink / raw)
To: gustavo; +Cc: marcel, linux-bluetooth
In-Reply-To: <20100719155804.GA23801@vigoh>
Ok, I see.=20
Thanks,
/Waldek
>-----Original Message-----
>From: Gustavo F. Padovan [mailto:gfpadovan@gmail.com] On=20
>Behalf Of Gustavo F. Padovan
>Sent: Monday, July 19, 2010 5:58 PM
>To: Rymarkiewicz Waldemar
>Cc: marcel@holtmann.org; linux-bluetooth@vger.kernel.org
>Subject: Re: Patches for kernel bluetooth
>
>Hi Waldek,
>
>* Waldemar.Rymarkiewicz@tieto.com=20
><Waldemar.Rymarkiewicz@tieto.com> [2010-07-19 14:33:37 +0300]:
>
>> Hi,
>>=20
>> Wondering if preparing patches for kernel bt (net/bluetooth=20
>and include/net/bluetooth) I should base on linux-next git =20
>or =20
>git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetoot
>h-2.6.git?=20
>
>Base it on bluetooth-next. Actually you have to base it on=20
>bluetooth-testing but it is not up-to-date, so use=20
>bluetooth-next for now.=20
>
>--
>Gustavo F. Padovan
>http://padovan.org
>=
^ permalink raw reply
* Re: Patches for kernel bluetooth
From: Gustavo F. Padovan @ 2010-07-19 15:58 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz; +Cc: marcel, linux-bluetooth
In-Reply-To: <99B09243E1A5DA4898CDD8B700111448096B738982@EXMB04.eu.tieto.com>
Hi Waldek,
* Waldemar.Rymarkiewicz@tieto.com <Waldemar.Rymarkiewicz@tieto.com> [2010-07-19 14:33:37 +0300]:
> Hi,
>
> Wondering if preparing patches for kernel bt (net/bluetooth and include/net/bluetooth) I should base on linux-next git or git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git?
Base it on bluetooth-next. Actually you have to base it on
bluetooth-testing but it is not up-to-date, so use bluetooth-next for
now.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* BlueZ segfault on sdp resolving
From: Manuel Naranjo @ 2010-07-19 15:22 UTC (permalink / raw)
To: linux-bluetooth
Hi guys,
I had been tracing a BlueZ segfault for a few months all ready, the
other day I got an idea, I added some trace to the code just printed
which line got called (then I discover |-finstrument-functions from gcc)
Anyway, I run the test two times, and both times it died the same way,
here's the trace I got:
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_free()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_free()
device_free(0x2cf17e8)
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/security.c:io_security_event()
bluetoothd[3551]: ../bluez-4.66/src/security.c:inquiry_complete()
bluetoothd[3551]: ../bluez-4.66/src/manager.c:manager_find_adapter()
bluetoothd[3551]: ../bluez-4.66/src/manager.c:adapter_cmp()
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/security.c:io_security_event()
bluetoothd[3551]: ../bluez-4.66/src/security.c:cmd_status()
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/adapter.c:session_unref()
session_unref(0x2c99a68): ref=0
bluetoothd[3551]: ../bluez-4.66/src/adapter.c:session_free() Discovery
session 0x2c99a68 with :1.247 deactivated
bluetoothd[3551]: ../bluez-4.66/src/adapter.c:session_remove() Stopping
discovery
bluetoothd[3551]: Stopping discovery
bluetoothd[3551]: ../bluez-4.66/src/security.c:io_security_event()
bluetoothd[3551]: ../bluez-4.66/src/security.c:cmd_complete()
bluetoothd[3551]: ../bluez-4.66/src/security.c:inquiry_complete()
bluetoothd[3551]: ../bluez-4.66/src/manager.c:manager_find_adapter()
bluetoothd[3551]: ../bluez-4.66/src/manager.c:adapter_cmp()
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_address_cmp()
....
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_address_cmp()
bluetoothd[3551]: ../bluez-4.66/src/adapter.c:create_device()
create_device(00:25:E7:98:AB:57)
bluetoothd[3551]: ../bluez-4.66/src/adapter.c:adapter_create_device()
adapter_create_device(00:25:E7:98:AB:57)
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_create()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_create() Creating
device /org/bluez/3551/hci0/dev_00_25_E7_98_AB_57
bluetoothd[3551]: ../bluez-4.66/src/device.c:btd_device_ref()
btd_device_ref(0x2cf3938): ref=1
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_get_path()
....
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_get_path()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_browse()
bluetoothd[3551]: ../bluez-4.66/src/device.c:btd_device_ref()
btd_device_ref(0x2cf3938): ref=2
bluetoothd[3551]: ../bluez-4.66/src/device.c:init_browse()
bluetoothd[3551]: ../bluez-4.66/src/glib-helper.c:bt_search_service()
bluetoothd[3551]: ../bluez-4.66/src/glib-helper.c:create_search_context()
bluetoothd[3551]: ../bluez-4.66/src/glib-helper.c:get_sdp_session() new
(0x2ce2ce0)
bluetoothd[3551]: ../bluez-4.66/src/glib-helper.c:search_context_ref()
(0x2cdd858) ref=1, src(0x2cdd858), dest(0x2cdd85e)
bluetoothd[3551]:
../bluez-4.66/src/glib-helper.c:create_search_context() (0x2cdd858)
bluetoothd[3551]: ../bluez-4.66/src/device.c:get_properties()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_is_paired()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_is_trusted()
bluetoothd[3551]: ../bluez-4.66/src/device.c:get_properties()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_is_paired()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_is_trusted()
bluetoothd[3551]: ../bluez-4.66/src/device.c:get_properties()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_is_paired()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_is_trusted()
bluetoothd[3551]: ../bluez-4.66/src/security.c:io_security_event()
bluetoothd[3551]: ../bluez-4.66/src/security.c:conn_complete()
bluetoothd[3551]: ../bluez-4.66/src/manager.c:manager_find_adapter()
bluetoothd[3551]: ../bluez-4.66/src/manager.c:adapter_cmp()
bluetoothd[3551]: ../bluez-4.66/src/adapter.c:adapter_get_device()
adapter_get_device(00:25:E7:98:AB:57)
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_address_cmp()
....
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_address_cmp()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_add_connection()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_set_connected()
bluetoothd[3551]: ../bluez-4.66/src/security.c:update_lastused()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_data_new()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_queue_append()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_find_by_devid()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_queue_process()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_find_by_devid()
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_find_by_devid()
bluetoothd[3551]: ../bluez-4.66/src/security.c:io_security_event()
bluetoothd[3551]: ../bluez-4.66/src/security.c:cmd_status()
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_find_by_devid()
bluetoothd[3551]: ../bluez-4.66/src/security.c:io_security_event()
bluetoothd[3551]: ../bluez-4.66/src/security.c:cmd_status()
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_find_by_devid()
bluetoothd[3551]: ../bluez-4.66/src/security.c:io_security_event()
bluetoothd[3551]: ../bluez-4.66/src/security.c:cmd_status()
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_find_by_devid()
bluetoothd[3551]: ../bluez-4.66/src/security.c:io_security_event()
bluetoothd[3551]:
../bluez-4.66/src/security.c:remote_features_information()
bluetoothd[3551]: ../bluez-4.66/src/security.c:get_bdaddr()
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_find_by_devid()
bluetoothd[3551]: Discovery session 0x2cd6958 with :1.247 activated
bluetoothd[3551]: ../bluez-4.66/src/adapter.c:session_ref()
session_ref(0x2cd6958): ref=1
bluetoothd[3551]: ../bluez-4.66/src/security.c:io_security_event()
bluetoothd[3551]: ../bluez-4.66/src/security.c:remote_name_information()
bluetoothd[3551]: ../bluez-4.66/src/manager.c:manager_find_adapter()
bluetoothd[3551]: ../bluez-4.66/src/manager.c:adapter_cmp()
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_address_cmp()
....
bluetoothd[3551]: ../bluez-4.66/src/device.c:device_set_name()
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_find_by_devid()
bluetoothd[3551]: ../bluez-4.66/src/security.c:hci_req_queue_process()
bluetoothd[3551]: ../bluez-4.66/src/security.c:io_security_event()
bluetoothd[3551]: ../bluez-4.66/src/security.c:cmd_complete()
bluetoothd[3551]: ../bluez-4.66/src/security.c:start_inquiry()
bluetoothd[3551]: ../bluez-4.66/src/manager.c:manager_find_adapter()
bluetoothd[3551]: ../bluez-4.66/src/manager.c:adapter_cmp()
bluetoothd[3551]: ../bluez-4.66/src/security.c:check_pending_hci_req()
bluetoothd[3551]: ../bluez-4.66/src/glib-helper.c:connect_watch()
bluetoothd[3551]: ../bluez-4.66/src/device.c:browse_cb()
bluetoothd[3551]: ../bluez-4.66/src/device.c:search_cb()
Segmentation fault
If I read the code then I see device.c gets into search_cb directly from
browse_cb in this piece
/* If we have a valid response and req->search_uuid == 2, then L2CAP
* UUID & PNP searching was successful -- we are done */
if (err < 0 || (req->search_uuid == 2 && req->records)) {
if (err == -ECONNRESET && req->reconnect_attempt < 1) {
req->search_uuid--;
req->reconnect_attempt++;
} else
goto done;
}
...
done:
search_cb(recs, err, user_data);
Problem is that device has been released by when search_cb does:
if (err < 0) {
error("%s: error updating services: %s (%d)",
device->path, strerror(-err), -err);
goto send_reply;
}
The solution we found a few months ago was to make a slight change in
security.c, tell glib to do resources releasing with low priority:
chan = g_io_channel_unix_new(dev);
g_io_channel_set_close_on_unref(chan, TRUE);
io_data[hdev].watch_id = g_io_add_watch_full(chan, G_PRIORITY_LOW,
G_IO_IN | G_IO_NVAL | G_IO_HUP | G_IO_ERR,
io_security_event, di, (GDestroyNotify) g_free);
Still this is not enough. I think the problem is that the refcount is
broken, we're forgeting to do btd_device_ref under some circustances?
I can mail the log if someone needs it.
Manuel
|
^ permalink raw reply
* Re: [PATCH] bluetooth: retry reset for devices that fail
From: Oliver Neukum @ 2010-07-19 12:52 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1279296636.6282.77.camel@localhost.localdomain>
Am Freitag, 16. Juli 2010, 18:10:36 schrieb Marcel Holtmann:
> Hi Oliver,
>=20
> > Some devices fail to reset properly at the first attempt to reset
> > them under unknown circumstances. Failures can be identified by
> > an invalid btaddr. Retry in those cases.
>=20
> I am not sure about this. Can you provide some examples when this is
> suppose to be happening. The empty BD_ADDR might not be a good indicator
> for this.
It happens with traces like this:
ece2d0c0 1582934618 S Ii:2:003:1 -115:1 16 <
ecd717c0 1582934818 S Bi:2:003:2 -115 1028 <
f44c0340 1582934828 S Bi:2:003:2 -115 1028 <
f44c02c0 1582934851 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 030c00
f44c02c0 1582935005 C Co:2:003:0 0 3 >
ece2d0c0 1582938187 C Ii:2:003:1 0:1 6 =3D 0e040103 0c00
ece2d0c0 1582938194 S Ii:2:003:1 -115:1 16 <
ece2d740 1582938207 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 031000
ece2d740 1582938376 C Co:2:003:0 0 3 >
ece2d0c0 1582940160 C Ii:2:003:1 0:1 14 =3D 0e0c0103 1000ffff 8ffe9bff 7987
ece2d0c0 1582940163 S Ii:2:003:1 -115:1 16 <
ecd71a40 1582940171 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 011000
ecd71a40 1582940286 C Co:2:003:0 0 3 >
ece2d0c0 1582941179 C Ii:2:003:1 0:1 14 =3D 0e0c0101 100005e1 01050f00 0342
ece2d0c0 1582941186 S Ii:2:003:1 -115:1 16 <
ece2d1c0 1582941201 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 051000
ece2d1c0 1582941421 C Co:2:003:0 0 3 >
Even a second reset doesn't always help. If it works, ou get traces like th=
is:
f37f35c0 3365799877 S Ii:2:003:1 -115:1 16 <
ecd76ac0 3365800125 S Bi:2:003:2 -115 1028 <
ecd76c40 3365800135 S Bi:2:003:2 -115 1028 <
hci_init_req():
ecd76d40 3365800155 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 030c00
ecd76d40 3365800280 C Co:2:003:0 0 3 >
HCI_OP_RESET
f37f35c0 3365804088 C Ii:2:003:1 0:1 6 =3D 0e040103 0c00
f37f35c0 3365804097 S Ii:2:003:1 -115:1 16 <
ecd76d40 3365804119 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 031000
ecd76d40 3365804276 C Co:2:003:0 0 3 >
HCI_OP_READ_LOCAL_FEATURES
f37f35c0 3365805026 C Ii:2:003:1 0:1 14 =3D 0e0c0103 1000ffff 8ffe9bff 7987
f37f35c0 3365805030 S Ii:2:003:1 -115:1 16 <
ecd76240 3365805037 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 011000
ecd76240 3365805150 C Co:2:003:0 0 3 >
HCI_OP_READ_LOCAL_VERSION
f37f35c0 3365806027 C Ii:2:003:1 0:1 14 =3D 0e0c0101 100005e1 01050f00 0342
f37f35c0 3365806030 S Ii:2:003:1 -115:1 16 <
f45703c0 3365806037 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 051000
f45703c0 3365806152 C Co:2:003:0 0 3 >
HCI_OP_READ_BUFFER_SIZE - no answer
=2D-----------------------------------------------------------------------
ecf40ec0 3395924102 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 030c00
ecf40ec0 3395924297 C Co:2:003:0 0 3 >
Again HCI_OP_RESET <presumably from second command>
f37f35c0 3395925197 C Ii:2:003:1 0:1 13 =3D 0e0b0105 1000fd03 40080001 00
Here's the answer to HCI_OP_READ_BUFFER_SIZE
f37f35c0 3395925204 S Ii:2:003:1 -115:1 16 <
f37f35c0 3395928199 C Ii:2:003:1 0:1 6 =3D 0e040103 0c00
Answer to the reset
f37f35c0 3395928205 S Ii:2:003:1 -115:1 16 <
f37f35c0 3395928277 C Ii:2:003:1 -2:1 0
ecd76c40 3395928447 C Bi:2:003:2 -2 0
ecd76ac0 3395928555 C Bi:2:003:2 -2 0
f45709c0 3395928572 S Co:2:002:0 s 23 08 9032 0001 0000 0
ecd76ac0 3395928601 S Ii:2:003:1 -115:1 16 <
f45709c0 3395928742 C Co:2:002:0 0 0
ecd76c40 3395928750 S Bi:2:003:2 -115 1028 <
f37f35c0 3395928752 S Bi:2:003:2 -115 1028 <
=46rom now on hci_init_req() that works is running:
ecd66440 3395928764 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 030c00
ecd66440 3395929102 C Co:2:003:0 0 3 >
Here's the reset
HCI_OP_RESET
ecd76ac0 3395932203 C Ii:2:003:1 0:1 6 =3D 0e040103 0c00
ecd76ac0 3395932209 S Ii:2:003:1 -115:1 16 <
f4578240 3395932223 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 031000
f4578240 3395932406 C Co:2:003:0 0 3 >
HCI_OP_READ_LOCAL_FEATURES
ecd76ac0 3395933198 C Ii:2:003:1 0:1 14 =3D 0e0c0103 1000ffff 8ffe9bff 7987
ecd76ac0 3395933204 S Ii:2:003:1 -115:1 16 <
ecd66640 3395933215 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 011000
ecd66640 3395933477 C Co:2:003:0 0 3 >
HCI_OP_READ_LOCAL_VERSION
ecd76ac0 3395934203 C Ii:2:003:1 0:1 14 =3D 0e0c0101 100005e1 01050f00 0342
ecd76ac0 3395934208 S Ii:2:003:1 -115:1 16 <
f4578340 3395934219 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 051000
f4578340 3395934439 C Co:2:003:0 0 3 >
HCI_OP_READ_BUFFER_SIZE
ecd76ac0 3395936200 C Ii:2:003:1 0:1 13 =3D 0e0b0105 1000fd03 40080001 00
ecd76ac0 3395936206 S Ii:2:003:1 -115:1 16 <
ecf6d7c0 3395936222 S Co:2:003:0 s 20 00 0000 0000 0003 3 =3D 091000
ecf6d7c0 3395936452 C Co:2:003:0 0 3 >
HCI_OP_READ_BD_ADDR
ecd76ac0 3395937198 C Ii:2:003:1 0:1 12 =3D 0e0a0109 10004031 63132700
requested bdaddr
Regards
Oliver
^ permalink raw reply
* Patches for kernel bluetooth
From: Waldemar.Rymarkiewicz @ 2010-07-19 11:33 UTC (permalink / raw)
To: marcel; +Cc: linux-bluetooth
In-Reply-To: <1279519823.4572.17.camel@localhost.localdomain>
Hi,
Wondering if preparing patches for kernel bt (net/bluetooth and include/net=
/bluetooth) I should base on linux-next git or git://git.kernel.org/pub/=
scm/linux/kernel/git/holtmann/bluetooth-2.6.git?=20
Thanks,
/Waldek
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox