* [PATCH] tools/hci2hid: properly format device path
From: Matthew Monaco @ 2013-11-04 1:46 UTC (permalink / raw)
To: linux-bluetooth
From: Matthew Monaco <matthew.monaco@0x01b.net>
---
Hello! I hope this is the correct place to send a bugfix for bluez.
tools/hid2hci.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/tools/hid2hci.c b/tools/hid2hci.c
index bb8a521..8f22047 100644
--- a/tools/hid2hci.c
+++ b/tools/hid2hci.c
@@ -221,18 +221,21 @@ static int usb_switch_dell(int fd, enum mode mode)
static int find_device(struct udev_device *udev_dev)
{
char path[PATH_MAX];
- const char *busnum, *devnum;
+ const char *str;
+ long int busnum, devnum;
int fd;
- busnum = udev_device_get_sysattr_value(udev_dev, "busnum");
- if (!busnum)
+ str = udev_device_get_sysattr_value(udev_dev, "busnum");
+ if (!str)
return -1;
+ busnum = strtol(str, NULL, 0);
- devnum = udev_device_get_sysattr_value(udev_dev, "devnum");
- if (!devnum)
+ str = udev_device_get_sysattr_value(udev_dev, "devnum");
+ if (!str)
return -1;
+ devnum = strtol(str, NULL, 0);
- snprintf(path, sizeof(path), "/dev/bus/usb/%s/%s", busnum, devnum);
+ snprintf(path, sizeof(path), "/dev/bus/usb/%03d/%03d", busnum, devnum);
fd = open(path, O_RDWR, O_CLOEXEC);
if (fd < 0) {
--
1.8.4.2
^ permalink raw reply related
* Re: Intel 7260 bluetooth malfunction when it is connected to EHCI bus
From: Marcel Holtmann @ 2013-11-02 19:05 UTC (permalink / raw)
To: Hui Wang
Cc: Tedd An, Johan Hedberg, xiong.y.zhang, Gustavo F. Padovan,
linux-bluetooth@vger.kernel.org development, Kun Yang,
Anthony Wong
In-Reply-To: <527371D4.1010305@canonical.com>
Hi Hui,
>>>>>>>>> The problem is:
>>>>>>>>> On the machine which has Intel 7260 BT module, i use it to connect a bluetooth headset,
>>>>>>>>> it can successfully scan and connect to the headset, when i play sound to the bt headset,
>>>>>>>>> the problem comes, if the bt module is connected to the XHCI, it can work very well.
>>>>>>>>>
>>>>>>>>> u@u-Lenovo-B4400:~$ lsusb -t
>>>>>>>>> 1-7:1.0: No such file or directory
>>>>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
>>>>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
>>>>>>>>> |__ Port 6: Dev 8, If 0, Class=HID, Driver=usbhid, 1.5M
>>>>>>>>> |__ Port 7: Dev 2, If 0, Class=vend., Driver=, 12M
>>>>>>>>> |__ Port 11: Dev 3, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>>>> |__ Port 11: Dev 3, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>>>>
>>>>>>>>> But if the bt module is connected to the EHCI, it always fails to play sound.
>>>>>>>>>
>>>>>>>>> u@u-Lenovo-B4400:~$ lsusb -t
>>>>>>>>> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
>>>>>>>>> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
>>>>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M
>>>>>>>>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M
>>>>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M
>>>>>>>>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
>>>>>>>>> |__ Port 5: Dev 3, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>>>> |__ Port 5: Dev 3, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>>>> |__ Port 6: Dev 4, If 0, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M
>>>>>>>>> |__ Port 6: Dev 4, If 1, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M
>>>>>>>> can you paste /sys/kernel/debug/usb/devices here.
>>>>>>>>
>>>>>>>> If the uvcvideo driver is also using ISOC URBs, we might have just exhausted the bandwidth of the USB bus here or these two devices just do not play nice with each other.
>>>>>>>>
>>>>>>>> Try to unload the uvcvideo driver and try it again.
>>>>>>> Thanks for your reply, follow your instruction, i totally disabled the camera from the BIOS, then the usb tree like this,
>>>>>>> u@u-Lenovo-B4400:~$ lsusb -t
>>>>>>> 1-1.3:1.0: No such file or directory
>>>>>>> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
>>>>>>> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
>>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>>>>>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M
>>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>>>>>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
>>>>>>> |__ Port 2: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M
>>>>>>> |__ Port 3: Dev 4, If 0, Class=vend., Driver=, 12M
>>>>>>> |__ Port 5: Dev 5, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>> |__ Port 5: Dev 5, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>> u@u-Lenovo-B4400:~$ uname -a
>>>>>>> Linux u-Lenovo-B4400 3.12.0-031200rc6-generic #201310191635 SMP Sat Oct 19 20:36:43 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>>>>>>>
>>>>>>> I re-did the test, the result is same as before, after the headset is connected and i play audio, no sound is heard from the headset.
>>>>>>> And hciconfig output shows still no SCO packets received by BT driver.
>>>>>>> u@u-Lenovo-B4400:~$ hciconfig
>>>>>>> hci0: Type: BR/EDR Bus: USB
>>>>>>> BD Address: 00:15:00:CC:2D:D2 ACL MTU: 1021:5 SCO MTU: 96:5
>>>>>>> UP RUNNING PSCAN
>>>>>>> RX bytes:5853 acl:61 sco:0 events:298 errors:0
>>>>>>> TX bytes:19212 acl:68 sco:1 commands:179 errors:0
>>>>>> this is strange. The only reason I can think of is that you do not have the firmware installed and or it is not loaded correctly. Does dmesg give any indication that something failed here.
>>>>> I can confirm the firmware file is the /lib/firmware/intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq, and it is in the filesystem. And from the dmesg, the firmware was successfully loaded.
>>>>>
>>>>> [ 8.600217] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
>>>>> [ 8.653635] kvm: disabled by bios
>>>>> [ 8.672981] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd00123/0x840300/0x126c00
>>>>> [ 8.707034] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input13
>>>>> [ 8.717725] Registered led device: phy0-led
>>>>> [ 8.722730] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
>>>>> [ 8.752626] Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated
>>>>>
>>>>>> Since this is a 3.12 kernel it should have native support for Intel specific setup routing. Any chance you can run btmon -w <file> before plugging the device into the bus. Maybe something goes wrong with the setup routine on EHCI.
>>>>> Do you mean the hcidump file i just sent in my previous email.
>>>> I do not get this. I specifically asked to run “btmon -w <file>” before plugging in the device. I want to see the early setup process here. What would I do with a hcidump trace.
>>> The attachment is the logfile generated by "btmon -w <file>". And the logfile was generated by below steps,
>>>
>>> 1) boot up the system into the ubuntu desktop
>>> 2) open a terminal and run "sudo btmon -w ~/lenovo-m4400s-btmon.log"
>>> 3) open bluetooth applet and click adding a new device, the bluetooth begin to scan devices
>>> 4) power up the bt headset
>>> 5) laptop bt module find the headset and connect it successfully
>>> 6) open the sound applet, choose bt headset as output device, play sound, but no sound can be heard from bt headset
>>> 7) Ctrl+C to terminate the "btmon -w <file>"
>>>
>>> In case you can't receive the attachment, i decode the logfile and paste the content here.
>> what I need is to see the 7260 controller init. So you need to start btmon -w <file> before the 7260 gets attached to the USB bus or before btusb.ko driver gets loaded.
> Understand now.
>
> The attachment lenovo-k4450-btmon-v0.log is the log of intel 7260 init procedure, generated by "btmon -w <file>; insmod btusb.ko; ctrl+c terminate the btmon".
>
> The attachment lenovo-k4450-btmon-v1.log is the log of intel 7260 init procedure + scan headset + connect headset + play sound.
I looked through the logs and the controller init is just fine. So in theory this should route the SCO audio frames over HCI. For some reason it does not and I have no idea why not.
That it makes a different between EHCI and XHCI is strange. I can not explain this. Maybe Tedd can help you since I have no further insights in our chips at this moment.
Regards
Marcel
^ permalink raw reply
* Re: [RFC 0/5] Disconnect complete refactoring
From: Marcel Holtmann @ 2013-11-02 18:17 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth@vger.kernel.org development
In-Reply-To: <1383170504-16602-1-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> This patch set does some code refactoring in disconnect complete event handler
> and related functions from Mgmt layer.
>
> This refactoring used to be one patch from LE auto connection patch set, but
> since Marcel asked me to do more changes, I put all these refactoring patches
> in its own patch set.
>
> Regards,
>
> Andre Guedes (5):
> Bluetooth: Check address in mgmt_disconnect_failed()
> Bluetooth: Add an extra check in mgmt_device_disconnected()
> Bluetooth: Remove link type check in hci_disconn_complete_evt()
> Bluetooth: Remove unneeded check in hci_disconn_complete_evt()
> Bluetooth: Refactor hci_disconn_complete_evt
>
> net/bluetooth/hci_event.c | 61 ++++++++++++++++++++++-------------------------
> net/bluetooth/mgmt.c | 15 +++++++++++-
> 2 files changed, 43 insertions(+), 33 deletions(-)
I applied the first 3 patches of this series to bluetooth-next tree. You need to fix up patch 4 and resend the rest.
Regards
Marcel
^ permalink raw reply
* Re: [RFC 4/5] Bluetooth: Remove unneeded check in hci_disconn_complete_evt()
From: Marcel Holtmann @ 2013-11-02 18:14 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth@vger.kernel.org development
In-Reply-To: <1383170504-16602-5-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> According to b644ba336 (patch that introduced HCI_CONN_MGMT_CONNECTED
> flag), the HCI_CONN_MGMT_CONNECTED flag tracks when mgmt has been
> notified about the connection.
>
> That being said, there is no point in checking this flag in hci_
> disconn_complete_evt() since neither mgmt_disconnect_failed() nor
> mgmt_device_disconnected() depend on it. Below follows more details:
> * mgmt_disconnect_failed() removes pending MGMT_OP_DISCONNECT
> commands, it doesn't matter if that connection was notified or not.
> * mgmt_device_disconnected() sends the mgmt event only if the link
> type is ACL_LINK or LE_LINK. For those connection type, the flag is
> always set.
>
> So this patch removes the HCI_CONN_MGMT_CONNECTED check.
>
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
> net/bluetooth/hci_event.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 4673cfb..9225a9c 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -1795,16 +1795,14 @@ static void hci_disconn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
> if (ev->status == 0)
> conn->state = BT_CLOSED;
>
> - if (test_and_clear_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags)) {
> - if (ev->status) {
> - mgmt_disconnect_failed(hdev, &conn->dst, conn->type,
> - conn->dst_type, ev->status);
> - } else {
> - u8 reason = hci_to_mgmt_reason(ev->reason);
> + if (ev->status) {
> + mgmt_disconnect_failed(hdev, &conn->dst, conn->type,
> + conn->dst_type, ev->status);
something went wrong with the coding style here.
> + } else {
> + u8 reason = hci_to_mgmt_reason(ev->reason);
>
> - mgmt_device_disconnected(hdev, &conn->dst, conn->type,
> - conn->dst_type, reason);
> - }
> + mgmt_device_disconnected(hdev, &conn->dst, conn->type,
> + conn->dst_type, reason);
And here.
> }
>
> if (ev->status == 0) {
Regards
Marcel
^ permalink raw reply
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Fabio Rossi @ 2013-11-02 12:06 UTC (permalink / raw)
To: marcel
Cc: linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
Hi Marcel,
>I finally managed to reproduce it. It does not always happen. And strangely
enough I can only trigger it when enabling experimental features of bluetoothd
with -E command line switch.
>
>But I have no idea why your bisecting points to that specific commit. And
more important it used to work just fine (see below). However I can tell you
what makes the code crash.
>
>0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
>738
>739 static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname,
char __user *optval, int __user *optlen)
>740 {
>741 struct sock *sk = sock->sk;
>742 struct rfcomm_conninfo cinfo;
>743 struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
>744 int len, err = 0;
>745 u32 opt;
>746
>747 BT_DBG("sk %p", sk);
>
>The l2cap_pi(sk) is fully broken. That is an rfcomm_pi(sk). The commit that
broke this is actually from an earlier time. I have this one:
>
>commit 8c1d787be4b62d2d1b6f04953eca4bcf7c839d44
>Author: Gustavo F. Padovan <padovan@profusion.mobi>
>Date: Wed Apr 13 20:23:55 2011 -0300
>
> Bluetooth: Move conn to struct l2cap_chan
>
>diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
>index 66cc1f0c3df8..386cfaffd4b7 100644
>--- a/net/bluetooth/rfcomm/sock.c
>+++ b/net/bluetooth/rfcomm/sock.c
>@@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket
*sock, int optname, char __u
> struct sock *sk = sock->sk;
> struct sock *l2cap_sk;
> struct rfcomm_conninfo cinfo;
>+ struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> int len, err = 0;
> u32 opt;
>
>@@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket
*sock, int optname, char __u
>
> l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
>
>- cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
>- memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon-
>dev_class, 3);
>+ cinfo.hci_handle = conn->hcon->handle;
>+ memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
>
>The conversion is clearly wrong since we used to have a l2cap_sk that was
pointing to the right socket.
>
>This should have blown up month ago and not just with the latest changes we
have done to the L2CAP layer. Anyhow, you can try this small change and see if
it fixes things for you.
>
>diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
>index c4d3d423f89b..0be7619c5e5e 100644
>--- a/net/bluetooth/rfcomm/sock.c
>+++ b/net/bluetooth/rfcomm/sock.c
>@@ -739,8 +739,9 @@ static int rfcomm_sock_setsockopt(struct socket *sock,
int level, int optname, c
> static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char
__user *optval, int __user *optlen)
> {
> struct sock *sk = sock->sk;
>+ struct sock *l2cap_sk;
>+ struct l2cap_conn *conn;
> struct rfcomm_conninfo cinfo;
>- struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> int len, err = 0;
> u32 opt;
>
>@@ -783,6 +784,9 @@ static int rfcomm_sock_getsockopt_old(struct socket
*sock, int optname, char __u
> break;
> }
>
>+ l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
>+ conn = l2cap_pi(l2cap_sk)->chan->conn;
>+
> memset(&cinfo, 0, sizeof(cinfo));
> cinfo.hci_handle = conn->hcon->handle;
> memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
>
>Regards
This patch solves the issue, I don't see the crash anymore.
Thanks,
Fabio
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix issue with RFCOMM getsockopt operation
From: Johan Hedberg @ 2013-11-02 10:30 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1383384991-63025-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sat, Nov 02, 2013, Marcel Holtmann wrote:
> The commit 94a86df01082557e2de45865e538d7fb6c46231c seem to have
> uncovered a long standing bug that did not trigger so far.
>
> BUG: unable to handle kernel paging request at 00000009dd503502
> IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
> PGD 0
> Oops: 0000 [#1] SMP
> Modules linked in: ath5k ath mac80211 cfg80211
> CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
> Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
> 1202 12/22/2010
> task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
> RIP: 0010:[<ffffffff815b1868>] [<ffffffff815b1868>]
> rfcomm_sock_getsockopt+0x128/0x200
> RSP: 0018:ffff88033046bed8 EFLAGS: 00010246
> RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
> RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
> RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
> R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
> R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
> FS: 00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
> Stack:
> ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
> 0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
> 0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
> Call Trace:
> [<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
> [<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
> [<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
> Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
> f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
> 2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
> RIP [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
> RSP <ffff88033046bed8>
> CR2: 00000009dd503502
>
> It triggers in the following segment of the code:
>
> 0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
> 738
> 739 static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
> 740 {
> 741 struct sock *sk = sock->sk;
> 742 struct rfcomm_conninfo cinfo;
> 743 struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> 744 int len, err = 0;
> 745 u32 opt;
> 746
> 747 BT_DBG("sk %p", sk);
>
> The l2cap_pi(sk) is wrong here since it should have been rfcomm_pi(sk),
> but that socket of course does not contain the low-level connection
> details requested here.
>
> Tracking down the actual offending commit, it seems that this has been
> introduced when doing some L2CAP refactoring:
>
> commit 8c1d787be4b62d2d1b6f04953eca4bcf7c839d44
> Author: Gustavo F. Padovan <padovan@profusion.mobi>
> Date: Wed Apr 13 20:23:55 2011 -0300
>
> @@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
> struct sock *sk = sock->sk;
> struct sock *l2cap_sk;
> struct rfcomm_conninfo cinfo;
> + struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> int len, err = 0;
> u32 opt;
>
> @@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
>
> l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
>
> - cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
> - memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon->dev_class, 3);
> + cinfo.hci_handle = conn->hcon->handle;
> + memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
>
> The l2cap_sk got accidentally mixed into the sk (which is RFCOMM) and
> now causing a problem within getsocketopt() system call. To fix this,
> just re-introduce l2cap_sk and make sure the right socket is used for
> the low-level connection details.
>
> Reported-by: Fabio Rossi <rossi.f@inwind.it>
> Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
> Tested-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/rfcomm/sock.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* [PATCH] Bluetooth: Fix issue with RFCOMM getsockopt operation
From: Marcel Holtmann @ 2013-11-02 9:36 UTC (permalink / raw)
To: linux-bluetooth
The commit 94a86df01082557e2de45865e538d7fb6c46231c seem to have
uncovered a long standing bug that did not trigger so far.
BUG: unable to handle kernel paging request at 00000009dd503502
IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: ath5k ath mac80211 cfg80211
CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
1202 12/22/2010
task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
RIP: 0010:[<ffffffff815b1868>] [<ffffffff815b1868>]
rfcomm_sock_getsockopt+0x128/0x200
RSP: 0018:ffff88033046bed8 EFLAGS: 00010246
RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
FS: 00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
Stack:
ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
Call Trace:
[<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
[<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
[<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
RIP [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
RSP <ffff88033046bed8>
CR2: 00000009dd503502
It triggers in the following segment of the code:
0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
738
739 static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
740 {
741 struct sock *sk = sock->sk;
742 struct rfcomm_conninfo cinfo;
743 struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
744 int len, err = 0;
745 u32 opt;
746
747 BT_DBG("sk %p", sk);
The l2cap_pi(sk) is wrong here since it should have been rfcomm_pi(sk),
but that socket of course does not contain the low-level connection
details requested here.
Tracking down the actual offending commit, it seems that this has been
introduced when doing some L2CAP refactoring:
commit 8c1d787be4b62d2d1b6f04953eca4bcf7c839d44
Author: Gustavo F. Padovan <padovan@profusion.mobi>
Date: Wed Apr 13 20:23:55 2011 -0300
@@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
struct sock *sk = sock->sk;
struct sock *l2cap_sk;
struct rfcomm_conninfo cinfo;
+ struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
int len, err = 0;
u32 opt;
@@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
- cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
- memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon->dev_class, 3);
+ cinfo.hci_handle = conn->hcon->handle;
+ memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
The l2cap_sk got accidentally mixed into the sk (which is RFCOMM) and
now causing a problem within getsocketopt() system call. To fix this,
just re-introduce l2cap_sk and make sure the right socket is used for
the low-level connection details.
Reported-by: Fabio Rossi <rossi.f@inwind.it>
Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Tested-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/rfcomm/sock.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index c4d3d423f89b..0be7619c5e5e 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -739,8 +739,9 @@ static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, c
static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
{
struct sock *sk = sock->sk;
+ struct sock *l2cap_sk;
+ struct l2cap_conn *conn;
struct rfcomm_conninfo cinfo;
- struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
int len, err = 0;
u32 opt;
@@ -783,6 +784,9 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
break;
}
+ l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
+ conn = l2cap_pi(l2cap_sk)->chan->conn;
+
memset(&cinfo, 0, sizeof(cinfo));
cinfo.hci_handle = conn->hcon->handle;
memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
--
1.8.3.1
^ permalink raw reply related
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Janusz Dziedzic @ 2013-11-02 8:01 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Fabio Rossi, linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <0C59D92B-D434-48B8-B8E7-CFCDFC2524A9@holtmann.org>
2013/11/2 Marcel Holtmann <marcel@holtmann.org>:
> Hi Fabio,
>
>>> can you quickly test a kernel build from bluetooth-next tree. I would like to
>> see if that crashes as well. Since I have been running that one for weeks and
>> never saw this bug.
>>
>> here is the same problem with bluetooth-next.git
>>
>> BUG: unable to handle kernel paging request at 00000009dd503502
>> IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
>> PGD 0
>> Oops: 0000 [#1] SMP
>> Modules linked in: ath5k ath mac80211 cfg80211
>> CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
>> Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
>> 1202 12/22/2010
>> task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
>> RIP: 0010:[<ffffffff815b1868>] [<ffffffff815b1868>]
>> rfcomm_sock_getsockopt+0x128/0x200
>> RSP: 0018:ffff88033046bed8 EFLAGS: 00010246
>> RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
>> RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
>> RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
>> R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
>> R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
>> FS: 00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
>> Stack:
>> ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
>> 0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
>> 0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
>> Call Trace:
>> [<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
>> [<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
>> [<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
>> Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
>> f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
>> 2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
>> RIP [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
>> RSP <ffff88033046bed8>
>> CR2: 00000009dd503502
>> ---[ end trace 719ace9ee57b7a58 ]---
>
> I finally managed to reproduce it. It does not always happen. And strangely enough I can only trigger it when enabling experimental features of bluetoothd with -E command line switch.
>
> But I have no idea why your bisecting points to that specific commit. And more important it used to work just fine (see below). However I can tell you what makes the code crash.
>
> 0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
> 738
> 739 static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
> 740 {
> 741 struct sock *sk = sock->sk;
> 742 struct rfcomm_conninfo cinfo;
> 743 struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> 744 int len, err = 0;
> 745 u32 opt;
> 746
> 747 BT_DBG("sk %p", sk);
>
> The l2cap_pi(sk) is fully broken. That is an rfcomm_pi(sk). The commit that broke this is actually from an earlier time. I have this one:
>
> commit 8c1d787be4b62d2d1b6f04953eca4bcf7c839d44
> Author: Gustavo F. Padovan <padovan@profusion.mobi>
> Date: Wed Apr 13 20:23:55 2011 -0300
>
> Bluetooth: Move conn to struct l2cap_chan
>
> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> index 66cc1f0c3df8..386cfaffd4b7 100644
> --- a/net/bluetooth/rfcomm/sock.c
> +++ b/net/bluetooth/rfcomm/sock.c
> @@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
> struct sock *sk = sock->sk;
> struct sock *l2cap_sk;
> struct rfcomm_conninfo cinfo;
> + struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> int len, err = 0;
> u32 opt;
>
> @@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
>
> l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
>
> - cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
> - memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon->dev_class, 3);
> + cinfo.hci_handle = conn->hcon->handle;
> + memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
>
> The conversion is clearly wrong since we used to have a l2cap_sk that was pointing to the right socket.
>
> This should have blown up month ago and not just with the latest changes we have done to the L2CAP layer. Anyhow, you can try this small change and see if it fixes things for you.
>
> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> index c4d3d423f89b..0be7619c5e5e 100644
> --- a/net/bluetooth/rfcomm/sock.c
> +++ b/net/bluetooth/rfcomm/sock.c
> @@ -739,8 +739,9 @@ static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, c
> static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
> {
> struct sock *sk = sock->sk;
> + struct sock *l2cap_sk;
> + struct l2cap_conn *conn;
> struct rfcomm_conninfo cinfo;
> - struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> int len, err = 0;
> u32 opt;
>
> @@ -783,6 +784,9 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
> break;
> }
>
> + l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
> + conn = l2cap_pi(l2cap_sk)->chan->conn;
> +
> memset(&cinfo, 0, sizeof(cinfo));
> cinfo.hci_handle = conn->hcon->handle;
> memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
>
Hello,
With this patch I don't see startup dump anymore. Thanks.
BR
Janusz
^ permalink raw reply
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Marcel Holtmann @ 2013-11-02 1:59 UTC (permalink / raw)
To: Fabio Rossi
Cc: linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <1175475492.2023361383354760278.JavaMail.defaultUser@defaultHost>
Hi Fabio,
>> can you quickly test a kernel build from bluetooth-next tree. I would like to
> see if that crashes as well. Since I have been running that one for weeks and
> never saw this bug.
>
> here is the same problem with bluetooth-next.git
>
> BUG: unable to handle kernel paging request at 00000009dd503502
> IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
> PGD 0
> Oops: 0000 [#1] SMP
> Modules linked in: ath5k ath mac80211 cfg80211
> CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
> Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
> 1202 12/22/2010
> task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
> RIP: 0010:[<ffffffff815b1868>] [<ffffffff815b1868>]
> rfcomm_sock_getsockopt+0x128/0x200
> RSP: 0018:ffff88033046bed8 EFLAGS: 00010246
> RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
> RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
> RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
> R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
> R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
> FS: 00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
> Stack:
> ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
> 0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
> 0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
> Call Trace:
> [<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
> [<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
> [<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
> Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
> f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
> 2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
> RIP [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
> RSP <ffff88033046bed8>
> CR2: 00000009dd503502
> ---[ end trace 719ace9ee57b7a58 ]---
I finally managed to reproduce it. It does not always happen. And strangely enough I can only trigger it when enabling experimental features of bluetoothd with -E command line switch.
But I have no idea why your bisecting points to that specific commit. And more important it used to work just fine (see below). However I can tell you what makes the code crash.
0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
738
739 static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
740 {
741 struct sock *sk = sock->sk;
742 struct rfcomm_conninfo cinfo;
743 struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
744 int len, err = 0;
745 u32 opt;
746
747 BT_DBG("sk %p", sk);
The l2cap_pi(sk) is fully broken. That is an rfcomm_pi(sk). The commit that broke this is actually from an earlier time. I have this one:
commit 8c1d787be4b62d2d1b6f04953eca4bcf7c839d44
Author: Gustavo F. Padovan <padovan@profusion.mobi>
Date: Wed Apr 13 20:23:55 2011 -0300
Bluetooth: Move conn to struct l2cap_chan
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 66cc1f0c3df8..386cfaffd4b7 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
struct sock *sk = sock->sk;
struct sock *l2cap_sk;
struct rfcomm_conninfo cinfo;
+ struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
int len, err = 0;
u32 opt;
@@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
- cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
- memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon->dev_class, 3);
+ cinfo.hci_handle = conn->hcon->handle;
+ memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
The conversion is clearly wrong since we used to have a l2cap_sk that was pointing to the right socket.
This should have blown up month ago and not just with the latest changes we have done to the L2CAP layer. Anyhow, you can try this small change and see if it fixes things for you.
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index c4d3d423f89b..0be7619c5e5e 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -739,8 +739,9 @@ static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, c
static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
{
struct sock *sk = sock->sk;
+ struct sock *l2cap_sk;
+ struct l2cap_conn *conn;
struct rfcomm_conninfo cinfo;
- struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
int len, err = 0;
u32 opt;
@@ -783,6 +784,9 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
break;
}
+ l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
+ conn = l2cap_pi(l2cap_sk)->chan->conn;
+
memset(&cinfo, 0, sizeof(cinfo));
cinfo.hci_handle = conn->hcon->handle;
memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
Regards
Marcel
^ permalink raw reply related
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Fabio Rossi @ 2013-11-02 1:12 UTC (permalink / raw)
To: marcel
Cc: linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
>can you quickly test a kernel build from bluetooth-next tree. I would like to
see if that crashes as well. Since I have been running that one for weeks and
never saw this bug.
>
>Regards
>
>Marcel
Hi Marcel,
here is the same problem with bluetooth-next.git
BUG: unable to handle kernel paging request at 00000009dd503502
IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: ath5k ath mac80211 cfg80211
CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
1202 12/22/2010
task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
RIP: 0010:[<ffffffff815b1868>] [<ffffffff815b1868>]
rfcomm_sock_getsockopt+0x128/0x200
RSP: 0018:ffff88033046bed8 EFLAGS: 00010246
RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
FS: 00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
Stack:
ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
Call Trace:
[<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
[<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
[<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
RIP [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
RSP <ffff88033046bed8>
CR2: 00000009dd503502
---[ end trace 719ace9ee57b7a58 ]---
Regards,
Fabio
^ permalink raw reply
* Re: [PATCH v2 2/2] Bluetooth: btmrvl: remove cal-data byte swapping and redundant mem copy
From: Marcel Holtmann @ 2013-11-01 22:39 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan,
Johan Hedberg, Mike Frysinger, Amitkumar Karwar
In-Reply-To: <1383344905-3525-2-git-send-email-bzhao@marvell.com>
Hi Bing,
> The device tree property can define the cal-data in proper order.
> There is no need to swap the bytes in driver.
> Also remove the redundant cal-data memory copy after removing the
> byte swapping.
>
> Cc: Mike Frysinger <vapier@chromium.org>
> Cc: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
> Signed-off-by: Hyuckjoo Lee <hyuckjoo.lee@samsung.com>
> ---
> v2: no change from v1
>
> drivers/bluetooth/btmrvl_drv.h | 2 +-
> drivers/bluetooth/btmrvl_main.c | 27 ++++++++++-----------------
> 2 files changed, 11 insertions(+), 18 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2 1/2] Bluetooth: btmrvl: use cal-data from device-tree instead of conf file
From: Marcel Holtmann @ 2013-11-01 22:39 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan,
Johan Hedberg, Mike Frysinger, Amitkumar Karwar
In-Reply-To: <1383344905-3525-1-git-send-email-bzhao@marvell.com>
Hi Bing,
> Some ARM versions of Chromebook need to download a new calibration
> data from host driver to firmware. They do have EEPROM but still
> need a piece of new calibration data in test mode.
>
> The cal-data is platform dependent. It's simpler and more feasible
> to use device tree based cal-data instead of configuration file
> based cal-data.
>
> This patch remove configuration file based cal-data downloading
> and replace it using cal-data from device tree.
>
> When CONFIG_OF is not selected, or the specific property is not
> present in the device tree, the calibration downloading will not
> happen.
>
> Cc: Mike Frysinger <vapier@chromium.org>
> Cc: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
> Signed-off-by: Hyuckjoo Lee <hyuckjoo.lee@samsung.com>
> ---
> v2: add verbose commit messages (Marcel Holtmann)
>
> drivers/bluetooth/btmrvl_drv.h | 4 --
> drivers/bluetooth/btmrvl_main.c | 92 ++++++++---------------------------------
> drivers/bluetooth/btmrvl_sdio.c | 9 +---
> drivers/bluetooth/btmrvl_sdio.h | 2 -
> 4 files changed, 18 insertions(+), 89 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/3] Bluetooth: btmrvl: operate on 16-bit opcodes instead of ogf/ocf
From: Marcel Holtmann @ 2013-11-01 22:33 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan,
Johan Hedberg, Mike Frysinger, Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F70430F45757D88@SC-VEXCH1.marvell.com>
Hi Bing,
>>> Replace ogf/ocf and its packing with 16-bit opcodes.
>>>
>>> Signed-off-by: Bing Zhao <bzhao@marvell.com>
>>> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
>>> ---
>>> drivers/bluetooth/btmrvl_drv.h | 19 +++++++++++--------
>>> drivers/bluetooth/btmrvl_main.c | 21 +++++++++------------
>>> 2 files changed, 20 insertions(+), 20 deletions(-)
>>
>> patch looks fine to me. Since you send it as 3/3, I don’t know if you want me to apply it right away
>> or just when the whole series is ready to be applied.
>
> Please apply 3/3 first if that's convenient for you.
> I will resend 1/3 and 2/3 in v2 series.
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH v2 2/2] Bluetooth: btmrvl: remove cal-data byte swapping and redundant mem copy
From: Bing Zhao @ 2013-11-01 22:28 UTC (permalink / raw)
To: linux-bluetooth
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Mike Frysinger,
Amitkumar Karwar, Bing Zhao
In-Reply-To: <1383344905-3525-1-git-send-email-bzhao@marvell.com>
The device tree property can define the cal-data in proper order.
There is no need to swap the bytes in driver.
Also remove the redundant cal-data memory copy after removing the
byte swapping.
Cc: Mike Frysinger <vapier@chromium.org>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Hyuckjoo Lee <hyuckjoo.lee@samsung.com>
---
v2: no change from v1
drivers/bluetooth/btmrvl_drv.h | 2 +-
drivers/bluetooth/btmrvl_main.c | 27 ++++++++++-----------------
2 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index be76851..ffac0e4 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -117,7 +117,7 @@ struct btmrvl_private {
#define PS_SLEEP 0x01
#define PS_AWAKE 0x00
-#define BT_CMD_DATA_SIZE 32
+#define BT_CAL_HDR_LEN 4
#define BT_CAL_DATA_SIZE 28
struct btmrvl_event {
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index a17812d..f13bef8 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -418,28 +418,20 @@ static int btmrvl_open(struct hci_dev *hdev)
}
static int btmrvl_download_cal_data(struct btmrvl_private *priv,
- u8 *config_data)
+ u8 *data, int len)
{
- int i, ret;
- u8 data[BT_CMD_DATA_SIZE];
+ int ret;
data[0] = 0x00;
data[1] = 0x00;
data[2] = 0x00;
- data[3] = BT_CMD_DATA_SIZE - 4;
-
- /* Swap cal-data bytes. Each four bytes are swapped. Considering 4
- * byte SDIO header offset, mapping of input and output bytes will be
- * {3, 2, 1, 0} -> {0+4, 1+4, 2+4, 3+4},
- * {7, 6, 5, 4} -> {4+4, 5+4, 6+4, 7+4} */
- for (i = 4; i < BT_CMD_DATA_SIZE; i++)
- data[i] = config_data[(i / 4) * 8 - 1 - i];
+ data[3] = len;
print_hex_dump_bytes("Calibration data: ",
- DUMP_PREFIX_OFFSET, data, BT_CMD_DATA_SIZE);
+ DUMP_PREFIX_OFFSET, data, BT_CAL_HDR_LEN + len);
ret = btmrvl_send_sync_cmd(priv, BT_CMD_LOAD_CONFIG_DATA, data,
- BT_CMD_DATA_SIZE);
+ BT_CAL_HDR_LEN + len);
if (ret)
BT_ERR("Failed to download caibration data\n");
@@ -449,7 +441,7 @@ static int btmrvl_download_cal_data(struct btmrvl_private *priv,
static int btmrvl_cal_data_dt(struct btmrvl_private *priv)
{
struct device_node *dt_node;
- u8 cal_data[BT_CAL_DATA_SIZE];
+ u8 cal_data[BT_CAL_HDR_LEN + BT_CAL_DATA_SIZE];
const char name[] = "btmrvl_caldata";
const char property[] = "btmrvl,caldata";
int ret;
@@ -458,13 +450,14 @@ static int btmrvl_cal_data_dt(struct btmrvl_private *priv)
if (!dt_node)
return -ENODEV;
- ret = of_property_read_u8_array(dt_node, property, cal_data,
- sizeof(cal_data));
+ ret = of_property_read_u8_array(dt_node, property,
+ cal_data + BT_CAL_HDR_LEN,
+ BT_CAL_DATA_SIZE);
if (ret)
return ret;
BT_DBG("Use cal data from device tree");
- ret = btmrvl_download_cal_data(priv, cal_data);
+ ret = btmrvl_download_cal_data(priv, cal_data, BT_CAL_DATA_SIZE);
if (ret) {
BT_ERR("Fail to download calibrate data");
return ret;
--
1.8.0
^ permalink raw reply related
* [PATCH v2 1/2] Bluetooth: btmrvl: use cal-data from device-tree instead of conf file
From: Bing Zhao @ 2013-11-01 22:28 UTC (permalink / raw)
To: linux-bluetooth
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Mike Frysinger,
Amitkumar Karwar, Bing Zhao
Some ARM versions of Chromebook need to download a new calibration
data from host driver to firmware. They do have EEPROM but still
need a piece of new calibration data in test mode.
The cal-data is platform dependent. It's simpler and more feasible
to use device tree based cal-data instead of configuration file
based cal-data.
This patch remove configuration file based cal-data downloading
and replace it using cal-data from device tree.
When CONFIG_OF is not selected, or the specific property is not
present in the device tree, the calibration downloading will not
happen.
Cc: Mike Frysinger <vapier@chromium.org>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Hyuckjoo Lee <hyuckjoo.lee@samsung.com>
---
v2: add verbose commit messages (Marcel Holtmann)
drivers/bluetooth/btmrvl_drv.h | 4 --
drivers/bluetooth/btmrvl_main.c | 92 ++++++++---------------------------------
drivers/bluetooth/btmrvl_sdio.c | 9 +---
drivers/bluetooth/btmrvl_sdio.h | 2 -
4 files changed, 18 insertions(+), 89 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index f9d1833..be76851 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -23,8 +23,6 @@
#include <linux/bitops.h>
#include <linux/slab.h>
#include <net/bluetooth/bluetooth.h>
-#include <linux/ctype.h>
-#include <linux/firmware.h>
#define BTM_HEADER_LEN 4
#define BTM_UPLD_SIZE 2312
@@ -43,8 +41,6 @@ struct btmrvl_thread {
struct btmrvl_device {
void *card;
struct hci_dev *hcidev;
- struct device *dev;
- const char *cal_data;
u8 dev_type;
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 5cf31c4..a17812d 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -19,7 +19,7 @@
**/
#include <linux/module.h>
-
+#include <linux/of.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
@@ -417,52 +417,8 @@ static int btmrvl_open(struct hci_dev *hdev)
return 0;
}
-/*
- * This function parses provided calibration data input. It should contain
- * hex bytes separated by space or new line character. Here is an example.
- * 00 1C 01 37 FF FF FF FF 02 04 7F 01
- * CE BA 00 00 00 2D C6 C0 00 00 00 00
- * 00 F0 00 00
- */
-static int btmrvl_parse_cal_cfg(const u8 *src, u32 len, u8 *dst, u32 dst_size)
-{
- const u8 *s = src;
- u8 *d = dst;
- int ret;
- u8 tmp[3];
-
- tmp[2] = '\0';
- while ((s - src) <= len - 2) {
- if (isspace(*s)) {
- s++;
- continue;
- }
-
- if (isxdigit(*s)) {
- if ((d - dst) >= dst_size) {
- BT_ERR("calibration data file too big!!!");
- return -EINVAL;
- }
-
- memcpy(tmp, s, 2);
-
- ret = kstrtou8(tmp, 16, d++);
- if (ret < 0)
- return ret;
-
- s += 2;
- } else {
- return -EINVAL;
- }
- }
- if (d == dst)
- return -EINVAL;
-
- return 0;
-}
-
-static int btmrvl_load_cal_data(struct btmrvl_private *priv,
- u8 *config_data)
+static int btmrvl_download_cal_data(struct btmrvl_private *priv,
+ u8 *config_data)
{
int i, ret;
u8 data[BT_CMD_DATA_SIZE];
@@ -490,54 +446,40 @@ static int btmrvl_load_cal_data(struct btmrvl_private *priv,
return 0;
}
-static int
-btmrvl_process_cal_cfg(struct btmrvl_private *priv, u8 *data, u32 size)
+static int btmrvl_cal_data_dt(struct btmrvl_private *priv)
{
+ struct device_node *dt_node;
u8 cal_data[BT_CAL_DATA_SIZE];
+ const char name[] = "btmrvl_caldata";
+ const char property[] = "btmrvl,caldata";
int ret;
- ret = btmrvl_parse_cal_cfg(data, size, cal_data, sizeof(cal_data));
+ dt_node = of_find_node_by_name(NULL, name);
+ if (!dt_node)
+ return -ENODEV;
+
+ ret = of_property_read_u8_array(dt_node, property, cal_data,
+ sizeof(cal_data));
if (ret)
return ret;
- ret = btmrvl_load_cal_data(priv, cal_data);
+ BT_DBG("Use cal data from device tree");
+ ret = btmrvl_download_cal_data(priv, cal_data);
if (ret) {
- BT_ERR("Fail to load calibrate data");
+ BT_ERR("Fail to download calibrate data");
return ret;
}
return 0;
}
-static int btmrvl_cal_data_config(struct btmrvl_private *priv)
-{
- const struct firmware *cfg;
- int ret;
- const char *cal_data = priv->btmrvl_dev.cal_data;
-
- if (!cal_data)
- return 0;
-
- ret = request_firmware(&cfg, cal_data, priv->btmrvl_dev.dev);
- if (ret < 0) {
- BT_DBG("Failed to get %s file, skipping cal data download",
- cal_data);
- return 0;
- }
-
- ret = btmrvl_process_cal_cfg(priv, (u8 *)cfg->data, cfg->size);
- release_firmware(cfg);
- return ret;
-}
-
static int btmrvl_setup(struct hci_dev *hdev)
{
struct btmrvl_private *priv = hci_get_drvdata(hdev);
btmrvl_send_module_cfg_cmd(priv, MODULE_BRINGUP_REQ);
- if (btmrvl_cal_data_config(priv))
- BT_ERR("Set cal data failed");
+ btmrvl_cal_data_dt(priv);
priv->btmrvl_dev.psmode = 1;
btmrvl_enable_ps(priv);
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index fabcf5b..1b52c9f 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -18,6 +18,7 @@
* this warranty disclaimer.
**/
+#include <linux/firmware.h>
#include <linux/slab.h>
#include <linux/mmc/sdio_ids.h>
@@ -101,7 +102,6 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_88xx = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
.helper = "mrvl/sd8688_helper.bin",
.firmware = "mrvl/sd8688.bin",
- .cal_data = NULL,
.reg = &btmrvl_reg_8688,
.sd_blksz_fw_dl = 64,
};
@@ -109,7 +109,6 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8787 = {
.helper = NULL,
.firmware = "mrvl/sd8787_uapsta.bin",
- .cal_data = NULL,
.reg = &btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
@@ -117,7 +116,6 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8787 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8797 = {
.helper = NULL,
.firmware = "mrvl/sd8797_uapsta.bin",
- .cal_data = "mrvl/sd8797_caldata.conf",
.reg = &btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
@@ -125,7 +123,6 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8797 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8897 = {
.helper = NULL,
.firmware = "mrvl/sd8897_uapsta.bin",
- .cal_data = NULL,
.reg = &btmrvl_reg_88xx,
.sd_blksz_fw_dl = 256,
};
@@ -1007,7 +1004,6 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
struct btmrvl_sdio_device *data = (void *) id->driver_data;
card->helper = data->helper;
card->firmware = data->firmware;
- card->cal_data = data->cal_data;
card->reg = data->reg;
card->sd_blksz_fw_dl = data->sd_blksz_fw_dl;
}
@@ -1036,8 +1032,6 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
}
card->priv = priv;
- priv->btmrvl_dev.dev = &card->func->dev;
- priv->btmrvl_dev.cal_data = card->cal_data;
/* Initialize the interface specific function pointers */
priv->hw_host_to_card = btmrvl_sdio_host_to_card;
@@ -1220,5 +1214,4 @@ MODULE_FIRMWARE("mrvl/sd8688_helper.bin");
MODULE_FIRMWARE("mrvl/sd8688.bin");
MODULE_FIRMWARE("mrvl/sd8787_uapsta.bin");
MODULE_FIRMWARE("mrvl/sd8797_uapsta.bin");
-MODULE_FIRMWARE("mrvl/sd8797_caldata.conf");
MODULE_FIRMWARE("mrvl/sd8897_uapsta.bin");
diff --git a/drivers/bluetooth/btmrvl_sdio.h b/drivers/bluetooth/btmrvl_sdio.h
index 6872d9e..43d35a6 100644
--- a/drivers/bluetooth/btmrvl_sdio.h
+++ b/drivers/bluetooth/btmrvl_sdio.h
@@ -85,7 +85,6 @@ struct btmrvl_sdio_card {
u32 ioport;
const char *helper;
const char *firmware;
- const char *cal_data;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
u8 rx_unit;
@@ -95,7 +94,6 @@ struct btmrvl_sdio_card {
struct btmrvl_sdio_device {
const char *helper;
const char *firmware;
- const char *cal_data;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
};
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 1/3] Bluetooth: btmrvl: use cal-data from device-tree instead of conf file
From: Marcel Holtmann @ 2013-11-01 22:21 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan,
Johan Hedberg, Mike Frysinger, Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F70430F45757D87@SC-VEXCH1.marvell.com>
Hi Bing,
>>> +#include <linux/of.h>
>>> #include <net/bluetooth/bluetooth.h>
>>> #include <net/bluetooth/hci_core.h>
>>
>> here now it becomes tricky. Does this now depend on CONFIG_OF as well?
>
> No. It doesn't depend on CONFIG_OF.
> The of.h takes good care of the two OF functions (of_find_node_by_name and of_property_read_u8_array) used in this patch. If CONFIG_OF is not defined, the 1st function returns NULL and the 2nd function returns -ENOSYS.
>
>>
>> What happens to x86 systems that generally do not use open firmware or device tree. Do they still
>> work?
>
> On x86 systems without OF or device tree, the entire calibration data downloading will be skipped.
>
>> Which kind of devices need the calibration data anyway? All of them? Just the ones without
>> EEPROM?
>
> Some ARM versions of Chromebook need the calibration data.
> They do have EEPROM but still need a piece of new calibration data in test mode.
>
>>
>> You need to pretty much verbose in your commit message on what is going on. And I get the feeling
>> that you have to handle the case where CONFIG_OF is not selected.
>
> When CONFIG_OF is not selected, or the specific property is not present in the device tree, the calibration downloading will not happen.
>
> I can add above messages to the commit log in v2.
that would be a good idea. Thanks.
Regards
Marcel
^ permalink raw reply
* RE: [PATCH 3/3] Bluetooth: btmrvl: operate on 16-bit opcodes instead of ogf/ocf
From: Bing Zhao @ 2013-11-01 22:11 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan,
Johan Hedberg, Mike Frysinger, Amitkumar Karwar
In-Reply-To: <5C5FA2A6-6FC9-4BCC-B153-419D64AD3FCA@holtmann.org>
Hi Marcel,
> Hi Bing,
>=20
> > Replace ogf/ocf and its packing with 16-bit opcodes.
> >
> > Signed-off-by: Bing Zhao <bzhao@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > ---
> > drivers/bluetooth/btmrvl_drv.h | 19 +++++++++++--------
> > drivers/bluetooth/btmrvl_main.c | 21 +++++++++------------
> > 2 files changed, 20 insertions(+), 20 deletions(-)
>=20
> patch looks fine to me. Since you send it as 3/3, I don=92t know if you w=
ant me to apply it right away
> or just when the whole series is ready to be applied.
Please apply 3/3 first if that's convenient for you.
I will resend 1/3 and 2/3 in v2 series.
Thanks,
Bing
^ permalink raw reply
* RE: [PATCH 1/3] Bluetooth: btmrvl: use cal-data from device-tree instead of conf file
From: Bing Zhao @ 2013-11-01 22:08 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan,
Johan Hedberg, Mike Frysinger, Amitkumar Karwar
In-Reply-To: <39C7BB16-B89A-465E-BB9D-09374FA877C6@holtmann.org>
Hi Marcel,
> > +#include <linux/of.h>
> > #include <net/bluetooth/bluetooth.h>
> > #include <net/bluetooth/hci_core.h>
>=20
> here now it becomes tricky. Does this now depend on CONFIG_OF as well?
No. It doesn't depend on CONFIG_OF.
The of.h takes good care of the two OF functions (of_find_node_by_name and =
of_property_read_u8_array) used in this patch. If CONFIG_OF is not defined,=
the 1st function returns NULL and the 2nd function returns -ENOSYS.
>=20
> What happens to x86 systems that generally do not use open firmware or de=
vice tree. Do they still
> work?=20
On x86 systems without OF or device tree, the entire calibration data downl=
oading will be skipped.
> Which kind of devices need the calibration data anyway? All of them? Just=
the ones without
> EEPROM?
Some ARM versions of Chromebook need the calibration data.
They do have EEPROM but still need a piece of new calibration data in test =
mode.
>=20
> You need to pretty much verbose in your commit message on what is going o=
n. And I get the feeling
> that you have to handle the case where CONFIG_OF is not selected.
When CONFIG_OF is not selected, or the specific property is not present in =
the device tree, the calibration downloading will not happen.
I can add above messages to the commit log in v2.
Thanks,
Bing
^ permalink raw reply
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Marcel Holtmann @ 2013-11-01 21:39 UTC (permalink / raw)
To: Fabio Rossi
Cc: linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <607082335.2055771383319324985.JavaMail.defaultUser@defaultHost>
Hi Fabio,
>> what socket option is your client program setting? Do you happen to know that.
> Would make it a lot easier to track this down.
>
> Hi Marcel,
> I'm using the bluetoothd daemon at startup and it crashes as soon as the
> dongle is inserted. To test the behaviour I removed the dongle and restart the
> daemon with
>
> # bluetoothd -n -d
>
> bluetoothd[4450]: Bluetooth daemon 4.101
> bluetoothd[4450]: src/main.c:parse_config() parsing main.conf
> bluetoothd[4450]: src/main.c:parse_config() discovto=0
> bluetoothd[4450]: src/main.c:parse_config() pairto=0
> bluetoothd[4450]: src/main.c:parse_config() pageto=8192
> bluetoothd[4450]: src/main.c:parse_config() auto_to=60
> bluetoothd[4450]: src/main.c:parse_config() name=%h-%d
> bluetoothd[4450]: src/main.c:parse_config() class=0x000100
> bluetoothd[4450]: src/main.c:parse_config() Key file does not have key
> 'DeviceID'
> bluetoothd[4450]: Starting SDP server
> bluetoothd[4450]: src/plugin.c:plugin_init() Loading builtin plugins
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading pnat plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading audio plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading input plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading serial plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading network plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading service plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading health plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading hciops plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading mgmtops plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading formfactor plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading storage plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading adaptername plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading wiimote plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading maemo6 plugin
> bluetoothd[4450]: src/plugin.c:plugin_init() Loading plugins
> /usr/lib64/bluetooth/plugins
> bluetoothd[4450]: plugins/service.c:register_interface() path
> /org/bluez/4450/any
> bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
> org.bluez.Service on path /org/bluez/4450/any
> bluetoothd[4450]: plugins/maemo6.c:maemo6_init() init maemo6 plugin
> bluetoothd[4450]: health/hdp.c:hdp_manager_start() Starting Health manager
> bluetoothd[4450]: network/manager.c:read_config() /etc/bluetooth/network.conf:
> Key file does not have key 'DisableSecurity'
> bluetoothd[4450]: network/manager.c:read_config() Config options:
> Security=true
> bluetoothd[4450]: input/manager.c:input_manager_init() input.conf: Key file
> does not have key 'IdleTimeout'
> bluetoothd[4450]: audio/manager.c:audio_manager_init() audio.conf: Key file
> does not have key 'AutoConnect'
> bluetoothd[4450]: plugins/pnat.c:pnat_init() Setup Phonet AT (DUN) plugin
> bluetoothd[4450]: plugins/hciops.c:hciops_init()
> bluetoothd[4450]: Bluetooth Management interface initialized
> bluetoothd[4450]: Failed to open RFKILL control device
> bluetoothd[4450]: src/main.c:main() Entering main loop
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 12 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
> bluetoothd[4450]: plugins/mgmtops.c:read_version_complete() version 1 revision
> 4
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 11 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
>
> then I insert the dongle
>
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 6 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:add_controller() Added controller 0
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 289 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
> XX:XX version 3 manufacturer 10 class 0x000000
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 settings
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 name CSR - bc4
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 short name
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_remove_uuid() index 0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_read_bdaddr() index 0 addr 00:09:DD:
> XX:XX:XX
> bluetoothd[4450]: src/sdpd-database.c:sdp_init_services_list()
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
> bluetoothd[4450]: plugins/service.c:register_interface() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
> org.bluez.Service on path /org/bluez/4450/hci0
> bluetoothd[4450]: plugins/maemo6.c:mce_probe() path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=2
> bluetoothd[4450]: network/manager.c:network_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=3
> bluetoothd[4450]: network/server.c:server_register() Registered interface org.
> bluez.NetworkServer on path /org/bluez/4450/hci0
> bluetoothd[4450]: serial/manager.c:proxy_probe() path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=4
> bluetoothd[4450]: serial/proxy.c:proxy_register() Registered interface org.
> bluez.SerialProxyManager on path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=5
> bluetoothd[4450]: audio/manager.c:media_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=6
> bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=1
> bluetoothd[4450]: audio/manager.c:headset_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=2
> bluetoothd[4450]: audio/manager.c:headset_server_init() audio.conf: Key file
> does not have key 'Master'
> Killed
>
> and I get the crash previously reported. If I use a working kernel the
> bluetooth daemon continues its startup and the next lines are
can you quickly test a kernel build from bluetooth-next tree. I would like to see if that crashes as well. Since I have been running that one for weeks and never saw this bug.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/3] Bluetooth: btmrvl: operate on 16-bit opcodes instead of ogf/ocf
From: Marcel Holtmann @ 2013-11-01 21:36 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan,
Johan Hedberg, Mike Frysinger, Amitkumar Karwar
In-Reply-To: <1383257311-1430-3-git-send-email-bzhao@marvell.com>
Hi Bing,
> Replace ogf/ocf and its packing with 16-bit opcodes.
>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> drivers/bluetooth/btmrvl_drv.h | 19 +++++++++++--------
> drivers/bluetooth/btmrvl_main.c | 21 +++++++++------------
> 2 files changed, 20 insertions(+), 20 deletions(-)
patch looks fine to me. Since you send it as 3/3, I don’t know if you want me to apply it right away or just when the whole series is ready to be applied.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/3] Bluetooth: btmrvl: use cal-data from device-tree instead of conf file
From: Marcel Holtmann @ 2013-11-01 21:33 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan,
Johan Hedberg, Mike Frysinger, Amitkumar Karwar
In-Reply-To: <1383257311-1430-1-git-send-email-bzhao@marvell.com>
Hi Bing,
> The cal-data is platform dependent. It's simpler and more feasible
> to use device tree based cal-data instead of configuration file
> based cal-data.
>
> This patch remove configuration file based cal-data downloading
> and replace it using cal-data from device tree.
>
> Cc: Mike Frysinger <vapier@chromium.org>
> Cc: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
> Signed-off-by: Hyuckjoo Lee <hyuckjoo.lee@samsung.com>
> ---
> drivers/bluetooth/btmrvl_drv.h | 4 --
> drivers/bluetooth/btmrvl_main.c | 92 ++++++++---------------------------------
> drivers/bluetooth/btmrvl_sdio.c | 9 +---
> drivers/bluetooth/btmrvl_sdio.h | 2 -
> 4 files changed, 18 insertions(+), 89 deletions(-)
>
> diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
> index f9d1833..be76851 100644
> --- a/drivers/bluetooth/btmrvl_drv.h
> +++ b/drivers/bluetooth/btmrvl_drv.h
> @@ -23,8 +23,6 @@
> #include <linux/bitops.h>
> #include <linux/slab.h>
> #include <net/bluetooth/bluetooth.h>
> -#include <linux/ctype.h>
> -#include <linux/firmware.h>
>
> #define BTM_HEADER_LEN 4
> #define BTM_UPLD_SIZE 2312
> @@ -43,8 +41,6 @@ struct btmrvl_thread {
> struct btmrvl_device {
> void *card;
> struct hci_dev *hcidev;
> - struct device *dev;
> - const char *cal_data;
>
> u8 dev_type;
>
> diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
> index 5cf31c4..a17812d 100644
> --- a/drivers/bluetooth/btmrvl_main.c
> +++ b/drivers/bluetooth/btmrvl_main.c
> @@ -19,7 +19,7 @@
> **/
>
> #include <linux/module.h>
> -
> +#include <linux/of.h>
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
here now it becomes tricky. Does this now depend on CONFIG_OF as well?
What happens to x86 systems that generally do not use open firmware or device tree. Do they still work? Which kind of devices need the calibration data anyway? All of them? Just the ones without EEPROM?
You need to pretty much verbose in your commit message on what is going on. And I get the feeling that you have to handle the case where CONFIG_OF is not selected.
Regards
Marcel
^ permalink raw reply
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Janusz Dziedzic @ 2013-11-01 20:27 UTC (permalink / raw)
To: Fabio Rossi
Cc: marcel, linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <607082335.2055771383319324985.JavaMail.defaultUser@defaultHost>
2013/11/1 Fabio Rossi <rossi.f@inwind.it>:
>>what socket option is your client program setting? Do you happen to know that.
> Would make it a lot easier to track this down.
>
> Hi Marcel,
> I'm using the bluetoothd daemon at startup and it crashes as soon as the
> dongle is inserted. To test the behaviour I removed the dongle and restart the
> daemon with
>
> # bluetoothd -n -d
>
> bluetoothd[4450]: Bluetooth daemon 4.101
> bluetoothd[4450]: src/main.c:parse_config() parsing main.conf
> bluetoothd[4450]: src/main.c:parse_config() discovto=0
> bluetoothd[4450]: src/main.c:parse_config() pairto=0
> bluetoothd[4450]: src/main.c:parse_config() pageto=8192
> bluetoothd[4450]: src/main.c:parse_config() auto_to=60
> bluetoothd[4450]: src/main.c:parse_config() name=%h-%d
> bluetoothd[4450]: src/main.c:parse_config() class=0x000100
> bluetoothd[4450]: src/main.c:parse_config() Key file does not have key
> 'DeviceID'
> bluetoothd[4450]: Starting SDP server
> bluetoothd[4450]: src/plugin.c:plugin_init() Loading builtin plugins
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading pnat plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading audio plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading input plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading serial plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading network plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading service plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading health plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading hciops plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading mgmtops plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading formfactor plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading storage plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading adaptername plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading wiimote plugin
> bluetoothd[4450]: src/plugin.c:add_plugin() Loading maemo6 plugin
> bluetoothd[4450]: src/plugin.c:plugin_init() Loading plugins
> /usr/lib64/bluetooth/plugins
> bluetoothd[4450]: plugins/service.c:register_interface() path
> /org/bluez/4450/any
> bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
> org.bluez.Service on path /org/bluez/4450/any
> bluetoothd[4450]: plugins/maemo6.c:maemo6_init() init maemo6 plugin
> bluetoothd[4450]: health/hdp.c:hdp_manager_start() Starting Health manager
> bluetoothd[4450]: network/manager.c:read_config() /etc/bluetooth/network.conf:
> Key file does not have key 'DisableSecurity'
> bluetoothd[4450]: network/manager.c:read_config() Config options:
> Security=true
> bluetoothd[4450]: input/manager.c:input_manager_init() input.conf: Key file
> does not have key 'IdleTimeout'
> bluetoothd[4450]: audio/manager.c:audio_manager_init() audio.conf: Key file
> does not have key 'AutoConnect'
> bluetoothd[4450]: plugins/pnat.c:pnat_init() Setup Phonet AT (DUN) plugin
> bluetoothd[4450]: plugins/hciops.c:hciops_init()
> bluetoothd[4450]: Bluetooth Management interface initialized
> bluetoothd[4450]: Failed to open RFKILL control device
> bluetoothd[4450]: src/main.c:main() Entering main loop
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 12 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
> bluetoothd[4450]: plugins/mgmtops.c:read_version_complete() version 1 revision
> 4
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 11 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
>
> then I insert the dongle
>
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 6 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:add_controller() Added controller 0
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 289 bytes from
> management socket
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
> XX:XX version 3 manufacturer 10 class 0x000000
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 settings
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 name CSR - bc4
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 short name
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_remove_uuid() index 0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=1
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_read_bdaddr() index 0 addr 00:09:DD:
> XX:XX:XX
> bluetoothd[4450]: src/sdpd-database.c:sdp_init_services_list()
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
> bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
> bluetoothd[4450]: plugins/service.c:register_interface() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
> org.bluez.Service on path /org/bluez/4450/hci0
> bluetoothd[4450]: plugins/maemo6.c:mce_probe() path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=2
> bluetoothd[4450]: network/manager.c:network_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=3
> bluetoothd[4450]: network/server.c:server_register() Registered interface org.
> bluez.NetworkServer on path /org/bluez/4450/hci0
> bluetoothd[4450]: serial/manager.c:proxy_probe() path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=4
> bluetoothd[4450]: serial/proxy.c:proxy_register() Registered interface org.
> bluez.SerialProxyManager on path /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=5
> bluetoothd[4450]: audio/manager.c:media_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=6
> bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=1
> bluetoothd[4450]: audio/manager.c:headset_server_probe() path
> /org/bluez/4450/hci0
> bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=2
> bluetoothd[4450]: audio/manager.c:headset_server_init() audio.conf: Key file
> does not have key 'Master'
> Killed
>
> and I get the crash previously reported. If I use a working kernel the
> bluetooth daemon continues its startup and the next lines are
>
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Adding record with
> handle 0x10000
> bluetoothd[2322]: plugins/mgmtops.c:mgmt_add_uuid() index
> 0
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00000003-0000-1000-8000-00805f9
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00000100-0000-1000-8000-00805f9
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00001002-0000-1000-8000-00805f9
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00001108-0000-1000-8000-00805f9
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00001112-0000-1000-8000-00805f9
> bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
> UUID 00001203-0000-1000-8000-00805f9
> ... [ omitted ] ...
>
> Furthermore, comparing bluetoothd logs (working vs not working kernel) I have
> noticed the following difference:
>
> bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
> XX:XX version 3 manufacturer 10 class 0x000000
> bluetoothd[2322]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
> XX:XX version 3 manufacturer 10 class 0x5a0100
>
> so it seems the class is not properly initialized.
>
> The kernel is configured with
>
> CONFIG_BT=y
> CONFIG_BT_RFCOMM=y
> CONFIG_BT_RFCOMM_TTY=y
> CONFIG_BT_BNEP=y
> CONFIG_BT_HIDP=y
> CONFIG_BT_HCIBTUSB=y
> CONFIG_BT_HCIUART=y
>
> Let me know if I can help providing more info.
>
I see the same problem and same dump during laptop startup (Ubuntu 12.04 LTS).
As a workaround I had to disable BT in bios (Dell E4300) and remove
ar3k firmware (have two BT devices).
BR
Janusz
^ permalink raw reply
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Fabio Rossi @ 2013-11-01 15:22 UTC (permalink / raw)
To: marcel
Cc: linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
>what socket option is your client program setting? Do you happen to know that.
Would make it a lot easier to track this down.
Hi Marcel,
I'm using the bluetoothd daemon at startup and it crashes as soon as the
dongle is inserted. To test the behaviour I removed the dongle and restart the
daemon with
# bluetoothd -n -d
bluetoothd[4450]: Bluetooth daemon 4.101
bluetoothd[4450]: src/main.c:parse_config() parsing main.conf
bluetoothd[4450]: src/main.c:parse_config() discovto=0
bluetoothd[4450]: src/main.c:parse_config() pairto=0
bluetoothd[4450]: src/main.c:parse_config() pageto=8192
bluetoothd[4450]: src/main.c:parse_config() auto_to=60
bluetoothd[4450]: src/main.c:parse_config() name=%h-%d
bluetoothd[4450]: src/main.c:parse_config() class=0x000100
bluetoothd[4450]: src/main.c:parse_config() Key file does not have key
'DeviceID'
bluetoothd[4450]: Starting SDP server
bluetoothd[4450]: src/plugin.c:plugin_init() Loading builtin plugins
bluetoothd[4450]: src/plugin.c:add_plugin() Loading pnat plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading audio plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading input plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading serial plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading network plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading service plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading health plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading hciops plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading mgmtops plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading formfactor plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading storage plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading adaptername plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading wiimote plugin
bluetoothd[4450]: src/plugin.c:add_plugin() Loading maemo6 plugin
bluetoothd[4450]: src/plugin.c:plugin_init() Loading plugins
/usr/lib64/bluetooth/plugins
bluetoothd[4450]: plugins/service.c:register_interface() path
/org/bluez/4450/any
bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
org.bluez.Service on path /org/bluez/4450/any
bluetoothd[4450]: plugins/maemo6.c:maemo6_init() init maemo6 plugin
bluetoothd[4450]: health/hdp.c:hdp_manager_start() Starting Health manager
bluetoothd[4450]: network/manager.c:read_config() /etc/bluetooth/network.conf:
Key file does not have key 'DisableSecurity'
bluetoothd[4450]: network/manager.c:read_config() Config options:
Security=true
bluetoothd[4450]: input/manager.c:input_manager_init() input.conf: Key file
does not have key 'IdleTimeout'
bluetoothd[4450]: audio/manager.c:audio_manager_init() audio.conf: Key file
does not have key 'AutoConnect'
bluetoothd[4450]: plugins/pnat.c:pnat_init() Setup Phonet AT (DUN) plugin
bluetoothd[4450]: plugins/hciops.c:hciops_init()
bluetoothd[4450]: Bluetooth Management interface initialized
bluetoothd[4450]: Failed to open RFKILL control device
bluetoothd[4450]: src/main.c:main() Entering main loop
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 12 bytes from
management socket
bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
bluetoothd[4450]: plugins/mgmtops.c:read_version_complete() version 1 revision
4
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 11 bytes from
management socket
bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
then I insert the dongle
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 6 bytes from
management socket
bluetoothd[4450]: plugins/mgmtops.c:add_controller() Added controller 0
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[4450]: plugins/mgmtops.c:mgmt_event() Received 289 bytes from
management socket
bluetoothd[4450]: plugins/mgmtops.c:mgmt_cmd_complete()
bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
XX:XX version 3 manufacturer 10 class 0x000000
bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 settings
bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 name CSR - bc4
bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 short name
bluetoothd[4450]: plugins/mgmtops.c:mgmt_remove_uuid() index 0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=1
bluetoothd[4450]: plugins/mgmtops.c:mgmt_read_bdaddr() index 0 addr 00:09:DD:
XX:XX:XX
bluetoothd[4450]: src/sdpd-database.c:sdp_init_services_list()
bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
bluetoothd[4450]: plugins/mgmtops.c:mgmt_add_uuid() index 0
bluetoothd[4450]: plugins/service.c:register_interface() path
/org/bluez/4450/hci0
bluetoothd[4450]: plugins/service.c:register_interface() Registered interface
org.bluez.Service on path /org/bluez/4450/hci0
bluetoothd[4450]: plugins/maemo6.c:mce_probe() path /org/bluez/4450/hci0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=2
bluetoothd[4450]: network/manager.c:network_server_probe() path
/org/bluez/4450/hci0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=3
bluetoothd[4450]: network/server.c:server_register() Registered interface org.
bluez.NetworkServer on path /org/bluez/4450/hci0
bluetoothd[4450]: serial/manager.c:proxy_probe() path /org/bluez/4450/hci0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=4
bluetoothd[4450]: serial/proxy.c:proxy_register() Registered interface org.
bluez.SerialProxyManager on path /org/bluez/4450/hci0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=5
bluetoothd[4450]: audio/manager.c:media_server_probe() path
/org/bluez/4450/hci0
bluetoothd[4450]: src/adapter.c:btd_adapter_ref() 0x7f6c1794a800: ref=6
bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=1
bluetoothd[4450]: audio/manager.c:headset_server_probe() path
/org/bluez/4450/hci0
bluetoothd[4450]: audio/manager.c:audio_adapter_ref() 0x7f6c1794b2b0: ref=2
bluetoothd[4450]: audio/manager.c:headset_server_init() audio.conf: Key file
does not have key 'Master'
Killed
and I get the crash previously reported. If I use a working kernel the
bluetooth daemon continues its startup and the next lines are
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Adding record with
handle 0x10000
bluetoothd[2322]: plugins/mgmtops.c:mgmt_add_uuid() index
0
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00000003-0000-1000-8000-00805f9
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00000100-0000-1000-8000-00805f9
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00001002-0000-1000-8000-00805f9
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00001108-0000-1000-8000-00805f9
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00001112-0000-1000-8000-00805f9
bluetoothd[2322]: src/sdpd-service.c:add_record_to_server() Record pattern
UUID 00001203-0000-1000-8000-00805f9
... [ omitted ] ...
Furthermore, comparing bluetoothd logs (working vs not working kernel) I have
noticed the following difference:
bluetoothd[4450]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
XX:XX version 3 manufacturer 10 class 0x000000
bluetoothd[2322]: plugins/mgmtops.c:read_info_complete() hci0 addr 00:09:DD:XX:
XX:XX version 3 manufacturer 10 class 0x5a0100
so it seems the class is not properly initialized.
The kernel is configured with
CONFIG_BT=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=y
CONFIG_BT_HIDP=y
CONFIG_BT_HCIBTUSB=y
CONFIG_BT_HCIUART=y
Let me know if I can help providing more info.
Best regards,
Fabio
^ permalink raw reply
* [PATCHv5 7/7] android/daemon: Add logs to trace failed cmd
From: Andrei Emeltchenko @ 2013-11-01 15:19 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1383319159-13060-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
android/adapter.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/android/adapter.c b/android/adapter.c
index 0797aa0..5552517 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -1572,6 +1572,8 @@ void bt_adapter_handle_cmd(GIOChannel *io, uint8_t opcode, void *buf,
return;
error:
+ DBG("Error handling command 0x%x status %u", opcode, status);
+
ipc_send_rsp(io, HAL_SERVICE_ID_BLUETOOTH, status);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCHv5 6/7] android: Use thread-safe helpers
From: Andrei Emeltchenko @ 2013-11-01 15:19 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1383319159-13060-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Make use of thread-safe helpers.
---
android/client/textconv.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/android/client/textconv.c b/android/client/textconv.c
index 18f60ee..8e6bdb9 100644
--- a/android/client/textconv.c
+++ b/android/client/textconv.c
@@ -19,6 +19,8 @@
#include <stdio.h>
#include <hardware/bluetooth.h>
+#include "../pthread-local.h"
+
#include "textconv.h"
/*
@@ -227,11 +229,12 @@ const char *enum_one_string(void *v, int i)
return (i == 0) && (m[0] != 0) ? m : NULL;
}
+GLOBAL_INIT_THREAD_LOCAL_BUFFER(bdaddr);
char *bdaddr2str(const bt_bdaddr_t *bd_addr)
{
- static char buf[MAX_ADDR_STR_LEN];
+ LOCAL_INIT_THREAD_LOCAL_BUFFER(char*, bdaddr, MAX_ADDR_STR_LEN);
- return bt_bdaddr_t2str(bd_addr, buf);
+ return bt_bdaddr_t2str(bd_addr, bdaddr_tls_buffer);
}
static char *btuuid2str(const bt_uuid_t *uuid)
@@ -241,12 +244,14 @@ static char *btuuid2str(const bt_uuid_t *uuid)
return bt_uuid_t2str(uuid, buf);
}
+GLOBAL_INIT_THREAD_LOCAL_BUFFER(property);
char *btproperty2str(const bt_property_t *property)
{
- static char buf[4096];
char *p;
+ LOCAL_INIT_THREAD_LOCAL_BUFFER(char*, property, 4096);
- p = buf + sprintf(buf, "type=%s len=%d val=",
+ p = property_tls_buffer + sprintf(property_tls_buffer,
+ "type=%s len=%d val=",
bt_property_type_t2str(property->type),
property->len);
@@ -333,5 +338,5 @@ char *btproperty2str(const bt_property_t *property)
sprintf(p, "%p", property->val);
}
- return buf;
+ return property_tls_buffer;
}
--
1.7.10.4
^ permalink raw reply related
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