1. 20 6月, 2012 13 次提交
  2. 19 6月, 2012 1 次提交
  3. 18 6月, 2012 2 次提交
  4. 17 6月, 2012 4 次提交
  5. 16 6月, 2012 2 次提交
  6. 14 6月, 2012 7 次提交
    • J
      ixgbe: Check PTP Rx timestamps via BPF filter · 1d1a79b5
      Jacob Keller 提交于
      This patch fixes a potential Rx timestamp deadlock that causes the Rx
      timestamping to stall indefinitely. The issue could occur when a PTP packet is
      timestamped by hardware but never reaches the Rx queue. In order to prevent a
      permanent loss of timestamping, the RXSTMP(L/H) registers have to be read to
      unlock them. (This used to only occur when a packet that was timestamped
      reached the software.) However the registers can't be read early otherwise
      there is no way to correlate them to the packet.
      
      This patch introduces a filter function which can be used to determine if a
      packet should have been timestamped. Supplied with the filter setup by the
      hwtstamp ioctl, check to make sure the PTP protocol and message type match the
      expected values. If so, then read the timestamp registers (to free them.) At
      this point check the descriptor bit, if the bit is set then we know this
      packet correlates to the timestamp stored in the RXTSTAMP registers.
      Otherwise, assume that packet was dropped by the hardware, and ignore this
      timestamp value. However, we have at least unlocked the rxtstamp registers for
      future timestamping.
      
      Due to the way the driver handles skb data, it cannot be directly accessed. In
      order to work around this, a copy of the skb data into a linear buffer is
      made. From this buffer it becomes possible to read the data correctly
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NRichard Cochran <richardcochran@gmail.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1d1a79b5
    • J
      ixgbe: PTP Fix hwtstamp mode settings · c19197a7
      Jacob Keller 提交于
      When enabling the hwtstamp mode for Rx timestamping the V2 ptp event type
      specific modes (Delay Request and Sync) have been rolled into the V2 all event
      packet modes, in order to more accurately represent what hardware is doing.
      Hardware always timestamps the Path delay packets when a V2 mode is selected,
      regardless of what type was selected (in order to always support Path delay
      mode). However this means the user selected modes of timestamping only Sync or
      Delay Request is not truly supported. This patch correctly sets the mode for
      the hwtstamp config and returns to the user that all V2 event packets will be
      timestamped.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c19197a7
    • J
      ixgbe: ptp code cleanup · 0ede4a60
      Jacob Keller 提交于
      This patch fixes two minor nits from Richard Cochran. The first is a case of
      ambitious line wrapping that wasn't necessary. The second is to re-order the
      flag checks for PPS support. Previously, the hardware test was done first, and
      the interrupt flag test was done second. Now, test the interrupt flag and use
      the unlikely macro.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0ede4a60
    • E
      ixgbe: do not compile ixgbe_sysfs.c when CONFIG_IXGBE_HWMON is not set · 6cbc52ef
      Emil Tantilov 提交于
      ixgbe_sysfs.c is only needed when CONFIG_IXGBE_HWMON is configured in the
      kernel.
      Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com>
      Acked-by: NDon Skidmore <Donald.c.skidmore@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6cbc52ef
    • J
      ixgbe: align flow control DV macros with datasheet · 4f8a91ad
      John Fastabend 提交于
      The flow control DV macros are used to calculate the flow control
      high and low thresholds. This patch annotates these macros slightly
      better and fixes the issues below.
      
      The macro variables are renamed LINK to _max_frame_link and TC to
      _max_frame_tc. This was to avoid confusion and make them more
      readable. It was found that people auditing the code read TC to be
      'traffic class' in the 802.1Q definition instead of the max frame
      size of the tc. Hopefully it is clear now.
      
      This audit also found the following real deviations from the
      theoretical values. Fixed in this patch.
      
        * I multiplied the DV calculations by (36/25) which always
          evaluates to 1. This does not match the intended theoretical
          value of 1.44.
      
        * IXGBE_BT2KB added 1023 to account for rounding however this
          really should be 8 * 1023 - 1 to account for division by 8k.
      
        * x2 multiplication of max frame in DV calculations to account
          for updated hardware recommendations.
      
      With this patch the DV values are inline with the recommendations
      in the 82599 and 82598 data sheets. Its worth noting I did not
      see any dropped frames with flow control on in my experiments without
      this patch. However aligning with the hardware specs and
      recommendations seems like a good idea here to account for worst
      case scenarios.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4f8a91ad
    • B
      e1000e: use more informative logging macros when netdev not yet registered · 185095fb
      Bruce Allan 提交于
      Based on a report from Ethan Zhao, before calling register_netdev() the
      driver should be using logging macros that do not display the potentially
      confusing "(unregistered net_device)" yet still display the useful driver
      name and PCI bus/device/function.
      Reported-by: NEthan Zhao <ethan.kernel@gmail.com>
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      185095fb
    • E
      bnx2x: fix checksum validation · d6cb3e41
      Eric Dumazet 提交于
      bnx2x driver incorrectly sets ip_summed to CHECKSUM_UNNECESSARY on
      encapsulated segments. TCP stack happily accepts frames with bad
      checksums, if they are inside a GRE or IPIP encapsulation.
      
      Our understanding is that if no IP or L4 csum validation was done by the
      hardware, we should leave ip_summed as is (CHECKSUM_NONE), since
      hardware doesn't provide CHECKSUM_COMPLETE support in its cqe.
      
      Then, if IP/L4 checksumming was done by the hardware, set
      CHECKSUM_UNNECESSARY if no error was flagged.
      
      Patch based on findings and analysis from Robert Evans
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Eilon Greenstein <eilong@broadcom.com>
      Cc: Yaniv Rosner <yanivr@broadcom.com>
      Cc: Merav Sicron <meravs@broadcom.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Robert Evans <evansr@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Acked-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d6cb3e41
  7. 12 6月, 2012 5 次提交
  8. 11 6月, 2012 1 次提交
    • F
      r8169: avoid NAPI scheduling delay. · 7dbb4918
      françois romieu 提交于
      While reworking the r8169 driver a few months ago to perform the
      smallest amount of work in the irq handler, I took care of avoiding
      any irq mask register operation in the slow work dedicated user
      context thread. The slow work thread scheduled an extra round of NAPI
      work which would ultimately set the irq mask register as required,
      thus keeping such irq mask operations in the NAPI handler.
      It would eventually race with the irq handler and delay NAPI execution
      for - assuming no further irq - a whole ksoftirqd period. Mildly a
      problem for rare link changes or corner case PCI events.
      
      The race was always lost after the last bh disabling lock had been
      removed from the work thread and people started wondering where those
      pesky "NOHZ: local_softirq_pending 08" messages came from.
      
      Actually the irq mask register _can_ be set up directly in the slow
      work thread.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Reported-by: NDave Jones <davej@redhat.com>
      Tested-by: NMarc Dionne <marc.c.dionne@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Hayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7dbb4918
  9. 09 6月, 2012 1 次提交
  10. 08 6月, 2012 4 次提交