event from mii(4) may not be delivered if valid link was already
established. To address the issue, check current link state after
driving MII_TICK. This should fix a regression introduced in
r184245.
PR: kern/129647
command whenever Tx completion interrupt is raised. The Tx poll
bit is cleared when all packets waiting to be transferred have been
processed. This means the second Tx poll command can be silently
ignored as the Tx poll bit could be still active while processing
of previous Tx poll command is in progress.
To address the issue re(4) used to invoke the Tx poll command in Tx
completion handler whenever it detects there are pending packets in
TxQ. However that still does not seem to completely eliminate
watchdog timeouts seen on RealTek PCIe controllers. To fix the
issue kick Tx poll command only after Tx completion interrupt is
raised as this would indicate Tx is now idle state such that it can
accept new Tx poll command again. While here apply this workaround
for PCIe based controllers as other controllers does not seem to
have this limitation.
Tested by: Victor Balada Diaz < victor <> bsdes DOT net >
out of sleep mode prior to accessing to PHY. This should fix device
attach failure seen on these controllers. Also enable the sleep
mode when device is put into sleep state.
PR: kern/123123, kern/123053
same LOM hardware with goofed-up EEPROM programming also needed reading the
Ethernet address from the chips registers as the EEPROM did not have a
sensible address programmed.
Patch developed by: pyun@
Funky hardware on loan: www.id-it.nl
MFC after: 2 weeks
established a valid link or not. In miibus_statchg handler add a
check for established link is valid one for the controller(e.g.
1000baseT is not a valid link for fastethernet controllers.)
o Added a flag RE_FLAG_FASTETHER to mark fastethernet controllers.
o Added additional check to know whether we've really encountered
watchdog timeouts or missed Tx completion interrupts. This change
may help to track down the cause of watchdog timeouts.
o In interrupt handler, removed a check for link state change
interrupt. Not all controllers have the bit and re(4) did not
rely on the event for a long time. In addition, re(4) didn't
request the interrupt in RL_IMR register.
Tested by: rpaulo
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)
established a valid link or not.
In rl_start_locked, don't try to send packets unless we have valid
link. While I'm here add a check that verifies whether driver can
accept Tx requests by inspecting IFF_DRV_OACTIVE/IFF_DRV_RUNNING
flag.
- 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
- Just grab Giant in the ixp425_iic(4) driver since this driver uses
a shared address/data register window pair to access the actual
I2C registers. None of the other ixp425 drivers lock access to these
shared address/data registers yet and that would need to be done before
this could use any meaningful locking.
- Add locking to the interrupt handler and 'iicbus_reset' methods of the
at91_twi(4) driver.
- Add locking to the pcf(4) driver. Other pcf(4) fixes include:
- Don't needlessly zero the softc.
- Use bus_foo rather than bus_space_foo and remove bus space tag and
handle from softc.
- The lpbb(4) driver just grabs Giant for now. This will be refined later
when ppbus(4) is locked.
- As was done with smbus earlier, move the DRIVER_MODULE() lines to match
the bus driver (either iicbus or iicbb) to the bridge driver into the
bridge drivers.
Tested by: sam (arm/ixp425)
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.
well as the 15C since it seems to be required in practice. The Linux
natsemi.c driver mostly does this as well.
PR: kern/112179
Submitted by: Mark Willson mark - hydrus org uk
MFC after: 1 week
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.
received frame under certain conditions. wpaul said the length
0xfff0 is special meaning that indicates hardware is in the
process of copying a packet into host memory. But it seems
there are other cases that hardware is busy or stuck in bad
situation even if the received frame length is not 0xfff0.
To work-around this condition, add a check that verifys that
recevied frame length is in valid range. If received length is out
of range reinitialize hardware to recover from stuck condition.
Reported by: Mike Tancsa ( mike AT sentex DOT net )
Tested by: Mike Tancsa
Obtained from: OpenBSD
MFC after: 1 week
Removed dead code that assumed that M_TRYWAIT can return NULL; it's not true
since the advent of MBUMA.
Reviewed by: arch
There are ongoing disputes as to whether we want to switch to directly using
UMA flags M_WAITOK/M_NOWAIT for mbuf(9) allocation.
- Take advantage of m_collapse(9).
- Sync with other NIC drivers and prepend a TX mbuf if the first attempt
to load it fails with an error other than EFBIG and stop trying instead
of freeing it and keeping on trying to enqueue more mbufs. Also ensure
the driver queue isn't empty before trying to enqueue mbufs in order to
reduce locking operations.
- In xl_ifmedia_upd() add a missing XL_UNLOCK(). [1]
- Const'ify the xl_devs array.
- Remove an outdated comment.
PR: 113406 [1]
MFC after: 1 month
free function controlable, instead of passing the KVA of the buffer
storage as the first argument.
Fix all conventional users of the API to pass the KVA of the buffer
as the first argument, to make this a no-op commit.
Likely break the only non-convetional user of the API, after informing
the relevant committer.
Update the mbuf(9) manual page, which was already out of sync on
this point.
Bump __FreeBSD_version to 800016 as there is no way to tell how
many arguments a CPP macro needs any other way.
This paves the way for giving sendfile(9) a way to wait for the
passed storage to have been accessed before returning.
This does not affect the memory layout or size of mbufs.
Parental oversight by: sam and rwatson.
No MFC is anticipated.
