1. 22 10月, 2008 3 次提交
    • F
      r8169: checks against wrong mac addresse init · e1564ec9
      Francois Romieu 提交于
      Checking the signature of the eeprom and the validity of the
      MAC address should be enough to filter out the bad addresses
      observed so far.
      
      Contributed by Ivan Vecera and Martin Capitanio.
      
      Tested on 8102el, 8168b and 8169 for a start.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Edward Hsu <edward_hsu@realtek.com.tw>
      e1564ec9
    • F
      r8169: verbose mac address init · cd926c73
      Francois Romieu 提交于
      I prefer the debug information to be displayed until
      the issue is properly handled.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Edward Hsu <edward_hsu@realtek.com.tw>
      cd926c73
    • I
      tcp: should use number of sack blocks instead of -1 · 75e3d8db
      Ilpo Järvinen 提交于
      While looking for the recent "sack issue" I also read all eff_sacks
      usage that was played around by some relevant commit. I found
      out that there's another thing that is asking for a fix (unrelated
      to the "sack issue" though).
      
      This feature has probably very little significance in practice.
      Opposite direction timeout with bidirectional tcp comes to me as
      the most likely scenario though there might be other cases as
      well related to non-data segments we send (e.g., response to the
      opposite direction segment). Also some ACK losses or option space
      wasted for other purposes is necessary to prevent the earlier
      SACK feedback getting to the sender.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75e3d8db
  2. 21 10月, 2008 37 次提交