1. 19 12月, 2011 3 次提交
  2. 17 12月, 2011 1 次提交
  3. 02 12月, 2011 2 次提交
  4. 22 11月, 2011 2 次提交
  5. 17 11月, 2011 2 次提交
  6. 09 11月, 2011 4 次提交
  7. 08 11月, 2011 12 次提交
  8. 01 11月, 2011 1 次提交
    • S
      Bluetooth: Increase HCI reset timeout in hci_dev_do_close · e1b6eb3c
      Szymon Janc 提交于
      I've noticed that my CSR usb dongle was not working if it was plugged in when
      PC was booting. It looks like I get two HCI reset command complete events (see
      hcidump logs below).
      The root cause is reset called from off_timer. Timeout for this reset to
      complete is set to 250ms and my bt dongle requires more time for replying with
      command complete event. After that, chip seems to reply with reset command
      complete event for next non-reset command.
      
      Attached patch increase mentioned timeout to HCI_INIT_TIMEOUT, this value is
      already used for timeouting hci_reset_req in hci_dev_reset().
      
      This might also be related to BT not working after suspend that was reported
      here some time ago.
      
      Hcidump log:
      
      2011-09-12 23:13:27.379465 < HCI Command: Reset (0x03|0x0003) plen 0
      2011-09-12 23:13:27.380797 > HCI Event: Command Complete (0x0e) plen 4
          Reset (0x03|0x0003) ncmd 1
          status 0x00
      2011-09-12 23:13:27.380859 < HCI Command: Read Local Supported Features (0x04|0x000
      3) plen 0
      2011-09-12 23:13:27.760789 > HCI Event: Command Complete (0x0e) plen 4
          Reset (0x03|0x0003) ncmd 1
          status 0x00
      2011-09-12 23:13:27.760831 < HCI Command: Read Local Version Information (0x04|0x00
      01) plen 0
      2011-09-12 23:13:27.764780 > HCI Event: Command Complete (0x0e) plen 12
          Read Local Version Information (0x04|0x0001) ncmd 1
          status 0x00
          HCI Version: 1.1 (0x1) HCI Revision: 0x36f
          LMP Version: 1.1 (0x1) LMP Subversion: 0x36f
          Manufacturer: Cambridge Silicon Radio (10)
      Signed-off-by: NSzymon Janc <szymon@janc.net.pl>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      e1b6eb3c
  9. 15 10月, 2011 3 次提交
  10. 21 9月, 2011 3 次提交
  11. 12 8月, 2011 2 次提交
  12. 09 7月, 2011 2 次提交
  13. 08 7月, 2011 1 次提交
    • A
      Bluetooth: Fix potential deadlock in hci_core · 8aded711
      Andre Guedes 提交于
      Since hdev->lock may be acquired by threads runnning in interrupt
      context, all threads running in process context should disable
      local bottom halve before locking hdev->lock. This can be done by
      using hci_dev_lock_bh macro.
      
      This way, we avoid potencial deadlocks like this one reported by
      CONFIG_PROVE_LOCKING=y.
      
      [  304.788780] =================================
      [  304.789686] [ INFO: inconsistent lock state ]
      [  304.789686] 2.6.39+ #1
      [  304.789686] ---------------------------------
      [  304.789686] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [  304.789686] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [  304.789686]  (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686] {SOFTIRQ-ON-W} state was registered at:
      [  304.789686]   [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
      [  304.789686]   [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
      [  304.789686]   [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
      [  304.789686]   [<ffffffffa0009cf0>] hci_blacklist_del+0x1f/0x8a [bluetooth]
      [  304.789686]   [<ffffffffa00139fd>] hci_sock_ioctl+0x2d9/0x314 [bluetooth]
      [  304.789686]   [<ffffffff812197d8>] sock_ioctl+0x1f2/0x214
      [  304.789686]   [<ffffffff810b0fd6>] do_vfs_ioctl+0x46c/0x4ad
      [  304.789686]   [<ffffffff810b1059>] sys_ioctl+0x42/0x65
      [  304.789686]   [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
      [  304.789686] irq event stamp: 9768
      [  304.789686] hardirqs last  enabled at (9768): [<ffffffff812b40d4>] restore_args+0x0/0x30
      [  304.789686] hardirqs last disabled at (9767): [<ffffffff812b3f6a>] save_args+0x6a/0x70
      [  304.789686] softirqs last  enabled at (9726): [<ffffffff8102fa9b>] __do_softirq+0x129/0x13f
      [  304.789686] softirqs last disabled at (9739): [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
      [  304.789686]
      [  304.789686] other info that might help us debug this:
      [  304.789686]  Possible unsafe locking scenario:
      [  304.789686]
      [  304.789686]        CPU0
      [  304.789686]        ----
      [  304.789686]   lock(&(&hdev->lock)->rlock);
      [  304.789686]   <Interrupt>
      [  304.789686]     lock(&(&hdev->lock)->rlock);
      [  304.789686]
      [  304.789686]  *** DEADLOCK ***
      [  304.789686]
      [  304.789686] 1 lock held by ksoftirqd/0/3:
      [  304.789686]  #0:  (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
      [  304.789686]
      [  304.789686] stack backtrace:
      [  304.789686] Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.39+ #1
      [  304.789686] Call Trace:
      [  304.789686]  [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
      [  304.789686]  [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
      [  304.789686]  [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
      [  304.789686]  [<ffffffff810504bb>] mark_lock+0x106/0x258
      [  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
      [  304.789686]  [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
      [  304.789686]  [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
      [  304.789686]  [<ffffffff812ae126>] ? printk+0x3c/0x3e
      [  304.789686]  [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
      [  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686]  [<ffffffff811601c6>] ? __dynamic_pr_debug+0x10c/0x11a
      [  304.789686]  [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
      [  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686]  [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686]  [<ffffffffa000c561>] hci_event_packet+0x38e/0x3e12 [bluetooth]
      [  304.789686]  [<ffffffff81052615>] ? lock_release+0x16c/0x179
      [  304.789686]  [<ffffffff812b3b41>] ? _raw_read_unlock+0x23/0x27
      [  304.789686]  [<ffffffffa0013e7f>] ? hci_send_to_sock+0x179/0x188 [bluetooth]
      [  304.789686]  [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
      [  304.789686]  [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
      [  304.789686]  [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
      [  304.789686]  [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
      [  304.789686]  [<ffffffff8102fab1>] ? __do_softirq+0x13f/0x13f
      [  304.789686]  [<ffffffff81040f0a>] kthread+0x7f/0x87
      [  304.789686]  [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
      [  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
      [  304.789686]  [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
      [  304.789686]  [<ffffffff812b55c0>] ? gs_change+0x13/0x13
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      8aded711
  14. 07 7月, 2011 2 次提交