1. 11 Jun, 2010 1 commit
    • John Fastabend's avatar
      net: deliver skbs on inactive slaves to exact matches · 597a264b
      John Fastabend authored
      Currently, the accelerated receive path for VLAN's will
      drop packets if the real device is an inactive slave and
      is not one of the special pkts tested for in
      skb_bond_should_drop().  This behavior is different then
      the non-accelerated path and for pkts over a bonded vlan.
      
      For example,
      
      vlanx -> bond0 -> ethx
      
      will be dropped in the vlan path and not delivered to any
      packet handlers at all.  However,
      
      bond0 -> vlanx -> ethx
      
      and
      
      bond0 -> ethx
      
      will be delivered to handlers that match the exact dev,
      because the VLAN path checks the real_dev which is not a
      slave and netif_recv_skb() doesn't drop frames but only
      delivers them to exact matches.
      
      This patch adds a sk_buff flag which is used for tagging
      skbs that would previously been dropped and allows the
      skb to continue to skb_netif_recv().  Here we add
      logic to check for the deliver_no_wcard flag and if it
      is set only deliver to handlers that match exactly.  This
      makes both paths above consistent and gives pkt handlers
      a way to identify skbs that come from inactive slaves.
      Without this patch in some configurations skbs will be
      delivered to handlers with exact matches and in others
      be dropped out right in the vlan path.
      
      I have tested the following 4 configurations in failover modes
      and load balancing modes.
      
      # bond0 -> ethx
      
      # vlanx -> bond0 -> ethx
      
      # bond0 -> vlanx -> ethx
      
      # bond0 -> ethx
                  |
        vlanx -> --
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      597a264b
  2. 10 Jun, 2010 2 commits
  3. 09 Jun, 2010 6 commits
  4. 08 Jun, 2010 2 commits
  5. 07 Jun, 2010 8 commits
  6. 06 Jun, 2010 6 commits
    • Timo Teräs's avatar
      r8169: fix random mdio_write failures · 024a07ba
      Timo Teräs authored
      Some configurations need delay between the "write completed" indication
      and new write to work reliably.
      
      Realtek driver seems to use longer delay when polling the "write complete"
      bit, so it waits long enough between writes with high probability (but
      could probably break too). This patch adds a new udelay to make sure we
      wait unconditionally some time after the write complete indication.
      
      This caused a regression with XID 18000000 boards when the board specific
      phy configuration writing many mdio registers was added in commit
      2e955856 (r8169: phy init for the 8169scd). Some of the configration
      mdio writes would almost always fail, and depending on failure might leave
      the PHY in non-working state.
      Signed-off-by: default avatarTimo Teräs <timo.teras@iki.fi>
      Acked-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      024a07ba
    • Eric Dumazet's avatar
      8ffb335e
    • Emmanuel Grumbach's avatar
      iwlwifi: move sysfs_create_group to post request firmware · 7d47618a
      Emmanuel Grumbach authored
      Move the sysfs_create_group to iwl_ucode_callback after we
      have safely got the firmware.
      
      The motivation to do this comes from a warning from lockdep which detected
      that we request priv->mutex while holding s_active during a sysfs request
      (show_statistics in the example copy pasted). The reverse order exists upon
      request_firmware: request_firmware which is a sysfs operation
      that requires s_active is run under priv->mutex.
      
      This ensures that we don't get sysfs request before we finish to request
      the firmware, avoiding this deadlock.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      -------------------------------------------------------
      cat/2595 is trying to acquire lock:
       (&priv->mutex){+.+.+.}, at: [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
      
      but task is already holding lock:
       (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (s_active){++++.+}:
             [<c0489b74>] __lock_acquire+0xc44/0x1230
             [<c048a1ed>] lock_acquire+0x8d/0x110
             [<c0581499>] sysfs_addrm_finish+0xe9/0x180
             [<c057f64a>] sysfs_hash_and_remove+0x4a/0x80
             [<c05829d4>] sysfs_remove_group+0x44/0xd0
             [<c0714b75>] dpm_sysfs_remove+0x15/0x20
             [<c070dac8>] device_del+0x38/0x170
             [<c070dc1e>] device_unregister+0x1e/0x60
             [<c071838d>] _request_firmware+0x29d/0x550
             [<c07186c7>] request_firmware+0x17/0x20
             [<fad01bf1>] iwl_mac_start+0xb1/0x1230 [iwlagn]
             [<fa46ba06>] ieee80211_open+0x436/0x6f0 [mac80211]
             [<c0808cd2>] dev_open+0x92/0xf0
             [<c0808b2b>] dev_change_flags+0x7b/0x190
             [<c08148e8>] do_setlink+0x178/0x3b0
             [<c0815169>] rtnl_setlink+0xf9/0x130
             [<c081453b>] rtnetlink_rcv_msg+0x1bb/0x1f0
             [<c0827ce6>] netlink_rcv_skb+0x86/0xa0
             [<c081436c>] rtnetlink_rcv+0x1c/0x30
             [<c08279c3>] netlink_unicast+0x263/0x290
             [<c0828768>] netlink_sendmsg+0x1c8/0x2a0
             [<c07f85fd>] sock_sendmsg+0xcd/0x100
             [<c07f964d>] sys_sendmsg+0x15d/0x290
             [<c07f9e6b>] sys_socketcall+0xeb/0x2a0
             [<c040ad9f>] sysenter_do_call+0x12/0x38
      
      -> #0 (&priv->mutex){+.+.+.}:
             [<c0489f84>] __lock_acquire+0x1054/0x1230
             [<c048a1ed>] lock_acquire+0x8d/0x110
             [<c08bb358>] __mutex_lock_common+0x58/0x470
             [<c08bb84a>] mutex_lock_nested+0x3a/0x50
             [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
             [<c070d219>] dev_attr_show+0x29/0x50
             [<c057fecd>] sysfs_read_file+0xdd/0x190
             [<c052880f>] vfs_read+0x9f/0x190
             [<c0528d22>] sys_read+0x42/0x70
             [<c040ad9f>] sysenter_do_call+0x12/0x38
      
      other info that might help us debug this:
      
      3 locks held by cat/2595:
       #0:  (&buffer->mutex){+.+.+.}, at: [<c057fe25>] sysfs_read_file+0x35/0x190
       #1:  (s_active){++++.+}, at: [<c0580ecd>] sysfs_get_active_two+0x2d/0x50
       #2:  (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50
      
      stack backtrace:
      Pid: 2595, comm: cat Not tainted 2.6.33-tp-rc4 #2
      Call Trace:
       [<c08b99ab>] ? printk+0x1d/0x22
       [<c0487752>] print_circular_bug+0xc2/0xd0
       [<c0489f84>] __lock_acquire+0x1054/0x1230
       [<c0478d81>] ? sched_clock_cpu+0x121/0x180
       [<c048a1ed>] lock_acquire+0x8d/0x110
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<c08bb358>] __mutex_lock_common+0x58/0x470
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<c08bb84a>] mutex_lock_nested+0x3a/0x50
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
       [<c0580cf9>] ? sysfs_get_active+0x69/0xb0
       [<facfa550>] ? show_statistics+0x0/0x100 [iwlagn]
       [<c070d219>] dev_attr_show+0x29/0x50
       [<c057fecd>] sysfs_read_file+0xdd/0x190
       [<c05ff314>] ? security_file_permission+0x14/0x20
       [<c0528242>] ? rw_verify_area+0x62/0xd0
       [<c052880f>] vfs_read+0x9f/0x190
       [<c047745b>] ? up_read+0x1b/0x30
       [<c057fdf0>] ? sysfs_read_file+0x0/0x190
       [<c04af3b4>] ? audit_syscall_entry+0x1f4/0x220
       [<c0528d22>] sys_read+0x42/0x70
       [<c040ad9f>] sysenter_do_call+0x12/0x38
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      7d47618a
    • Wey-Yi Guy's avatar
      iwlwifi: add name to Maintainers list · 9edc71b7
      Wey-Yi Guy authored
      Add "Wey-Yi Guy" to maintainers list for iwlwifi.
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      9edc71b7
    • Abhijeet Kolekar's avatar
      iwl3945: fix internal scan · 14023641
      Abhijeet Kolekar authored
      Port of internal scan to iwl3945 missed introduction
      of iwl3945_get_single_channel_for_scan.
      
      Fix the following bug by introducing the iwl3945_get_single_channel_for_scan
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208Signed-off-by: default avatarAbhijeet Kolekar <abhijeet.kolekar@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      14023641
    • Reinette Chatre's avatar
      iwl3945: enable stuck queue detection on 3945 · a6866ac9
      Reinette Chatre authored
      We learn from
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and
      https://bugzilla.redhat.com/show_bug.cgi?id=589777
      that 3945 can also suffer from a stuck command queue. Enable stuck queue
      detection for iwl3945 to enable recovery in this case.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      a6866ac9
  7. 05 Jun, 2010 1 commit
  8. 04 Jun, 2010 11 commits
  9. 03 Jun, 2010 3 commits