1. 27 Jul, 2009 2 commits
    • reinette chatre's avatar
      iwlagn: fix minimum number of queues setting · 45f5fa32
      reinette chatre authored
      
      
      We need to provide a reasonable minimum that will result in a
      working setup if used. Set minimum to be 10 to provide for
      4 standard TX queues + 1 command queue + 2 (unused) HCCA queues +
      4 HT queues (one per AC).
      
      We allow the user to change the number of queues used via a module
      parameter and use this minimum value to check if it is valid. Without
      this patch a user can select a value for the number of queues that
      will result in a failing setup.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Reviewed-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Acked-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      45f5fa32
    • Johannes Berg's avatar
      iwlwifi: fix TX queue race · 3995bd93
      Johannes Berg authored
      
      
      I had a problem on 4965 hardware (well, probably other hardware too,
      but others don't survive my stress testing right now, unfortunately)
      where the driver was sending invalid commands to the device, but no
      such thing could be seen from the driver's point of view. I could
      reproduce this fairly easily by sending multiple TCP streams with
      iperf on different TIDs, though sometimes a single iperf stream was
      sufficient. It even happened with a single core, but I have forced
      preemption turned on.
      
      The culprit was a queue overrun, where we advanced the queue's write
      pointer over the read pointer. After careful analysis I've come to
      the conclusion that the cause is a race condition between iwlwifi
      and mac80211.
      
      mac80211, of course, checks whether the queue is stopped, before
      transmitting a frame. This effectively looks like this:
      
              lock(queues)
              if (stopped(queue)) {
                      unlock(queues)
                      return busy;
      	}
              unlock(queues)
              ...             <-- this place will be important
      			    there is some more code here
              drv_tx(frame)
      
      The driver, on the other hand, can stop and start queues, which does
      
              lock(queues)
              mark_running/stopped(queue)
              unlock(queues)
      
      	[if marked running: wake up tasklet to send pending frames]
      
      Now, however, once the driver starts the queue, mac80211 can see that
      and end up at the marked place above, at which point for some reason the
      driver seems to stop the queue again (I don't understand that) and then
      we end up transmitting while the queue is actually full.
      
      Now, this shouldn't actually matter much, but for some reason I've seen
      it happen multiple times in a row and the queue actually overflows, at
      which point the queue bites itself in the tail and things go completely
      wrong.
      
      This patch fixes this by just dropping the packet should this have
      happened, and making the lock in iwlwifi cover everything so iwlwifi
      can't race against itself (dropping the lock there might make it more
      likely, but it did seem to happen without that too).
      
      Since we can't hold the lock across drv_tx() above, I see no way to fix
      this in mac80211, but I also don't understand why I haven't seen this
      before -- maybe I just never stress tested it this badly.
      
      With this patch, the device has survived many minutes of simultanously
      sending two iperf streams on different TIDs with combined throughput
      of about 60 Mbps.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3995bd93
  2. 21 Jul, 2009 12 commits
  3. 14 Jul, 2009 1 commit
  4. 12 Jul, 2009 2 commits
    • Ralf Baechle's avatar
      NET: Fix locking issues in PPP, 6pack, mkiss and strip line disciplines. · adeab1af
      Ralf Baechle authored
      Guido Trentalancia reports:
      
      I am trying to use the kiss driver in the Linux kernel that is being
      shipped with Fedora 10 but unfortunately I get the following oops:
      
      mkiss: AX.25 Multikiss, Hans Albas PE1AYX
      mkiss: ax0: crc mode is auto.
      ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready
      ------------[ cut here ]------------
      WARNING: at kernel/softirq.c:77 __local_bh_disable+0x2f/0x83() (Not
      tainted)
      [...]
      unloaded: microcode]
      Pid: 0, comm: swapper Not tainted 2.6.27.25-170.2.72.fc10.i686 #1
       [<c042ddfb>] warn_on_slowpath+0x65/0x8b
       [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38
       [<c04228b4>] ? __enqueue_entity+0xe3/0xeb
       [<c042431e>] ? enqueue_entity+0x203/0x20b
       [<c0424361>] ? enqueue_task_fair+0x3b/0x3f
       [<c041f88c>] ? resched_task+0x3a/0x6e
       [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38
       [<c06ab4e2>] ? _spin_lock_bh+0xb/0x16
       [<c043255b>] __local_bh_disable+0x2f/0x83
       [<c04325ba>] local_bh_disable+0xb/0xd
       [<c06ab4e2>] _spin_lock_bh+0xb/0x16
       [<f8b6f600>] mkiss_receive_buf+0x2fb/0x3a6 [mkiss]
       [<c0572a30>] flush_to_ldisc+0xf7/0x198
       [<c0572b12>] tty_flip_buffer_push+0x41/0x51
       [<f89477f2>] ftdi_process_read+0x375/0x4ad [ftdi_sio]
       [<f8947a5a>] ftdi_read_bulk_callback+0x130/0x138 [ftdi_sio]
       [<c05d4bec>] usb_hcd_giveback_urb+0x63/0x93
       [<c05ea290>] uhci_giveback_urb+0xe5/0x15f
       [<c05eaabf>] uhci_scan_schedule+0x52e/0x767
       [<c05f6288>] ? psmouse_handle_byte+0xc/0xe5
       [<c054df78>] ? acpi_ev_gpe_detect+0xd6/0xe1
       [<c05ec5b0>] uhci_irq+0x110/0x125
       [<c05d4834>] usb_hcd_irq+0x40/0xa3
       [<c0465313>] handle_IRQ_event+0x2f/0x64
       [<c046642b>] handle_level_irq+0x74/0xbe
       [<c04663b7>] ? handle_level_irq+0x0/0xbe
       [<c0406e6e>] do_IRQ+0xc7/0xfe
       [<c0405668>] common_interrupt+0x28/0x30
       [<c056821a>] ? acpi_idle_enter_simple+0x162/0x19d
       [<c0617f52>] cpuidle_idle_call+0x60/0x92
       [<c0403c61>] cpu_idle+0x101/0x134
       [<c069b1ba>] rest_init+0x4e/0x50
       =======================
      ---[ end trace b7cc8076093467ad ]---
      ------------[ cut here ]------------
      WARNING: at kernel/softirq.c:136 _local_bh_enable_ip+0x3d/0xc4()
      [...]
      Pid: 0, comm: swapper Tainted: G        W 2.6.27.25-170.2.72.fc10.i686
       [<c042ddfb>] warn_on_slowpath+0x65/0x8b
       [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38
       [<c04228b4>] ? __enqueue_entity+0xe3/0xeb
       [<c042431e>] ? enqueue_entity+0x203/0x20b
       [<c0424361>] ? enqueue_task_fair+0x3b/0x3f
       [<c041f88c>] ? resched_task+0x3a/0x6e
       [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38
       [<c06ab4e2>] ? _spin_lock_bh+0xb/0x16
       [<f8b6f642>] ? mkiss_receive_buf+0x33d/0x3a6 [mkiss]
       [<c04325f9>] _local_bh_enable_ip+0x3d/0xc4
       [<c0432688>] local_bh_enable_ip+0x8/0xa
       [<c06ab54d>] _spin_unlock_bh+0x11/0x13
       [<f8b6f642>] mkiss_receive_buf+0x33d/0x3a6 [mkiss]
       [<c0572a30>] flush_to_ldisc+0xf7/0x198
       [<c0572b12>] tty_flip_buffer_push+0x41/0x51
       [<f89477f2>] ftdi_process_read+0x375/0x4ad [ftdi_sio]
       [<f8947a5a>] ftdi_read_bulk_callback+0x130/0x138 [ftdi_sio]
       [<c05d4bec>] usb_hcd_giveback_urb+0x63/0x93
       [<c05ea290>] uhci_giveback_urb+0xe5/0x15f
       [<c05eaabf>] uhci_scan_schedule+0x52e/0x767
       [<c05f6288>] ? psmouse_handle_byte+0xc/0xe5
       [<c054df78>] ? acpi_ev_gpe_detect+0xd6/0xe1
       [<c05ec5b0>] uhci_irq+0x110/0x125
       [<c05d4834>] usb_hcd_irq+0x40/0xa3
       [<c0465313>] handle_IRQ_event+0x2f/0x64
       [<c046642b>] handle_level_irq+0x74/0xbe
       [<c04663b7>] ? handle_level_irq+0x0/0xbe
       [<c0406e6e>] do_IRQ+0xc7/0xfe
       [<c0405668>] common_interrupt+0x28/0x30
       [<c056821a>] ? acpi_idle_enter_simple+0x162/0x19d
       [<c0617f52>] cpuidle_idle_call+0x60/0x92
       [<c0403c61>] cpu_idle+0x101/0x134
       [<c069b1ba>] rest_init+0x4e/0x50
       =======================
      ---[ end trace b7cc8076093467ad ]---
      mkiss: ax0: Trying crc-smack
      mkiss: ax0: Trying crc-flexnet
      
      The issue was, that the locking code in mkiss was assuming it was only
      ever being called in process or bh context.  Fixed by converting the
      involved locking code to use irq-safe locks.
      
      Review of other networking line disciplines shows that 6pack, both sync
      and async PPP and STRIP have similar issues.  The ppp_async one is the
      most interesting one as it sorts out half of the issue as far back as
      2004 in commit http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=2996d8deaeddd01820691a872550dc0cfba0c37d
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Reported-by: default avatarGuido Trentalancia <guido@trentalancia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      adeab1af
    • Ben Hutchings's avatar
      netdev: restore MAC address set and validate operations · 240c102d
      Ben Hutchings authored
      
      
      alloc_etherdev() used to install default implementations of these
      operations, but they must now be explicitly installed in struct
      net_device_ops.
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      240c102d
  5. 08 Jul, 2009 6 commits
  6. 07 Jul, 2009 3 commits
    • Samuel Ortiz's avatar
      iwmc3200wifi: add Kconfig help · a7a4e41e
      Samuel Ortiz authored
      
      
      We're missing a Kconfig help for the iwmc3200wifi driver.
      Signed-off-by: default avatarSamuel Ortiz <samuel.ortiz@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a7a4e41e
    • Vasanthakumar Thiagarajan's avatar
      ath9k: Fix leak in tx descriptor · cbfe89c6
      Vasanthakumar Thiagarajan authored
      
      
      When we reclaim the tx desc, we always assume that the
      last desc is a holding desc, which is not true, and skip it.
      If the tx queue is drained during channel change, internal
      reset and etc, the last descriptor may not be the holding
      descriptor and we fail to reclaim them. This results in the
      following two issues.
      
      1. Tx stuck - We drop all the frames coming from upper layer
      due to shortage in tx desc.
      
      2. Crash - If we fail to reclaim a tx descriptor, we miss to
      update the tx BA window with the seq number of the frame
      associated to that desc, which, at some point, result in
      the following crash due to an assert failure in ath_tx_addto_baw().
      
      This patch fixes these two issues.
      
       kernel BUG at ../drivers/net/wireless/ath/ath9k/xmit.c:180!
      [155064.304164] invalid opcode: 0000 [#1] SMP
       Call Trace:
        [<fbc6d83b>] ? ath9k_tx+0xeb/0x160 [ath9k]
        [<fbbc9591>]  ipv6? __ieee80211_tx+0x41/0x120 [mac80211]
        [<fbbcb5ae>] ?  aes_i586ieee80211_master_start_xmit+0x28e/0x560 [mac80211]
        [<c037e501>]  aes_generic? _spin_lock_irqsave+0x31/0x40
        [<c02f347b>] ? dev_hard_start_xmit+0x16b/0x1c0
        [<c03058b5>] ? __qdisc_run+0x1b5/0x200
        [<fbbcda5a>] ?  af_packetieee80211_select_queue+0xa/0x100 [mac80211]
        [<c02f53b7>] ?  i915dev_queue_xmit+0x2e7/0x3f0
        [<fbbc9b49>] ? ieee80211_subif_start_xmit+0x369/0x7a0 [mac80211]
        [<c031bc35>] ? ip_output+0x55/0xb0
        [<c02e0188>] ? show_memcpy_count+0x18/0x60
        [<c02eb186>] ? __kfree_skb+0x36/0x90
        [<c02f2202>] ?  binfmt_miscdev_queue_xmit_nit+0xd2/0x110
        [<c02f347b>] ? dev_hard_start_xmit+0x16b/0x1c0
        [<c03058b5>] ? __qdisc_run+0x1b5/0x200
        [<c033bca7>] ?  scoarp_create+0x57/0x2a0
        [<c02f53b7>] ?  bridgedev_queue_xmit+0x2e7/0x3f0
        [<c03034a0>] ? eth_header+0x0/0xc0
        [<c033b95f>]  stp? arp_xmit+0x5f/0x70
        [<c033bf4f>] ? arp_send+0x5f/0x70
        [<c033c8f5>]  bnep? arp_solicit+0x105/0x210
        [<c02fa5aa>] ? neigh_timer_handler+0x19a/0x390
        [<c013bf88>] ? run_timer_softirq+0x138/0x210
        [<c02fa410>] ?  ppdevneigh_timer_handler+0x0/0x390
        [<c02fa410>] ? neigh_timer_handler+0x0/0x390
      Signed-off-by: default avatarVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      cbfe89c6
    • Larry Finger's avatar
      b43/b43legacy: fix radio LED initialization · fd4973c5
      Larry Finger authored
      
      
      Fix condition in which radio LED did not initialize correctly, and remove
      4 compilation warnings.
      
      After the recent changes in rfkill, the radio LED used by b43/b43legacy
      did not always initialize correctly.
      
      Both b43 and b43legacy used the deprecated variable radio_enabled in
      struct ieee80211_conf.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      fd4973c5
  7. 06 Jul, 2009 1 commit
  8. 19 Jun, 2009 10 commits
  9. 15 Jun, 2009 3 commits