| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
so use just 1 MSI message. This fixes regression introduced in
r188381.
Tested by: many
|
|
|
|
|
|
| |
controllers that lose Tx completion interrupts under certain
conditions. With this change it's safe to use MSI on PCIe
controllers so enable MSI on these controllers.
|
|
|
|
|
|
|
| |
Linux driver.
- Swap hardware revisions for 8110S and 8169S as Linux driver claims.
Reviewed by: yongari (early version)
|
| |
|
|
|
|
|
|
|
|
|
| |
- Always program RX configuration register from scratch instead of
doing read/modify/write.
- Rename re_setmulti() to re_set_rxmode() to be reflect reality.
- Simplify hash filter logic a little while I am here.
Reviewed by: yongari (early version)
|
|
|
|
|
|
|
|
| |
in device attach phase. Double GMII register access timeout value
to fix the issue.
Reported by: wkoszek
Tested by: wkoszek
|
|
|
|
|
|
|
|
|
|
| |
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
r185753 on fast ethernet controllers.
Reported by: csjp, Bruce Cran < bruce <> cran DOT org DOT uk >
Tested by: csjp, Bruce Cran (initial version)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
explicit command to enable Rx MAC prior to entering D3.
Tested by: Cyrus Rahman <crahman <> gmail DOT com>
|
|
|
|
|
|
|
| |
have no such register. While here clear undocumented PHY
register 0x0B for RTL8110S.
Obtained from: RealTek FreeBSD driver
|
|
|
|
| |
terminate active Tx/Rx operation.
|
|
|
|
|
| |
While here remove re_reset calls invoked in system error case as
controller reset is always done in device initialization.
|
|
|
|
|
|
|
|
| |
GMII access while Tx/Rx is in progress.
Reported by: Jaakko Heinonen <jh <> saunalahti DOT fi>,
Anton Yuzhaninov <citrin <> citrin DOT ru>
Tested by: Jaakko Heinonen <jh <> saunalahti DOT fi>
|
|
|
|
|
|
|
|
| |
Waiting for 1ms for each GMII register access looks overkill and it
may also decrease overall performance of driver because re(4)
invokes mii_tick for every hz.
Tested by: rpaulo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Previously it used to return success regardless of the result.
|
|
|
|
| |
Submitted by: Andrew < andrewwtulloch <> gmail DOT com >
|
|
|
|
|
|
|
| |
reading from EEPROM doesn't seem to work on these controllers.
Reported by: Milan Obuch ( freebsd-net at dino dot sk )
Tested by: Milan Obuch ( freebsd-net at dino dot sk )
|
|
|
|
|
|
|
|
| |
architectures.
Reported by: naddy
Tested on: sparc64
MFC after: 1 week
|
|
|
|
| |
highlighting work in vim.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
watchdog timeout issues and the root cause seems to stem from
silicon bug of controller. Personally I couldn't reproduce it on
RTL8169 controller but it seems it's dependent on usage pattern.
For newer PCIe based controllers I have no TSO complaints but
turning off TSO would be more safe. Users who are sure that
their controller works with TSO can still reenable the TSO with
ifconfig(8).
Reported by: Oliver Lehmann (lehmann at ans-netz dot de), Eugene Butusov (ebutusov at gmail dot com)
|
|
|
|
|
|
|
| |
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 )
|
| |
|
|
|
|
|
| |
Reported by: nork
Tested by: nork
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
diagnose revision specific issues in future. Also add 0x to notify
that the revision number is in hex form.
|
| |
|
|
|
|
|
| |
attached. This fixes NULL pointer dereference when polling(9) is
active and unsupported hardware is detected in device attach.
|
|
|
|
| |
reintialization.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
mapping fails fall back to traditional IO space access.
|
|
|
|
| |
instead of hardcoded value.
|
|
|
|
|
|
|
|
| |
RL_TXCFG register to identify a device in device probe. Reflect the
fact by modifing device description with general ethernet
controller family.
Note, rl_basetype in struct rl_type is not used and the more
detailed information is provided with rl_hwrev structure.
|
| |
|
|
|
|
|
|
|
|
| |
clearing MSI enable bit for MSI capable hardwares resulted in Tx
problems. MSI enable bit is set only when MSI is requested from
user.
Tested by: remko
|
|
|
|
|
|
|
|
| |
PCIe RealTek chips. Only pad IP packets if the payload is less than
28 bytes.
Obtained from: NetBSD
PR: kern/122221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
offload bugs by manual padding for short IP/UDP frames. Unfortunately
it seems that these workaround does not work reliably on newer PCIe
variants of RealTek chips.
To workaround the hardware bug, always pad short frames if Tx IP
checksum offload is requested. It seems that the hardware has a
bug in IP checksum offload handling. NetBSD manually pads short
frames only when the length of IP frame is less than 28 bytes but I
chose 60 bytes to safety. Also unconditionally set IP checksum
offload bit in Tx descriptor if any TCP or UDP checksum offload is
requested. This is the same way as Linux does but it's not
mentioned in data sheet.
Obtained from: NetBSD
Tested by: remko, danger
|
|
|
|
|
|
|
| |
default.
Reported by: Giulio Ferro ( auryn AT zirakzigil DOT org )
Tested by: Giulio Ferro ( auryn AT zirakzigil DOT org )
|
|
|
|
|
| |
register. If MSI was disabled by hw.re.msi_disable tunable
expliclty clear the MSI enable bit.
|
|
|
|
| |
disable DAC by default.
|
|
|
|
|
|
|
|
|
| |
multi-descriptor transmission attempt. Datasheet said nothing about
this requirements. This should fix a long-standing VLAN hardware
tagging issues with re(4).
Reported by: Giulio Ferro ( auryn AT zirakzigil DOT org )
Tested by: Giulio Ferro ( auryn AT zirakzigil DOT org )
|
|
|
|
|
|
| |
Previously re(4) used to blindly enable VLAN hardware tag stripping
and Rx checksum offload regardless of enabled optional features of
interface.
|
|
|
|
|
|
| |
vendor/revision/sub device id of the hardware to probe it.
This is the same way as NetBSD does and it enhances readabilty
a lot.
|
|
|
|
| |
While I'm here add a check for minimal MTU length.
|
|
|
|
| |
Tested by: Fabian Keil ( freebsd-listen AT fabienkeli DOT de )
|