cable tuning. This has helped in some installations for hardware
deployed by a former employer. Made optional because the lists aren't
full of complaints about these cards... even when they were wildly
popular.
Reviewed by: attilio@, jhb@, trhodes@ (all an older version of the patch)
- The hardware does not support DAC so limit DMA address space to
4GB.
- Removed BUS_DMA_ALLOC_NOW flag.
- Created separated Tx buffer and Rx buffer DMA tags. Previously
it used to single DMA tag and it was not possible to specify
different DMA restrictions.
- Apply 4 bytes alignment limitation of Tx buffer.
- Apply 8 bytes alignment limitation of Rx buffer.
- Tx side bus_dmamap_load_mbuf_sg(9) support.
- Preallocate Tx DMA maps as creating DMA maps take very long time
on architectures that require real DMA maps.
- Adjust guard buffer size to 1522 + 8 as it should include VLAN
and additional reserved bytes in Rx buffer.
- Plug memory leak in device detach. Previously wrong buffer
address was used to free allocated memory.
- Added rl_list_rx_init() to clear Rx buffer and cleared the
buffer.
- Don't destroy DMA maps in rl_txeof() as the DMA map should be
reused. There is no reason to destroy/recreate the DMA maps in
this driver.
- Removed rl_dma_map_rxbuf()/rl_dma_map_txbuf() callbacks.
- The hardware does not support descriptor based DMA on Tx side
and the Tx buffer address should be aligned on 4 bytes boundary
as well as manual padding for short frames. Because of this
hardware limitation rl(4) always used to invoke m_defrag(9) to
get a 4 bytes aligned single buffer. However m_defrag(9) takes
a lot of CPU cycles on slow machines and not all packets need
the help of m_defrag(9). Armed with the information, don't
invoke m_defrag(9) if the following conditions are true.
1. Buffer is not fragmented.
2. Buffer is aligned on 4 bytes boundary.
3. Manual padding is not necessary.
4. Or padding is necessary but upper stack passed a writable
buffer and the space needed for padding is satisfied.
This change combined with preallocated DMA maps greatly
increased Tx performance of driver on sparc64.
- Moved bus_dmamap_sync(9) in rl_start_locked() to rl_encap() and
corrected memory synchronization operation specifier of
bus_dmamap_sync(9).
- Removed bus_dmamap_unload(9) in rl_stop(). There is no need to
reload/unload Rx buffer as rl(4) always have to copy from the
buffer. It just needs proper bus_dmamap_sync(9) calls before
copying the received frame.
With this change rl(4) should work on systems with more than 4GB
memory.
PR: kern/128143
11bits. This limits the maximum interface MTU size in TSO case
as upper stack should not generate TCP segments with MSS greater
than the limit. Armed with this information, disable TSO if
interface MTU is greater than the limit.
generation of RTL810x PCIe fast ethernet controller. Note, Tx/Rx
descriptor format is different from that of first generation of
RTL8101E series. Jumbo frame is not supported for RTL810x
family.
Tested by: NAGATA Shinya ( maya AT negeta DOT com )
ATM Tx/Rx checksum offload is supported but TSO and jumbo frame is
not yet supported. Because these newer controllers use different
descriptor formats, a flag RL_FLAG_DESCV2 flag was introduced to
handle that case in Tx/Rx handler. Also newer controllers seems to
require to not touch 'enable Tx/Rx bit' in RL_CPLUS_CMD register
so don't blindly try to set that bits.
Note, it seems that there is still power-saving related issue where
driver fails to attach PHY. Rebooting seems to fix that issue but
number of required reboots varys.
Many thanks to users that helped during developement. I really
appreciate their patient and test/feedbacks.
a dedicated flag that represents controller capabilities/events.
This will simplify many part of code that requires different
workaround for each controller revisions and will enhance
readability.
While I'm here move PHY wakeup code up before mii_phy_probe() which
seems to help to wake PHY in some cases.
o Increased number of Rx/Tx descriptors to 256 for 8169 GigEs
because it's hard to push the hardware to the limit with default
64 descriptors.
TSO requires large number of Tx descriptors to pass a full sized
TCP segment(65535 bytes IP packet) to hardware. Previously it
consumed 32 Tx descriptors, assuming MCLBYTES DMA segment size,
to send the TCP segment which means re(4) couldn't queue more
than two full sized IP packets.
For 8139C+ it still uses 64 Rx/Tx descriptors due to its hardware
limitations. With this changes there are (very) small waste of
memory for 8139C+ users but I don't think it would affect 8139C+
users for most cases.
o Various bus_dma(9) fixes.
- The hardware supports DAC so allow 64bit DMA operations.
- Removed BUS_DMA_ALLOC_NOW flag.
- Increased DMA segment size to 4096 from MCLBYTES because TSO
consumes too many descriptors with MCLBYTES DMA segment size.
- Tx/Rx side bus_dmamap_load_mbuf_sg(9) support. With these
changes the code is more readable than previous one and got a
(slightly) better performance as it doesn't need to pass/
decode arguments to/from callback function.
- Removed unnecessary callback function re_dmamap_desc() and
nuked rl_dmaload_arg structure which was used in the callback.
- Additional protection for DMA map load failure. In case of
failure reuse current map instead of returning a bogus DMA
map.
- Deferred DMA map unloading/sync operation for maximum
performance until we really need to load new DMA map. If we
happen to reuse current map(e.g. input error) there is no need
to sync/unload/load again.
- The number of allowable Tx DMA segments for a mbuf chains are
now 32 instead of magic nseg value. If the number of available
Tx descriptors are short enough to send highly fragmented mbuf
chains an optimized re_defrag() is called to collapse mbuf
chains which is supposed to be much faster than m_defrag(9).
re_defrag() was borrowed from ath(4).
- Separated Rx/Tx DMA tag from a common DMA tag such that Rx DMA
tag correctly uses DMA maps that were created with DMA alignment
restriction(8bytes alignments). Tx DMA tag does not have such
alignment limitation.
- Added additional sanity checks for DMA ring map load failure.
- Added additional spare Rx DMA map for graceful handling of Rx
DMA map load failure.
- Fixed misused bus_dmamap_sync(9) and added missing
bus_dmamap_sync(9) in re_encap()/re_txeof()/re_rxeof().
o Enabled TSO again as re(4) have reasonable number of Tx
descriptors.
o Don't touch DMA address of a Tx descriptor in re_txeof(). It's
not needed.
o Fix incorrect update of if_ierrors counter. For Rx buffer
shortage it should update if_qdrops as the buffer is reused.
o Added checks for unsupported H/W revisions and return ENXIO for
these hardwares. This is required to remove resource allocation
code in re_probe as other drivers do in device probe routine.
o Modified descriptor index manipulation macros as it's now possible
to have different number of descriptors for Rx/Tx.
o In re_start, to save a lock operation, use IFQ_DRV_IS_EMPTY before
trying to invoke IFQ_DRV_DEQUEUE. Also don't blindly call re_encap
since we already know the number of available Tx descriptors in
advance.
o Removed RL_TX_DESC_THLD which was used to reserve RL_TX_DESC_THLD
descriptors in Tx path. There is no such a limitation mentioned in
8139C+/8169/8110/8168/8101/8111 datasheet and it seems to work ok
without reserving RL_TX_DESC_THLD descriptors.
o Fix a comment for RL_GTXSTART. The register is 8bits register.
o Added comments for 8169/8139C+ hardware restrictions on descriptors.
o Removed forward declaration for "struct rl_softc", it's not needed.
o Added a new structure rl_txdesc for Tx descriptor managements and
a structure rl_rxdesc for Rx descriptor managements.
o Removed unused member variable rl_intlock in driver softc. There are
still several unused member variables which are supposed to be used
to access hardware statistics counters. But it seems that accessing
hardware counters were not implemented yet.
Ethernet Controller. Multicast filtering wasn't tested and needs more
expore. While I'm here change complex if statements with switch
statement which would improve readability.
Reported by: Abdullah Ibn Hamad Al-Marri < wearabnet AT yahoo DOT ca >
Tested by: Abdullah Ibn Hamad Al-Marri < wearabnet AT yahoo DOT ca >
Ever since switching to adaptive polling re(4) occasionally spews
watchdog timeouts on systems with MSI capability. This change is
minimal one for supporting MSI and re(4) also needs MSIX support
for RTL8111C in future. Because softc structure of re(4) is shared
with rl(4), rl(4) was touched to use the modified softc.
Reported by: cnst
Tested by: cnst
Approved by: re (kensmith)
would be 93C46(1Kbit) or 93C56(2Kbit). One of differences between them
is number of address lines required to access the EEPROM. For example,
93C56 EEPROM needs 8 address lines to read/write data. If 93C56
recevied premature end of required number of serial clock(CLK) to set
OP code/address of EEPROM, the result would be unexpected behavior.
Previously it tried to detect 93C46, which requires 6 address lines,
and then assumed it would be 93C56 if read data was not expected
value. However, this approach didn't work in some models/situations
as 93C56 requries 8 address lines to access its data. In order to fix
it, change EEPROM probing order such that 93C56 is detected reliably.
While I'm here change hard-coded address line numbers with defined
constant to enhance readability.
PR: 112710
Approved by: re (mux)
Previously whenever PROMISC mode turned on/off link renegotiation
occurs and it could resulted in network unavailability for serveral
seconds.(Depending on switch STP settings it could last several tens
seconds.)
Reported by: Prokofiev S.P. < proks AT logos DOT uptel DOT net >
Tested by: Prokofiev S.P. < proks AT logos DOT uptel DOT net >
operation as it ran out of free descriptors or if there are too many
segments in the first place, call bus_dmamap_unload() in order to
unload the already loaded segments.
For trying to map the defragmented mbuf (chain) in re_encap() this
introduces re_dma_map_desc() setting arg.rl_maxsegs to 0 as a new
failure mode. Previously we just ignored this case, corrupting our
view of the TX ring.
o In re_txeof():
- Don't clear IFF_DRV_OACTIVE unless there are at least 4 free TX
descriptors. Further down the road re_encap() will bail if there
aren't at least 4 free TX descriptors, causing re_start() to
abort and prepend the dequeued mbuf again so it makes no sense
to pretend we could process mbufs again when in fact we won't.
While at it replace this magic 4 with a macro RL_TX_DESC_THLD
throughout this driver.
- Don't cancel the watchdog timeout as soon as there's at least one
free TX descriptor but instead only if all descriptors have been
handled. It's perfectly normal, especially in the DEVICE_POLLING
case, that re_txeof() is called when only a part of the enqueued
TX descriptors have been handled, causing the watchdog to be
disarmed prematurely.
o In re_encap():
- If m_defrag() fails just drop the packet like other NIC drivers
do. This should only happen when there's a mbuf shortage, in which
case it was possible to end up with an IFQ full of packets which
couldn't be processed as they couldn't be defragmented as they
were taking up all the mbufs themselves. This includes adjusting
re_start() to not trying to prepend the mbuf (chain) if re_encap()
has freed it.
- Remove dupe initialization of members of struct rl_dmaload_arg to
values that didn't change since trying to process the fragmented
mbuf chain.
While at it remove an unused member from struct rl_dmaload_arg.
o In re_start() remove a abandoned, banal comment. The corresponding
code was moved to re_attach() some time ago.
With these changes re(4) now survives one day (until stopped) of
hammering out packets here.
Reviewed by: yongari
MFC after: 2 weeks
- 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.
- Correct the PCI ID for the 8169SC/8110SC in the device list (I added
the macro for it to if_rlreg.h before, but forgot to use it.)
- Remove the extra interrupt spinlock I added previously. After giving it
some more thought, it's not really needed.
- Work around a hardware bug in some versions of the 8169. When sending
very small IP datagrams with checksum offload enabled, a conflict can
occur between the TX autopadding feature and the hardware checksumming
that can corrupt the outbound packet. This is the reason that checksum
offload sometimes breaks NFS: if you're using NFS over UDP, and you're
very unlucky, you might find yourself doing a fragmented NFS write where
the last fragment is smaller than the minimum ethernet frame size (60
bytes). (It's rare, but if you keep NFS running long enough it'll
happen.) If checksum offload is enabled, the chip will have to both
autopad the fragment and calculate its checksum header. This confuses
some revs of the 8169, causing the packet that appears on the wire
to be corrupted. (The IP addresses and the checksum field are mangled.)
This will cause the NFS write to fail. Unfortunately, when NFS retries,
it sends the same write request over and over again, and it keeps
failing, so NFS stays wedged.
(A simple way to provoke the failure is to connect the failing system
to a network with a known good machine and do "ping -s 1473 <badhost>"
from the good system. The ping will fail.)
Someone had previously worked around this using the heavy-handed
approahch of just disabling checksum offload. The correct fix is to
manually pad short frames where the TCP/IP stack has requested
checksum offloading. This allows us to have checksum offload turned
on by default but still let NFS work right.
- Not a bug, but change the ID strings for devices with hardware rev
0x30000000 and 0x38000000 to both be 8168B/8111B. According to RealTek,
they're both the same device, but 0x30000000 is an earlier silicon spin.
cards: the chips are all marked "RTL8111B", but they put stickers on the
back that say "RTL8168B/8111B". The manual says there's only one HWREV code
for both the 8111B and 8168B devices, which is 0x30000000, but the cards
they sent me actually report HWREV of 0x38000000. Deciding to trust the
hardware in front of me rather than a possibly incorrect manual (it wouldn't
be the first time the HWREVs were incorrectly documented), I changed the
8168 revision code. It turns out this was a mistake though: 0x30000000
really is a valid for the 8168.
There are two possible reasons for there to be two different HWREVs:
1) 0x30000000 is used only for the 8168B and 0x38000000 is only for
the 8111B.
2) There were 8111/8168 rev A devices which both used code 0x30000000,
and the 8111B/8168B both use 0x38000000.
The product list on the RealTek website doesn't mention the existence of
any 8168/8111 rev A chips being in production though, and I've never seen
one, so until I get clarification from RealTek, I'm going to assume that
0x30000000 is just for the 8168B and 0x38000000 is for the 8111B only.
So, the HWREV code for the 8168 has been put back to 0x30000000,
a new 8111 HWREV code has been added, and there are now separate
entries for recognizing both devices in the device list. This will
allow all devices to work, though if it turns out I'm wrong I may
need to change the ID strings
latter is a PCIe 10/100 chip.
Finally fix the EEPROM reading code so that we can access the EEPROMs on all
devices. In order to access the EEPROM, we must select 'EEPROM programming'
mode, and then set the EEPROM chip select bit. Previously, we were setting
both bits simultaneously, which doesn't work: they must be set in the
right sequence.
Always obtain the station address from the EEPROM, now that EEPROM
reading works correctly.
Make the TX interrupt moderation code based on the internal timer
optional and turned off by default.
Make the re_diag() routine conditional and off by default. When it is
on, only use it for the original 8169, which was the only device that
that really needed it.
Modify interrupt handling to use a fast interrupt handler and fast
taskqeueue.
Correct the rgephy driver so that it only applies the DSP fixup for
PHY revs 0 and 1. Later chips are fixed and don't need the fixup.
Make the rgephy driver advertise both 1000_FD and 1000_HD bits in
autoneg mode. A couple of the devices don't autoneg correctly unless
configured this way.
cards and teach the re(4) driver to attach to revision 3 cards.
Submitted by: Fredrik Lindberg fli+freebsd-current at shapeshifter dot se
MFC after: 2 weeks
Reviewed by: imp, mdodd
the softc.
- Use callout_init_mtx() and rather than timeout/untimeout in both rl(4)
and re(4).
- Fix locking for ifmedia by locking the driver in the ifmedia handlers
rather than in the miibus functions. (re(4) didn't lock the mii stuff
at all!)
- Fix some locking in re_ioctl().
Note: the two drivers share the same softc declared in if_rlreg.h, so they
had to be change simultaneously.
MFC after: 1 week
Tested by: several on rl(4), none on re(4)
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.
This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.
Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.
Reviewed by: sobomax, sam
to 7422 since it appears that the 8169S can't transmit anything larger..
The 8169S can receive full jumbo frames, but we don't have an mru to let
the upper layers know this...
add fixup so that this driver should work on alignment constrained platforms
(!i386 && !amd64)
MFC after: 5 days
Use C99 types. Use ANSI function definitions. Sort prototypes.
Split long lines correctly. Punctuate/wordsmith comments.
Use device_printf()/if_printf() where possible.
Reviewed by: -net (silence)
the packets are immediately returned for sending (e.g. when bridging
or packet forwarding). There are more efficient ways to do this
but for now use the least intrusive approach.
Reviewed by: imp, rwatson
we're on a 32-bit/64-bit bus or not. Use this to decide if we should
set the PCI dual-address cycle enable bit in the C+ command register.
(Enabling DAC on a 32-bit bus seems to do bad things.)
Also, initialize the C+ command register early in the re_init() routine.
The documentation says this register should be configured first.
autoload and then copying the contends of the station address
registers. For some reason, reading the EEPROM on the 8169S doesn't
work right. This gets around the problem, and allows us to read
the station address correctly on the 8169S.
- Insert a delay after initiating packet transmition in re_diag() to
allow lots of time for the frame to echo back to the host, and wait
for both the 'RX complete' and 'timeout expired' bits in the ISR
register to be set.
- Deal more intelligently with the fact that the frame length
field in the RX descriptor is a different width on the 8139C+
than it is on the 8169/8169S/8110S
- For the 8169, you have to set bit 17 in the TX config register
to enter digital loopback mode, but for the 8139C+, you have to
set both bits 17 and 18. Take this into account so that re_diag()
works properly for both types of chips.
ethernet chips. This driver is pretty simple, however it contains
special DSP initialization code which is needed in order to get
the chip to negotiate a gigE link. (This special initialization
may not be needed in subsequent chip revs.) Also:
- Fix typo in if_rlreg.h (RL_GMEDIASTAT_1000MPS -> RL_GMEDIASTAT_1000MBPS)
- Deal with shared interrupts in re_intr(): if interface isn't up,
return.
- Fix another bug in re_gmii_writereg() (properly apply data field mask)
- Allow PHY driver to read the RL_GMEDIASTAT register via the
re_gmii_readreg() register (this is register needed to determine
real time link/media status).
for the 8169S, according to my sample board. The RealTek Linux driver
mentions 0x00800000. I'm assigning this to the 8110S until I get
more info on it. (The (preliminary) RealTek docs only say that 8169S/8110S
chips will have some combination of those two bits set, but doesn't say
exactly what bit combination goes with which chip variant.)
rl(4) driver and put it in a new re(4) driver. The re(4) driver shares
the if_rlreg.h file with rl(4) but is a separate module. (Ultimately
I may change this. For now, it's convenient.)
rl(4) has been modified so that it will never attach to an 8139C+
chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to
match the 8169/8169S/8110S gigE chips. if_re.c contains the same
basic code that was originally bolted onto if_rl.c, with the
following updates:
- Added support for jumbo frames. Currently, there seems to be
a limit of approximately 6200 bytes for jumbo frames on transmit.
(This was determined via experimentation.) The 8169S/8110S chips
apparently are limited to 7.5K frames on transmit. This may require
some more work, though the framework to handle jumbo frames on RX
is in place: the re_rxeof() routine will gather up frames than span
multiple 2K clusters into a single mbuf list.
- Fixed bug in re_txeof(): if we reap some of the TX buffers,
but there are still some pending, re-arm the timer before exiting
re_txeof() so that another timeout interrupt will be generated, just
in case re_start() doesn't do it for us.
- Handle the 'link state changed' interrupt
- Fix a detach bug. If re(4) is loaded as a module, and you do
tcpdump -i re0, then you do 'kldunload if_re,' the system will
panic after a few seconds. This happens because ether_ifdetach()
ends up calling the BPF detach code, which notices the interface
is in promiscuous mode and tries to switch promisc mode off while
detaching the BPF listner. This ultimately results in a call
to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init()
to handle the IFF_PROMISC flag change. Unfortunately, calling re_init()
here turns the chip back on and restarts the 1-second timeout loop
that drives re_tick(). By the time the timeout fires, if_re.ko
has been unloaded, which results in a call to invalid code and
blows up the system.
To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(),
which stops the ioctl routine from trying to reset the chip.
- Modified comments in re_rxeof() relating to the difference in
RX descriptor status bit layout between the 8139C+ and the gigE
chips. The layout is different because the frame length field
was expanded from 12 bits to 13, and they got rid of one of the
status bits to make room.
- Add diagnostic code (re_diag()) to test for the case where a user
has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some
NICs have the REQ64# and ACK64# lines connected even though the
board is 32-bit only (in this case, they should be pulled high).
This fools the chip into doing 64-bit DMA transfers even though
there is no 64-bit data path. To detect this, re_diag() puts the
chip into digital loopback mode and sets the receiver to promiscuous
mode, then initiates a single 64-byte packet transmission. The
frame is echoed back to the host, and if the frame contents are
intact, we know DMA is working correctly, otherwise we complain
loudly on the console and abort the device attach. (At the moment,
I don't know of any way to work around the problem other than
physically modifying the board, so until/unless I can think of a
software workaround, this will have do to.)
- Created re(4) man page
- Modified rlphy.c to allow re(4) to attach as well as rl(4).
Note that this code works for the sample 8169/Marvell 88E1000 NIC
that I have, but probably won't work for the 8169S/8110S chips.
RealTek has sent me some sample NICs, but they haven't arrived yet.
I will probably need to add an rlgphy driver to handle the on-board
PHY in the 8169S/8110S (it needs special DSP initialization).
