Hi John
Here's another set of patches for 3.19. Most of it is again fixes and
cleanups to ieee802154 related code from Alexander Aring. We've also got
better handling of hardware error events along with a proper API for HCI
drivers to notify the HCI core of such situations. There's also a minor
fix for mgmt events as well as a sparse warning fix. The code for
sending HCI commands synchronously also gets a fix where we might loose
the completion event in the case of very fast HW (particularly easily
reproducible with an emulated HCI device).
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit 6bc6c49f1e2f3ab1bec05d1c08aad219ab4eb5d0:
mwifiex: add cfg80211 dump_survey handler (2014-10-31 16:07:49 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream
for you to fetch changes up to 56b2c3eea398c772dd895dc62c18cbdd1ba127b1:
6lowpan: move skb_free from error paths in decompression (2014-11-06 22:09:48 +0100)
----------------------------------------------------------------
Alexander Aring (41):
at86rf230: fix page parameter constraints
ieee802154: remove default channel settings
at86rf230: add default channel settings
cfg802154: introduce cfg802154_registered_device
mac802154: introduce mac802154_config_ops
ieee802154: add helper wpan_phy_to_rdev function
cfg802154: convert deprecated iface add and del
ieee802154: don't allow to change addr while netif_running
mac802154: add helper for converting dev_addr
mac802154: set extended address filter on ifup
mac802154: set short address filter on ifup
mac802154: set panid address filter on ifup
mac802154: move phy settings into netlink receive
ieee802154: add extended address validation helper
mac802154: iface: add validation for extended address
ieee802154: 6lowpan: remove set of mac address
ieee802154: add missing ULL definition
ieee802154: fix byteorder issues
mac802154: fix byteorder issues
ieee802154: sysfs: add missing include
mac802154: cfg: add missing include
ieee802154: remove unnecessary functions
netdevice: add ieee802154_ptr to net_device
ieee802154: rework wpan_phy index assignment
ieee802154: remove nl802154 unused functions
mac802154: move interface del handling in iface
mac802154: move interface add handling in iface
mac802154: move dev_hold out of ieee802154_if_add
ieee802154: rework interface registration
ieee802154: remove mlme get_phy callback
mac802154: add default interface registration
mac802154: add ieee802154_vif struct
ieee802154: add IEEE802154_EXTENDED_ADDR_LEN
ieee802154: add ieee802154_random_extended_addr
mac802154: add ieee802154_le64_to_be64
mac802154: cleanup ieee802154_netdev_to_extended_addr
mac802154: add support for perm_extended_addr
at86rf230: generate random perm extended address
at86rf230: add force slotted operation bit
mac802154: use IEEE802154_EXTENDED_ADDR_LEN
mac802154: fix typo promisuous to promiscuous
Chan-yeol Park (1):
Bluetooth: Fix hci_sync missing wakeup interrupt
Dan Carpenter (1):
ieee802154: || vs && in ieee802154_is_valid_extended_addr()
Fengguang Wu (1):
at86rf230: fix simple_return.cocci warnings
Johan Hedberg (1):
Bluetooth: Fix sparse warnings in RFCOMM
Kuba Pawlak (2):
Bluetooth: Clear role switch pending flag
Bluetooth: Sort switch cases by opcode's numeric value
Marcel Holtmann (11):
Bluetooth: Check status of command complete for HCI_Reset
Bluetooth: Print error message for HCI_Hardware_Error event
Bluetooth: Use HCI_EV_HARDWARE_ERROR define for event payload
Bluetooth: Introduce BT_BREDR and BT_LE config options
Bluetooth: Add hci_reset_dev() for driver triggerd stack reset
Bluetooth: Switch HCI H5 driver to use hci_reset_dev() function
Bluetooth: Introduce HCI_QUIRK_STRICT_DUPLICATE_FILTER
Bluetooth: Set HCI_QUIRK_STRICT_DUPLICATE_FILTER for Broadcom devices
Bluetooth: Consolidate whitelist debugfs entry into device_list
Bluetooth: btusb: Add internal callback for USB bulk rx data
Bluetooth: Add hci_conn_lookup_type() helper function
Martin Townsend (1):
6lowpan: move skb_free from error paths in decompression
Simon Vincent (1):
6lowpan: fix udp header compression when using raw sockets
Szymon Janc (1):
Bluetooth: Fix invalid response for 'Start Discovery' command
MAINTAINERS | 1 -
drivers/bluetooth/btusb.c | 7 +-
drivers/bluetooth/hci_h5.c | 13 +--
drivers/net/ieee802154/at86rf230.c | 13 ++-
drivers/net/ieee802154/cc2520.c | 1 +
include/linux/ieee802154.h | 32 ++++++
include/linux/netdevice.h | 3 +
include/net/bluetooth/hci.h | 15 +++
include/net/bluetooth/hci_core.h | 21 ++++
include/net/cfg802154.h | 24 +++--
include/net/ieee802154_netdev.h | 12 ---
include/net/mac802154.h | 33 ++++++
include/net/nl802154.h | 122 ---------------------
net/6lowpan/iphc.c | 41 +++----
net/bluetooth/6lowpan.c | 15 ++-
net/bluetooth/Kconfig | 20 +++-
net/bluetooth/bnep/Kconfig | 2 +-
net/bluetooth/cmtp/Kconfig | 2 +-
net/bluetooth/hci_core.c | 72 ++++++-------
net/bluetooth/hci_event.c | 61 +++++++++--
net/bluetooth/hidp/Kconfig | 2 +-
net/bluetooth/mgmt.c | 56 ++++++----
net/bluetooth/rfcomm/Kconfig | 2 +-
net/bluetooth/rfcomm/core.c | 6 +-
net/ieee802154/6lowpan_rtnl.c | 38 ++-----
net/ieee802154/core.c | 64 +++++------
net/ieee802154/core.h | 29 +++++
net/ieee802154/nl-mac.c | 203 ++++-------------------------------
net/ieee802154/nl-phy.c | 23 ++--
net/ieee802154/rdev-ops.h | 23 ++++
net/ieee802154/sysfs.c | 16 ++-
net/mac802154/Makefile | 2 +-
net/mac802154/cfg.c | 47 ++++++++
net/mac802154/cfg.h | 9 ++
net/mac802154/ieee802154_i.h | 17 ++-
net/mac802154/iface.c | 195 +++++++++++++++++++++------------
net/mac802154/mac_cmd.c | 42 ++++----
net/mac802154/main.c | 102 +++---------------
net/mac802154/mib.c | 71 ------------
net/mac802154/rx.c | 4 +-
40 files changed, 678 insertions(+), 783 deletions(-)
delete mode 100644 include/net/nl802154.h
create mode 100644 net/ieee802154/core.h
create mode 100644 net/ieee802154/rdev-ops.h
create mode 100644 net/mac802154/cfg.c
create mode 100644 net/mac802154/cfg.h
On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote:
> Hi John
>
> Here's another set of patches for 3.19. Most of it is again fixes and
> cleanups to ieee802154 related code from Alexander Aring. We've also got
> better handling of hardware error events along with a proper API for HCI
> drivers to notify the HCI core of such situations. There's also a minor
> fix for mgmt events as well as a sparse warning fix. The code for
> sending HCI commands synchronously also gets a fix where we might loose
> the completion event in the case of very fast HW (particularly easily
> reproducible with an emulated HCI device).
>
> Please let me know if there are any issues pulling. Thanks.
>
> Johan
>
> ---
> The following changes since commit 6bc6c49f1e2f3ab1bec05d1c08aad219ab4eb5d0:
>
> mwifiex: add cfg80211 dump_survey handler (2014-10-31 16:07:49 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream
>
> for you to fetch changes up to 56b2c3eea398c772dd895dc62c18cbdd1ba127b1:
>
> 6lowpan: move skb_free from error paths in decompression (2014-11-06 22:09:48 +0100)
Pulling now...
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote:
> Chan-yeol Park (1):
> Bluetooth: Fix hci_sync missing wakeup interrupt
Look like this commit causes problem for me:
[ 2.018671] ------------[ cut here ]------------
[ 2.022836] WARNING: CPU: 2 PID: 109 at /home/kas/git/public/linux/kernel/sched/core.c:7323 __might_sleep+0xbd/0xd0()
[ 2.023166] Freeing unused kernel memory: 944K (ffff880001b14000 - ffff880001c00000)
[ 2.030362] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff819ab67b>] __hci_req_sync+0x7b/0x2a0
[ 2.034193] Modules linked in:
[ 2.036133] CPU: 2 PID: 109 Comm: kworker/u17:0 Not tainted 3.18.0-rc4-next-20141117-07404-g9dad2ab6df8b #66
[ 2.036383] Freeing unused kernel memory: 1404K (ffff8800020a1000 - ffff880002200000)
[ 2.038940] Hardware name: LENOVO 3460CC6/3460CC6, BIOS G6ET93WW (2.53 ) 02/04/2013
[ 2.040233] Workqueue: hci0 hci_power_on
[ 2.041517] ffffffff81f51d50 ffff8800d3ecfb28 ffffffff81afc316 0000000000000000
[ 2.042811] ffff8800d3ecfb78 ffff8800d3ecfb68 ffffffff810fc11a ffff880000000000
[ 2.042812] ffffffff81f52a28 000000000000026d 0000000000000000 ffff8800d3ec9200
[ 2.042813] Call Trace:
[ 2.042818] [<ffffffff81afc316>] dump_stack+0x4c/0x6e
[ 2.042821] [<ffffffff810fc11a>] warn_slowpath_common+0x8a/0xc0
[ 2.042823] [<ffffffff810fc196>] warn_slowpath_fmt+0x46/0x50
[ 2.042825] [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
[ 2.042827] [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
[ 2.042830] [<ffffffff811295ed>] __might_sleep+0xbd/0xd0
[ 2.042832] [<ffffffff81b04b8f>] mutex_lock_nested+0x2f/0x450
[ 2.042835] [<ffffffff81b0812b>] ? _raw_spin_unlock+0x2b/0x50
[ 2.042837] [<ffffffff81131db0>] ? wake_up_process+0x50/0x50
[ 2.042840] [<ffffffff813b9ea1>] __create_file+0x71/0x2c0
[ 2.042842] [<ffffffff813ba10f>] debugfs_create_file+0x1f/0x30
[ 2.042844] [<ffffffff819ac461>] hci_dev_do_open+0x431/0xa70
[ 2.042846] [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
[ 2.042847] [<ffffffff819ad2b1>] hci_power_on+0x31/0x1e0
[ 2.042849] [<ffffffff8111a7c8>] process_one_work+0x1d8/0x810
[ 2.042850] [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
[ 2.042851] [<ffffffff8111b2db>] worker_thread+0x6b/0x4b0
[ 2.042852] [<ffffffff8111b270>] ? init_pwq+0xf0/0xf0
[ 2.042854] [<ffffffff81120ef9>] kthread+0x119/0x130
[ 2.042855] [<ffffffff8112923d>] ? finish_task_switch+0x4d/0x140
[ 2.042857] [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
[ 2.042859] [<ffffffff81b08cfc>] ret_from_fork+0x7c/0xb0
[ 2.042861] [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
[ 2.042863] ---[ end trace 3a40e80ec4ca7159 ]---
--
Kirill A. Shutemov
Hi Kirill,
On Tue, Nov 18, 2014, Kirill A. Shutemov wrote:
> On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote:
> > Chan-yeol Park (1):
> > Bluetooth: Fix hci_sync missing wakeup interrupt
>
> Look like this commit causes problem for me:
>
> [ 2.018671] ------------[ cut here ]------------
> [ 2.022836] WARNING: CPU: 2 PID: 109 at /home/kas/git/public/linux/kernel/sched/core.c:7323 __might_sleep+0xbd/0xd0()
> [ 2.023166] Freeing unused kernel memory: 944K (ffff880001b14000 - ffff880001c00000)
> [ 2.030362] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff819ab67b>] __hci_req_sync+0x7b/0x2a0
> [ 2.034193] Modules linked in:
> [ 2.036133] CPU: 2 PID: 109 Comm: kworker/u17:0 Not tainted 3.18.0-rc4-next-20141117-07404-g9dad2ab6df8b #66
> [ 2.036383] Freeing unused kernel memory: 1404K (ffff8800020a1000 - ffff880002200000)
> [ 2.038940] Hardware name: LENOVO 3460CC6/3460CC6, BIOS G6ET93WW (2.53 ) 02/04/2013
> [ 2.040233] Workqueue: hci0 hci_power_on
> [ 2.041517] ffffffff81f51d50 ffff8800d3ecfb28 ffffffff81afc316 0000000000000000
> [ 2.042811] ffff8800d3ecfb78 ffff8800d3ecfb68 ffffffff810fc11a ffff880000000000
> [ 2.042812] ffffffff81f52a28 000000000000026d 0000000000000000 ffff8800d3ec9200
> [ 2.042813] Call Trace:
> [ 2.042818] [<ffffffff81afc316>] dump_stack+0x4c/0x6e
> [ 2.042821] [<ffffffff810fc11a>] warn_slowpath_common+0x8a/0xc0
> [ 2.042823] [<ffffffff810fc196>] warn_slowpath_fmt+0x46/0x50
> [ 2.042825] [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
> [ 2.042827] [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
> [ 2.042830] [<ffffffff811295ed>] __might_sleep+0xbd/0xd0
> [ 2.042832] [<ffffffff81b04b8f>] mutex_lock_nested+0x2f/0x450
> [ 2.042835] [<ffffffff81b0812b>] ? _raw_spin_unlock+0x2b/0x50
> [ 2.042837] [<ffffffff81131db0>] ? wake_up_process+0x50/0x50
> [ 2.042840] [<ffffffff813b9ea1>] __create_file+0x71/0x2c0
> [ 2.042842] [<ffffffff813ba10f>] debugfs_create_file+0x1f/0x30
> [ 2.042844] [<ffffffff819ac461>] hci_dev_do_open+0x431/0xa70
> [ 2.042846] [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
> [ 2.042847] [<ffffffff819ad2b1>] hci_power_on+0x31/0x1e0
> [ 2.042849] [<ffffffff8111a7c8>] process_one_work+0x1d8/0x810
> [ 2.042850] [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
> [ 2.042851] [<ffffffff8111b2db>] worker_thread+0x6b/0x4b0
> [ 2.042852] [<ffffffff8111b270>] ? init_pwq+0xf0/0xf0
> [ 2.042854] [<ffffffff81120ef9>] kthread+0x119/0x130
> [ 2.042855] [<ffffffff8112923d>] ? finish_task_switch+0x4d/0x140
> [ 2.042857] [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
> [ 2.042859] [<ffffffff81b08cfc>] ret_from_fork+0x7c/0xb0
> [ 2.042861] [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
> [ 2.042863] ---[ end trace 3a40e80ec4ca7159 ]---
At least one obvious bug that the patch in question seems to have is
that it fails to set the state back to TASK_RUNNING in case
hci_req_run() fails and we never call schedule_timeout(). This would
also seem to match the error you're getting.
The attached patch fixes the missing set_current_state() calls - could
you please check if it fixes the issue for you? Out of curiosity, which
HW are you reproducing this with and are there any special steps
involved? Looking at the code it seems that at least some older
Bluetooth adapters could cause some hci_req_run() calls to return
ENODATA, however I wasn't able to get the warning with any of my own
adapters (I have one for pretty much every Bluetooth version).
Johan
Hi All
On 11/19/2014 03:09 AM, Johan Hedberg wrote:
> Hi Kirill,
>
> On Tue, Nov 18, 2014, Kirill A. Shutemov wrote:
>> On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote:
>>> Chan-yeol Park (1):
>>> Bluetooth: Fix hci_sync missing wakeup interrupt
>> Look like this commit causes problem for me:
>>
>> [ 2.018671] ------------[ cut here ]------------
>> [ 2.022836] WARNING: CPU: 2 PID: 109 at /home/kas/git/public/linux/kernel/sched/core.c:7323 __might_sleep+0xbd/0xd0()
>> [ 2.023166] Freeing unused kernel memory: 944K (ffff880001b14000 - ffff880001c00000)
>> [ 2.030362] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff819ab67b>] __hci_req_sync+0x7b/0x2a0
>> [ 2.034193] Modules linked in:
>> [ 2.036133] CPU: 2 PID: 109 Comm: kworker/u17:0 Not tainted 3.18.0-rc4-next-20141117-07404-g9dad2ab6df8b #66
>> [ 2.036383] Freeing unused kernel memory: 1404K (ffff8800020a1000 - ffff880002200000)
>> [ 2.038940] Hardware name: LENOVO 3460CC6/3460CC6, BIOS G6ET93WW (2.53 ) 02/04/2013
>> [ 2.040233] Workqueue: hci0 hci_power_on
>> [ 2.041517] ffffffff81f51d50 ffff8800d3ecfb28 ffffffff81afc316 0000000000000000
>> [ 2.042811] ffff8800d3ecfb78 ffff8800d3ecfb68 ffffffff810fc11a ffff880000000000
>> [ 2.042812] ffffffff81f52a28 000000000000026d 0000000000000000 ffff8800d3ec9200
>> [ 2.042813] Call Trace:
>> [ 2.042818] [<ffffffff81afc316>] dump_stack+0x4c/0x6e
>> [ 2.042821] [<ffffffff810fc11a>] warn_slowpath_common+0x8a/0xc0
>> [ 2.042823] [<ffffffff810fc196>] warn_slowpath_fmt+0x46/0x50
>> [ 2.042825] [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
>> [ 2.042827] [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
>> [ 2.042830] [<ffffffff811295ed>] __might_sleep+0xbd/0xd0
>> [ 2.042832] [<ffffffff81b04b8f>] mutex_lock_nested+0x2f/0x450
>> [ 2.042835] [<ffffffff81b0812b>] ? _raw_spin_unlock+0x2b/0x50
>> [ 2.042837] [<ffffffff81131db0>] ? wake_up_process+0x50/0x50
>> [ 2.042840] [<ffffffff813b9ea1>] __create_file+0x71/0x2c0
>> [ 2.042842] [<ffffffff813ba10f>] debugfs_create_file+0x1f/0x30
>> [ 2.042844] [<ffffffff819ac461>] hci_dev_do_open+0x431/0xa70
>> [ 2.042846] [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
>> [ 2.042847] [<ffffffff819ad2b1>] hci_power_on+0x31/0x1e0
>> [ 2.042849] [<ffffffff8111a7c8>] process_one_work+0x1d8/0x810
>> [ 2.042850] [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
>> [ 2.042851] [<ffffffff8111b2db>] worker_thread+0x6b/0x4b0
>> [ 2.042852] [<ffffffff8111b270>] ? init_pwq+0xf0/0xf0
>> [ 2.042854] [<ffffffff81120ef9>] kthread+0x119/0x130
>> [ 2.042855] [<ffffffff8112923d>] ? finish_task_switch+0x4d/0x140
>> [ 2.042857] [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
>> [ 2.042859] [<ffffffff81b08cfc>] ret_from_fork+0x7c/0xb0
>> [ 2.042861] [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
>> [ 2.042863] ---[ end trace 3a40e80ec4ca7159 ]---
> At least one obvious bug that the patch in question seems to have is
> that it fails to set the state back to TASK_RUNNING in case
> hci_req_run() fails and we never call schedule_timeout(). This would
> also seem to match the error you're getting.
>
> The attached patch fixes the missing set_current_state() calls - could
> you please check if it fixes the issue for you? Out of curiosity, which
> HW are you reproducing this with and are there any special steps
> involved? Looking at the code it seems that at least some older
> Bluetooth adapters could cause some hci_req_run() calls to return
> ENODATA, however I wasn't able to get the warning with any of my own
> adapters (I have one for pretty much every Bluetooth version).
>
> Johan
I agree I made a bug in the previous commit and I think we need to apply
Johan's patch.
It is working fine on my machine.
Thanks
Chanyeol
Hi
On 11/19/2014 03:09 AM, Johan Hedberg wrote:
> Hi Kirill,
>
> On Tue, Nov 18, 2014, Kirill A. Shutemov wrote:
>> On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote:
>>> Chan-yeol Park (1):
>>> Bluetooth: Fix hci_sync missing wakeup interrupt
>> Look like this commit causes problem for me:
>>
>> [ 2.018671] ------------[ cut here ]------------
>> [ 2.022836] WARNING: CPU: 2 PID: 109 at /home/kas/git/public/linux/kernel/sched/core.c:7323 __might_sleep+0xbd/0xd0()
>> [ 2.023166] Freeing unused kernel memory: 944K (ffff880001b14000 - ffff880001c00000)
>> [ 2.030362] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff819ab67b>] __hci_req_sync+0x7b/0x2a0
>> [ 2.034193] Modules linked in:
>> [ 2.036133] CPU: 2 PID: 109 Comm: kworker/u17:0 Not tainted 3.18.0-rc4-next-20141117-07404-g9dad2ab6df8b #66
>> [ 2.036383] Freeing unused kernel memory: 1404K (ffff8800020a1000 - ffff880002200000)
>> [ 2.038940] Hardware name: LENOVO 3460CC6/3460CC6, BIOS G6ET93WW (2.53 ) 02/04/2013
>> [ 2.040233] Workqueue: hci0 hci_power_on
>> [ 2.041517] ffffffff81f51d50 ffff8800d3ecfb28 ffffffff81afc316 0000000000000000
>> [ 2.042811] ffff8800d3ecfb78 ffff8800d3ecfb68 ffffffff810fc11a ffff880000000000
>> [ 2.042812] ffffffff81f52a28 000000000000026d 0000000000000000 ffff8800d3ec9200
>> [ 2.042813] Call Trace:
>> [ 2.042818] [<ffffffff81afc316>] dump_stack+0x4c/0x6e
>> [ 2.042821] [<ffffffff810fc11a>] warn_slowpath_common+0x8a/0xc0
>> [ 2.042823] [<ffffffff810fc196>] warn_slowpath_fmt+0x46/0x50
>> [ 2.042825] [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
>> [ 2.042827] [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
>> [ 2.042830] [<ffffffff811295ed>] __might_sleep+0xbd/0xd0
>> [ 2.042832] [<ffffffff81b04b8f>] mutex_lock_nested+0x2f/0x450
>> [ 2.042835] [<ffffffff81b0812b>] ? _raw_spin_unlock+0x2b/0x50
>> [ 2.042837] [<ffffffff81131db0>] ? wake_up_process+0x50/0x50
>> [ 2.042840] [<ffffffff813b9ea1>] __create_file+0x71/0x2c0
>> [ 2.042842] [<ffffffff813ba10f>] debugfs_create_file+0x1f/0x30
>> [ 2.042844] [<ffffffff819ac461>] hci_dev_do_open+0x431/0xa70
>> [ 2.042846] [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
>> [ 2.042847] [<ffffffff819ad2b1>] hci_power_on+0x31/0x1e0
>> [ 2.042849] [<ffffffff8111a7c8>] process_one_work+0x1d8/0x810
>> [ 2.042850] [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
>> [ 2.042851] [<ffffffff8111b2db>] worker_thread+0x6b/0x4b0
>> [ 2.042852] [<ffffffff8111b270>] ? init_pwq+0xf0/0xf0
>> [ 2.042854] [<ffffffff81120ef9>] kthread+0x119/0x130
>> [ 2.042855] [<ffffffff8112923d>] ? finish_task_switch+0x4d/0x140
>> [ 2.042857] [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
>> [ 2.042859] [<ffffffff81b08cfc>] ret_from_fork+0x7c/0xb0
>> [ 2.042861] [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
>> [ 2.042863] ---[ end trace 3a40e80ec4ca7159 ]---
> At least one obvious bug that the patch in question seems to have is
> that it fails to set the state back to TASK_RUNNING in case
> hci_req_run() fails and we never call schedule_timeout(). This would
> also seem to match the error you're getting.
>
> The attached patch fixes the missing set_current_state() calls - could
> you please check if it fixes the issue for you? Out of curiosity, which
> HW are you reproducing this with and are there any special steps
> involved? Looking at the code it seems that at least some older
> Bluetooth adapters could cause some hci_req_run() calls to return
> ENODATA, however I wasn't able to get the warning with any of my own
> adapters (I have one for pretty much every Bluetooth version).
>
> Johan
I agree I made a bug in the previous commit and I think we need to apply
Johan's patch.
It is working fine on my machine.
Thanks
Chanyeol
On Tue, Nov 18, 2014 at 08:09:19PM +0200, Johan Hedberg wrote:
> Hi Kirill,
>
> On Tue, Nov 18, 2014, Kirill A. Shutemov wrote:
> > On Fri, Nov 07, 2014 at 11:27:54AM +0200, Johan Hedberg wrote:
> > > Chan-yeol Park (1):
> > > Bluetooth: Fix hci_sync missing wakeup interrupt
> >
> > Look like this commit causes problem for me:
> >
> > [ 2.018671] ------------[ cut here ]------------
> > [ 2.022836] WARNING: CPU: 2 PID: 109 at /home/kas/git/public/linux/kernel/sched/core.c:7323 __might_sleep+0xbd/0xd0()
> > [ 2.023166] Freeing unused kernel memory: 944K (ffff880001b14000 - ffff880001c00000)
> > [ 2.030362] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff819ab67b>] __hci_req_sync+0x7b/0x2a0
> > [ 2.034193] Modules linked in:
> > [ 2.036133] CPU: 2 PID: 109 Comm: kworker/u17:0 Not tainted 3.18.0-rc4-next-20141117-07404-g9dad2ab6df8b #66
> > [ 2.036383] Freeing unused kernel memory: 1404K (ffff8800020a1000 - ffff880002200000)
> > [ 2.038940] Hardware name: LENOVO 3460CC6/3460CC6, BIOS G6ET93WW (2.53 ) 02/04/2013
> > [ 2.040233] Workqueue: hci0 hci_power_on
> > [ 2.041517] ffffffff81f51d50 ffff8800d3ecfb28 ffffffff81afc316 0000000000000000
> > [ 2.042811] ffff8800d3ecfb78 ffff8800d3ecfb68 ffffffff810fc11a ffff880000000000
> > [ 2.042812] ffffffff81f52a28 000000000000026d 0000000000000000 ffff8800d3ec9200
> > [ 2.042813] Call Trace:
> > [ 2.042818] [<ffffffff81afc316>] dump_stack+0x4c/0x6e
> > [ 2.042821] [<ffffffff810fc11a>] warn_slowpath_common+0x8a/0xc0
> > [ 2.042823] [<ffffffff810fc196>] warn_slowpath_fmt+0x46/0x50
> > [ 2.042825] [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
> > [ 2.042827] [<ffffffff819ab67b>] ? __hci_req_sync+0x7b/0x2a0
> > [ 2.042830] [<ffffffff811295ed>] __might_sleep+0xbd/0xd0
> > [ 2.042832] [<ffffffff81b04b8f>] mutex_lock_nested+0x2f/0x450
> > [ 2.042835] [<ffffffff81b0812b>] ? _raw_spin_unlock+0x2b/0x50
> > [ 2.042837] [<ffffffff81131db0>] ? wake_up_process+0x50/0x50
> > [ 2.042840] [<ffffffff813b9ea1>] __create_file+0x71/0x2c0
> > [ 2.042842] [<ffffffff813ba10f>] debugfs_create_file+0x1f/0x30
> > [ 2.042844] [<ffffffff819ac461>] hci_dev_do_open+0x431/0xa70
> > [ 2.042846] [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
> > [ 2.042847] [<ffffffff819ad2b1>] hci_power_on+0x31/0x1e0
> > [ 2.042849] [<ffffffff8111a7c8>] process_one_work+0x1d8/0x810
> > [ 2.042850] [<ffffffff8111a72c>] ? process_one_work+0x13c/0x810
> > [ 2.042851] [<ffffffff8111b2db>] worker_thread+0x6b/0x4b0
> > [ 2.042852] [<ffffffff8111b270>] ? init_pwq+0xf0/0xf0
> > [ 2.042854] [<ffffffff81120ef9>] kthread+0x119/0x130
> > [ 2.042855] [<ffffffff8112923d>] ? finish_task_switch+0x4d/0x140
> > [ 2.042857] [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
> > [ 2.042859] [<ffffffff81b08cfc>] ret_from_fork+0x7c/0xb0
> > [ 2.042861] [<ffffffff81120de0>] ? kthread_create_on_node+0x240/0x240
> > [ 2.042863] ---[ end trace 3a40e80ec4ca7159 ]---
>
> At least one obvious bug that the patch in question seems to have is
> that it fails to set the state back to TASK_RUNNING in case
> hci_req_run() fails and we never call schedule_timeout(). This would
> also seem to match the error you're getting.
>
> The attached patch fixes the missing set_current_state() calls - could
> you please check if it fixes the issue for you? Out of curiosity, which
> HW are you reproducing this with and are there any special steps
> involved? Looking at the code it seems that at least some older
> Bluetooth adapters could cause some hci_req_run() calls to return
> ENODATA, however I wasn't able to get the warning with any of my own
> adapters (I have one for pretty much every Bluetooth version).
>
> Johan
> From a75be9ae3c163db6a812330b5b50079891e1f7bd Mon Sep 17 00:00:00 2001
> From: Johan Hedberg <[email protected]>
> Date: Tue, 18 Nov 2014 20:00:15 +0200
> Subject: [PATCH] Bluetooth: Fix setting state back to TASK_RUNNING
>
> In __hci_cmd_sync_ev() and __hci_req_sync() if the hci_req_run() call
> fails and we return from the functions we should ensure that the state
> doesn't remain in TASK_INTERRUPTIBLE that we just set it to. This patch
> fixes missing calls to set_current_state(TASK_RUNNING) in both places.
>
> Signed-off-by: Johan Hedberg <[email protected]>
This patch helps -- warning is gone.
Trace from btmon on 'hciconfig hci0 up' is attached.
--
Kirill A. Shutemov
Hi Kirill,
On Wed, Nov 19, 2014, Kirill A. Shutemov wrote:
> > From: Johan Hedberg <[email protected]>
> > Date: Tue, 18 Nov 2014 20:00:15 +0200
> > Subject: [PATCH] Bluetooth: Fix setting state back to TASK_RUNNING
> >
> > In __hci_cmd_sync_ev() and __hci_req_sync() if the hci_req_run() call
> > fails and we return from the functions we should ensure that the state
> > doesn't remain in TASK_INTERRUPTIBLE that we just set it to. This patch
> > fixes missing calls to set_current_state(TASK_RUNNING) in both places.
> >
> > Signed-off-by: Johan Hedberg <[email protected]>
>
> This patch helps -- warning is gone.
Thanks! I've resent it to linux-bluetooth with the appropriate
Reported-by/Tested-by credits. It'll be included in the next pull
request for the bluetooth-next tree.
Johan