]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Another small update to the re(4) driver:
authorwpaul <wpaul@FreeBSD.org>
Tue, 1 Aug 2006 17:18:25 +0000 (17:18 +0000)
committerwpaul <wpaul@FreeBSD.org>
Tue, 1 Aug 2006 17:18:25 +0000 (17:18 +0000)
commit1e0ddf7fae5884e70d7b1608edf2d929c1786ba5
treeeca9c2b109c5e4fd1c1d05a465319840b059f9fe
parent023ecadf48622b9accaf88dd47b13cd8a99ae035
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.
sys/dev/re/if_re.c
sys/pci/if_rlreg.h