1. 04 12月, 2009 4 次提交
    • G
      Bluetooth: Implement RejActioned flag · 4ec10d97
      Gustavo F. Padovan 提交于
      RejActioned is used to prevent retransmission when a entity is on the
      WAIT_F state, i.e., waiting for a frame with F-bit set due local busy
      condition or a expired retransmission timer. (When these two events raise
      they send a frame with the Poll bit set and enters in the WAIT_F state to
      wait for a frame with the Final bit set.)
      The local entity doesn't send I-frames(the data frames) until the receipt
      of a frame with F-bit set. When that happens it also set RejActioned to false.
      RejActioned is a mandatory feature of ERTM spec.
      Signed-off-by: NGustavo F. Padovan <gustavo@las.ic.unicamp.br>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4ec10d97
    • G
      Bluetooth: Fix sending ReqSeq on I-frames · 9f121a5a
      Gustavo F. Padovan 提交于
      As specified by ERTM spec an ERTM channel can acknowledge received
      I-frames(the data frames) by sending an I-frame with the proper ReqSeq
      value (i.e. ReqSeq is set to BufferSeq).  Until now we aren't setting the
      ReqSeq value on I-frame control bits. That way we can save sending
      S-frames(Supervise frames) only to acknowledge receipt of I-frames. It
      is very helpful to the full-duplex channel.
      ReqSeq is the packet sequence number sent in an acknowledgement frame to
      acknowledge receipt of frames up to (ReqSeq - 1).
      BufferSeq controls the receiver buffer, it is used to delay
      acknowledgement of new frames to not cause buffer overflow. BufferSeq
      value is not increased until frames are pulled by reassembly function.
      Signed-off-by: NGustavo F. Padovan <gustavo@las.ic.unicamp.br>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9f121a5a
    • G
      Bluetooth: Fix unset of SrejActioned flag · 889a3ca4
      Gustavo F. Padovan 提交于
      SrejActioned  is a flag that when set prevents local side to retransmit a
      I-frame(the data frame) already retransmitted. The local entity can
      retransmit again only when it receives a SREJ frame with the F-bit set.
      SREJ frame - Selective Reject frame  - is sent when an entity wants the
      retransmission of a specific I-frame that was lost or corrupted.
      This bug can put ERTM in an unknown state once the entity can't
      retransmit.
      A frame with the Final bit set is expected when the local side sends a
      frame with the Poll bit set due to a local busy condition or a
      retransmission timer expired. (Receipt of P-bit shall always be replied by
      a frame with the F-bit set).
      pi->conn_state keeps informations about many ERTM flags including
      SrejActioned.
      Signed-off-by: NGustavo F. Padovan <gustavo@las.ic.unicamp.br>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      889a3ca4
    • G
      Bluetooth: Initialize variables and timers for both channel's sides · 0565c1c2
      Gustavo F. Padovan 提交于
      Fix ERTM's full-duplex channel to work as specified by ERTM spec. ERTM
      needs to handle state vars, timers and counters to send and receive
      I-frames(the data frames), i.e., for both sides of data communication.
      We initialize all of them to the default values here.
      Full-duplex channel is a mandatory feature of ERTM spec.
      Signed-off-by: NGustavo F. Padovan <gustavo@las.ic.unicamp.br>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0565c1c2
  2. 30 11月, 2009 1 次提交
  3. 16 11月, 2009 2 次提交
  4. 06 11月, 2009 2 次提交
  5. 20 10月, 2009 1 次提交
    • D
      bluetooth: static lock key fix · 45054dc1
      Dave Young 提交于
      When shutdown ppp connection, lockdep waring about non-static key
      will happen, it is caused by the lock is not initialized properly
      at that time.
      
      Fix with tuning the lock/skb_queue_head init order
      
      [   94.339261] INFO: trying to register non-static key.
      [   94.342509] the code is fine but needs lockdep annotation.
      [   94.342509] turning off the locking correctness validator.
      [   94.342509] Pid: 0, comm: swapper Not tainted 2.6.31-mm1 #2
      [   94.342509] Call Trace:
      [   94.342509]  [<c0248fbe>] register_lock_class+0x58/0x241
      [   94.342509]  [<c024b5df>] ? __lock_acquire+0xb57/0xb73
      [   94.342509]  [<c024ab34>] __lock_acquire+0xac/0xb73
      [   94.342509]  [<c024b7fa>] ? lock_release_non_nested+0x17b/0x1de
      [   94.342509]  [<c024b662>] lock_acquire+0x67/0x84
      [   94.342509]  [<c04cd1eb>] ? skb_dequeue+0x15/0x41
      [   94.342509]  [<c054a857>] _spin_lock_irqsave+0x2f/0x3f
      [   94.342509]  [<c04cd1eb>] ? skb_dequeue+0x15/0x41
      [   94.342509]  [<c04cd1eb>] skb_dequeue+0x15/0x41
      [   94.342509]  [<c054a648>] ? _read_unlock+0x1d/0x20
      [   94.342509]  [<c04cd641>] skb_queue_purge+0x14/0x1b
      [   94.342509]  [<fab94fdc>] l2cap_recv_frame+0xea1/0x115a [l2cap]
      [   94.342509]  [<c024b5df>] ? __lock_acquire+0xb57/0xb73
      [   94.342509]  [<c0249c04>] ? mark_lock+0x1e/0x1c7
      [   94.342509]  [<f8364963>] ? hci_rx_task+0xd2/0x1bc [bluetooth]
      [   94.342509]  [<fab95346>] l2cap_recv_acldata+0xb1/0x1c6 [l2cap]
      [   94.342509]  [<f8364997>] hci_rx_task+0x106/0x1bc [bluetooth]
      [   94.342509]  [<fab95295>] ? l2cap_recv_acldata+0x0/0x1c6 [l2cap]
      [   94.342509]  [<c02302c4>] tasklet_action+0x69/0xc1
      [   94.342509]  [<c022fbef>] __do_softirq+0x94/0x11e
      [   94.342509]  [<c022fcaf>] do_softirq+0x36/0x5a
      [   94.342509]  [<c022fe14>] irq_exit+0x35/0x68
      [   94.342509]  [<c0204ced>] do_IRQ+0x72/0x89
      [   94.342509]  [<c02038ee>] common_interrupt+0x2e/0x34
      [   94.342509]  [<c024007b>] ? pm_qos_add_requirement+0x63/0x9d
      [   94.342509]  [<c038e8a5>] ? acpi_idle_enter_bm+0x209/0x238
      [   94.342509]  [<c049d238>] cpuidle_idle_call+0x5c/0x94
      [   94.342509]  [<c02023f8>] cpu_idle+0x4e/0x6f
      [   94.342509]  [<c0534153>] rest_init+0x53/0x55
      [   94.342509]  [<c0781894>] start_kernel+0x2f0/0x2f5
      [   94.342509]  [<c0781091>] i386_start_kernel+0x91/0x96
      Reported-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Tested-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45054dc1
  6. 07 10月, 2009 1 次提交
  7. 01 10月, 2009 1 次提交
  8. 26 8月, 2009 3 次提交
  9. 24 8月, 2009 2 次提交
  10. 23 8月, 2009 13 次提交
  11. 08 6月, 2009 6 次提交
  12. 27 2月, 2009 4 次提交