* Re: Deadlock in Bluetooth code in 2.6.36
From: David Miller @ 2010-09-25 4:18 UTC (permalink / raw)
To: padovan; +Cc: netdev, linux-bluetooth, linux-kernel, marcel, mathewm
In-Reply-To: <1285104013-9946-1-git-send-email-padovan@profusion.mobi>
From: "Gustavo F. Padovan" <padovan@profusion.mobi>
Date: Tue, 21 Sep 2010 18:20:12 -0300
> My questions here is on how to fix this properly. Maybe
> sock_alloc_send_skb() should not be used with SOCK_STREAM and reliable
> protocols and I'm not aware of that? And should I use something like
> sk_stream_alloc_skb() instead?
>
> Any comments are welcome. With lucky we can fix that for 2.6.36 and
> together with others fixes we have queued deliver a fully functional
> L2CAP layer on 2.6.36.
Use sock_alloc_send_skb() as you do now, but if it fails wait for socket
space to become available just like TCP does, then loop back and try to
allocate again if the space-wait doesn't return an error.
I think you should be able to reuse sk_stream_wait_memory() for this
purpose just fine and without any problems.
^ permalink raw reply
* Re: Deadlock in Bluetooth code in 2.6.36
From: Gustavo F. Padovan @ 2010-09-26 0:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-bluetooth, linux-kernel, marcel, mathewm
In-Reply-To: <20100924.211824.242130957.davem@davemloft.net>
* David Miller <davem@davemloft.net> [2010-09-24 21:18:24 -0700]:
> From: "Gustavo F. Padovan" <padovan@profusion.mobi>
> Date: Tue, 21 Sep 2010 18:20:12 -0300
>
> > My questions here is on how to fix this properly. Maybe
> > sock_alloc_send_skb() should not be used with SOCK_STREAM and reliable
> > protocols and I'm not aware of that? And should I use something like
> > sk_stream_alloc_skb() instead?
> >
> > Any comments are welcome. With lucky we can fix that for 2.6.36 and
> > together with others fixes we have queued deliver a fully functional
> > L2CAP layer on 2.6.36.
>
> Use sock_alloc_send_skb() as you do now, but if it fails wait for socket
> space to become available just like TCP does, then loop back and try to
> allocate again if the space-wait doesn't return an error.
sock_alloc_send_skb() doesn't fail when there is no space available
it sleeps and try again later. That is the problem. So if
sock_alloc_send_skb() is called with the socket lock held potentially we
can have a starvation in the backlog queue and then the deadlock due to
be unable to read the acknowledgments packets residing in the backlog
queue.
Our current solution is release the lock before call
sock_alloc_send_skb() and acquire it again when sock_alloc_send_skb()
returns. Patch follows:
------
Bluetooth: Fix deadlock in the ERTM logic
The Enhanced Retransmission Mode(ERTM) is a reliable mode of operation
of the Bluetooth L2CAP layer. Think on it like a simplified version of
TCP.
The problem we were facing here was a deadlock. ERTM uses a backlog
queue to queue incomimg packets while the user is helding the lock. At
some moment the sk_sndbuf can be exceeded and we can't alloc new skbs
then the code sleep with the lock to wait for memory, that stalls the
ERTM connection once we can't read the acknowledgements packets in the
backlog queue to free memory and make the allocation of outcoming skb
successful.
This patch actually affect all users of bt_skb_send_alloc(), i.e., all
L2CAP modes and SCO.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi>
---
include/net/bluetooth/bluetooth.h | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 27a902d..118b69b 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -161,10 +161,21 @@ static inline struct sk_buff *bt_skb_send_alloc(struct sock *sk, unsigned long l
{
struct sk_buff *skb;
+ release_sock(sk);
if ((skb = sock_alloc_send_skb(sk, len + BT_SKB_RESERVE, nb, err))) {
skb_reserve(skb, BT_SKB_RESERVE);
bt_cb(skb)->incoming = 0;
}
+ lock_sock(sk);
+
+ if (*err)
+ return NULL;
+
+ *err = sock_error(sk);
+ if (*err) {
+ kfree_skb(skb);
+ return NULL;
+ }
return skb;
}
--
1.7.2.2
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply related
* Re: Support for Device ID profile
From: Jose Antonio Santos Cadenas @ 2010-09-27 7:04 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: steven bluez, linux-bluetooth
In-Reply-To: <AANLkTi=aX_XQqEwa3q=1krNfpYxGFbkc2V4wEGcT9oHA@mail.gmail.com>
Hi,
2010/9/24 Luiz Augusto von Dentz <luiz.dentz@gmail.com>:
> Hi Steven,
>
> Yes, you can use DeviceID on main.conf to add that, but as you see it
> is pretty limited so we are planning to have a better support for
> this, perhaps extend adapter driver interface where you can write a
> plugin to fill this information.
Is anyone working on this plugin now. I'd like to work on it if nobody
is working yet.
Regards.
>
> Regards,
>
> On Fri, Sep 24, 2010 at 11:54 AM, steven bluez <steven.bluez@gmail.com> wrote:
>> Hi all,
>> Is there any support for Device ID Profile in Bluez 4.XX? versions ?\
>>
>> Regards,
>> Steven
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Spurious authentication request?
From: Daniel Örstadius @ 2010-09-27 7:52 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Occasionally when pairing with a headset BlueZ issues what looks
to be an unnecessary "Authentication Requested" after
receiving "Auth Complete" and "Simple Pairing Complete".
2010-09-22 11:23:45.282348 > HCI Event: Auth Complete (0x06) plen 3
status 0x00 handle 2
2010-09-22 11:23:45.282378 < HCI Command: Set Connection Encryption
(0x01|0x0013) plen 3
handle 2 encrypt 0x01
[..]
2010-09-22 11:23:45.363646 < HCI Command: Authentication Requested
(0x01|0x0011) plen 2
handle 2
This request is coming from bonding_connect_cb and occurs if that
callback happens to be executed before the function
hcid_dbus_bonding_process_complete (triggered by the auth complete
event). The order between those functions might have been affected
by this patch
http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=be35d00671519b8d92361c2caad9abeedda151f8
The request for authentication seems to be used for legacy pairing and
should probably not be made for simple pairing. Also, it might be
inconsistent that the kernel issues "Authentication Requested" for
simple pairing, but bluetoothd does it for legacy?
I guess enclosing the call in a check for legacy pairing would
work, if that information is or can be made available to
bluetoothd.
Have I understood the situation correctly and if so, what would
be a good way to fix this issue?
Thanks,
Daniel
^ permalink raw reply
* Re: Bluez simple-agent vs agent
From: Ville Tervo @ 2010-09-27 8:00 UTC (permalink / raw)
To: ext Viswanathan Sankararam; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTik_cwho9JNBPFhCDx0EGFcLN2+VTG8LT-D_Hw_3@mail.gmail.com>
Hi,
On Sat, Sep 25, 2010 at 03:11:32AM +0200, ext Viswanathan Sankararam wrote:
> Thanks Ville for letting me know about this. Is there a possibility to
> back port? Can I just blindly copy the net/bluetooth drivers to a
> linux-2.6.23 kernel and compile?
It won't work directly most probably.
--
Ville
^ permalink raw reply
* Re: [PATCH 1/6] This patch adds support for the ST-Ericsson CG2900
From: Par-Gunnar Hjalmdahl @ 2010-09-27 8:16 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-bluetooth, linux-kernel, linus.walleij, Pavan Savoy
In-Reply-To: <20100924141046.GA26454@sirena.org.uk>
Hi again Mark,
I've not got an answer from the developer of the particular piece of code.
2010/9/24 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> On Fri, Sep 24, 2010 at 03:46:44PM +0200, Par-Gunnar Hjalmdahl wrote:
>
>> +static irqreturn_t cg2900_devices_interrupt(int irq, void *dev_id)
>> +{
>> + disable_irq_nosync(irq);
>> + if (cg2900_dev_callback && cg2900_dev_callback->interrupt_cb)
>> + cg2900_dev_callback->interrupt_cb();
>> +
>> + return IRQ_HANDLED;
>> +}
>
> Why is there this callback mechanism - I'd expect the users of this code
> to just be using the standard IRQ infrastructure?
>
This is our local IRQ which is handled in cg2900_uart.c by creating a work:
static void cg2900_devices_irq_cb(void)
{
/* Create work and leave irq context. */
(void)create_work_item(uart_info->wq, handle_cts_irq, NULL);
}
I understand your concern that client implementing the
cg2900_dev_callback->interrupt_cb();
might not know realized that this is irq context which might cause problems.
My motivation for doing like this that we do not expect other clients
of this code, so there
is no such risk. We create work in cg2900_uart and leave function.
Let me know if it is ok.
If not then suggest what is expected way of handling it ? eg. moving
workqueue down to cg2900_devices
or other solution?
Best regards,
/Lukasz via P-G
^ permalink raw reply
* Re: [PATCHv4 0/3] Bluetooth: L2CAP robustness fixes
From: Andrei Emeltchenko @ 2010-09-27 12:50 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284550124-31201-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Ping
On Wed, Sep 15, 2010 at 2:28 PM, Emeltchenko Andrei
<Andrei.Emeltchenko.news@gmail.com> wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Fixes increase L2CAP robustness to DOS attacks to BT stack.
> Updated version after comments from Mat Martineau <mathewm@codeaurora.org>
> and Gustavo Padovan <padovan@profusion.mobi>.
>
> Andrei Emeltchenko (3):
> Bluetooth: fix MTU L2CAP configuration parameter
> Bluetooth: check for l2cap header in start fragment
> Bluetooth: check L2CAP length in first ACL fragment
>
> net/bluetooth/l2cap.c | 25 +++++++++++++++++++++----
> 1 files changed, 21 insertions(+), 4 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Add test/test-attrib for testing Attribute API
From: Anderson Lizardo @ 2010-09-27 15:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1285248924-12834-1-git-send-email-anderson.lizardo@openbossa.org>
On Thu, Sep 23, 2010 at 9:35 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> This is an initial version. Watcher registration is not working properly
> yet. For now it will list all characteristics and its properties.
Please ignore this pull request. I'm updating attrib/test-attrib to
have a working Watcher registration implementation.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 1/6] This patch adds support for the ST-Ericsson CG2900
From: Mark Brown @ 2010-09-27 15:15 UTC (permalink / raw)
To: Par-Gunnar Hjalmdahl
Cc: linux-bluetooth, linux-kernel, linus.walleij, Pavan Savoy
In-Reply-To: <AANLkTin=PPfgnD5tKBPR1QXf2OeBKBH-kXtoT+s-KPhk@mail.gmail.com>
On Mon, Sep 27, 2010 at 10:16:11AM +0200, Par-Gunnar Hjalmdahl wrote:
> 2010/9/24 Mark Brown <broonie@opensource.wolfsonmicro.com>:
> > On Fri, Sep 24, 2010 at 03:46:44PM +0200, Par-Gunnar Hjalmdahl wrote:
> >> +static irqreturn_t cg2900_devices_interrupt(int irq, void *dev_id)
> >> +{
> >> + disable_irq_nosync(irq);
> >> + if (cg2900_dev_callback && cg2900_dev_callback->interrupt_cb)
> >> + cg2900_dev_callback->interrupt_cb();
> >> +
> >> + return IRQ_HANDLED;
> >> +}
> > Why is there this callback mechanism - I'd expect the users of this code
> > to just be using the standard IRQ infrastructure?
> This is our local IRQ which is handled in cg2900_uart.c by creating a work:
I can tell it's an IRQ - that's my point; the kernel has an interrupt
handling subsystem which this isn't using.
> I understand your concern that client implementing the
> cg2900_dev_callback->interrupt_cb();
> might not know realized that this is irq context which might cause problems.
No, you're misunderstanding my point. The kernel has facilities for
representing interrupt controllers which this is not using.
> If not then suggest what is expected way of handling it ? eg. moving
> workqueue down to cg2900_devices
> or other solution?
Use the standard kernel IRQ framework to report interrupts to the
clients - there's quite a few examples of using this in the drivers/mfd
code. This will make your code more idiomatic and give you access to
all the diagnostic infrastructure the kernel provides for interrupts.
^ permalink raw reply
* Re: [PATCH 6/6] This patch adds support for using the ST-Ericsson CG2900
From: Gustavo F. Padovan @ 2010-09-27 16:45 UTC (permalink / raw)
To: pghatwork; +Cc: linux-bluetooth, linux-kernel, linus.walleij, Pavan Savoy
In-Reply-To: <AANLkTimOai9_92VuJUZMo26es9Wsu_6d+z36Sv_Q4i+L@mail.gmail.com>
Hi Par-Gunnar,
* Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com> [2010-09-24 15:52:16 +0200]:
> This patch adds support for using the ST-Ericsson CG2900
> connectivity controller as a driver for the BlueZ Bluetooth
> stack.
> This patch registers as a driver into the BlueZ framework and, when
> opened by BlueZ, it registers as user for bt_cmd, bt_acl, and bt_evt
> channels.
First of all your your commit message and subject should be improved.
The subject should bee something like:
"Bluetooth: Add support for ST-Ericsson CG2900"
and in the commit message you explain the details of the patch.
And normally we do not use the BlueZ word in kernelspace.
>
> Signed-off-by: Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com>
> ---
> drivers/bluetooth/Kconfig | 7 +
> drivers/bluetooth/Makefile | 2 +
> drivers/bluetooth/cg2900_hci.c | 896 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 905 insertions(+), 0 deletions(-)
> create mode 100644 drivers/bluetooth/cg2900_hci.c
Your patch looks a way complicated to a UART driver. Look at the others
drivers at drivers/bluetooth/ and see how we implemented other UART
drivers.
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 02deef4..9ca8d69 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -219,4 +219,11 @@ config BT_ATH3K
> Say Y here to compile support for "Atheros firmware download driver"
> into the kernel or say M to compile it as module (ath3k).
>
> +config BT_CG2900
> + tristate "ST-Ericsson CG2900 driver"
> + depends on MFD_CG2900 && BT
> + help
> + Select if ST-Ericsson CG2900 Connectivity controller shall be used as
> + Bluetooth controller for BlueZ.
> +
> endmenu
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 71bdf13..a479c16 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -19,6 +19,8 @@ obj-$(CONFIG_BT_ATH3K) += ath3k.o
> obj-$(CONFIG_BT_MRVL) += btmrvl.o
> obj-$(CONFIG_BT_MRVL_SDIO) += btmrvl_sdio.o
>
> +obj-$(CONFIG_BT_CG2900) += cg2900_hci.o
> +
> btmrvl-y := btmrvl_main.o
> btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
>
> diff --git a/drivers/bluetooth/cg2900_hci.c b/drivers/bluetooth/cg2900_hci.c
> new file mode 100644
> index 0000000..de1ada8
> --- /dev/null
> +++ b/drivers/bluetooth/cg2900_hci.c
> @@ -0,0 +1,896 @@
> +/*
> + * drivers/bluetooth/cg2900_hci.c
> + *
> + * Copyright (C) ST-Ericsson SA 2010
> + * Authors:
> + * Par-Gunnar Hjalmdahl (par-gunnar.p.hjalmdahl@stericsson.com) for
> ST-Ericsson.
> + * Henrik Possung (henrik.possung@stericsson.com) for ST-Ericsson.
> + * Josef Kindberg (josef.kindberg@stericsson.com) for ST-Ericsson.
> + * Dariusz Szymszak (dariusz.xd.szymczak@stericsson.com) for ST-Ericsson.
> + * Kjell Andersson (kjell.k.andersson@stericsson.com) for ST-Ericsson.
> + * License terms: GNU General Public License (GPL), version 2
> + *
> + * Linux Bluetooth HCI H:4 Driver for ST-Ericsson CG2900 connectivity
> controller
> + * towards the BlueZ Bluetooth stack.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/skbuff.h>
> +#include <asm/byteorder.h>
> +#include <net/bluetooth/bluetooth.h>
> +#include <net/bluetooth/hci.h>
> +#include <net/bluetooth/hci_core.h>
> +
> +#include <linux/workqueue.h>
> +#include <linux/wait.h>
> +#include <linux/time.h>
> +#include <linux/jiffies.h>
> +#include <linux/sched.h>
> +#include <linux/timer.h>
> +
> +#include <linux/mfd/cg2900.h>
> +#include <mach/cg2900_devices.h>
> +
> +/* module_param declared in cg2900_core.c */
> +extern int cg2900_debug_level;
You don't need that, just use dynamic debug instead
> +
> +#define NAME "CG2900 HCI"
> +
> +/* Debug defines */
> +#define CG2900_DBG_DATA(fmt, arg...) \
> +do { \
> + if (cg2900_debug_level >= 25) \
> + printk(KERN_DEBUG NAME " %s: " fmt "\n" , __func__ , ## arg); \
> +} while (0)
> +
> +#define CG2900_DBG(fmt, arg...) \
> +do { \
> + if (cg2900_debug_level >= 20) \
> + printk(KERN_DEBUG NAME " %s: " fmt "\n" , __func__ , ## arg); \
> +} while (0)
> +
> +#define CG2900_INFO(fmt, arg...) \
> +do { \
> + if (cg2900_debug_level >= 10) \
> + printk(KERN_INFO NAME ": " fmt "\n" , ## arg); \
> +} while (0)
> +
> +#define CG2900_ERR(fmt, arg...) \
> +do { \
> + if (cg2900_debug_level >= 1) \
> + printk(KERN_ERR NAME " %s: " fmt "\n" , __func__ , ## arg); \
> +} while (0)i
and BT_DBG, BT_INFO, BT_ERR instead of these macros.
> +
> +#define CG2900_SET_STATE(__name, __var, __new_state) \
> +do { \
> + CG2900_DBG("New %s: 0x%X", __name, (uint32_t)__new_state); \
> + __var = __new_state; \
> +} while (0)
Don't hide your operation with a macro, that is a simple attribution, so
no need for a macro for that.
> +
> +/* HCI device type */
> +#define HCI_CG2900 HCI_VIRTUAL
> +
> +/* Wait for 5 seconds for a response to our requests */
> +#define RESP_TIMEOUT 5000
> +
> +/* State-setting defines */
> +#define SET_RESET_STATE(__hci_reset_new_state) \
> + CG2900_SET_STATE("reset_state", hci_info->reset_state, \
> + __hci_reset_new_state)
> +#define SET_ENABLE_STATE(__hci_enable_new_state) \
> + CG2900_SET_STATE("enable_state", hci_info->enable_state, \
> + __hci_enable_new_state)
Same here.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Another "hci0 command tx timeout"
From: Sergej Pupykin @ 2010-09-27 18:52 UTC (permalink / raw)
To: linux-bluetooth
Hello, All.
How can I help to debug this issue? BT works without userspace, but does
not work if I enable it in udev rules (ACTION=="add",
SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev") or do
"/etc/rc.d/bluetooth start".
(Probably related to
https://bugzilla.redhat.com/show_bug.cgi?id=519176
and
https://bugs.launchpad.net/linux/+bug/268502)
Packages:
kernel26 2.6.35.5-1
bluez 4.72-1
Devices:
Bus 007 Device 005: ID 0a5c:3503 Broadcom Corp.
Bus 007 Device 004: ID 0a5c:3502 Broadcom Corp.
Bus 007 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth
Dongle (HCI mode)
Bus 007 Device 002: ID 0a5c:3500 Broadcom Corp.
Without userspace:
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0
> HCI Event: Command Complete (0x0e) plen 11
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
> HCI Event: Command Complete (0x0e) plen 10
< HCI Command: Read Class of Device (0x03|0x0023) plen 0
> HCI Event: Command Complete (0x0e) plen 7
< HCI Command: Read Local Name (0x03|0x0014) plen 0
> HCI Event: Command Complete (0x0e) plen 252
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0
> HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Set Event Filter (0x03|0x0005) plen 1
> HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Page Timeout (0x03|0x0018) plen 2
> HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2
> HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Inquiry (0x01|0x0001) plen 5
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Inquiry Result (0x02) plen 15
> HCI Event: Inquiry Complete (0x01) plen 1
With userspace:
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0
> HCI Event: Command Complete (0x0e) plen 11
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
> HCI Event: Command Complete (0x0e) plen 10
< HCI Command: Read Class of Device (0x03|0x0023) plen 0
> HCI Event: Command Complete (0x0e) plen 7
< HCI Command: Read Local Name (0x03|0x0014) plen 0
> HCI Event: Command Complete (0x0e) plen 252
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0
> HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Set Event Filter (0x03|0x0005) plen 1
> HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Page Timeout (0x03|0x0018) plen 2
> HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2
> HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Page Timeout (0x03|0x0018) plen 2
> HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Default Link Policy Settings (0x02|0x000f) plen 2
> HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Read Stored Link Key (0x03|0x000d) plen 7
> HCI Event: Command Complete (0x0e) plen 8
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Default Link Policy Settings (0x02|0x000e) plen 0
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1
^ permalink raw reply
* Re: Another "hci0 command tx timeout"
From: Gustavo F. Padovan @ 2010-09-27 19:21 UTC (permalink / raw)
To: Sergej Pupykin; +Cc: linux-bluetooth
In-Reply-To: <4CA0E800.4000000@sergej.pp.ru>
Hi Sergej,
* Sergej Pupykin <ml@sergej.pp.ru> [2010-09-27 22:52:48 +0400]:
> Hello, All.
>
> How can I help to debug this issue? BT works without userspace, but does
> not work if I enable it in udev rules (ACTION=="add",
> SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev") or do
> "/etc/rc.d/bluetooth start".
What do you mean by "works without userspace"?
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: Another "hci0 command tx timeout"
From: Sergej Pupykin @ 2010-09-27 19:35 UTC (permalink / raw)
Cc: linux-bluetooth
In-Reply-To: <20100927192108.GA5489@vigoh>
On 27.09.2010 23:21, Gustavo F. Padovan wrote:
>
> What do you mean by "works without userspace"
I try to do following:
1. ensure that userspace does not work (stop bluetoothd and comment udev
bluetooth rule)
2. modprobe btusb
3. hciconfig hci0 up
4. hcitool inq
then remove btusb, uncomment udev rules, start bluetoothd and do 2-4 again.
With userspace I got
$ hcitool inq
Inquiring ...
Inquiry failed.: Connection timed out
and subj error in dmesg.
Also I see that hcidump with userspace does not catch inquiry command.
^ permalink raw reply
* Re: Another "hci0 command tx timeout"
From: Gustavo F. Padovan @ 2010-09-27 19:46 UTC (permalink / raw)
To: Sergej Pupykin; +Cc: linux-bluetooth
In-Reply-To: <4CA0F1FE.8040006@sergej.pp.ru>
* Sergej Pupykin <ml@sergej.pp.ru> [2010-09-27 23:35:26 +0400]:
> On 27.09.2010 23:21, Gustavo F. Padovan wrote:
> >
> > What do you mean by "works without userspace"
> I try to do following:
>
> 1. ensure that userspace does not work (stop bluetoothd and comment udev
> bluetooth rule)
> 2. modprobe btusb
> 3. hciconfig hci0 up
> 4. hcitool inq
>
> then remove btusb, uncomment udev rules, start bluetoothd and do 2-4 again.
So that is the problem, you are removing btusb.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: Another "hci0 command tx timeout"
From: Sergej Pupykin @ 2010-09-27 20:10 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20100927194650.GB5489@vigoh>
On 27.09.2010 23:46, Gustavo F. Padovan wrote:
>
> So that is the problem, you are removing btusb.
>
Do you mean that removing/inserting back btusb can damage something? I
repeat it many times and it always works if bluetoothd stopped and
always does not work if bluetoothd is running.
^ permalink raw reply
* [PATCH 1/2] Bluetooth: set sk_sndbuf and sk_rcvbuf properly in ERTM
From: Gustavo F. Padovan @ 2010-09-27 20:16 UTC (permalink / raw)
To: linux-bluetooth
Setting both this value to MPS * TxWin * 1.2 guarantees that we are
reserving space to fit the whole txwindow in the memory, and that
sendmsg() will block when the transmission window is full avoid
overloading the system memory.
I don't have a strong reason about the 1.2 constant in the account, we
can do another tests in the future and change that value.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/l2cap_core.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 44aa034..1e2ab05 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3129,9 +3129,17 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hdr
l2cap_pi(sk)->next_tx_seq = 0;
l2cap_pi(sk)->expected_tx_seq = 0;
__skb_queue_head_init(TX_QUEUE(sk));
- if (l2cap_pi(sk)->mode == L2CAP_MODE_ERTM)
+ if (l2cap_pi(sk)->mode == L2CAP_MODE_ERTM) {
l2cap_ertm_init(sk);
+ sk->sk_sndbuf = (l2cap_pi(sk)->remote_tx_win * 1.2 *
+ (sizeof(struct l2cap_pinfo) +
+ l2cap_pi(sk)->mps));
+ sk->sk_rcvbuf = (l2cap_pi(sk)->tx_win * 1.2 *
+ (sizeof(struct l2cap_pinfo) +
+ l2cap_pi(sk)->remote_mps));
+ }
+
l2cap_chan_ready(sk);
}
--
1.7.3
^ permalink raw reply related
* [PATCH 2/2] Bluetooth: Use the proper error value from bt_skb_send_alloc()
From: Gustavo F. Padovan @ 2010-09-27 20:16 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1285618609-11499-1-git-send-email-padovan@profusion.mobi>
&err points to the proper error set by bt_skb_send_alloc() when it
fails.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/l2cap_core.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 1e2ab05..1510812 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1537,7 +1537,7 @@ static inline int l2cap_skbuff_fromiovec(struct sock *sk, struct msghdr *msg, in
*frag = bt_skb_send_alloc(sk, count, msg->msg_flags & MSG_DONTWAIT, &err);
if (!*frag)
- return -EFAULT;
+ return err;
if (memcpy_fromiovec(skb_put(*frag, count), msg->msg_iov, count))
return -EFAULT;
@@ -1563,7 +1563,7 @@ static struct sk_buff *l2cap_create_connless_pdu(struct sock *sk, struct msghdr
skb = bt_skb_send_alloc(sk, count + hlen,
msg->msg_flags & MSG_DONTWAIT, &err);
if (!skb)
- return ERR_PTR(-ENOMEM);
+ return ERR_PTR(err);
/* Create L2CAP header */
lh = (struct l2cap_hdr *) skb_put(skb, L2CAP_HDR_SIZE);
@@ -1592,7 +1592,7 @@ static struct sk_buff *l2cap_create_basic_pdu(struct sock *sk, struct msghdr *ms
skb = bt_skb_send_alloc(sk, count + hlen,
msg->msg_flags & MSG_DONTWAIT, &err);
if (!skb)
- return ERR_PTR(-ENOMEM);
+ return ERR_PTR(err);
/* Create L2CAP header */
lh = (struct l2cap_hdr *) skb_put(skb, L2CAP_HDR_SIZE);
@@ -1629,7 +1629,7 @@ static struct sk_buff *l2cap_create_iframe_pdu(struct sock *sk, struct msghdr *m
skb = bt_skb_send_alloc(sk, count + hlen,
msg->msg_flags & MSG_DONTWAIT, &err);
if (!skb)
- return ERR_PTR(-ENOMEM);
+ return ERR_PTR(err);
/* Create L2CAP header */
lh = (struct l2cap_hdr *) skb_put(skb, L2CAP_HDR_SIZE);
--
1.7.3
^ permalink raw reply related
* Re: [PATCH 0/4 v6] L2CAP updates for valid PSMs, SOCK_STREAM reads
From: Gustavo F. Padovan @ 2010-09-27 20:38 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, marcel, gustavo, rshaffer, linux-arm-msm
In-Reply-To: <1283965529-17068-1-git-send-email-mathewm@codeaurora.org>
Hi Mat,
* Mat Martineau <mathewm@codeaurora.org> [2010-09-08 10:05:25 -0700]:
> This patch set is the same as 'v5', with a fix to PSM validation.
>
>
> [PATCH 1/4] Bluetooth: Validate PSM values in calls to connect() and bind()
>
> Modified to bypass PSM validation for SOCK_RAW (bonding) sockets.
>
>
> [PATCH 2/4] Bluetooth: Add common code for stream-oriented recvmsg()
> [PATCH 3/4] Bluetooth: Use common SOCK_STREAM receive code in RFCOMM
> [PATCH 4/4] Bluetooth: Use a stream-oriented recvmsg with SOCK_STREAM L2CAP sockets.
>
> These patches change the read behavior of SOCK_STREAM L2CAP sockets to
> allow reading of partial SDUs. Same as the 'v5' patches.
All 4 patches have been applied to my bluetoot-next-2.6 tree for later
merge in wireless-next-2.6
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: Add socket option definitions for AMP
From: Gustavo F. Padovan @ 2010-09-27 20:40 UTC (permalink / raw)
To: Mat Martineau
Cc: linux-bluetooth, marcel, gustavo, rshaffer, haijun.liu,
linux-arm-msm
In-Reply-To: <1283966193-17831-1-git-send-email-mathewm@codeaurora.org>
Hi Mat,
* Mat Martineau <mathewm@codeaurora.org> [2010-09-08 10:16:33 -0700]:
> This adds a new BT_AMP socket option to control the use of AMP channels.
> It is for use with the SOL_BLUETOOTH option level on L2CAP sockets.
>
> Available option values are defined as:
>
> BT_AMP_REQUIRE_BR_EDR
> * Default
> * AMP controllers cannot be used
> * Channel move requests from the remote device are denied
> * If the L2CAP channel is currently using AMP, move the channel to
> BR/EDR
>
> BT_AMP_PREFER_AMP
> * Allow use of AMP controllers
> * If the L2CAP channel is currently on BR/EDR and AMP controller
> resources are available, initiate a channel move to AMP
> * Channel move requests from the remote device are allowed
> * If the L2CAP socket has not been connected yet, try to create
> and configure the channel directly on an AMP controller rather
> than BR/EDR
>
> BT_AMP_PREFER_BR_EDR
> * Allow use of AMP controllers
> * If the L2CAP channel is currently on AMP, move it to BR/EDR
> * Channel move requests from the remote device are allowed
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> include/net/bluetooth/bluetooth.h | 28 ++++++++++++++++++++++++++++
> 1 files changed, 28 insertions(+), 0 deletions(-)
Patch has been applied to my bluetooth-next-2.6 tree.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Bluetooth: remove extra newline from debug output
From: Gustavo F. Padovan @ 2010-09-27 20:45 UTC (permalink / raw)
To: Ville Tervo; +Cc: ext Emeltchenko Andrei, linux-bluetooth@vger.kernel.org
In-Reply-To: <20100915102952.GD14330@null>
Hi Andrei,
* Ville Tervo <ville.tervo@nokia.com> [2010-09-15 13:29:53 +0300]:
> Hi Andrei,
>
> On Wed, Sep 08, 2010 at 03:26:53PM +0200, ext Emeltchenko Andrei wrote:
> > From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> >
> >
> > Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Acked-by: Ville Tervo <ville.tervo@nokia.com>
Patch has been applied to my bluetooth-next-2.6 tree to later merge in
wireless-next-2.6
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Bluetooth: Don't clear the blacklist when closing the HCI device
From: Gustavo F. Padovan @ 2010-09-27 20:49 UTC (permalink / raw)
To: Ville Tervo
Cc: ext johan.hedberg@gmail.com, linux-bluetooth@vger.kernel.org,
Hedberg Johan (Nokia-MS/Helsinki)
In-Reply-To: <20100915094909.GB14330@null>
Hi Johan,
* Ville Tervo <ville.tervo@nokia.com> [2010-09-15 12:49:09 +0300]:
> On Thu, Sep 09, 2010 at 09:32:39AM +0200, ext johan.hedberg@gmail.com wrote:
> > From: Johan Hedberg <johan.hedberg@nokia.com>
> >
> > Clearing the blacklist in hci_dev_do_close() would mean that user space
> > needs to do extra work to re-block devices after a DEVDOWN-DEVUP cycle.
> > This patch removes the clearing of the blacklist in this case and
> > thereby saves user space from the extra work.
> >
> > Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
>
> Acked-by: Ville Tervo <ville.tervo@nokia.com>
Patch has been applied to my bluetooth-next-2.6 tree to later merge in
wireless-next-2.6
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH v3 2/2] Bluetooth: Implement LE Set Scan Enable cmd
From: Gustavo F. Padovan @ 2010-09-27 20:51 UTC (permalink / raw)
To: Anderson Briglia; +Cc: linux-bluetooth
In-Reply-To: <1284384122-8393-2-git-send-email-anderson.briglia@openbossa.org>
Hi Anderson,
* Anderson Briglia <anderson.briglia@openbossa.org> [2010-09-13 09:22:02 -0400]:
> This patch implements LE Set Scan Enable command for dual
> mode and Low Energy hci controllers. It also adds new HCI flags
> in order to indicate the LE Scanning state for userland applications
> and kernel itself.
>
> Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
> ---
> include/net/bluetooth/hci.h | 5 +++++
> net/bluetooth/hci_event.c | 27 +++++++++++++++++++++++++++
> 2 files changed, 32 insertions(+), 0 deletions(-)
Both patches have been applied to my bluetooth-next-2.6 tree.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 2/2 v3] bluetooth: Add support Bluetooth controller of MacbookPro 7,1
From: Gustavo F. Padovan @ 2010-09-27 21:18 UTC (permalink / raw)
To: Nobuhiro Iwamatsu; +Cc: linux-bluetooth
In-Reply-To: <1282289047-21444-2-git-send-email-iwamatsu@nigauri.org>
Hi Nobuhiro,
* Nobuhiro Iwamatsu <iwamatsu@nigauri.org> [2010-08-20 16:24:07 +0900]:
> Bluetooth controller of MacbookPro 7,1 does not work.
> Because Device Class of these controllers was set 255 (Vendor Sepecific Class).
>
> T: Bus=04 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=05ac ProdID=8213 Rev=01.86
> S: Manufacturer=Apple Inc.
> S: Product=Bluetooth USB Host Controller
> S: SerialNumber=5C5948C81B99
> C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
> I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> ---
> drivers/bluetooth/btusb.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
Both patches have been applied to my bluetooth-next-2.6 tree.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: set sk_sndbuf and sk_rcvbuf properly in ERTM
From: Mat Martineau @ 2010-09-27 21:22 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <1285618609-11499-1-git-send-email-padovan@profusion.mobi>
Gustavo -
On Mon, 27 Sep 2010, Gustavo F. Padovan wrote:
> Setting both this value to MPS * TxWin * 1.2 guarantees that we are
> reserving space to fit the whole txwindow in the memory, and that
> sendmsg() will block when the transmission window is full avoid
> overloading the system memory.
> I don't have a strong reason about the 1.2 constant in the account, we
> can do another tests in the future and change that value.
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> net/bluetooth/l2cap_core.c | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 44aa034..1e2ab05 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -3129,9 +3129,17 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hdr
> l2cap_pi(sk)->next_tx_seq = 0;
> l2cap_pi(sk)->expected_tx_seq = 0;
> __skb_queue_head_init(TX_QUEUE(sk));
> - if (l2cap_pi(sk)->mode == L2CAP_MODE_ERTM)
> + if (l2cap_pi(sk)->mode == L2CAP_MODE_ERTM) {
> l2cap_ertm_init(sk);
>
> + sk->sk_sndbuf = (l2cap_pi(sk)->remote_tx_win * 1.2 *
> + (sizeof(struct l2cap_pinfo) +
> + l2cap_pi(sk)->mps));
> + sk->sk_rcvbuf = (l2cap_pi(sk)->tx_win * 1.2 *
> + (sizeof(struct l2cap_pinfo) +
> + l2cap_pi(sk)->remote_mps));
> + }
> +
> l2cap_chan_ready(sk);
> }
>
> --
> 1.7.3
I think sizeof(struct sk_buff) would be better than
sizeof(struct l2cap_pinfo), since these limits apply to data buffers,
not per-socket overhead.
The 1.2 constant would need to be increased if we allow ERTM MPS
bigger than the HCI MTU, since there would be multiple sk_buffs per
PDU. However, the calculation could be updated when those MPS changes
are made.
It would also help to enforce some limits:
SOCK_MIN_SNDBUF < sk->sk_sndbuf < sysctl_wmem_max
SOCK_MIN_RCVBUF < sk->sk_rcvbuf < sysctl_rmem_max
Regards,
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* pull-request: bluetooth-2.6 2010-09-27
From: Gustavo F. Padovan @ 2010-09-28 2:30 UTC (permalink / raw)
To: davem; +Cc: linville, marcel, linux-bluetooth, netdev
Hi David,
These are the Bluetooth fixes for 2.6.36, you are used to see Marcel doing this
job, but he has been busy lately so I'm taking the job of the pull request this
time. Since we are a bit late on the pull request I'm skipping the
wireless-2.6 step, tell me if you (including John here) disagree.
In this patch set we have two fixes for regressions in L2CAP due to ERTM code
we added in L2CAP for 2.6.36, a bugfix in the L2CAP Streaming Mode that was
making the kernel crash. And a fix for a deadlock issue between the sk_sndbuf
and the backlog queue in ERTM. The rest are also needed bug fixes.
Please tell me any problem you have pulling this.
PS: Considering that these patches do not go immediately to net-next how do I
run the Bluetooth pull request to net-next? Currently my -next tree is rebased
on net-next but before the bluetooth-next patches I put the bluetooth patches
I have in my bluetooth-2.6 tree, i.e., when making the pull request I have to be
sure that the -next patches will be on top of the patches I'm submitting now
for 2.6.36. Any help on that is welcome. :)
Regards,
---
The following changes since commit b30a3f6257ed2105259b404d419b4964e363928c:
Linux 2.6.36-rc5 (2010-09-20 16:56:53 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master
Andrei Emeltchenko (1):
Bluetooth: fix MTU L2CAP configuration parameter
Gustavo F. Padovan (4):
Bluetooth: Simplify L2CAP Streaming mode sending
Bluetooth: Fix inconsistent lock state with RFCOMM
Revert "Bluetooth: Don't accept ConfigReq if we aren't in the BT_CONFIG state"
Bluetooth: Fix deadlock in the ERTM logic
Mat Martineau (1):
Bluetooth: Only enable L2CAP FCS for ERTM or streaming
include/net/bluetooth/bluetooth.h | 11 +++++++
net/bluetooth/l2cap.c | 57 +++++++++++++++---------------------
net/bluetooth/rfcomm/sock.c | 4 ++
3 files changed, 39 insertions(+), 33 deletions(-)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ 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