Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 1 Aug 2006 17:18:25 +0000 (UTC)
From:      Bill Paul <wpaul@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/dev/re if_re.c src/sys/pci if_rlreg.h
Message-ID:  <200608011718.k71HIP4M018878@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
wpaul       2006-08-01 17:18:25 UTC

  FreeBSD src repository

  Modified files:
    sys/dev/re           if_re.c 
    sys/pci              if_rlreg.h 
  Log:
  Another small update to the re(4) driver:
  
  - Change the workaround for the autopad/checksum offload bug so that
    instead of lying about the map size, we actually create a properly
    padded mbuf and map it as usual. The other trick works, but is ugly.
    This approach also gives us a chance to zero the pad space to avoid
    possibly leaking data.
  
  - With the PCIe devices, it looks issuing a TX command while there's
    already a transmission in progress doesn't have any effect. In other
    words, if you send two packets in rapid succession, the second one may
    end up sitting in the TX DMA ring until another transmit command is
    issued later in the future. Basically, if re_txeof() sees that there
    are still descriptors outstanding, it needs to manually resume the
    TX DMA channel by issuing another TX command to make sure all
    transmissions are flushed out. (The PCI devices seem to keep the
    TX channel moving until all descriptors have been consumed. I'm not
    sure why the PCIe devices behave differently.)
  
    (You can see this issue if you do the following test: plug an re(4)
    interface into another host via crossover cable, and from the other
    host do 'ping -c 2 <host with re(4) NIC>' to prime the ARP cache,
    then do 'ping -c 1 -s 1473 <host with re(4) NIC>'. You're supposed
    to see two packets sent in response, but you may only see one. If
    you do 'ping -c 1 -s 1473 <host with re(4) NIC>' again, you'll
    see two packets, but one will be the missing fragment from the last
    ping, followed by one of the fragments from this ping.)
  
  - Add the PCI ID for the US Robotics 997902 NIC, which is based on
    the RTL8169S.
  
  - Add a tsleep() of 1 second in re_detach() after the interrupt handler
    is disconnected. This should allow any tasks queued up by the ISR
    to drain. Now, I know you're supposed to use taskqueue_drain() for
    this, but something about the way taskqueue_drain() works with
    taskqueue_fast queues doesn't seem quite right, and I refuse to be
    tricked into fixing it.
  
  Revision  Changes    Path
  1.71      +52 -23    src/sys/dev/re/if_re.c
  1.60      +8 -0      src/sys/pci/if_rlreg.h



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608011718.k71HIP4M018878>