1. 08 May, 2012 2 commits
  2. 02 May, 2012 5 commits
  3. 01 May, 2012 2 commits
  4. 30 Apr, 2012 11 commits
  5. 27 Apr, 2012 7 commits
  6. 26 Apr, 2012 4 commits
  7. 25 Apr, 2012 2 commits
  8. 24 Apr, 2012 5 commits
    • Jeff Kirsher's avatar
      e1000e: Fix default interrupt throttle rate not set in NIC HW · 727c356f
      Jeff Kirsher authored
      
      
      Based on the original patch from  Ying Cai <ycai@google.com>
      This change ensures that the itr/itr_setting adjustment logic is used,
      even for the default/compiled-in value.
      
      Context:
        When we changed the default InterruptThrottleRate value from default
        (3 = dynamic mode) to 8000 for example, only adapter->itr_setting
        (which controls interrupt coalescing mode) was set to 8000, but
        adapter->itr (which controls the value set in NIC register) was not
        updated accordingly. So from ethtool, it seemed the interrupt
        throttling is enabled at 8000 intr/s, but the NIC actually was
        running in dynamic mode which has lower CPU efficiency especially
        when throughput is not high.
      
      CC: Ying Cai <ycai@google.com>
      CC: David Decotigny <david.decotigny@google.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.kirsher@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      727c356f
    • Prasanna S Panchamukhi's avatar
      e1000e: MSI interrupt test failed, using legacy interrupt · 569a3aff
      Prasanna S Panchamukhi authored
      
      
      Following logs where seen on Systems with multiple NICs,
      while using MSI interrupts as shown below:
      
      Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0d.0: lan0_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: wan0_1: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: lan0_1: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.warn kernel: 0000:40:0e.0: wan4_0: MSI interrupt
      test failed, using legacy interrupt.
      Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0e.0: wan1_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0e.0: lan1_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: wan2_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: lan2_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: wan3_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: lan3_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0e.0: lan4_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: wan5_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: lan5_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      
      This patch fixes this problem by increasing the msleep from 50 to 100.
      Signed-off-by: default avatarPrasanna S Panchamukhi <ppanchamukhi@riverbed.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      569a3aff
    • Meenakshi Venkataraman's avatar
      iwlwifi: use correct released ucode version · 78cbcf2b
      Meenakshi Venkataraman authored
      
      
      Report correctly the latest released version
      of the iwlwifi firmware for all
      iwlwifi-supported devices.
      
      Cc: stable@vger.kernel.org #3.3+
      Signed-off-by: default avatarMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      78cbcf2b
    • Johannes Berg's avatar
      iwlwifi: fix hardware queue programming · 5ef4acd5
      Johannes Berg authored
      
      
      Newer devices have 20 (5000 series) or 30 (6000 series)
      hardware queues, rather than the 16 that 4965 had. This
      was added to the driver a long time ago, but improperly:
      the queue registers for the higher queues aren't just
      continuations of the registers for the first 16 queues,
      they are in other places. Therefore, the hardware would
      lock up when trying to activate queue 16 or above and
      the device would have to be restarted.
      
      Thanks goes to Emmanuel who identified this and told me
      how the queue programming should be done.
      
      Note that we don't use queues 20 and higher today and
      doing so needs more work than this.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5ef4acd5
    • Ingo van Lil's avatar
      asix: Fix tx transfer padding for full-speed USB · 2a580949
      Ingo van Lil authored
      
      
      The asix.c USB Ethernet driver avoids ending a tx transfer with a zero-
      length packet by appending a four-byte padding to transfers whose length
      is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket
      length is valid for high-speed USB only; full-speed USB uses 64 byte
      packets.
      Signed-off-by: default avatarIngo van Lil <inguin@gmx.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a580949
  9. 23 Apr, 2012 2 commits
    • Anatolij Gustschin's avatar
      net/davinci_emac: fix failing PHY connect attempts · 1ab8be4a
      Anatolij Gustschin authored
      
      
      PHY connect attempts fail if no PHY id is specified in the emac platform
      data and another mdio bus has been registered before 'davinci_mdio' bus. In
      this case when configuring the interface, there will be an attempt to
      connect to already attached PHY on the previously registered mdio bus:
      
      net eth1: PHY already attached
      net eth1: could not connect to phy smsc911x-0:01
      IP-Config: Failed to open eth1
      IP-Config: Device `eth1' not found
      
      Fix this by modifying match_first_device() to match first PHY device
      on 'davinci_mdio' bus.
      Signed-off-by: default avatarAnatolij Gustschin <agust@denx.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ab8be4a
    • Thadeu Lima de Souza Cascardo's avatar
      ehea: only register irq after setting up ports · c2f1244b
      Thadeu Lima de Souza Cascardo authored
      
      
      If we receive an interrupt too early before we set up ports in the probe
      function, there won't be any port ready to handle it.
      
      Only registering the irq after the ports are setup fixes the problem,
      and works fine without losing any interrupts.
      
      This causes crashes in some situations:
      
      [c000000f7ff7fd60] d000000008e223f0 .ehea_neq_tasklet+0x78/0x148 [ehea]
      [c000000f7ff7fe00] c0000000000b6cac .tasklet_hi_action+0xdc/0x210
      [c000000f7ff7fea0] c0000000000b7cc8 .__do_softirq+0x178/0x300
      [c000000f7ff7ff90] c000000000022694 .call_do_softirq+0x14/0x24
      [c000000f68ee7900] c000000000010e04 .do_softirq+0xec/0x110
      [c000000f68ee79a0] c0000000000b789c .irq_exit+0xac/0xe0
      [c000000f68ee7a20] c0000000000110bc .do_IRQ+0x114/0x2a8
      [c000000f68ee7ae0] c00000000000553c hardware_interrupt_entry+0x18/0x1c
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c2f1244b