* [PATCH 2/4] Bluetooth: Fix remote and local txWindow roles on L2CAP
From: Gustavo F. Padovan @ 2010-03-16 0:26 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo
In-Reply-To: <1268699189-2910-1-git-send-email-gustavo@padovan.org>
L2CAP was misusing the values of txWindow. Now the remote txWindow is used
on the acknowledgement of I-frames and the local txWindow on the sending
of I-frames. It also renames pi->num_to_ack to a better name:
pi->num_acked.
Signed-off-by: Gustavo F. Padovan <gustavo@padovan.org>
---
include/net/bluetooth/l2cap.h | 5 ++---
net/bluetooth/l2cap.c | 9 +++++----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index c7bf676..f1eca05 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -30,7 +30,6 @@
#define L2CAP_DEFAULT_MIN_MTU 48
#define L2CAP_DEFAULT_FLUSH_TO 0xffff
#define L2CAP_DEFAULT_TX_WINDOW 63
-#define L2CAP_DEFAULT_NUM_TO_ACK (L2CAP_DEFAULT_TX_WINDOW/5)
#define L2CAP_DEFAULT_MAX_TX 3
#define L2CAP_DEFAULT_RETRANS_TO 1000 /* 1 second */
#define L2CAP_DEFAULT_MONITOR_TO 12000 /* 12 seconds */
@@ -333,7 +332,7 @@ struct l2cap_pinfo {
__u8 frames_sent;
__u8 unacked_frames;
__u8 retry_count;
- __u8 num_to_ack;
+ __u8 num_acked;
__u16 sdu_len;
__u16 partial_sdu_len;
struct sk_buff *sdu;
@@ -399,7 +398,7 @@ static inline int l2cap_tx_window_full(struct sock *sk)
if (sub < 0)
sub += 64;
- return (sub == pi->remote_tx_win);
+ return (sub == pi->tx_win);
}
#define __get_txseq(ctrl) ((ctrl) & L2CAP_CTRL_TXSEQ) >> 1
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 6679418..85ec8b2 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2248,7 +2248,7 @@ static inline void l2cap_ertm_init(struct sock *sk)
l2cap_pi(sk)->expected_ack_seq = 0;
l2cap_pi(sk)->unacked_frames = 0;
l2cap_pi(sk)->buffer_seq = 0;
- l2cap_pi(sk)->num_to_ack = 0;
+ l2cap_pi(sk)->num_acked = 0;
l2cap_pi(sk)->frames_sent = 0;
setup_timer(&l2cap_pi(sk)->retrans_timer,
@@ -2571,7 +2571,7 @@ static int l2cap_parse_conf_rsp(struct sock *sk, void *rsp, int len, void *data,
if (*result == L2CAP_CONF_SUCCESS) {
switch (rfc.mode) {
case L2CAP_MODE_ERTM:
- pi->remote_tx_win = rfc.txwin_size;
+ pi->tx_win = rfc.txwin_size;
pi->retrans_timeout = rfc.retrans_timeout;
pi->monitor_timeout = rfc.monitor_timeout;
pi->max_pdu_size = le16_to_cpu(rfc.max_pdu_size);
@@ -3408,6 +3408,7 @@ static inline int l2cap_data_channel_iframe(struct sock *sk, u16 rx_control, str
u8 tx_seq = __get_txseq(rx_control);
u8 req_seq = __get_reqseq(rx_control);
u8 sar = rx_control >> L2CAP_CTRL_SAR_SHIFT;
+ int num_to_ack = (pi->remote_tx_win/5) + 1;
int err = 0;
BT_DBG("sk %p rx_control 0x%4.4x len %d", sk, rx_control, skb->len);
@@ -3501,8 +3502,8 @@ expected:
__mod_ack_timer();
- pi->num_to_ack = (pi->num_to_ack + 1) % L2CAP_DEFAULT_NUM_TO_ACK;
- if (pi->num_to_ack == L2CAP_DEFAULT_NUM_TO_ACK - 1)
+ pi->num_acked = (pi->num_acked + 1) % num_to_ack;
+ if (pi->num_acked == num_to_ack - 1)
l2cap_send_ack(pi);
return 0;
--
1.6.4.4
^ permalink raw reply related
* [PATCH 1/4] Bluetooth: Add sockopt configuration for txWindow on L2CAP
From: Gustavo F. Padovan @ 2010-03-16 0:26 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo
Now can set/get Transmission Window size via sockopt.
Signed-off-by: Gustavo F. Padovan <gustavo@padovan.org>
---
include/net/bluetooth/l2cap.h | 2 ++
net/bluetooth/l2cap.c | 7 ++++++-
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 48f10f4..c7bf676 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -56,6 +56,7 @@ struct l2cap_options {
__u16 flush_to;
__u8 mode;
__u8 fcs;
+ __u8 txwin_size;
};
#define L2CAP_CONNINFO 0x02
@@ -339,6 +340,7 @@ struct l2cap_pinfo {
__u8 ident;
+ __u8 tx_win;
__u8 remote_tx_win;
__u8 remote_max_tx;
__u16 retrans_timeout;
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 930f987..6679418 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -780,6 +780,7 @@ static void l2cap_sock_init(struct sock *sk, struct sock *parent)
pi->omtu = l2cap_pi(parent)->omtu;
pi->mode = l2cap_pi(parent)->mode;
pi->fcs = l2cap_pi(parent)->fcs;
+ pi->tx_win = l2cap_pi(parent)->tx_win;
pi->sec_level = l2cap_pi(parent)->sec_level;
pi->role_switch = l2cap_pi(parent)->role_switch;
pi->force_reliable = l2cap_pi(parent)->force_reliable;
@@ -788,6 +789,7 @@ static void l2cap_sock_init(struct sock *sk, struct sock *parent)
pi->omtu = 0;
pi->mode = L2CAP_MODE_BASIC;
pi->fcs = L2CAP_FCS_CRC16;
+ pi->tx_win = L2CAP_DEFAULT_TX_WINDOW;
pi->sec_level = BT_SECURITY_LOW;
pi->role_switch = 0;
pi->force_reliable = 0;
@@ -1776,6 +1778,7 @@ static int l2cap_sock_setsockopt_old(struct socket *sock, int optname, char __us
opts.flush_to = l2cap_pi(sk)->flush_to;
opts.mode = l2cap_pi(sk)->mode;
opts.fcs = l2cap_pi(sk)->fcs;
+ opts.txwin_size = l2cap_pi(sk)->tx_win;
len = min_t(unsigned int, sizeof(opts), optlen);
if (copy_from_user((char *) &opts, optval, len)) {
@@ -1787,6 +1790,7 @@ static int l2cap_sock_setsockopt_old(struct socket *sock, int optname, char __us
l2cap_pi(sk)->omtu = opts.omtu;
l2cap_pi(sk)->mode = opts.mode;
l2cap_pi(sk)->fcs = opts.fcs;
+ l2cap_pi(sk)->tx_win = opts.txwin_size;
break;
case L2CAP_LM:
@@ -1901,6 +1905,7 @@ static int l2cap_sock_getsockopt_old(struct socket *sock, int optname, char __us
opts.flush_to = l2cap_pi(sk)->flush_to;
opts.mode = l2cap_pi(sk)->mode;
opts.fcs = l2cap_pi(sk)->fcs;
+ opts.txwin_size = l2cap_pi(sk)->tx_win;
len = min_t(unsigned int, len, sizeof(opts));
if (copy_to_user(optval, (char *) &opts, len))
@@ -2318,7 +2323,7 @@ done:
case L2CAP_MODE_ERTM:
rfc.mode = L2CAP_MODE_ERTM;
- rfc.txwin_size = L2CAP_DEFAULT_TX_WINDOW;
+ rfc.txwin_size = pi->tx_win;
rfc.max_transmit = max_transmit;
rfc.retrans_timeout = 0;
rfc.monitor_timeout = 0;
--
1.6.4.4
^ permalink raw reply related
* RE: A strange compatible problem for eSCO audio with CSR USB Bluetooth dongle
From: Cooper Xu @ 2010-03-15 22:24 UTC (permalink / raw)
To: 'Nick Pelly'; +Cc: linux-bluetooth
In-Reply-To: <35c90d961003151435i6dc2a096j300198decb4844e6@mail.gmail.com>
Thanks, I will try it.
The strange thing is the eSCO audio worked ok with Blackberry curve 8310,
which seems to use the same CSR BlueCore4 chipset and firmware version
0xc5c. I assume the library of Blackberry is not Bluez.
But when I use a PC with CSR BlueCore4 dongle with USB interface and Bluez
library as the remote for testing, from the captured eSCO stream, I can not
see any real data I sent, I got all zero.
However If I changed the USB dongle to Broadcom chipset, I can see a few
real data from captured eSCO stream (not all of data I sent, some seemed
lost or being replaced by zero).
-----Original Message-----
From: Nick Pelly [mailto:npelly@google.com]
Sent: Monday, March 15, 2010 5:35 PM
To: Cooper Xu
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: A strange compatible problem for eSCO audio with CSR USB
Bluetooth dongle
I wonder if this is some eSCO packet type incompatibility between
chipsets. Try setting /sys/module/sco/parameters/disable_esco to 1 to
see if this resolves the issue.
Nick
^ permalink raw reply
* Re: [PATCH] Expose wacom pen tablet battery and ac thru power_supply class
From: Przemo Firszt @ 2010-03-15 22:00 UTC (permalink / raw)
To: Jiri Kosina
Cc: Bastien Nocera, linux-bluetooth, marcel, Peter Hutterer, Ping,
Peter Huewe
In-Reply-To: <alpine.LNX.2.00.1003151454110.18642@pobox.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
Dnia 2010-03-15, pon o godzinie 14:54 +0100, Jiri Kosina pisze:
> On Wed, 10 Mar 2010, Przemo Firszt wrote:
[..]
> > Does it make sense to add a line to Kconfig to explain that
> > CONFIG_POWER_SUPPLY/CONFIG_POWER_SUPPLY_MODULE is required to enable
> > monitoring battery/ac state?
>
> Either that, or introducing separate CONFIG sub-option for the Wacom
> driver might be reasonable option as well.
Hi Jiri,
Thanks for help - next time I'll know how to do it :-)
I went the CONFIG sub-option way - see attached.
thanks,
Przemo
[-- Attachment #2: 0001-Expose-wacom-pen-tablet-battery-and-ac-thru-power_su.patch --]
[-- Type: text/x-patch, Size: 5608 bytes --]
>From d6ec58bc114bdf0dd01bc0407f5f7bbb8161e45e Mon Sep 17 00:00:00 2001
From: Przemo Firszt <przemo@firszt.eu>
Date: Mon, 15 Mar 2010 19:16:23 +0000
Subject: [PATCH] Expose wacom pen tablet battery and ac thru power_supply class
This patch exposes wacom pen tablet battery capacity and ac state thru
power_supply class is sysfs.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
---
drivers/hid/Kconfig | 8 +++
drivers/hid/hid-wacom.c | 127 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 135 insertions(+), 0 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 71d4c07..8e1b505 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -357,6 +357,14 @@ config HID_WACOM
---help---
Support for Wacom Graphire Bluetooth tablet.
+config HID_WACOM_POWER_SUPPLY
+ bool "Wacom Bluetooth devices power supply status support"
+ depends on HID_WACOM
+ select POWER_SUPPLY
+ ---help---
+ Say Y here if you want to enable power supply status monitoring for
+ Wacom Bluetooth devices.
+
config HID_ZEROPLUS
tristate "Zeroplus based game controller support" if EMBEDDED
depends on USB_HID
diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
index 8d3b46f..4d2d2a2 100644
--- a/drivers/hid/hid-wacom.c
+++ b/drivers/hid/hid-wacom.c
@@ -21,14 +21,88 @@
#include <linux/device.h>
#include <linux/hid.h>
#include <linux/module.h>
+#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
+#include <linux/power_supply.h>
+#endif
#include "hid-ids.h"
struct wacom_data {
__u16 tool;
unsigned char butstate;
+#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
+ int battery_capacity;
+ struct power_supply battery;
+ struct power_supply ac;
+#endif
};
+#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
+/*percent of battery capacity, 0 means AC online*/
+static unsigned short batcap[8] = { 1, 15, 25, 35, 50, 70, 100, 0 };
+
+static enum power_supply_property wacom_battery_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_CAPACITY
+};
+
+static enum power_supply_property wacom_ac_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_ONLINE
+};
+
+static int wacom_battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct wacom_data *wdata = container_of(psy,
+ struct wacom_data, battery);
+ int power_state = batcap[wdata->battery_capacity];
+ int ret = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = 1;
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ /* show 100% battery capacity when charging */
+ if (power_state == 0)
+ val->intval = 100;
+ else
+ val->intval = power_state;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+
+static int wacom_ac_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct wacom_data *wdata = container_of(psy, struct wacom_data, ac);
+ int power_state = batcap[wdata->battery_capacity];
+ int ret = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ /* fall through */
+ case POWER_SUPPLY_PROP_ONLINE:
+ if (power_state == 0)
+ val->intval = 1;
+ else
+ val->intval = 0;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+#endif
+
static int wacom_raw_event(struct hid_device *hdev, struct hid_report *report,
u8 *raw_data, int size)
{
@@ -147,6 +221,12 @@ static int wacom_raw_event(struct hid_device *hdev, struct hid_report *report,
input_sync(input);
}
+#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
+ /* Store current battery capacity */
+ rw = (data[7] >> 2 & 0x07);
+ if (rw != wdata->battery_capacity)
+ wdata->battery_capacity = rw;
+#endif
return 1;
}
@@ -206,6 +286,45 @@ static int wacom_probe(struct hid_device *hdev,
if (ret < 0)
dev_warn(&hdev->dev, "failed to poke device #2, %d\n", ret);
+#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
+ wdata->battery.properties = wacom_battery_props;
+ wdata->battery.num_properties = ARRAY_SIZE(wacom_battery_props);
+ wdata->battery.get_property = wacom_battery_get_property;
+ wdata->battery.name = "wacom_battery";
+ wdata->battery.type = POWER_SUPPLY_TYPE_BATTERY;
+ wdata->battery.use_for_apm = 0;
+
+ ret = power_supply_register(&hdev->dev, &wdata->battery);
+ if (ret) {
+ dev_warn(&hdev->dev,
+ "can't create sysfs battery attribute, err: %d\n", ret);
+ /*
+ * battery attribute is not critical for the tablet, but if it
+ * failed then there is no need to create ac attribute
+ */
+ goto move_on;
+ }
+
+ wdata->ac.properties = wacom_ac_props;
+ wdata->ac.num_properties = ARRAY_SIZE(wacom_ac_props);
+ wdata->ac.get_property = wacom_ac_get_property;
+ wdata->ac.name = "wacom_ac";
+ wdata->ac.type = POWER_SUPPLY_TYPE_MAINS;
+ wdata->ac.use_for_apm = 0;
+
+ ret = power_supply_register(&hdev->dev, &wdata->ac);
+ if (ret) {
+ dev_warn(&hdev->dev,
+ "can't create ac battery attribute, err: %d\n", ret);
+ /*
+ * ac attribute is not critical for the tablet, but if it
+ * failed then we don't want to battery attribute to exist
+ */
+ power_supply_unregister(&wdata->battery);
+ }
+
+move_on:
+#endif
hidinput = list_entry(hdev->inputs.next, struct hid_input, list);
input = hidinput->input;
@@ -250,7 +369,15 @@ err_free:
static void wacom_remove(struct hid_device *hdev)
{
+#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
+ struct wacom_data *wdata = hid_get_drvdata(hdev);
+#endif
hid_hw_stop(hdev);
+
+#ifdef CONFIG_HID_WACOM_POWER_SUPPLY
+ power_supply_unregister(&wdata->battery);
+ power_supply_unregister(&wdata->ac);
+#endif
kfree(hid_get_drvdata(hdev));
}
--
1.7.0.1
^ permalink raw reply related
* Re: A strange compatible problem for eSCO audio with CSR USB Bluetooth dongle
From: Nick Pelly @ 2010-03-15 21:35 UTC (permalink / raw)
To: Cooper Xu; +Cc: linux-bluetooth
In-Reply-To: <1660E2CC4AF24655A1FFE788570A34FF@mapleworks.com>
On Sun, Mar 14, 2010 at 4:01 PM, Cooper Xu <cooper.xu@mapleworks.com> wrote:
> Hi,
>
>
> We have a strange compatible problem with Bluez for eSCO audio.
>
> We develope an embedded application based on Bluez library that can play the
> role of HF and it uses a generic CSR USB Bluetooth dongle. The application
> worked well for most cell phones (iPhone, Blackberry etc). But when we tried
> it with an Android phone (Motorola Droid), we found one way voice problem.
> The Android phone side can not hear the voice.
>
> We know that Android phone also uses the Bluez library. So we tried to pair
> our application with another Linux with Bluez library with another CSR USB
> Bluetooth dongle. We used "hcidump" to capture the SCO packets in that
> system. We received a lot of SCO packets, but the content of packets is all
> zero. However from another end of SCO connection, we actually sent a lot
> non-zero contents.
>
> To simply our debug, we then used the "scotest" program from the Bluez 4.65
> source and used one system as client and another as server. From the hcidump
> output, we still saw the content of packets is all zero. However when we
> changed one USB dongle to another USB dongle with the Broadcom chipset, we
> can receive some non-zero data. In both case, we didn't see Bluez kernel
> error message.
>
> The Linux kernel for the system we used for test is 2.6.30. The attachment
> is the SCO packet we captured for receiving side. The following is the
> information of Bluetooth USB dongle we use:
>
>
> hciconfig -a
>
> hci0: Type: USB
>
> BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
> UP RUNNING PSCAN AUTH ENCRYPT
> RX bytes:2081370 acl:185 sco:17775 events:9695 errors:0
> TX bytes:252089 acl:164 sco:3002 commands:4693 errors:0
> Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: RSWITCH HOLD SNIFF PARK
> Link mode: SLAVE ACCEPT
> Name: 'test'
> Class: 0x000408
> Service Classes: Unspecified
> Device Class: Audio/Video, Hands-free
> HCI Ver: 2.0 (0x3) HCI Rev: 0xc5c LMP Ver: 2.0 (0x3) LMP Subver:
> 0xc5c
> Manufacturer: Cambridge Silicon Radio (10)
>
>
>
> hciconfig hci0 revision:
>
> hci0: Type: USB
>
> BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
> Unified 21e
> Chip version: BlueCore4-ROM
> Max key size: 128 bit
> SCO mapping: HCI
>
>
> This audio problem seems only happen if both ends use Bluez library. If one
> side uses a different Bluetooth library, this issue will not appear. What
> can be the cause of this? I am very confused.
I wonder if this is some eSCO packet type incompatibility between
chipsets. Try setting /sys/module/sco/parameters/disable_esco to 1 to
see if this resolves the issue.
Nick
^ permalink raw reply
* RE: [bluetooth-next V2] Bluetooth: handle device reset event
From: Marcel Holtmann @ 2010-03-15 19:57 UTC (permalink / raw)
To: Winkler, Tomas
Cc: linux-bluetooth@vger.kernel.org, Cohen, Guy, Rindjunsky, Ron,
Paskar, Gregory
In-Reply-To: <6F5C1D715B2DA5498A628E6B9C124F04016C15DFA3@hasmsx504.ger.corp.intel.com>
Hi Tomas,
> > > > > A Bluetooth device experiencing hardware failure may issue
> > > > > a HARDWARE_ERROR hci event. The reaction to this event is device
> > > > > reset flow implemented in following sequence.
> > > > >
> > > > > 1. Notify: HCI_DEV_DOWN
> > > > > 2. Reinitialize internal structures.
> > > > > 3. Call driver flush function
> > > > > 4. Send HCI reset request to the device.
> > > > > 5. Send HCI init sequence reset to the device.
> > > > > 6. Notify HCI_DEV_UP.
> > > >
> > > > I prefer if we create a generic per controller workqueue first before
> > > > having a workqueue for every task. Something similar to what the
> > > > mac80211 layer offers right now.
> > >
> > > That would be good approach but we are using default kernel workqueue in
> > this solution so there is no workqueue for every task.
> > > I'm not sure if this effort should block this patch.
> >
> > I have an initial patch that I have to dig out. It is actually not that
> > complicated. And I would prefer to get that one first before we apply
> > this patch.
>
> Okay, I can test this particular flow with your patch if you send it to me.
I pushed the per controller workqueue patch into bluetooth-testing.git
tree. Please adapt your patch to that and test it.
> > The reason why I really wanna solve this is because of potential race
> > conditions between the workqueue and a device removal. I have a bad
> > feeling that even with the current sysfs workqueue we have a race
> > condition hiding somewhere. So if going forward we have to shift more
> > and more code into workqueues we need a single point where this can be
> > fixed.
>
> Understood.
>
> In that context I would need to do some more instrumentation to test this kind of race for this feature.
I could be very well that we are protected against such a race. However
with moving from tasklet into workqueue I am always cautious. And I
wanna make sure that we keep the complexity simple. I want one place to
fix if it breaks and not twenty.
Regards
Marcel
^ permalink raw reply
* BlueZ module for the Enlightenment WM
From: Gustavo F. Padovan @ 2010-03-15 19:48 UTC (permalink / raw)
To: linux-bluetooth
Hi Folks,
I'm proud to announce that the Enlightenment Window Manager now has a module
to manage Bluetooth stuff. I did it during the last month here at
ProFUSION. It is still very simple, now it supports only Scan and Pairing of
devices and the set/get of some adapter's properties.
There is a blog post about it: http://padovan.org/blog/2010/03/bluez-module-for-enlightenment/
Regards,
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: Kernel panic when handing Motorola S305 headset
From: jaikumar Ganesh @ 2010-03-15 17:27 UTC (permalink / raw)
To: Liang Bao, Marcel Holtmann, padovan; +Cc: linux-bluetooth
In-Reply-To: <6aeb672b1003010154u6660632fj53fdbac2c8d0e302@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2440 bytes --]
Hi Marcel / Gustavo:
On Mon, Mar 1, 2010 at 2:54 AM, Liang Bao <tim.bao@gmail.com> wrote:
> I'd like to continue the previous thread on that Motorola S305 causes
> kernel panic because I did find some clue here. Sorry for misleading
> guess one month ago if any.
>
> Recap the problem here so that you don't to read the first long post.
> The pattern to reproduce the issue is:
> 1. Pair the S305 headset from the phone or the PC( I am using a Ubuntu)
> 2. Remove pairing on the phone or PC
> 3. Power off and then power on S305.
> 4. The S305 will try to connect and since link key removed on this
> side it will try to pair. Input 0000.
> 5. Kernel panic happens. This can be observed on kernel version
> 2.6.29(on the Droid phone, yes, it's a modified version),
> 2.6.31-19-generic on a Ubuntu and a pretty latest 2.6.33-020633rc8
> from Ubuntu official RC release.
>
> The exact kernel crash point is
> if (l2cap_check_security(sk)) {
> if (bt_sk(sk)->defer_setup) {
> struct sock *parent = bt_sk(sk)->parent;
> rsp.result = cpu_to_le16(L2CAP_CR_PEND);
> rsp.status = cpu_to_le16(L2CAP_CS_AUTHOR_PEND);
> >>> parent->sk_data_ready(parent, 0)
> } else {
>
> After tracing the issue for a couple of weeks, I find the difference
> between a normal flow and the panic one. If the user space process
> accepts the L2CAP connection request before L2CAP_INFO_RSP received,
> the following calls will be carried out:
>
> l2cap_sock_accept-> bt_accept_dequeue->bt_accept_unlink(in the branch
> bt_sk(parent)->defer_setup)-> set bt_sk(sk)->parent = NULL. Later when
> L2CAP_INFO_RSP arrives, the l2cap_conn_start() will try to call the
> marked line above and de-referring NULL happen.
>
> To fix this, shall we consider checking if a pending socket can be
> accepted in bt_accept_dequeue() prior to a pending L2CAP_INFO_REQ
> responded? For example, adding a check to BT_CONNECT2 in
> af_bluetooth.c.
>
> 215 if (sk->sk_state == BT_CONNECTED || !newsock ||
> 216 ( bt_sk(parent)->defer_setup &&
> (sk->sk_state != BT_CONNECT2))) {
>
> Again, I am not sure if this will bring a side-effect. Please advise
> the most appropriate way. Thanks.
>
> p.s: I attached partial trace files for those who're interested to the
> traces.
>
Can you ACK or NACK the analysis ?
Thanks
Jaikumar
[-- Attachment #1.2: Type: text/html, Size: 2997 bytes --]
[-- Attachment #2: s305-good-bad-trace.txt --]
[-- Type: text/plain, Size: 1891 bytes --]
Trace when panic happended:
<3>[ 356.758483] l2cap_connect_req: psm 0x19 scid 0x0041
<3>[ 356.763854] l2cap_connect_req: parent c7e8f600
<3>[ 356.768829] __l2cap_chan_add: conn c7fa37c0, psm 0x19, dcid 0x0041
<3>[ 356.775482] l2cap_connect_req: before return, sk c5d66c00 parent c7e8f600
<3>[ 356.782897] l2cap_connect_req: psm 0x01 scid 0x0042
<3>[ 356.788177] l2cap_connect_req: parent c7e8fe00
<3>[ 356.793121] __l2cap_chan_add: conn c7fa37c0, psm 0x01, dcid 0x0042
<3>[ 356.799774] l2cap_connect_req: before return, sk c5d66a00 parent c7e8fe00
<3>[ 356.837158] l2cap_sock_accept: new socket c5d66c00
<3>[ 356.842590] l2cap_conn_start: BT_CONNECTE2, sk c5d66c00, parent (null)
Trace when everything goes on well.
<3>[ 641.393463] l2cap_connect_req: psm 0x19 scid 0x0041
<3>[ 641.398956] l2cap_connect_req: parent c7e91200
<3>[ 641.403778] __l2cap_chan_add: conn c9519440, psm 0x19, dcid 0x0041
<3>[ 641.410461] l2cap_connect_req: before return, sk c97e3a00 parent c7e91200
<3>[ 641.417877] l2cap_connect_req: psm 0x01 scid 0x0042
<3>[ 641.423156] l2cap_connect_req: parent c64b0c00
<3>[ 641.428131] __l2cap_chan_add: conn c9519440, psm 0x01, dcid 0x0042
<3>[ 641.434753] l2cap_connect_req: before return, sk c97e3400 parent c64b0c00
<3>[ 641.476165] l2cap_conn_start: BT_CONNECTE2, sk c97e3a00, parent c7e91200
<3>[ 641.483856] l2cap_sock_accept: new socket c97e3a00
<3>[ 641.551513] l2cap_sock_accept: new socket c97e3400
<3>[ 641.592742] l2cap_sock_shutdown: sock cea7a840, sk c97e3a00, how 2
<3>[ 641.607727] l2cap_sock_shutdown: sock cea7a0c0, sk c97e3400, how 2
<3>[ 644.055419] __l2cap_chan_add: conn c9519440, psm 0x01, dcid 0x0000
<3>[ 650.055816] l2cap_sock_shutdown: sock cea7a0c0, sk c97e3400, how 2
<3>[ 650.063018] l2cap_sock_shutdown: sk-shutdown = true
<3>[ 650.069427] __l2cap_sock_close: sk c97e3400 state 1 socket cea7a0c0 reason 0
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix kernel crash on BT stress tests.
From: Gustavo F. Padovan @ 2010-03-15 15:05 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, marcel
In-Reply-To: <508e92ca1003150357t77defd4fqcd843965af35970a@mail.gmail.com>
* Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com> [2010-03-15 12:57:=
18 +0200]:
> Hi Gustavo
>=20
> On Fri, Mar 12, 2010 at 12:41 AM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
> > Hi Andrei,
> >
> > * Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com> [2010-02-16 12=
:36:47 +0200]:
> >
> >> From 0135f732cb45e5e91062aca84a61a40b172200a4 Mon Sep 17 00:00:00 2001
> >> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> >> Date: Tue, 16 Feb 2010 10:52:33 +0200
> >> Subject: [PATCH] Bluetooth: Fix kernel crash on BT stress tests.
> >>
> >> Added very simple check that req buffer has enough space to
> >> fit configuration parameters. Shall be enough to reject packets
> >> with configuration size more than req buffer.
> >>
> >> Crash trace below
> >>
> >> [ 6069.659393] Unable to handle kernel paging request at virtual
> >> address 02000205
> >> [ 6069.673034] Internal error: Oops: 805 [#1] PREEMPT
> >> ...
> >> [ 6069.727172] PC is at l2cap_add_conf_opt+0x70/0xf0 [l2cap]
> >> [ 6069.732604] LR is at l2cap_recv_frame+0x1350/0x2e78 [l2cap]
> >> ...
> >> [ 6070.030303] Backtrace:
> >> [ 6070.032806] [<bf1c2880>] (l2cap_add_conf_opt+0x0/0xf0 [l2cap]) from
> >> [<bf1c6624>] (l2cap_recv_frame+0x1350/0x2e78 [l2cap])
> >> [ 6070.043823] =A0r8:dc5d3100 r7:df2a91d6 r6:00000001 r5:df2a8000 r4:0=
0000200
> >> [ 6070.050659] [<bf1c52d4>] (l2cap_recv_frame+0x0/0x2e78 [l2cap]) from
> >> [<bf1c8408>] (l2cap_recv_acldata+0x2bc/0x350 [l2cap])
> >> [ 6070.061798] [<bf1c814c>] (l2cap_recv_acldata+0x0/0x350 [l2cap]) from
> >> [<bf0037a4>] (hci_rx_task+0x244/0x478 [bluetooth])
> >> [ 6070.072631] =A0r6:dc647700 r5:00000001 r4:df2ab740
> >> [ 6070.077362] [<bf003560>] (hci_rx_task+0x0/0x478 [bluetooth]) from
> >> [<c006b9fc>] (tasklet_action+0x78/0xd8)
> >> [ 6070.087005] [<c006b984>] (tasklet_action+0x0/0xd8) from [<c006c160>]
> >>
> >> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> >> ---
> >> =A0net/bluetooth/l2cap.c | =A0 =A06 ++++++
> >> =A01 files changed, 6 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> >> index 400efa2..69b7280 100644
> >> --- a/net/bluetooth/l2cap.c
> >> +++ b/net/bluetooth/l2cap.c
> >> @@ -2830,6 +2830,12 @@ static inline int l2cap_config_rsp(struct
> >> l2cap_conn *conn, struct l2cap_cmd_hdr
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int len =3D cmd->len - siz=
eof(*rsp);
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char req[64];
> >>
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (len > sizeof(req) - size=
of(struct l2cap_conf_req)) {
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BT_ERR("Conf=
ig response is too big");
> >
> > Remove the BT_ERR, normally we don't print any error on
> > l2cap_send_disconn_req.
> >
> >
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 l2cap_send_d=
isconn_req(conn, sk);
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto done;
> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> >> +
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* throw out any old store=
d conf requests */
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 result =3D L2CAP_CONF_SUCC=
ESS;
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 len =3D l2cap_parse_conf_r=
sp(sk, rsp->data,
> >
> > Also, this is very rare crash. Even if we add all configure options to
> > req we won't overwrite it. Doesn't make sense to me send a
> > configuration option more than once in the same config_{rsp,req}. The
> > only way to crash l2cap is using a bugous remote stack or a stress test
> > tools. We need to be protected against those bugous stacks so I'll
> > ack your patch after you send the updated patch without the BT_ERR.
> >
>=20
> I am attaching patch to the mail, otherwise it may be screwed up by maile=
rs.
Acked-by: Gustavo F. Padovan <gustavo@padovan.org>
>=20
> Regards,
> Andrei
--=20
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH] Expose wacom pen tablet battery and ac thru power_supply class
From: Jiri Kosina @ 2010-03-15 13:54 UTC (permalink / raw)
To: Przemo Firszt
Cc: Bastien Nocera, linux-bluetooth, marcel, Peter Hutterer, Ping,
Peter Huewe
In-Reply-To: <1268247817.3632.41.camel@pldmachine>
On Wed, 10 Mar 2010, Przemo Firszt wrote:
> > Anyway, you'll have to sort out the new dependency on CONFIG_POWER_SUPPLY
> > somehow (compiling the battery code out from the driver if
> > CONFIG_POWER_SUPPLY is unset, or selecting it directly from Kconfig).
> Thanks for checking the patch.
> See attached updated version - is it OK?
> Does it make sense to add a line to Kconfig to explain that
> CONFIG_POWER_SUPPLY/CONFIG_POWER_SUPPLY_MODULE is required to enable
> monitoring battery/ac state?
Either that, or introducing separate CONFIG sub-option for the Wacom
driver might be reasonable option as well.
Otherwise the patch looks good.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix kernel crash on BT stress tests.
From: Andrei Emeltchenko @ 2010-03-15 10:57 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, marcel
In-Reply-To: <20100311224140.GA17295@vigoh>
[-- Attachment #1: Type: text/plain, Size: 3404 bytes --]
Hi Gustavo
On Fri, Mar 12, 2010 at 12:41 AM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Andrei,
>
> * Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com> [2010-02-16 12:36:47 +0200]:
>
>> From 0135f732cb45e5e91062aca84a61a40b172200a4 Mon Sep 17 00:00:00 2001
>> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>> Date: Tue, 16 Feb 2010 10:52:33 +0200
>> Subject: [PATCH] Bluetooth: Fix kernel crash on BT stress tests.
>>
>> Added very simple check that req buffer has enough space to
>> fit configuration parameters. Shall be enough to reject packets
>> with configuration size more than req buffer.
>>
>> Crash trace below
>>
>> [ 6069.659393] Unable to handle kernel paging request at virtual
>> address 02000205
>> [ 6069.673034] Internal error: Oops: 805 [#1] PREEMPT
>> ...
>> [ 6069.727172] PC is at l2cap_add_conf_opt+0x70/0xf0 [l2cap]
>> [ 6069.732604] LR is at l2cap_recv_frame+0x1350/0x2e78 [l2cap]
>> ...
>> [ 6070.030303] Backtrace:
>> [ 6070.032806] [<bf1c2880>] (l2cap_add_conf_opt+0x0/0xf0 [l2cap]) from
>> [<bf1c6624>] (l2cap_recv_frame+0x1350/0x2e78 [l2cap])
>> [ 6070.043823] r8:dc5d3100 r7:df2a91d6 r6:00000001 r5:df2a8000 r4:00000200
>> [ 6070.050659] [<bf1c52d4>] (l2cap_recv_frame+0x0/0x2e78 [l2cap]) from
>> [<bf1c8408>] (l2cap_recv_acldata+0x2bc/0x350 [l2cap])
>> [ 6070.061798] [<bf1c814c>] (l2cap_recv_acldata+0x0/0x350 [l2cap]) from
>> [<bf0037a4>] (hci_rx_task+0x244/0x478 [bluetooth])
>> [ 6070.072631] r6:dc647700 r5:00000001 r4:df2ab740
>> [ 6070.077362] [<bf003560>] (hci_rx_task+0x0/0x478 [bluetooth]) from
>> [<c006b9fc>] (tasklet_action+0x78/0xd8)
>> [ 6070.087005] [<c006b984>] (tasklet_action+0x0/0xd8) from [<c006c160>]
>>
>> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>> ---
>> net/bluetooth/l2cap.c | 6 ++++++
>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index 400efa2..69b7280 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -2830,6 +2830,12 @@ static inline int l2cap_config_rsp(struct
>> l2cap_conn *conn, struct l2cap_cmd_hdr
>> int len = cmd->len - sizeof(*rsp);
>> char req[64];
>>
>> + if (len > sizeof(req) - sizeof(struct l2cap_conf_req)) {
>> + BT_ERR("Config response is too big");
>
> Remove the BT_ERR, normally we don't print any error on
> l2cap_send_disconn_req.
>
>
>> + l2cap_send_disconn_req(conn, sk);
>> + goto done;
>> + }
>> +
>> /* throw out any old stored conf requests */
>> result = L2CAP_CONF_SUCCESS;
>> len = l2cap_parse_conf_rsp(sk, rsp->data,
>
> Also, this is very rare crash. Even if we add all configure options to
> req we won't overwrite it. Doesn't make sense to me send a
> configuration option more than once in the same config_{rsp,req}. The
> only way to crash l2cap is using a bugous remote stack or a stress test
> tools. We need to be protected against those bugous stacks so I'll
> ack your patch after you send the updated patch without the BT_ERR.
>
I am attaching patch to the mail, otherwise it may be screwed up by mailers.
Regards,
Andrei
[-- Attachment #2: 0001-Bluetooth-Fix-kernel-crash-on-BT-stress-tests.patch --]
[-- Type: text/x-patch, Size: 2127 bytes --]
From af8cab3087cf4d4865ad88fb25d130ebea108db0 Mon Sep 17 00:00:00 2001
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Date: Tue, 16 Feb 2010 10:52:33 +0200
Subject: [PATCH] Bluetooth: Fix kernel crash on BT stress tests.
Added very simple check that req buffer has enough space to
fit configuration parameters. Shall be enough to reject packets
with configuration size more than req buffer.
Crash trace below
[ 6069.659393] Unable to handle kernel paging request at virtual address 02000205
[ 6069.673034] Internal error: Oops: 805 [#1] PREEMPT
...
[ 6069.727172] PC is at l2cap_add_conf_opt+0x70/0xf0 [l2cap]
[ 6069.732604] LR is at l2cap_recv_frame+0x1350/0x2e78 [l2cap]
...
[ 6070.030303] Backtrace:
[ 6070.032806] [<bf1c2880>] (l2cap_add_conf_opt+0x0/0xf0 [l2cap]) from
[<bf1c6624>] (l2cap_recv_frame+0x1350/0x2e78 [l2cap])
[ 6070.043823] r8:dc5d3100 r7:df2a91d6 r6:00000001 r5:df2a8000 r4:00000200
[ 6070.050659] [<bf1c52d4>] (l2cap_recv_frame+0x0/0x2e78 [l2cap]) from
[<bf1c8408>] (l2cap_recv_acldata+0x2bc/0x350 [l2cap])
[ 6070.061798] [<bf1c814c>] (l2cap_recv_acldata+0x0/0x350 [l2cap]) from
[<bf0037a4>] (hci_rx_task+0x244/0x478 [bluetooth])
[ 6070.072631] r6:dc647700 r5:00000001 r4:df2ab740
[ 6070.077362] [<bf003560>] (hci_rx_task+0x0/0x478 [bluetooth]) from
[<c006b9fc>] (tasklet_action+0x78/0xd8)
[ 6070.087005] [<c006b984>] (tasklet_action+0x0/0xd8) from [<c006c160>]
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 930f987..f4258bc 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2897,6 +2897,11 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hdr
int len = cmd->len - sizeof(*rsp);
char req[64];
+ if (len > sizeof(req) - sizeof(struct l2cap_conf_req)) {
+ l2cap_send_disconn_req(conn, sk);
+ goto done;
+ }
+
/* throw out any old stored conf requests */
result = L2CAP_CONF_SUCCESS;
len = l2cap_parse_conf_rsp(sk, rsp->data,
--
1.6.0.4
^ permalink raw reply related
* Re: HCI_MAX_DEV is a bit too small.
From: Iain Hibbert @ 2010-03-15 8:34 UTC (permalink / raw)
To: Peter Dons Tychsen; +Cc: Marcel Holtmann, linux-bluetooth
In-Reply-To: <1268619078.6278.10.camel@donpedro>
On Mon, 15 Mar 2010, Peter Dons Tychsen wrote:
> > So I could be convinced to add new functions to read/write the limit
> > from within an application itself. So that it can be changed without
> > re-compiling the library. Feel free to propose a patch.
>
> I will see what i can do. What is needed is probably a
> hci_set_max_devices() call. Then hcitool could call that with the number
> of devices needed.
A suggestion. I have used this construct in the past for something that
contains a hard coded limit where somebody might want to override it
without rebuilding, and requires no change to the API..
hci.h:
#define HCI_MAX_DEV hci_max_dev()
hci.c:
unsigned int
hci_max_dev(void)
{
static unsigned int max = 0;
char *env, *ep;
unsigned long v;
if (max == 0) {
max = 16;
env = getenv("HCI_MAX_DEV");
if (env == NULL)
break;
errno = 0;
v = strtoul(env, &ep, 0);
if (env[0] == '\0' || *ep != '\0')
break;
if (errno == ERANGE && v == ULONG_MAX)
break;
if (v > UINT_MAX)
break;
max = v;
}
return max;
}
regards,
iain
^ permalink raw reply
* [PATCH] Added support for Atheros AR300x Bluetooth Chip
From: suraj @ 2010-03-15 5:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Luis.Rodriguez, Jothikumar.Mothilal
This protocol implements support for power management feature provided by AR300x chip.
This lets the controller chip go to sleep mode if there is no Bluetooth activity for some time.
It then wakes up the chip in case of a Bluetooth activity.
Signed-off-by: Suraj <suraj@atheros.com>
---
drivers/bluetooth/Kconfig | 11 ++
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/hci_ath.c | 353 +++++++++++++++++++++++++++++++++++++++++
drivers/bluetooth/hci_ldisc.c | 6 +
drivers/bluetooth/hci_uart.h | 8 +-
5 files changed, 378 insertions(+), 1 deletions(-)
create mode 100755 drivers/bluetooth/hci_ath.c
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 058fbcc..81abeff 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -58,6 +58,17 @@ config BT_HCIUART_BCSP
Say Y here to compile support for HCI BCSP protocol.
+config BT_HCIUART_ATH
+ bool "Atheros AR300x Board support"
+ depends on BT_HCIUART
+ help
+ HCIATH (HCI Atheros) is a serial protocol for communication
+ between Bluetooth device and host with support for Atheros AR300x
+ power management feature. This protocol is required for
+ serial Bluetooth devices that are based on Atheros AR300x chips.
+
+ Say Y here to compile support for HCIATH protocol.
+
config BT_HCIUART_LL
bool "HCILL protocol support"
depends on BT_HCIUART
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 7e5aed5..1481faa 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -26,4 +26,5 @@ hci_uart-y := hci_ldisc.o
hci_uart-$(CONFIG_BT_HCIUART_H4) += hci_h4.o
hci_uart-$(CONFIG_BT_HCIUART_BCSP) += hci_bcsp.o
hci_uart-$(CONFIG_BT_HCIUART_LL) += hci_ll.o
+hci_uart-$(CONFIG_BT_HCIUART_ATH) += hci_ath.o
hci_uart-objs := $(hci_uart-y)
diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
new file mode 100755
index 0000000..13e4404
--- /dev/null
+++ b/drivers/bluetooth/hci_ath.c
@@ -0,0 +1,353 @@
+/*
+ * Copyright (c) 2009-2010 Atheros Communications Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/tty.h>
+#include <linux/errno.h>
+#include <linux/ioctl.h>
+#include <linux/skbuff.h>
+
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include "hci_uart.h"
+
+
+/* HCIATH receiver States */
+#define HCIATH_W4_PACKET_TYPE 0
+#define HCIATH_W4_EVENT_HDR 1
+#define HCIATH_W4_ACL_HDR 2
+#define HCIATH_W4_SCO_HDR 3
+#define HCIATH_W4_DATA 4
+
+struct ath_struct {
+ struct hci_uart *hu;
+ unsigned int rx_state;
+ unsigned int rx_count;
+ unsigned int cur_sleep;
+
+ spinlock_t hciath_lock;
+ struct sk_buff *rx_skb;
+ struct sk_buff_head txq;
+ wait_queue_head_t wqevt;
+ struct work_struct ctxtsw;
+};
+
+int ath_wakeup_ar3001(struct tty_struct *tty)
+{
+ struct termios settings;
+ int status = 0x00;
+ mm_segment_t oldfs;
+ status = tty->driver->ops->tiocmget(tty, NULL);
+
+ if ((status & TIOCM_CTS))
+ return status;
+
+ oldfs = get_fs();
+ set_fs(KERNEL_DS);
+ n_tty_ioctl_helper(tty, NULL, TCGETS, (unsigned long)&settings);
+
+ settings.c_cflag &= ~CRTSCTS;
+ n_tty_ioctl_helper(tty, NULL, TCSETS, (unsigned long)&settings);
+ set_fs(oldfs);
+ status = tty->driver->ops->tiocmget(tty, NULL);
+
+ /* Wake up board */
+ tty->driver->ops->tiocmset(tty, NULL, 0x00, TIOCM_RTS);
+ mdelay(20);
+
+ status = tty->driver->ops->tiocmget(tty, NULL);
+
+ tty->driver->ops->tiocmset(tty, NULL, TIOCM_RTS, 0x00);
+ mdelay(20);
+
+ status = tty->driver->ops->tiocmget(tty, NULL);
+ oldfs = get_fs();
+ set_fs(KERNEL_DS);
+ n_tty_ioctl_helper(tty, NULL, TCGETS, (unsigned long)&settings);
+
+ settings.c_cflag |= CRTSCTS;
+ n_tty_ioctl_helper(tty, NULL, TCSETS, (unsigned long)&settings);
+ set_fs(oldfs);
+ return status;
+}
+
+static void ath_context_switch(struct work_struct *work)
+{
+ int status;
+ struct ath_struct *ath;
+ struct hci_uart *hu;
+ struct tty_struct *tty;
+
+ ath = container_of(work, struct ath_struct, ctxtsw);
+
+ hu = ath->hu;
+ tty = hu->tty;
+
+ /* verify and wake up controller */
+ if (ath->cur_sleep) {
+
+ status = ath_wakeup_ar3001(tty);
+ if (!(status & TIOCM_CTS))
+ return;
+ }
+
+ /* Ready to send Data */
+ clear_bit(HCI_UART_SENDING, &hu->tx_state);
+ hci_uart_tx_wakeup(hu);
+}
+
+int ath_check_sleep_cmd(struct ath_struct *ath, unsigned char *packet)
+{
+ if (packet[0] == 0x04 && packet[1] == 0xFC)
+ ath->cur_sleep = packet[3];
+
+ return 0;
+}
+
+
+/* Initialize protocol */
+static int ath_open(struct hci_uart *hu)
+{
+ struct ath_struct *ath;
+ BT_DBG("hu %p", hu);
+
+ ath = kzalloc(sizeof(*ath), GFP_ATOMIC);
+ if (!ath)
+ return -ENOMEM;
+
+ skb_queue_head_init(&ath->txq);
+ spin_lock_init(&ath->hciath_lock);
+
+ ath->cur_sleep = 0;
+ hu->priv = ath;
+ ath->hu = hu;
+
+ init_waitqueue_head(&ath->wqevt);
+ INIT_WORK(&ath->ctxtsw, ath_context_switch);
+ return 0;
+}
+
+/* Flush protocol data */
+static int ath_flush(struct hci_uart *hu)
+{
+ struct ath_struct *ath = hu->priv;
+ BT_DBG("hu %p", hu);
+ skb_queue_purge(&ath->txq);
+
+ return 0;
+}
+
+/* Close protocol */
+static int ath_close(struct hci_uart *hu)
+{
+ struct ath_struct *ath = hu->priv;
+ BT_DBG("hu %p", hu);
+
+ skb_queue_purge(&ath->txq);
+
+ if (ath->rx_skb)
+ kfree_skb(ath->rx_skb);
+
+ wake_up_interruptible(&ath->wqevt);
+ hu->priv = NULL;
+ kfree(ath);
+ return 0;
+}
+
+/* Enqueue frame for transmittion */
+static int ath_enqueue(struct hci_uart *hu, struct sk_buff *skb)
+{
+ struct ath_struct *ath = hu->priv;
+ if (bt_cb(skb)->pkt_type == HCI_SCODATA_PKT) {
+
+ /* Discard SCO packet.AR3001 does not support SCO over HCI */
+ BT_DBG("SCO Packet over HCI received Dropping\n");
+ kfree(skb);
+ return 0;
+ }
+ BT_DBG("hu %p skb %p", hu, skb);
+
+ /* Prepend skb with frame type */
+ memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
+
+ skb_queue_tail(&ath->txq, skb);
+ set_bit(HCI_UART_SENDING, &hu->tx_state);
+
+ schedule_work(&ath->ctxtsw);
+ return 0;
+}
+
+static struct sk_buff *ath_dequeue(struct hci_uart *hu)
+{
+ struct ath_struct *ath = hu->priv;
+ struct sk_buff *skbuf;
+
+ skbuf = skb_dequeue(&ath->txq);
+ if (skbuf != NULL)
+ ath_check_sleep_cmd(ath, &skbuf->data[1]);
+
+ return skbuf;
+}
+
+static inline int ath_check_data_len(struct ath_struct *ath, int len)
+{
+ register int room = skb_tailroom(ath->rx_skb);
+ BT_DBG("len %d room %d", len, room);
+
+ if (len > room) {
+ BT_ERR("Data length is too large");
+ kfree_skb(ath->rx_skb);
+ ath->rx_state = HCIATH_W4_PACKET_TYPE;
+ ath->rx_skb = NULL;
+ ath->rx_count = 0;
+ } else {
+ ath->rx_state = HCIATH_W4_DATA;
+ ath->rx_count = len;
+ return len;
+ }
+
+ return 0;
+}
+
+/* Recv data */
+static int ath_recv(struct hci_uart *hu, void *data, int count)
+{
+ struct ath_struct *ath = hu->priv;
+ register char *ptr;
+ struct hci_event_hdr *eh;
+ struct hci_acl_hdr *ah;
+ struct hci_sco_hdr *sh;
+ struct sk_buff *skbuf;
+ register int len, type, dlen;
+
+ skbuf = NULL;
+ BT_DBG("hu %p count %d rx_state %d rx_count %d", hu, count,
+ ath->rx_state, ath->rx_count);
+ ptr = data;
+ while (count) {
+ if (ath->rx_count) {
+
+ len = min_t(unsigned int, ath->rx_count, count);
+ memcpy(skb_put(ath->rx_skb, len), ptr, len);
+ ath->rx_count -= len;
+ count -= len;
+ ptr += len;
+
+ if (ath->rx_count)
+ continue;
+ switch (ath->rx_state) {
+ case HCIATH_W4_DATA:
+ hci_recv_frame(ath->rx_skb);
+ ath->rx_state = HCIATH_W4_PACKET_TYPE;
+ ath->rx_skb = NULL;
+ ath->rx_count = 0;
+ continue;
+ case HCIATH_W4_EVENT_HDR:
+ eh = (struct hci_event_hdr *)ath->rx_skb->data;
+ BT_DBG("Event header: evt 0x%2.2x plen %d",
+ eh->evt, eh->plen);
+ ath_check_data_len(ath, eh->plen);
+ continue;
+ case HCIATH_W4_ACL_HDR:
+ ah = (struct hci_acl_hdr *)ath->rx_skb->data;
+ dlen = __le16_to_cpu(ah->dlen);
+ BT_DBG("ACL header: dlen %d", dlen);
+ ath_check_data_len(ath, dlen);
+ continue;
+ case HCIATH_W4_SCO_HDR:
+ sh = (struct hci_sco_hdr *)ath->rx_skb->data;
+ BT_DBG("SCO header: dlen %d", sh->dlen);
+ ath_check_data_len(ath, sh->dlen);
+ continue;
+ }
+ }
+
+ /* HCIATH_W4_PACKET_TYPE */
+ switch (*ptr) {
+ case HCI_EVENT_PKT:
+ BT_DBG("Event packet");
+ ath->rx_state = HCIATH_W4_EVENT_HDR;
+ ath->rx_count = HCI_EVENT_HDR_SIZE;
+ type = HCI_EVENT_PKT;
+ break;
+ case HCI_ACLDATA_PKT:
+ BT_DBG("ACL packet");
+ ath->rx_state = HCIATH_W4_ACL_HDR;
+ ath->rx_count = HCI_ACL_HDR_SIZE;
+ type = HCI_ACLDATA_PKT;
+ break;
+ case HCI_SCODATA_PKT:
+ BT_DBG("SCO packet");
+ ath->rx_state = HCIATH_W4_SCO_HDR;
+ ath->rx_count = HCI_SCO_HDR_SIZE;
+ type = HCI_SCODATA_PKT;
+ break;
+ default:
+ BT_ERR("Unknown HCI packet type %2.2x", (__u8) *ptr);
+ hu->hdev->stat.err_rx++;
+ ptr++;
+ count--;
+ continue;
+ };
+ ptr++;
+ count--;
+
+ /* Allocate packet */
+ ath->rx_skb = bt_skb_alloc(HCI_MAX_FRAME_SIZE, GFP_ATOMIC);
+ if (!ath->rx_skb) {
+ BT_ERR("Can't allocate mem for new packet");
+ ath->rx_state = HCIATH_W4_PACKET_TYPE;
+ ath->rx_count = 0;
+ return -ENOMEM;
+ }
+ ath->rx_skb->dev = (void *)hu->hdev;
+ bt_cb(ath->rx_skb)->pkt_type = type;
+ } return count;
+}
+
+static struct hci_uart_proto athp = {
+ .id = HCI_UART_ATH,
+ .open = ath_open,
+ .close = ath_close,
+ .recv = ath_recv,
+ .enqueue = ath_enqueue,
+ .dequeue = ath_dequeue,
+ .flush = ath_flush,
+};
+
+int ath_init(void)
+{
+ int err = hci_uart_register_proto(&athp);
+ if (!err)
+ BT_INFO("HCIATH protocol initialized");
+
+ else
+ BT_ERR("HCIATH protocol registration failed");
+ return err;
+}
+
+int ath_deinit(void)
+{
+ return hci_uart_unregister_proto(&athp);
+}
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 76a1abb..7dd76d1 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -542,6 +542,9 @@ static int __init hci_uart_init(void)
#ifdef CONFIG_BT_HCIUART_LL
ll_init();
#endif
+#ifdef CONFIG_BT_HCIUART_ATH
+ ath_init();
+#endif
return 0;
}
@@ -559,6 +562,9 @@ static void __exit hci_uart_exit(void)
#ifdef CONFIG_BT_HCIUART_LL
ll_deinit();
#endif
+#ifdef CONFIG_BT_HCIUART_ATH
+ ath_deinit();
+#endif
/* Release tty registration of line discipline */
if ((err = tty_unregister_ldisc(N_HCI)))
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 50113db..385537f 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -33,13 +33,14 @@
#define HCIUARTGETDEVICE _IOR('U', 202, int)
/* UART protocols */
-#define HCI_UART_MAX_PROTO 5
+#define HCI_UART_MAX_PROTO 6
#define HCI_UART_H4 0
#define HCI_UART_BCSP 1
#define HCI_UART_3WIRE 2
#define HCI_UART_H4DS 3
#define HCI_UART_LL 4
+#define HCI_UART_ATH 5
struct hci_uart;
@@ -91,3 +92,8 @@ int bcsp_deinit(void);
int ll_init(void);
int ll_deinit(void);
#endif
+
+#ifdef CONFIG_BT_HCIUART_ATH
+int ath_init(void);
+int ath_deinit(void);
+#endif
--
1.6.3.3
^ permalink raw reply related
* Re: HCI_MAX_DEV is a bit too small.
From: Peter Dons Tychsen @ 2010-03-15 2:11 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1268609659.3897.56.camel@localhost.localdomain>
Hi M,
Thanks for the fast reply,
> you are seriously considering the case of more than 16 Bluetooth devices
> are real normal use cases. We are talking about 1 device vs. 2 and can
> not even find an agreement for the UI cases there.
I know that normal users do not use that many devices, but test systems
or bluetooth servers (gateways) can easily have more than 16.
> So I could be convinced to add new functions to read/write the limit
> from within an application itself. So that it can be changed without
> re-compiling the library. Feel free to propose a patch.
I will see what i can do. What is needed is probably a
hci_set_max_devices() call. Then hcitool could call that with the number
of devices needed.
Thanks,
/Pedro
^ permalink raw reply
* Re: HCI_MAX_DEV is a bit too small.
From: Marcel Holtmann @ 2010-03-14 23:34 UTC (permalink / raw)
To: donpedro; +Cc: linux-bluetooth
In-Reply-To: <1268608837.6400.26.camel@donpedro>
Hi Pedro,
> HCI_MAX_DEV is set a bit low (16), causing hci_for_each_dev() to not
> return all of the devices if you have more. This is not a disaster for
> the library itself, as i can just copy hci_for_each_dev() and make a
> version supporting more devices.
>
> However, hcitool uses the library version of hci_for_each_dev(), so that
> makes hcitool useless for a system with more devices. You could of
> course fix this is hcitool, but changing HCI_MAX_DEV seem like the right
> solution.
>
> Can this be changed, or does it *need* to be 16?
>
> If changed, it would be nice if it was raised to something like 256, to
> keep the number in the power of 2. To be honest, i don't think this
> should have been a constant at all, as the number of devices is
> virtually endless. hci_for_each_dev() should probably have taken a MAX
> parameter, but should not itself have set a limit. But to keep the API
> intact, changing HCI_MAX_DEV could be a solution.
you are seriously considering the case of more than 16 Bluetooth devices
are real normal use cases. We are talking about 1 device vs. 2 and can
not even find an agreement for the UI cases there.
Anyhow, I agree with you that the number of devices should not have been
limited within the library. That was a bug we inherited from the initial
library design. However I am against just raising the number. We did
raise it once from 4 to 16 a long time ago. It is a serious memory issue
in the long running apps like bluetoothd.
So I could be convinced to add new functions to read/write the limit
from within an application itself. So that it can be changed without
re-compiling the library. Feel free to propose a patch.
Regards
Marcel
^ permalink raw reply
* Re: A strange compatible problem for eSCO audio with CSR USB Bluetooth dongle
From: Marcel Holtmann @ 2010-03-14 23:28 UTC (permalink / raw)
To: Cooper Xu; +Cc: linux-bluetooth
In-Reply-To: <1660E2CC4AF24655A1FFE788570A34FF@mapleworks.com>
Hi Cooper,
> We have a strange compatible problem with Bluez for eSCO audio.
>
> We develope an embedded application based on Bluez library that can play the
> role of HF and it uses a generic CSR USB Bluetooth dongle. The application
> worked well for most cell phones (iPhone, Blackberry etc). But when we tried
> it with an Android phone (Motorola Droid), we found one way voice problem.
> The Android phone side can not hear the voice.
do you have a link to your sources so that we can have a look at it.
> We know that Android phone also uses the Bluez library. So we tried to pair
> our application with another Linux with Bluez library with another CSR USB
> Bluetooth dongle. We used "hcidump" to capture the SCO packets in that
> system. We received a lot of SCO packets, but the content of packets is all
> zero. However from another end of SCO connection, we actually sent a lot
> non-zero contents.
>
> To simply our debug, we then used the "scotest" program from the Bluez 4.65
> source and used one system as client and another as server. From the hcidump
> output, we still saw the content of packets is all zero. However when we
> changed one USB dongle to another USB dongle with the Broadcom chipset, we
> can receive some non-zero data. In both case, we didn't see Bluez kernel
> error message.
If you are using BlueZ 4.65 then I want a ride in your time machine ;)
> The Linux kernel for the system we used for test is 2.6.30. The attachment
> is the SCO packet we captured for receiving side. The following is the
> information of Bluetooth USB dongle we use:
>
> BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
> UP RUNNING PSCAN AUTH ENCRYPT
Bluetooth security mode 3. Seriously? Who still thinks this is a good
idea. I don't get it.
> BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
> Unified 21e
> Chip version: BlueCore4-ROM
> Max key size: 128 bit
> SCO mapping: HCI
So at least the SCO mapping is correctly set to HCI.
For the 2.6.30 kernel, that is a pretty ancient kernel. It is most
likely over 9 month old. I would prefer if you can re-test it with a
2.6.34-rc1 kernel to ensure there is no kernel issue.
> This audio problem seems only happen if both ends use Bluez library. If one
> side uses a different Bluetooth library, this issue will not appear. What
> can be the cause of this? I am very confused.
Nothing can really cause this. Please show us the source code for your
application maybe someone can have a quick look. The BlueZ builtin
headset and handsfree support works perfectly.
Regards
Marcel
^ permalink raw reply
* HCI_MAX_DEV is a bit too small.
From: Peter Dons Tychsen @ 2010-03-14 23:20 UTC (permalink / raw)
To: linux-bluetooth
Hello,
HCI_MAX_DEV is set a bit low (16), causing hci_for_each_dev() to not
return all of the devices if you have more. This is not a disaster for
the library itself, as i can just copy hci_for_each_dev() and make a
version supporting more devices.
However, hcitool uses the library version of hci_for_each_dev(), so that
makes hcitool useless for a system with more devices. You could of
course fix this is hcitool, but changing HCI_MAX_DEV seem like the right
solution.
Can this be changed, or does it *need* to be 16?
If changed, it would be nice if it was raised to something like 256, to
keep the number in the power of 2. To be honest, i don't think this
should have been a constant at all, as the number of devices is
virtually endless. hci_for_each_dev() should probably have taken a MAX
parameter, but should not itself have set a limit. But to keep the API
intact, changing HCI_MAX_DEV could be a solution.
Thanks,
/Pedro
^ permalink raw reply
* A strange compatible problem for eSCO audio with CSR USB Bluetooth dongle
From: Cooper Xu @ 2010-03-14 23:01 UTC (permalink / raw)
To: linux-bluetooth
Hi,
We have a strange compatible problem with Bluez for eSCO audio.
We develope an embedded application based on Bluez library that can play the
role of HF and it uses a generic CSR USB Bluetooth dongle. The application
worked well for most cell phones (iPhone, Blackberry etc). But when we tried
it with an Android phone (Motorola Droid), we found one way voice problem.
The Android phone side can not hear the voice.
We know that Android phone also uses the Bluez library. So we tried to pair
our application with another Linux with Bluez library with another CSR USB
Bluetooth dongle. We used "hcidump" to capture the SCO packets in that
system. We received a lot of SCO packets, but the content of packets is all
zero. However from another end of SCO connection, we actually sent a lot
non-zero contents.
To simply our debug, we then used the "scotest" program from the Bluez 4.65
source and used one system as client and another as server. From the hcidump
output, we still saw the content of packets is all zero. However when we
changed one USB dongle to another USB dongle with the Broadcom chipset, we
can receive some non-zero data. In both case, we didn't see Bluez kernel
error message.
The Linux kernel for the system we used for test is 2.6.30. The attachment
is the SCO packet we captured for receiving side. The following is the
information of Bluetooth USB dongle we use:
hciconfig -a
hci0: Type: USB
BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN AUTH ENCRYPT
RX bytes:2081370 acl:185 sco:17775 events:9695 errors:0
TX bytes:252089 acl:164 sco:3002 commands:4693 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'test'
Class: 0x000408
Service Classes: Unspecified
Device Class: Audio/Video, Hands-free
HCI Ver: 2.0 (0x3) HCI Rev: 0xc5c LMP Ver: 2.0 (0x3) LMP Subver:
0xc5c
Manufacturer: Cambridge Silicon Radio (10)
hciconfig hci0 revision:
hci0: Type: USB
BD Address: 00:11:F6:0B:CA:EE ACL MTU: 310:10 SCO MTU: 64:8
Unified 21e
Chip version: BlueCore4-ROM
Max key size: 128 bit
SCO mapping: HCI
This audio problem seems only happen if both ends use Bluez library. If one
side uses a different Bluetooth library, this issue will not appear. What
can be the cause of this? I am very confused.
^ permalink raw reply
* Re: 2.6.34-rc1: bluetooth oops
From: Pavel Machek @ 2010-03-14 20:44 UTC (permalink / raw)
To: Marcel Holtmann, netdev; +Cc: kernel list, linux-bluetooth
In-Reply-To: <1268598500.3897.36.camel@localhost.localdomain>
Hi!
> > I got this after trying to use bnep for few minutes... Machine locked
> > after that, not sure if it is related.
>
> I can't explain it since we haven't changed the BNEP code. So that might
> be a problem in the networking layer. So posting it to netdev might be a
> good idea.
Ok, I'll try using bnep some more. I had bad problems with cellphone
connection at that point, so maybe it is not easy to repeat, and it
the fact I have not seen it before may not mean much...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Bug in parsing of SDP_ServiceSearchAttributeResponse?
From: Marcel Holtmann @ 2010-03-14 20:40 UTC (permalink / raw)
To: Iain Hibbert; +Cc: Daniel Abraham, linux-bluetooth
In-Reply-To: <1268352254.586562.6662.nullmailer@galant.ukfsn.org>
Hi Daniel,
> > According to hcidump (attached), the SDP_ServiceSearchAttributeResponse
> > is malformed, but a different Bluetooth stack (IVT on Windows) is able
> > to report correctly the remote computer's available services.
>
> It could be that the different Bluetooth stacks fetch that information via
> a different request than ServiceSearchAttributes, or that it queries the
> services that it hopes to see individually rather than just the
> PublicBrowseGroup to get everything as in this case.
>
> > So I'm guessing this is a parsing error or interoperability weakness in
> > BlueZ...? (Or, less likely but possible, a bug in the other 2 stacks?)
>
> The PDU that the remote computer sends is truncated at the end of the
> first L2CAP frame (all the 0's that hcidump shows are just empty buffer as
> it does not check the actual frame length). But, each L2CAP frame is
> supposed to contain an entire PDU and when the data exceeds the MTU it
> sends a non zero Continuation State to enable the client to request more
> data.
>
> It might be that this computer was not expecting that the response would
> overflow the L2CAP frame and they didn't write the code to handle that,
> but in the meantime many services were added..
you can decode only HCI and L2CAP like this:
hcidump -r <file> -X -V hci l2cap
That will avoid involving the SDP parser and you see that it is one
L2CAP packet with 672 bytes in there (split over two ACL packets).
The remote stack is having a bug in L2CAP already anyway:
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
It is mandatory for the config response to include the MTU size to
confirm the configured value.
The SDP protocol is pretty clear in how to handle splitting long PDUs
over multiple L2CAP frames. This remote stack doesn't do it at all.
BlueZ handles this properly.
I wouldn't be surprised that even if you see the packet in hcidump, the
kernel actually dropped it. And it never was handed out to the
application because it was not fragmented properly. Check dmesg if the
kernel dropped a packet.
Regards
Marcel
^ permalink raw reply
* Re: 2.6.34-rc1: bluetooth oops
From: Marcel Holtmann @ 2010-03-14 20:28 UTC (permalink / raw)
To: Pavel Machek; +Cc: kernel list, linux-bluetooth
In-Reply-To: <20100314201434.GE22059@elf.ucw.cz>
Hi Pavel,
> I got this after trying to use bnep for few minutes... Machine locked
> after that, not sure if it is related.
I can't explain it since we haven't changed the BNEP code. So that might
be a problem in the networking layer. So posting it to netdev might be a
good idea.
Regards
Marcel
^ permalink raw reply
* Re: Bug in parsing of SDP_ServiceSearchAttributeResponse?
From: Iain Hibbert @ 2010-03-14 20:16 UTC (permalink / raw)
To: Daniel Abraham; +Cc: linux-bluetooth
In-Reply-To: <1268574616.6238.903.camel@dabraham-mobl>
On Sun, 14 Mar 2010, Daniel Abraham wrote:
> > You can probably use "sdptool search" to find specific services ok?
>
> Actually "sdptool" is just an example, the real problem is that when
> BlueZ discovers that device, the SDP PDU truncation causes it to appear
> to be profile-less, so I can't actively connect to any service, only
> passively accept connections.
Well, I'm not sure how BlueZ works in this regard but my question covers
searching for a specific service in general - eg if you perform a
ServiceSearchAttribute with a specific UUID and possibly a limited
AttributeIDList then the response will be a whole lot smaller and probably
fit into the L2CAP packet..
> > Although sdptool has no way to increase the "Incoming MTU" on the SDP
> > connection, if you could work out how to do that it might allow more
> > information to be received (in lib/sdp.c:sdp_connect_l2cap() set
> > L2CAP_OPTIONS with imtu at some large number than 672, before the
> > connect())
>
> Although the PDU truncation is a bug not in BlueZ, I still think it
> uncovers a point for improvement in BlueZ.
>
> Up until the truncation point, the PDU still contains 6-7 valid
> attribute lists, which are discarded. Why not use them despite the
> malformed PDU?
The code that parses the response from the remote side is told that there
are XXX bytes in the following data, but only yyy are in the packet.. what
to do? Its obviously an error and you can't necessarily guess what the
other side intended to send..
On the other hand, if BlueZ were to set the MaximiumAttributeByteCount to
a lower value (eg see patch below), that might help your remote device to
do the right thing.. if that works, the count could be calculated at
runtime as
MTU - 5(pdu hdr) - 2(attr count) - 17(max cont state)
rather than using a fixed value.
iain
--- lib/sdp.c.orig 2010-03-14 19:56:19.000000000 +0000
+++ lib/sdp.c 2010-03-14 19:56:53.000000000 +0000
@@ -95,7 +95,7 @@
0x80, 0x00, 0x00, 0x80, 0x5F, 0x9B, 0x34, 0xFB }
};
-#define SDP_MAX_ATTR_LEN 65535
+#define SDP_MAX_ATTR_LEN 600
static sdp_data_t *sdp_copy_seq(sdp_data_t *data);
static int sdp_attr_add_new_with_length(sdp_record_t *rec,
^ permalink raw reply
* 2.6.34-rc1: bluetooth oops
From: Pavel Machek @ 2010-03-14 20:14 UTC (permalink / raw)
To: marcel, kernel list, linux-bluetooth
Hi!
I got this after trying to use bnep for few minutes... Machine locked
after that, not sure if it is related.
Pavel
Mar 13 15:01:38 amd kernel: Failure of coda_cnode_make for root: error -4
Mar 13 15:21:33 amd -- MARK --
Mar 13 15:41:33 amd -- MARK --
Mar 13 16:01:33 amd -- MARK --
Mar 13 16:21:33 amd -- MARK --
Mar 13 16:41:34 amd -- MARK --
Mar 13 17:01:34 amd -- MARK --
Mar 13 17:09:47 amd log1n[1781]: ROOT LOGIN on `tty8'
Mar 13 17:09:55 amd pand[1961]: Bluetooth PAN daemon version 4.57
Mar 13 17:09:55 amd pand[1961]: Connecting to 00:21:BA:FF:2D:37
Mar 13 17:09:58 amd pand[1961]: bnep0 connected
Mar 13 17:09:59 amd pumpd[1979]: starting at (uptime 0 days, 2:08:43) Sat Mar 13 17:09:59 2010
Mar 13 17:09:59 amd pumpd[1979]: configured interface bnep0
Mar 13 17:09:59 amd modprobe: FATAL: Could not load /lib/modules/2.6.34-rc1-00182-g3c96f03-dirty/modules.dep: No such file or directory
Mar 13 17:11:02 amd modprobe: FATAL: Could not load /lib/modules/2.6.34-rc1-00182-g3c96f03-dirty/modules.dep: No such file or directory
Mar 13 17:11:02 amd acpid: client connected from 2006[0:0]
Mar 13 17:11:02 amd acpid: 1 client rule loaded
Mar 13 17:11:08 amd ck-launch-session: error connecting to ConsoleKit
Mar 13 17:11:16 amd modprobe: FATAL: Could not load /lib/modules/2.6.34-rc1-00182-g3c96f03-dirty/modules.dep: No such file or directory
Mar 13 17:11:16 amd last message repeated 7 times
Mar 13 17:12:59 amd modprobe: FATAL: Could not load /lib/modules/2.6.34-rc1-00182-g3c96f03-dirty/modules.dep: No such file or directory
Mar 13 17:13:22 amd last message repeated 2 times
Mar 13 17:14:07 amd kernel: ------------[ cut here ]------------
Mar 13 17:14:07 amd kernel: WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x226/0x230()
Mar 13 17:14:07 amd kernel: Hardware name: 17097HU
Mar 13 17:14:07 amd kernel: NETDEV WATCHDOG: bnep0 (): transmit queue 0 timed out
Mar 13 17:14:07 amd kernel: Modules linked in:
Mar 13 17:14:07 amd kernel: Pid: 0, comm: swapper Tainted: G W 2.6.34-rc1-00182-g3c96f03-dirty #109
Mar 13 17:14:07 amd kernel: Call Trace:
Mar 13 17:14:07 amd kernel: [<c0698bb6>] ? dev_watchdog+0x226/0x230
Mar 13 17:14:07 amd kernel: [<c0698bb6>] ? dev_watchdog+0x226/0x230
Mar 13 17:14:07 amd kernel: [<c0234dbc>] warn_slowpath_common+0x6c/0xc0
Mar 13 17:14:07 amd kernel: [<c0698bb6>] ? dev_watchdog+0x226/0x230
Mar 13 17:14:07 amd kernel: [<c0234e56>] warn_slowpath_fmt+0x26/0x30
Mar 13 17:14:07 amd kernel: [<c0698bb6>] dev_watchdog+0x226/0x230
Mar 13 17:14:07 amd kernel: [<c023f0ec>] ? run_timer_softirq+0xfc/0x250
Mar 13 17:14:07 amd kernel: [<c023f169>] run_timer_softirq+0x179/0x250
Mar 13 17:14:07 amd kernel: [<c023f0ec>] ? run_timer_softirq+0xfc/0x250
Mar 13 17:14:07 amd kernel: [<c0698990>] ? dev_watchdog+0x0/0x230
Mar 13 17:14:07 amd kernel: [<c023a255>] __do_softirq+0x85/0x110
Mar 13 17:14:07 amd kernel: [<c023a30d>] do_softirq+0x2d/0x40
Mar 13 17:14:07 amd kernel: [<c023a4a5>] irq_exit+0x65/0x80
Mar 13 17:14:07 amd kernel: [<c020468f>] do_IRQ+0x4f/0xc0
Mar 13 17:14:07 amd kernel: [<c024fda2>] ? sched_clock_local+0xd2/0x170
Mar 13 17:14:07 amd kernel: [<c02030e9>] common_interrupt+0x29/0x30
Mar 13 17:14:07 amd kernel: [<c025007b>] ? sched_clock_idle_wakeup_event+0xb/0x30
Mar 13 17:14:07 amd kernel: [<c03e01d3>] ? acpi_idle_enter_simple+0x13f/0x16a
Mar 13 17:14:07 amd kernel: [<c03dfeb0>] acpi_idle_enter_bm+0xc3/0x2a7
Mar 13 17:14:07 amd kernel: [<c05c160d>] cpuidle_idle_call+0x7d/0xc0
Mar 13 17:14:07 amd kernel: [<c0201cad>] cpu_idle+0x4d/0x80
Mar 13 17:14:07 amd kernel: [<c0785c6b>] rest_init+0xab/0xc0
Mar 13 17:14:07 amd kernel: [<c0785bc0>] ? rest_init+0x0/0xc0
Mar 13 17:14:07 amd kernel: [<c0aa08b5>] start_kernel+0x28d/0x2c7
Mar 13 17:14:07 amd kernel: [<c0aa0404>] ? unknown_bootoption+0x0/0x1d3
Mar 13 17:14:07 amd kernel: [<c0aa0089>] i386_start_kernel+0x89/0x8b
Mar 13 17:14:07 amd kernel: ---[ end trace a7919e7f17c0a727 ]---
Mar 13 17:14:12 amd modprobe: FATAL: Could not load /lib/modules/2.6.34-rc1-00182-g3c96f03-dirty/modules.dep: No such file or directory
Mar 13 17:14:59 amd kernel: BUG: soft lockup - CPU#1 stuck for 61s! [kbnepd bnep0:1965]
Mar 13 17:14:59 amd kernel: Modules linked in:
Mar 13 17:14:59 amd kernel: Modules linked in:
Mar 13 17:14:59 amd kernel:
Mar 13 17:14:59 amd kernel: Pid: 1965, comm: kbnepd bnep0 Tainted: G W 2.6.34-rc1-00182-g3c96f03-dirty #109 17097HU/17097HU
Mar 13 17:14:59 amd kernel: EIP: 0060:[<c06e244d>] EFLAGS: 00010282 CPU: 1
Mar 13 17:14:59 amd kernel: EIP is at tcp_v4_rcv+0x19d/0x7d0
Mar 13 17:14:59 amd kernel: EAX: 00000036 EBX: f1232e20 ECX: c06cd093 EDX: f2891e00
Mar 13 17:14:59 amd kernel: ESI: f2f50f48 EDI: f2891e14 EBP: f0c29ddc ESP: f0c29da0
Mar 13 17:14:59 amd kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Mar 13 17:14:59 amd kernel: Process kbnepd bnep0 (pid: 1965, ti=f0c28000 task=f7361648 task.ti=f0c28000)
Mar 13 17:14:59 amd kernel: Stack:
Mar 13 17:14:59 amd kernel: 00005000 6702a8c0 0000c602 00000004 f0c29ddc f2f50f48 f2891e00 0000c602
Mar 13 17:14:59 amd kernel: <0> 00000004 6702a8c0 f1232e20 00000000 c081aab0 f2f50f48 f2891e00 f0c29dfc
Mar 13 17:14:59 amd kernel: <0> c06c5ba3 00000002 00000001 00000000 c06c5b20 f2f50f48 f2f50f48 f0c29e18
Mar 13 17:14:59 amd kernel: Call Trace:
Mar 13 17:14:59 amd kernel: [<c06c5ba3>] ? ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:14:59 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:14:59 amd kernel: [<c06c5d3f>] ? ip_local_deliver+0x8f/0xa0
Mar 13 17:14:59 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:14:59 amd kernel: [<c06c55e3>] ? ip_rcv_finish+0xf3/0x370
Mar 13 17:14:59 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:14:59 amd kernel: [<c06c5a94>] ? ip_rcv+0x234/0x290
Mar 13 17:14:59 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:14:59 amd kernel: [<c0688a70>] ? netif_receive_skb+0x1b0/0x310
Mar 13 17:14:59 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:14:59 amd kernel: [<c0688c32>] ? process_backlog+0x62/0xa0
Mar 13 17:14:59 amd kernel: [<c0688e4d>] ? net_rx_action+0x7d/0x100
Mar 13 17:14:59 amd kernel: [<c023a255>] ? __do_softirq+0x85/0x110
Mar 13 17:14:59 amd kernel: [<c023a30d>] ? do_softirq+0x2d/0x40
Mar 13 17:14:59 amd kernel: [<c06895da>] ? netif_rx_ni+0x1a/0x20
Mar 13 17:14:59 amd kernel: [<c0734c33>] ? bnep_session+0x2c3/0x820
Mar 13 17:14:59 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:14:59 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:14:59 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:14:59 amd kernel: [<c02030f6>] ? kernel_thread_helper+0x6/0x10
Mar 13 17:14:59 amd kernel: Code: b7 1f 8b 8e 88 00 00 00 85 c0 89 45 ec 0f 84 d3 01 00 00 c7 46 68 00 00 00 00 c7 46 10 00 00 00 00 8b 55 dc 8b 5d ec 0f b6 42 08 <3a> 83 45 02 00 00 0f 82 bf 00 00 00 0f b6 43 16 3c 06 0f 85 42
Mar 13 17:14:59 amd kernel: Call Trace:
Mar 13 17:14:59 amd kernel: [<c06c5ba3>] ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:14:59 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:14:59 amd kernel: [<c06c5d3f>] ip_local_deliver+0x8f/0xa0
Mar 13 17:14:59 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:14:59 amd kernel: [<c06c55e3>] ip_rcv_finish+0xf3/0x370
Mar 13 17:14:59 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:14:59 amd kernel: [<c06c5a94>] ip_rcv+0x234/0x290
Mar 13 17:14:59 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:14:59 amd kernel: [<c0688a70>] netif_receive_skb+0x1b0/0x310
Mar 13 17:14:59 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:14:59 amd kernel: [<c0688c32>] process_backlog+0x62/0xa0
Mar 13 17:14:59 amd kernel: [<c0688e4d>] net_rx_action+0x7d/0x100
Mar 13 17:14:59 amd kernel: [<c023a255>] __do_softirq+0x85/0x110
Mar 13 17:14:59 amd kernel: [<c023a30d>] do_softirq+0x2d/0x40
Mar 13 17:14:59 amd kernel: [<c06895da>] netif_rx_ni+0x1a/0x20
Mar 13 17:14:59 amd kernel: [<c0734c33>] bnep_session+0x2c3/0x820
Mar 13 17:14:59 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:14:59 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:14:59 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:14:59 amd kernel: [<c02030f6>] kernel_thread_helper+0x6/0x10
Mar 13 17:16:04 amd kernel: BUG: soft lockup - CPU#1 stuck for 61s! [kbnepd bnep0:1965]
Mar 13 17:16:04 amd kernel: Modules linked in:
Mar 13 17:16:04 amd kernel: Modules linked in:
Mar 13 17:16:04 amd kernel:
Mar 13 17:16:04 amd kernel: Pid: 1965, comm: kbnepd bnep0 Tainted: G W 2.6.34-rc1-00182-g3c96f03-dirty #109 17097HU/17097HU
Mar 13 17:16:04 amd kernel: EIP: 0060:[<c06e244d>] EFLAGS: 00010282 CPU: 1
Mar 13 17:16:04 amd kernel: EIP is at tcp_v4_rcv+0x19d/0x7d0
Mar 13 17:16:04 amd kernel: EAX: 00000036 EBX: f1232e20 ECX: c06cd093 EDX: f2891e00
Mar 13 17:16:04 amd kernel: ESI: f2f50f48 EDI: f2891e14 EBP: f0c29ddc ESP: f0c29da0
Mar 13 17:16:04 amd kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Mar 13 17:16:04 amd kernel: Process kbnepd bnep0 (pid: 1965, ti=f0c28000 task=f7361648 task.ti=f0c28000)
Mar 13 17:16:04 amd kernel: Stack:
Mar 13 17:16:04 amd kernel: 00005000 6702a8c0 0000c602 00000004 f0c29ddc f2f50f48 f2891e00 0000c602
Mar 13 17:16:04 amd kernel: <0> 00000004 6702a8c0 f1232e20 00000000 c081aab0 f2f50f48 f2891e00 f0c29dfc
Mar 13 17:16:04 amd kernel: <0> c06c5ba3 00000002 00000001 00000000 c06c5b20 f2f50f48 f2f50f48 f0c29e18
Mar 13 17:16:04 amd kernel: Call Trace:
Mar 13 17:16:04 amd kernel: [<c06c5ba3>] ? ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:16:04 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:16:04 amd kernel: [<c06c5d3f>] ? ip_local_deliver+0x8f/0xa0
Mar 13 17:16:04 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:16:04 amd kernel: [<c06c55e3>] ? ip_rcv_finish+0xf3/0x370
Mar 13 17:16:04 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:16:04 amd kernel: [<c06c5a94>] ? ip_rcv+0x234/0x290
Mar 13 17:16:04 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:16:04 amd kernel: [<c0688a70>] ? netif_receive_skb+0x1b0/0x310
Mar 13 17:16:04 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:16:04 amd kernel: [<c0688c32>] ? process_backlog+0x62/0xa0
Mar 13 17:16:04 amd kernel: [<c0688e4d>] ? net_rx_action+0x7d/0x100
Mar 13 17:16:04 amd kernel: [<c023a255>] ? __do_softirq+0x85/0x110
Mar 13 17:16:04 amd kernel: [<c023a30d>] ? do_softirq+0x2d/0x40
Mar 13 17:16:04 amd kernel: [<c06895da>] ? netif_rx_ni+0x1a/0x20
Mar 13 17:16:04 amd kernel: [<c0734c33>] ? bnep_session+0x2c3/0x820
Mar 13 17:16:04 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:16:04 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:16:04 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:16:04 amd kernel: [<c02030f6>] ? kernel_thread_helper+0x6/0x10
Mar 13 17:16:04 amd kernel: Code: b7 1f 8b 8e 88 00 00 00 85 c0 89 45 ec 0f 84 d3 01 00 00 c7 46 68 00 00 00 00 c7 46 10 00 00 00 00 8b 55 dc 8b 5d ec 0f b6 42 08 <3a> 83 45 02 00 00 0f 82 bf 00 00 00 0f b6 43 16 3c 06 0f 85 42
Mar 13 17:16:04 amd kernel: Call Trace:
Mar 13 17:16:04 amd kernel: [<c06c5ba3>] ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:16:04 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:16:04 amd kernel: [<c06c5d3f>] ip_local_deliver+0x8f/0xa0
Mar 13 17:16:04 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:16:04 amd kernel: [<c06c55e3>] ip_rcv_finish+0xf3/0x370
Mar 13 17:16:04 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:16:04 amd kernel: [<c06c5a94>] ip_rcv+0x234/0x290
Mar 13 17:16:04 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:16:04 amd kernel: [<c0688a70>] netif_receive_skb+0x1b0/0x310
Mar 13 17:16:04 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:16:04 amd kernel: [<c0688c32>] process_backlog+0x62/0xa0
Mar 13 17:16:04 amd kernel: [<c0688e4d>] net_rx_action+0x7d/0x100
Mar 13 17:16:04 amd kernel: [<c023a255>] __do_softirq+0x85/0x110
Mar 13 17:16:04 amd kernel: [<c023a30d>] do_softirq+0x2d/0x40
Mar 13 17:16:04 amd kernel: [<c06895da>] netif_rx_ni+0x1a/0x20
Mar 13 17:16:04 amd kernel: [<c0734c33>] bnep_session+0x2c3/0x820
Mar 13 17:16:04 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:16:04 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:16:04 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:16:04 amd kernel: [<c02030f6>] kernel_thread_helper+0x6/0x10
Mar 13 17:17:09 amd kernel: BUG: soft lockup - CPU#1 stuck for 61s! [kbnepd bnep0:1965]
Mar 13 17:17:09 amd kernel: Modules linked in:
Mar 13 17:17:09 amd kernel: Modules linked in:
Mar 13 17:17:09 amd kernel:
Mar 13 17:17:09 amd kernel: Pid: 1965, comm: kbnepd bnep0 Tainted: G W 2.6.34-rc1-00182-g3c96f03-dirty #109 17097HU/17097HU
Mar 13 17:17:09 amd kernel: EIP: 0060:[<c06e244d>] EFLAGS: 00010282 CPU: 1
Mar 13 17:17:09 amd kernel: EIP is at tcp_v4_rcv+0x19d/0x7d0
Mar 13 17:17:09 amd kernel: EAX: 00000036 EBX: f1232e20 ECX: c06cd093 EDX: f2891e00
Mar 13 17:17:09 amd kernel: ESI: f2f50f48 EDI: f2891e14 EBP: f0c29ddc ESP: f0c29da0
Mar 13 17:17:09 amd kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Mar 13 17:17:09 amd kernel: Process kbnepd bnep0 (pid: 1965, ti=f0c28000 task=f7361648 task.ti=f0c28000)
Mar 13 17:17:10 amd kernel: Stack:
Mar 13 17:17:10 amd kernel: 00005000 6702a8c0 0000c602 00000004 f0c29ddc f2f50f48 f2891e00 0000c602
Mar 13 17:17:10 amd kernel: <0> 00000004 6702a8c0 f1232e20 00000000 c081aab0 f2f50f48 f2891e00 f0c29dfc
Mar 13 17:17:10 amd kernel: <0> c06c5ba3 00000002 00000001 00000000 c06c5b20 f2f50f48 f2f50f48 f0c29e18
Mar 13 17:17:10 amd kernel: Call Trace:
Mar 13 17:17:10 amd kernel: [<c06c5ba3>] ? ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:17:10 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:17:10 amd kernel: [<c06c5d3f>] ? ip_local_deliver+0x8f/0xa0
Mar 13 17:17:10 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:17:10 amd kernel: [<c06c55e3>] ? ip_rcv_finish+0xf3/0x370
Mar 13 17:17:10 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:17:10 amd kernel: [<c06c5a94>] ? ip_rcv+0x234/0x290
Mar 13 17:17:10 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:17:10 amd kernel: [<c0688a70>] ? netif_receive_skb+0x1b0/0x310
Mar 13 17:17:10 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:17:10 amd kernel: [<c0688c32>] ? process_backlog+0x62/0xa0
Mar 13 17:17:10 amd kernel: [<c0688e4d>] ? net_rx_action+0x7d/0x100
Mar 13 17:17:10 amd kernel: [<c023a255>] ? __do_softirq+0x85/0x110
Mar 13 17:17:10 amd kernel: [<c023a30d>] ? do_softirq+0x2d/0x40
Mar 13 17:17:10 amd kernel: [<c06895da>] ? netif_rx_ni+0x1a/0x20
Mar 13 17:17:10 amd kernel: [<c0734c33>] ? bnep_session+0x2c3/0x820
Mar 13 17:17:10 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:17:10 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:17:10 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:17:10 amd kernel: [<c02030f6>] ? kernel_thread_helper+0x6/0x10
Mar 13 17:17:10 amd kernel: Code: b7 1f 8b 8e 88 00 00 00 85 c0 89 45 ec 0f 84 d3 01 00 00 c7 46 68 00 00 00 00 c7 46 10 00 00 00 00 8b 55 dc 8b 5d ec 0f b6 42 08 <3a> 83 45 02 00 00 0f 82 bf 00 00 00 0f b6 43 16 3c 06 0f 85 42
Mar 13 17:17:10 amd kernel: Call Trace:
Mar 13 17:17:10 amd kernel: [<c06c5ba3>] ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:17:10 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:17:10 amd kernel: [<c06c5d3f>] ip_local_deliver+0x8f/0xa0
Mar 13 17:17:10 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:17:10 amd kernel: [<c06c55e3>] ip_rcv_finish+0xf3/0x370
Mar 13 17:17:10 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:17:10 amd kernel: [<c06c5a94>] ip_rcv+0x234/0x290
Mar 13 17:17:10 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:17:10 amd kernel: [<c0688a70>] netif_receive_skb+0x1b0/0x310
Mar 13 17:17:10 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:17:10 amd kernel: [<c0688c32>] process_backlog+0x62/0xa0
Mar 13 17:17:10 amd kernel: [<c0688e4d>] net_rx_action+0x7d/0x100
Mar 13 17:17:10 amd kernel: [<c023a255>] __do_softirq+0x85/0x110
Mar 13 17:17:10 amd kernel: [<c023a30d>] do_softirq+0x2d/0x40
Mar 13 17:17:10 amd kernel: [<c06895da>] netif_rx_ni+0x1a/0x20
Mar 13 17:17:10 amd kernel: [<c0734c33>] bnep_session+0x2c3/0x820
Mar 13 17:17:10 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:17:10 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:17:10 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:17:10 amd kernel: [<c02030f6>] kernel_thread_helper+0x6/0x10
Mar 13 17:18:15 amd kernel: BUG: soft lockup - CPU#1 stuck for 61s! [kbnepd bnep0:1965]
Mar 13 17:18:15 amd kernel: Modules linked in:
Mar 13 17:18:15 amd kernel: Modules linked in:
Mar 13 17:18:15 amd kernel:
Mar 13 17:18:15 amd kernel: Pid: 1965, comm: kbnepd bnep0 Tainted: G W 2.6.34-rc1-00182-g3c96f03-dirty #109 17097HU/17097HU
Mar 13 17:18:15 amd kernel: EIP: 0060:[<c06e244d>] EFLAGS: 00010282 CPU: 1
Mar 13 17:18:15 amd kernel: EIP is at tcp_v4_rcv+0x19d/0x7d0
Mar 13 17:18:15 amd kernel: EAX: 00000036 EBX: f1232e20 ECX: c06cd093 EDX: f2891e00
Mar 13 17:18:15 amd kernel: ESI: f2f50f48 EDI: f2891e14 EBP: f0c29ddc ESP: f0c29da0
Mar 13 17:18:15 amd kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Mar 13 17:18:15 amd kernel: Process kbnepd bnep0 (pid: 1965, ti=f0c28000 task=f7361648 task.ti=f0c28000)
Mar 13 17:18:15 amd kernel: Stack:
Mar 13 17:18:15 amd kernel: 00005000 6702a8c0 0000c602 00000004 f0c29ddc f2f50f48 f2891e00 0000c602
Mar 13 17:18:15 amd kernel: <0> 00000004 6702a8c0 f1232e20 00000000 c081aab0 f2f50f48 f2891e00 f0c29dfc
Mar 13 17:18:15 amd kernel: <0> c06c5ba3 00000002 00000001 00000000 c06c5b20 f2f50f48 f2f50f48 f0c29e18
Mar 13 17:18:15 amd kernel: Call Trace:
Mar 13 17:18:15 amd kernel: [<c06c5ba3>] ? ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:18:15 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:18:15 amd kernel: [<c06c5d3f>] ? ip_local_deliver+0x8f/0xa0
Mar 13 17:18:15 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:18:15 amd kernel: [<c06c55e3>] ? ip_rcv_finish+0xf3/0x370
Mar 13 17:18:15 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:18:15 amd kernel: [<c06c5a94>] ? ip_rcv+0x234/0x290
Mar 13 17:18:15 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:18:15 amd kernel: [<c0688a70>] ? netif_receive_skb+0x1b0/0x310
Mar 13 17:18:15 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:18:15 amd kernel: [<c0688c32>] ? process_backlog+0x62/0xa0
Mar 13 17:18:15 amd kernel: [<c0688e4d>] ? net_rx_action+0x7d/0x100
Mar 13 17:18:15 amd kernel: [<c023a255>] ? __do_softirq+0x85/0x110
Mar 13 17:18:15 amd kernel: [<c023a30d>] ? do_softirq+0x2d/0x40
Mar 13 17:18:15 amd kernel: [<c06895da>] ? netif_rx_ni+0x1a/0x20
Mar 13 17:18:15 amd kernel: [<c0734c33>] ? bnep_session+0x2c3/0x820
Mar 13 17:18:15 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:18:15 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:18:15 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:18:15 amd kernel: [<c02030f6>] ? kernel_thread_helper+0x6/0x10
Mar 13 17:18:15 amd kernel: Code: b7 1f 8b 8e 88 00 00 00 85 c0 89 45 ec 0f 84 d3 01 00 00 c7 46 68 00 00 00 00 c7 46 10 00 00 00 00 8b 55 dc 8b 5d ec 0f b6 42 08 <3a> 83 45 02 00 00 0f 82 bf 00 00 00 0f b6 43 16 3c 06 0f 85 42
Mar 13 17:18:15 amd kernel: Call Trace:
Mar 13 17:18:15 amd kernel: [<c06c5ba3>] ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:18:15 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:18:15 amd kernel: [<c06c5d3f>] ip_local_deliver+0x8f/0xa0
Mar 13 17:18:15 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:18:15 amd kernel: [<c06c55e3>] ip_rcv_finish+0xf3/0x370
Mar 13 17:18:15 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:18:15 amd kernel: [<c06c5a94>] ip_rcv+0x234/0x290
Mar 13 17:18:15 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:18:15 amd kernel: [<c0688a70>] netif_receive_skb+0x1b0/0x310
Mar 13 17:18:15 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:18:15 amd kernel: [<c0688c32>] process_backlog+0x62/0xa0
Mar 13 17:18:15 amd kernel: [<c0688e4d>] net_rx_action+0x7d/0x100
Mar 13 17:18:15 amd kernel: [<c023a255>] __do_softirq+0x85/0x110
Mar 13 17:18:15 amd kernel: [<c023a30d>] do_softirq+0x2d/0x40
Mar 13 17:18:15 amd kernel: [<c06895da>] netif_rx_ni+0x1a/0x20
Mar 13 17:18:15 amd kernel: [<c0734c33>] bnep_session+0x2c3/0x820
Mar 13 17:18:15 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:18:15 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:18:15 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:18:15 amd kernel: [<c02030f6>] kernel_thread_helper+0x6/0x10
Mar 13 17:19:20 amd kernel: BUG: soft lockup - CPU#1 stuck for 61s! [kbnepd bnep0:1965]
Mar 13 17:19:20 amd kernel: Modules linked in:
Mar 13 17:19:20 amd kernel: Modules linked in:
Mar 13 17:19:20 amd kernel:
Mar 13 17:19:20 amd kernel: Pid: 1965, comm: kbnepd bnep0 Tainted: G W 2.6.34-rc1-00182-g3c96f03-dirty #109 17097HU/17097HU
Mar 13 17:19:20 amd kernel: EIP: 0060:[<c06e244d>] EFLAGS: 00010282 CPU: 1
Mar 13 17:19:20 amd kernel: EIP is at tcp_v4_rcv+0x19d/0x7d0
Mar 13 17:19:20 amd kernel: EAX: 00000036 EBX: f1232e20 ECX: c06cd093 EDX: f2891e00
Mar 13 17:19:20 amd kernel: ESI: f2f50f48 EDI: f2891e14 EBP: f0c29ddc ESP: f0c29da0
Mar 13 17:19:20 amd kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Mar 13 17:19:20 amd kernel: Process kbnepd bnep0 (pid: 1965, ti=f0c28000 task=f7361648 task.ti=f0c28000)
Mar 13 17:19:20 amd kernel: Stack:
Mar 13 17:19:20 amd kernel: 00005000 6702a8c0 0000c602 00000004 f0c29ddc f2f50f48 f2891e00 0000c602
Mar 13 17:19:20 amd kernel: <0> 00000004 6702a8c0 f1232e20 00000000 c081aab0 f2f50f48 f2891e00 f0c29dfc
Mar 13 17:19:20 amd kernel: <0> c06c5ba3 00000002 00000001 00000000 c06c5b20 f2f50f48 f2f50f48 f0c29e18
Mar 13 17:19:20 amd kernel: Call Trace:
Mar 13 17:19:20 amd kernel: [<c06c5ba3>] ? ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:19:20 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:19:20 amd kernel: [<c06c5d3f>] ? ip_local_deliver+0x8f/0xa0
Mar 13 17:19:20 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:19:20 amd kernel: [<c06c55e3>] ? ip_rcv_finish+0xf3/0x370
Mar 13 17:19:20 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:19:20 amd kernel: [<c06c5a94>] ? ip_rcv+0x234/0x290
Mar 13 17:19:20 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:19:20 amd kernel: [<c0688a70>] ? netif_receive_skb+0x1b0/0x310
Mar 13 17:19:20 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:19:20 amd kernel: [<c0688c32>] ? process_backlog+0x62/0xa0
Mar 13 17:19:20 amd kernel: [<c0688e4d>] ? net_rx_action+0x7d/0x100
Mar 13 17:19:20 amd kernel: [<c023a255>] ? __do_softirq+0x85/0x110
Mar 13 17:19:20 amd kernel: [<c023a30d>] ? do_softirq+0x2d/0x40
Mar 13 17:19:21 amd kernel: [<c06895da>] ? netif_rx_ni+0x1a/0x20
Mar 13 17:19:21 amd kernel: [<c0734c33>] ? bnep_session+0x2c3/0x820
Mar 13 17:19:21 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:19:21 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:19:21 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:19:21 amd kernel: [<c02030f6>] ? kernel_thread_helper+0x6/0x10
Mar 13 17:19:21 amd kernel: Code: b7 1f 8b 8e 88 00 00 00 85 c0 89 45 ec 0f 84 d3 01 00 00 c7 46 68 00 00 00 00 c7 46 10 00 00 00 00 8b 55 dc 8b 5d ec 0f b6 42 08 <3a> 83 45 02 00 00 0f 82 bf 00 00 00 0f b6 43 16 3c 06 0f 85 42
Mar 13 17:19:21 amd kernel: Call Trace:
Mar 13 17:19:21 amd kernel: [<c06c5ba3>] ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:19:21 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:19:21 amd kernel: [<c06c5d3f>] ip_local_deliver+0x8f/0xa0
Mar 13 17:19:21 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:19:21 amd kernel: [<c06c55e3>] ip_rcv_finish+0xf3/0x370
Mar 13 17:19:21 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:19:21 amd kernel: [<c06c5a94>] ip_rcv+0x234/0x290
Mar 13 17:19:21 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:19:21 amd kernel: [<c0688a70>] netif_receive_skb+0x1b0/0x310
Mar 13 17:19:21 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:19:21 amd kernel: [<c0688c32>] process_backlog+0x62/0xa0
Mar 13 17:19:21 amd kernel: [<c0688e4d>] net_rx_action+0x7d/0x100
Mar 13 17:19:21 amd kernel: [<c023a255>] __do_softirq+0x85/0x110
Mar 13 17:19:21 amd kernel: [<c023a30d>] do_softirq+0x2d/0x40
Mar 13 17:19:21 amd kernel: [<c06895da>] netif_rx_ni+0x1a/0x20
Mar 13 17:19:21 amd kernel: [<c0734c33>] bnep_session+0x2c3/0x820
Mar 13 17:19:21 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:19:21 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:19:21 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:19:21 amd kernel: [<c02030f6>] kernel_thread_helper+0x6/0x10
Mar 13 17:19:32 amd su[2469]: pam_unix(su:auth): Couldn't open /etc/securetty: No such file or directory
Mar 13 17:19:33 amd su[2469]: pam_unix(su:auth): Couldn't open /etc/securetty: No such file or directory
Mar 13 17:19:33 amd su[2469]: unknown configuration item `FAIL_DELAY'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `DIALUPS_CHECK_ENAB'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `LASTLOG_ENAB'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `MAIL_CHECK_ENAB'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `OBSCURE_CHECKS_ENAB'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `PORTTIME_CHECKS_ENAB'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `QUOTAS_ENAB'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `NO_PASSWORD_CONSOLE'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `MOTD_FILE'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `NOLOGINS_FILE'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `NOLOGIN_STR'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `ENV_HZ'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `ULIMIT'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `PASS_MIN_LEN'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `SU_WHEEL_ONLY'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `PASS_CHANGE_TRIES'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `PASS_ALWAYS_WARN'
Mar 13 17:19:33 amd su[2469]: unknown configuration item `CHFN_AUTH'
Mar 13 17:19:33 amd su[2469]: Successful su for root by pavel
Mar 13 17:19:33 amd su[2469]: + /dev/ttyp3 pavel:root
Mar 13 17:19:33 amd su[2469]: pam_unix(su:session): session opened for user root by (uid=1000)
Mar 13 17:20:26 amd kernel: BUG: soft lockup - CPU#1 stuck for 61s! [kbnepd bnep0:1965]
Mar 13 17:20:26 amd kernel: Modules linked in:
Mar 13 17:20:26 amd kernel: Modules linked in:
Mar 13 17:20:26 amd kernel:
Mar 13 17:20:26 amd kernel: Pid: 1965, comm: kbnepd bnep0 Tainted: G W 2.6.34-rc1-00182-g3c96f03-dirty #109 17097HU/17097HU
Mar 13 17:20:26 amd kernel: EIP: 0060:[<c06e244d>] EFLAGS: 00010282 CPU: 1
Mar 13 17:20:26 amd kernel: EIP is at tcp_v4_rcv+0x19d/0x7d0
Mar 13 17:20:26 amd kernel: EAX: 00000036 EBX: f1232e20 ECX: c06cd093 EDX: f2891e00
Mar 13 17:20:26 amd kernel: ESI: f2f50f48 EDI: f2891e14 EBP: f0c29ddc ESP: f0c29da0
Mar 13 17:20:26 amd kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Mar 13 17:20:26 amd kernel: Process kbnepd bnep0 (pid: 1965, ti=f0c28000 task=f7361648 task.ti=f0c28000)
Mar 13 17:20:26 amd kernel: Stack:
Mar 13 17:20:26 amd kernel: 00005000 6702a8c0 0000c602 00000004 f0c29ddc f2f50f48 f2891e00 0000c602
Mar 13 17:20:26 amd kernel: <0> 00000004 6702a8c0 f1232e20 00000000 c081aab0 f2f50f48 f2891e00 f0c29dfc
Mar 13 17:20:26 amd kernel: <0> c06c5ba3 00000002 00000001 00000000 c06c5b20 f2f50f48 f2f50f48 f0c29e18
Mar 13 17:20:26 amd kernel: Call Trace:
Mar 13 17:20:26 amd kernel: [<c06c5ba3>] ? ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:20:26 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:20:26 amd kernel: [<c06c5d3f>] ? ip_local_deliver+0x8f/0xa0
Mar 13 17:20:26 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:20:26 amd kernel: [<c06c55e3>] ? ip_rcv_finish+0xf3/0x370
Mar 13 17:20:26 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:20:26 amd kernel: [<c06c5a94>] ? ip_rcv+0x234/0x290
Mar 13 17:20:26 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:20:26 amd kernel: [<c0688a70>] ? netif_receive_skb+0x1b0/0x310
Mar 13 17:20:26 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:20:26 amd kernel: [<c0688c32>] ? process_backlog+0x62/0xa0
Mar 13 17:20:26 amd kernel: [<c0688e4d>] ? net_rx_action+0x7d/0x100
Mar 13 17:20:26 amd kernel: [<c023a255>] ? __do_softirq+0x85/0x110
Mar 13 17:20:26 amd kernel: [<c023a30d>] ? do_softirq+0x2d/0x40
Mar 13 17:20:26 amd kernel: [<c06895da>] ? netif_rx_ni+0x1a/0x20
Mar 13 17:20:26 amd kernel: [<c0734c33>] ? bnep_session+0x2c3/0x820
Mar 13 17:20:26 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:20:26 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:20:26 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:20:26 amd kernel: [<c02030f6>] ? kernel_thread_helper+0x6/0x10
Mar 13 17:20:26 amd kernel: Code: b7 1f 8b 8e 88 00 00 00 85 c0 89 45 ec 0f 84 d3 01 00 00 c7 46 68 00 00 00 00 c7 46 10 00 00 00 00 8b 55 dc 8b 5d ec 0f b6 42 08 <3a> 83 45 02 00 00 0f 82 bf 00 00 00 0f b6 43 16 3c 06 0f 85 42
Mar 13 17:20:26 amd kernel: Call Trace:
Mar 13 17:20:26 amd kernel: [<c06c5ba3>] ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:20:26 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:20:26 amd kernel: [<c06c5d3f>] ip_local_deliver+0x8f/0xa0
Mar 13 17:20:26 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:20:26 amd kernel: [<c06c55e3>] ip_rcv_finish+0xf3/0x370
Mar 13 17:20:26 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:20:26 amd kernel: [<c06c5a94>] ip_rcv+0x234/0x290
Mar 13 17:20:26 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:20:26 amd kernel: [<c0688a70>] netif_receive_skb+0x1b0/0x310
Mar 13 17:20:26 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:20:26 amd kernel: [<c0688c32>] process_backlog+0x62/0xa0
Mar 13 17:20:26 amd kernel: [<c0688e4d>] net_rx_action+0x7d/0x100
Mar 13 17:20:26 amd kernel: [<c023a255>] __do_softirq+0x85/0x110
Mar 13 17:20:26 amd kernel: [<c023a30d>] do_softirq+0x2d/0x40
Mar 13 17:20:26 amd kernel: [<c06895da>] netif_rx_ni+0x1a/0x20
Mar 13 17:20:26 amd kernel: [<c0734c33>] bnep_session+0x2c3/0x820
Mar 13 17:20:26 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:20:26 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:20:26 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:20:26 amd kernel: [<c02030f6>] kernel_thread_helper+0x6/0x10
Mar 13 17:21:31 amd kernel: BUG: soft lockup - CPU#1 stuck for 61s! [kbnepd bnep0:1965]
Mar 13 17:21:31 amd kernel: Modules linked in:
Mar 13 17:21:31 amd kernel: Modules linked in:
Mar 13 17:21:31 amd kernel:
Mar 13 17:21:31 amd kernel: Pid: 1965, comm: kbnepd bnep0 Tainted: G W 2.6.34-rc1-00182-g3c96f03-dirty #109 17097HU/17097HU
Mar 13 17:21:31 amd kernel: EIP: 0060:[<c06e244d>] EFLAGS: 00010282 CPU: 1
Mar 13 17:21:31 amd kernel: EIP is at tcp_v4_rcv+0x19d/0x7d0
Mar 13 17:21:31 amd kernel: EAX: 00000036 EBX: f1232e20 ECX: c06cd093 EDX: f2891e00
Mar 13 17:21:31 amd kernel: ESI: f2f50f48 EDI: f2891e14 EBP: f0c29ddc ESP: f0c29da0
Mar 13 17:21:31 amd kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Mar 13 17:21:31 amd kernel: Process kbnepd bnep0 (pid: 1965, ti=f0c28000 task=f7361648 task.ti=f0c28000)
Mar 13 17:21:31 amd kernel: Stack:
Mar 13 17:21:31 amd kernel: 00005000 6702a8c0 0000c602 00000004 f0c29ddc f2f50f48 f2891e00 0000c602
Mar 13 17:21:31 amd kernel: <0> 00000004 6702a8c0 f1232e20 00000000 c081aab0 f2f50f48 f2891e00 f0c29dfc
Mar 13 17:21:31 amd kernel: <0> c06c5ba3 00000002 00000001 00000000 c06c5b20 f2f50f48 f2f50f48 f0c29e18
Mar 13 17:21:31 amd kernel: Call Trace:
Mar 13 17:21:31 amd kernel: [<c06c5ba3>] ? ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:21:31 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:21:31 amd kernel: [<c06c5d3f>] ? ip_local_deliver+0x8f/0xa0
Mar 13 17:21:31 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:21:31 amd kernel: [<c06c55e3>] ? ip_rcv_finish+0xf3/0x370
Mar 13 17:21:31 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:21:31 amd kernel: [<c06c5a94>] ? ip_rcv+0x234/0x290
Mar 13 17:21:31 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:21:31 amd kernel: [<c0688a70>] ? netif_receive_skb+0x1b0/0x310
Mar 13 17:21:31 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:21:31 amd kernel: [<c0688c32>] ? process_backlog+0x62/0xa0
Mar 13 17:21:31 amd kernel: [<c0688e4d>] ? net_rx_action+0x7d/0x100
Mar 13 17:21:31 amd kernel: [<c023a255>] ? __do_softirq+0x85/0x110
Mar 13 17:21:31 amd kernel: [<c023a30d>] ? do_softirq+0x2d/0x40
Mar 13 17:21:31 amd kernel: [<c06895da>] ? netif_rx_ni+0x1a/0x20
Mar 13 17:21:31 amd kernel: [<c0734c33>] ? bnep_session+0x2c3/0x820
Mar 13 17:21:31 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:21:31 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:21:31 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:21:31 amd kernel: [<c02030f6>] ? kernel_thread_helper+0x6/0x10
Mar 13 17:21:31 amd kernel: Code: b7 1f 8b 8e 88 00 00 00 85 c0 89 45 ec 0f 84 d3 01 00 00 c7 46 68 00 00 00 00 c7 46 10 00 00 00 00 8b 55 dc 8b 5d ec 0f b6 42 08 <3a> 83 45 02 00 00 0f 82 bf 00 00 00 0f b6 43 16 3c 06 0f 85 42
Mar 13 17:21:31 amd kernel: Call Trace:
Mar 13 17:21:31 amd kernel: [<c06c5ba3>] ip_local_deliver_finish+0xb3/0x1c0
Mar 13 17:21:31 amd kernel: [<c06c5b20>] ? ip_local_deliver_finish+0x30/0x1c0
Mar 13 17:21:31 amd kernel: [<c06c5d3f>] ip_local_deliver+0x8f/0xa0
Mar 13 17:21:31 amd kernel: [<c06c5af0>] ? ip_local_deliver_finish+0x0/0x1c0
Mar 13 17:21:31 amd kernel: [<c06c55e3>] ip_rcv_finish+0xf3/0x370
Mar 13 17:21:31 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:21:31 amd kernel: [<c06c5a94>] ip_rcv+0x234/0x290
Mar 13 17:21:31 amd kernel: [<c06c54f0>] ? ip_rcv_finish+0x0/0x370
Mar 13 17:21:31 amd kernel: [<c0688a70>] netif_receive_skb+0x1b0/0x310
Mar 13 17:21:31 amd kernel: [<c0688971>] ? netif_receive_skb+0xb1/0x310
Mar 13 17:21:31 amd kernel: [<c0688c32>] process_backlog+0x62/0xa0
Mar 13 17:21:31 amd kernel: [<c0688e4d>] net_rx_action+0x7d/0x100
Mar 13 17:21:32 amd kernel: [<c023a255>] __do_softirq+0x85/0x110
Mar 13 17:21:32 amd kernel: [<c023a30d>] do_softirq+0x2d/0x40
Mar 13 17:21:32 amd kernel: [<c06895da>] netif_rx_ni+0x1a/0x20
Mar 13 17:21:32 amd kernel: [<c0734c33>] bnep_session+0x2c3/0x820
Mar 13 17:21:32 amd kernel: [<c07ad6ad>] ? _raw_spin_unlock_irq+0x1d/0x30
Mar 13 17:21:32 amd kernel: [<c02305e0>] ? default_wake_function+0x0/0x10
Mar 13 17:21:32 amd kernel: [<c0734970>] ? bnep_session+0x0/0x820
Mar 13 17:21:32 amd kernel: [<c02030f6>] kernel_thread_helper+0x6/0x10
Mar 13 17:21:33 amd su[2507]: unknown configuration item `FAIL_DELAY'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `DIALUPS_CHECK_ENAB'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `LASTLOG_ENAB'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `MAIL_CHECK_ENAB'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `OBSCURE_CHECKS_ENAB'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `PORTTIME_CHECKS_ENAB'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `QUOTAS_ENAB'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `NO_PASSWORD_CONSOLE'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `MOTD_FILE'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `NOLOGINS_FILE'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `NOLOGIN_STR'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `ENV_HZ'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `ULIMIT'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `PASS_MIN_LEN'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `SU_WHEEL_ONLY'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `PASS_CHANGE_TRIES'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `PASS_ALWAYS_WARN'
Mar 13 17:21:33 amd su[2507]: unknown configuration item `CHFN_AUTH'
Mar 13 17:21:33 amd su[2507]: Successful su for root by root
Mar 13 17:21:33 amd su[2507]: + /dev/ttyp3 root:root
Mar 13 17:21:33 amd su[2507]: pam_unix(su:session): session opened for user root by (uid=0)
Mar 13 17:21:37 amd pand[2532]: Bluetooth PAN daemon version 4.57
Mar 13 17:21:37 amd pand[2532]: Connecting to 00:21:BA:FF:2D:37
Mar 13 17:21:37 amd pand[2532]: Connect to 00:21:BA:FF:2D:37 failed. File exists(17)
Mar 13 17:22:58 amd syslogd 1.5.0#5: restart.
Mar 13 17:22:58 amd kernel: klogd 1.5.0#5, log source = /proc/kmsg started.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Openmoko and HFP
From: Gustavo F. Padovan @ 2010-03-14 18:43 UTC (permalink / raw)
To: dehqan65; +Cc: linux-bluetooth
In-Reply-To: <267bb6671003140945l7f49328cs3cbf6eea5a85dd35@mail.gmail.com>
Hi deqhan,
* dehqan65 <dehqan65@gmail.com> [2010-03-14 20:15:25 +0330]:
> In The Name Of God The compassionate merciful
>
> Good day all ;
> There is a tool for converting laptop as headset . Tool >
> http://nohands.sourceforge.net
You can try the native HFP implementation on BlueZ recently merged. You
will need oFono as an agent and Pulseaudio for the audio stuff. I think
it's not ready for production, we might have some bugs yet.
> Humble tested it with sony ericson phone and it worked , so was able
> to dial and talk from laptop .
> But it does not work with Freerunner phone (SHR os) .
> Does this can solve it ??
> http://marc.info/?l=linux-bluetooth&m=126810597223611&w=2
> How to make it works ?
>
> Regards dehqan
> --
> 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
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Openmoko and HFP
From: dehqan65 @ 2010-03-14 16:45 UTC (permalink / raw)
To: linux-bluetooth
In The Name Of God The compassionate merciful
Good day all ;
There is a tool for converting laptop as headset . Tool >
http://nohands.sourceforge.net
Humble tested it with sony ericson phone and it worked , so was able
to dial and talk from laptop .
But it does not work with Freerunner phone (SHR os) .
Does this can solve it ??
http://marc.info/?l=linux-bluetooth&m=126810597223611&w=2
How to make it works ?
Regards dehqan
^ 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