1. 19 5月, 2012 3 次提交
  2. 03 5月, 2012 5 次提交
  3. 02 5月, 2012 2 次提交
  4. 01 5月, 2012 11 次提交
  5. 28 4月, 2012 7 次提交
  6. 26 4月, 2012 6 次提交
  7. 25 4月, 2012 4 次提交
    • J
      e1000e: Fix default interrupt throttle rate not set in NIC HW · 727c356f
      Jeff Kirsher 提交于
      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: NJeff Kirsher <jeffrey.kirsher@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      727c356f
    • P
      e1000e: MSI interrupt test failed, using legacy interrupt · 569a3aff
      Prasanna S Panchamukhi 提交于
      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: NPrasanna S Panchamukhi <ppanchamukhi@riverbed.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      569a3aff
    • M
      iwlwifi: use correct released ucode version · 78cbcf2b
      Meenakshi Venkataraman 提交于
      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: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      78cbcf2b
    • J
      iwlwifi: fix hardware queue programming · 5ef4acd5
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5ef4acd5
  8. 24 4月, 2012 2 次提交