1. 29 Sep, 2011 12 commits
    • David S. Miller's avatar
      Merge git://github.com/Jkirsher/net-next · 3869f806
      David S. Miller authored
      3869f806
    • Michael Riesch's avatar
      usbnet: add timestamping support · f9b491ec
      Michael Riesch authored
      In order to make USB-to-Ethernet-adapters (depending on usbnet) support
      timestamping, the "skb_defer_rx_timestamp" and "skb_tx_timestamp" function
      calls are added.
      Signed-off-by: default avatarMichael Riesch <michael@riesch.at>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9b491ec
    • Xiao Jiang's avatar
      net/fec: add poll controller function for fec nic · 7f5c6add
      Xiao Jiang authored
      Add poll controller function for fec nic.
      Signed-off-by: default avatarXiao Jiang <jgq516@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f5c6add
    • Xiao Jiang's avatar
      net/fec: replace hardcoded irq num with macro · c7c83d1c
      Xiao Jiang authored
      Don't use hardcoded irq num and replace it with
      FEC_IRQ_NUM macro.
      Signed-off-by: default avatarXiao Jiang <jgq516@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7c83d1c
    • Don Skidmore's avatar
      ixgbe: add ECC warning for legacy interrupts · 0ccb974d
      Don Skidmore authored
      Noticed that the legacy Interrupt handler didn't have the same
      ECC warning as did the MSI.  So this patch adds it.
      
      Signed-off-by: Don Skidmore <donald.c.skidmore>
      Tested-by: default avatarPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0ccb974d
    • Don Skidmore's avatar
      ixgbe: cleanup ixgbe_setup_gpie() for X540 · f3df98ec
      Don Skidmore authored
      The X540 thermal sensor interrupt isn't a General Purpose Interrupt
      so doesn't need to be enabled in ixgbe_setup_gpie().  Likewise X540 doesn't
      use the SDP0 for thermal sensor so it doesn't need to be enabled for any
      device other than 82599.
      Signed-off-by: default avatarDon Skidmore <donald.c.skidmore@intel.com>
      Tested-by: default avatarPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f3df98ec
    • Jacob Keller's avatar
      ixgbe add thermal sensor support for x540 hardware · 4f51bf70
      Jacob Keller authored
      Add code to enable thermal sensors for the x540 hardware, as well as a
      thermal interrupt check which will exit with a critical message of a
      thermal overheat is detected. Intent of code allows other mac types to
      be added with different configuration in the future.
      
      Fixed in this version is the addition of setting the temp_sensor
      capable flag which was previously only set for a specific mac.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4f51bf70
    • John Fastabend's avatar
      ixgbe: update {P}FC thresholds to account for X540 and loopback · 9da712d2
      John Fastabend authored
      Revise high and low threshold marks wrt flow control to account
      for the X540 devices and latency introduced by the loopback
      switch.
      
      Without this it was in theory possible to drop frames on a
      supposedly lossless link with X540 or SR-IOV enabled.
      
      Previously we used a magic number in a define to calculate the
      threshold values. This made it difficult to sort out exactly
      which latencies were or were not being accounted for. Here
      I was overly explicit and tried to used #define names that would
      be recognizable after reading the IEEE 802.1Qbb specification.
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: default avatarRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9da712d2
    • Vasu Dev's avatar
      ixgbe: disable LLI for FCoE · 934c18cc
      Vasu Dev authored
      Disable LLI for FCoE since regular interrupt
      and their moderation rate works slightly better
      for FCoE also.
      Signed-off-by: default avatarVasu Dev <vasu.dev@intel.com>
      Tested-by: default avatarRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      934c18cc
    • Emil Tantilov's avatar
      ixgbe: Cleanup q_vector interrupt throttle rate logic · d5bf4f67
      Emil Tantilov authored
      This patch is meant to help cleanup the interrupt throttle rate logic by
      storing the interrupt throttle rate as a value in microseconds instead of
      interrupts per second.  The advantage to this approach is that the value
      can now be stored in an 16 bit field and doesn't require as much math to
      flip the value back and forth since the hardware already used microseconds
      when setting the rate.
      Signed-off-by: default avatarEmil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: default avatarPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d5bf4f67
    • Greg Rose's avatar
      ixgbevf: Fix broken trunk vlan · dd1ed3b7
      Greg Rose authored
      Changes to clean up the vlan rx path broke trunk vlan.  Trunk vlans in
      a VF driver are those set using:
      
      "ip link set <pfdev> vf <n> <vlanid>"
      Signed-off-by: default avatarGreg Rose <gregory.v.rose@intel.com>
      CC: Jiri Pirko <jpirko@redhat.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      dd1ed3b7
    • Dean Nelson's avatar
      e1000: don't enable dma receives until after dma address has been setup · d5bc77a2
      Dean Nelson authored
      Doing an 'ifconfig ethN down' followed by an 'ifconfig ethN up' on a qemu-kvm
      guest system configured with two e1000 NICs can result in an 'unable to handle
      kernel paging request at 0000000100000000' or 'bad page map in process ...' or
      something similar.
      
      These result from a 4096-byte page being corrupted with the following two-word
      pattern (16-bytes) repeated throughout the entire page:
      
        0x0000000000000000
        0x0000000100000000
      
      There can be other bits set as well. What is a constant is that the 2nd word
      has the 32nd bit set. So one could see:
      
              :
        0x0000000000000000
        0x0000000100000000
        0x0000000000000000
        0x0000000172adc067    <<< bad pte
        0x800000006ec60067
        0x0000000700000040
        0x0000000000000000
        0x0000000100000000
              :
      
      Which came from from a process' page table I dumped out when the marked line
      was seen as bad by print_bad_pte().
      
      The repeating pattern represents the e1000's two-word receive descriptor:
      
      struct e1000_rx_desc {
              __le64 buffer_addr;   /* Address of the descriptor's data buffer */
              __le16 length;        /* Length of data DMAed into data buffer */
              __le16 csum;          /* Packet checksum */
              u8 status;            /* Descriptor status */
              u8 errors;            /* Descriptor Errors */
              __le16 special;
      };
      
      And the 32nd bit of the 2nd word maps to the 'u8 status' member, and
      corresponds to E1000_RXD_STAT_DD which indicates the descriptor is done.
      
      The corruption appears to result from the following...
      
       . An 'ifconfig ethN down' gets us into e1000_close(), which through a number
         of subfunctions results in:
           1. E1000_RCTL_EN being cleared in RCTL register.  [e1000_down()]
           2. dma_free_coherent() being called.  [e1000_free_rx_resources()]
      
       . An 'ifconfig ethN up' gets us into e1000_open(), which through a number of
         subfunctions results in:
           1. dma_alloc_coherent() being called.  [e1000_setup_rx_resources()]
           2. E1000_RCTL_EN being set in RCTL register.  [e1000_setup_rctl()]
           3. E1000_RCTL_EN being cleared in RCTL register.  [e1000_configure_rx()]
           4. RDLEN, RDBAH and RDBAL registers being set to reflect the dma page
              allocated in step 1.  [e1000_configure_rx()]
           5. E1000_RCTL_EN being set in RCTL register.  [e1000_configure_rx()]
      
      During the 'ifconfig ethN up' there is a window opened, starting in step 2
      where the receives are enabled up until they are disabled in step 3, in which
      the address of the receive descriptor dma page known by the NIC is still the
      previous one which was freed during the 'ifconfig ethN down'. If this memory
      has been reallocated for some other use and the NIC feels so inclined, it will
      write to that former dma page with predictably unpleasant results.
      
      I realize that in the guest, we're dealing with an e1000 NIC that is software
      emulated by qemu-kvm. The problem doesn't appear to occur on bare-metal. Andy
      suspects that this is because in the emulator link-up is essentially instant
      and traffic can start flowing immediately. Whereas on bare-metal, link-up
      usually seems to take at least a few milliseconds. And this might be enough
      to prevent traffic from flowing into the device inside the window where
      E1000_RCTL_EN is set.
      
      So perhaps a modification needs to be made to the qemu-kvm e1000 NIC emulator
      to delay the link-up. But in defense of the emulator, it seems like a bad idea
      to enable dma operations before the address of the memory to be involved has
      been made known.
      
      The following patch no longer enables receives in e1000_setup_rctl() but leaves
      them however they were. It only enables receives in e1000_configure_rx(), and
      only after the dma address has been made known to the hardware.
      
      There are two places where e1000_setup_rctl() gets called. The one in
      e1000_configure() is followed immediately by a call to e1000_configure_rx(), so
      there's really no change functionally (except for the removal of the problem
      window. The other is in __e1000_shutdown() and is not followed by a call to
      e1000_configure_rx(), so there is a change functionally. But consider...
      
       . An 'ifconfig ethN down' (just as described above).
      
       . A 'suspend' of the system, which (I'm assuming) will find its way into
         e1000_suspend() which calls __e1000_shutdown() resulting in:
           1. E1000_RCTL_EN being set in RCTL register.  [e1000_setup_rctl()]
      
      And again we've re-opened the problem window for some unknown amount of time.
      Signed-off-by: default avatarAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDean Nelson <dnelson@redhat.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d5bc77a2
  2. 28 Sep, 2011 8 commits
  3. 27 Sep, 2011 13 commits
  4. 26 Sep, 2011 3 commits
  5. 23 Sep, 2011 4 commits