Up to [DragonFly] / src / sys / dev / netif / re
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
- Move RX filter configuration from re_init() into re_setmulti() - IFF_BROADCAST will never be set/cleared - Fix SIOCSIFFLAGS support; it was really annoying that each time when I ran tcpdump, the NIC reinitialized itself.
- In re_stop(), call re_reset(), which is supposed to stop TX/RX engines. - In re_reset(), don't touch 0x82 (a magic CSR), which seems to be 8110/8169 specific. Write 1 to it on attach path. According-to: RealTek r8169-6.007.00 - For certain chips (looks like all MAC2 chips), RE_CMD_RESET will not stop TX/RX engines, a seperate command (RE_CMD_STOPREQ) must be issued before RE_CMD_RESET. According-to: RealTek r8168-8.008.00
- Pack boolean fields into re_softc.re_flags - Nuke some unused fields in re_softc # This file should have been committed along with if_re.c rev1.93
- Don't claim 7422 MTU size is support by various 8111/8169 chips (PCI devices); 6144 MTU size works reliably. Set MTU above 6144 (6 * 1024) on these chips and do following test: netperf -H host -l 30 -t UDP_STREAM -- -m (mtu-28) All kinds of wiredness will pop up on the test box. - Set max supported MTU to 9216 for 8168D. Obtained-from: Realtek r8168-8.008.00 - Set max supported MTU to 6144 for non-8168D GigE chips. - Cleanup jumbo frame/MTU size related macros. # As usual, 8169(with 88E1000 PHY) does not seem to work well with any jumbo # frame size
Correct jumbo frame support for 8168C/CP/D. These newer chips use ancient design, which does _not_ support gathering RX. An even worse aspect of the new chips' design is that it does not compat with old ones: the buffer length field in the RX descriptor seems to be completely ignored by the hardware. This means host memory will be trashed by hardware if driver uses gathering RX. Allocate a jumbo buffer pool for these chips and configure "max RX packet size" register according to MTU.
According to wpaul's comment, 8139C+ only support 64 TX/RX descriptors
Add hardware csum offload support for MAC style 2 chips, which include 8102E, 8102EL, 8168C, 8168CP and 8168D. Obtained-from: RealTek r8101-1.009.00 r8168-8.008.00 Add RE_C_AUTOPAD capability to indicate hardware could correctly pad short ether frames. Turn it on for newer version of 8168B (0x38000000 and 0xb8000000) and MAC style 2 chips; manually padding short UDP packets for newer version 8168B will result in incorrect UDP csum, while manually padding short ICMP packets for MAC style 2 chips will result in both incorrect IP header csum and incorrect IP length (o_O)
- Adjust PCI latency timer on all types of chips - Adjust PCI cache line size for 8110/8169 chips - For certain revision of 8101E, reading MAC address from IDRx may not work; read from EEPROM instead - Add comment that adjusting config1 and config5 may cause unrecoverible disaster Obtained-from: RealTek Linux drivers
Add some PHY fixups before we do mii_phy_probe() Obtained-from: Realtek BSD driver v176
Bring in some PCI register settings from RealTek BSD driver v176. Disable the PCI register configuration for "style 2 MAC", add comment about it.
- Read ethernet address from IDRx registers. Obtained-from: RealTek BSD driver v176 This eliminates the need to read/config EEPROM. Put EEPROM related functions under RE_USE_EEPROM; disabled by default - Maintain re_softc size no matter what kernel options we are using - Remove RE_DISABLE_HWCSUM; we could do it by clearing RE_C_HWCUM
- Nuke re_type, add RE_C_8139CP to indicate the chip is 8139C+ - Change hardware revision mask from 0x7cc00000 to 0xfc800000 Obtained-from: Realtek BSD driver v176 - Convert MAC mode to MAC version and save MAC version in softc Obtained-from: Realtek BSD driver v176 - Add hardware revision 0x34800000(8102E) and 0x28000000(chip name is unknown) Obtained-from: Realtek BSD driver v176
Increase default RX/TX descriptor count from 64 to 256
Use hardware timer to simulate interrupt moderation. Old devices will no longer be livelocked when they are receiving on GigE line. Newer devices also gain well controlled interrupt rate. If hardware supports interrupt moderation (e.g. 8168B, 8168C), you could also use hardware based interrupt moderation, however, due to lack of necessary information it does not work as reliably as simulated interrupt moderation. It is _not_ recommended currently. By default, PCI-E devices' simulated interrupt moderation timer is set to 75us, while PCI devices' is set to 125us.
- According to Realtek's BSD driver v176, we could always write to MISSEDPKT - Use pci_get_pciecap_ptr() to decide whether a given chip is PCI-E or not - Rename re_flags to re_caps; we will need a real re_flags soon
- It does not make sense to disable TX interrupt moderation - Add field in softc to store RX related interrupt bits This cleanup eases upcoming changes.
Add RX interrupt moderation suport for PCI-E GigaE chips. Interrupt moderation register position is obtained from Realtek's BSD driver v176. The meaning of the IM register bits is partially reverse engineered: RX timer position and unit. This kind of interrupt moderation does not work on PCI GigaE chips.
Get bus clock, which will be used to fix broken TCTR setting (hardware timer, interrupt moderation related)
Add tunable for RX/TX descriptor count
Don't assume that RE_RX_DESC_CNT and RE_TX_DESC_CNT are always same
Move some macros from if_rereg.h to if_revar.h; regroup them
re_chain_data is never used
- For relative newer parts (8168B), setting MTPS (max transmit packet size) according to MTU makes jumbo frame + TX csum offloading work. However, for old ones (8169), setting MTPS does not have much effect. - Reduce max jumbo frame size from 9018 to 7440 (according to DS) - Fix MTU setting in re_ioctl
Transmit csum offload does not work at all on certain hardware revision once frame length exceeds certain threshold (different parts seems to have different thresholds). Borrow code from ip_output to do software csum, if transmit csum offloading is enabled and frame length exceeds hardware's threshold. 8169, 8169S, 8169SB and 8168B are tested, while 8169S and 8169SB does not seem to have this bug.
- Don't substract ETHER_ALIGN from the fragment length, we don't do m_adj(ETHET_ALIGN) in re_newbuf() - If one fragment of a multi-fragment packet recolletion fails, we drop will consecutive fragments of this packet. - All of the TX descs in TX ring could be used; there is no need to reserve RE_TXDESC_SPARE TX descs
Rework re_newbuf() and re_encap()
- Instead of using magic number 4 define it as RE_TXDESC_SPARE - Clear if_timer only if all TX descs are free - Clear IFF_OACTIVE only if more than RE_TXDESC_SPARE TX descs ar free
By default do not enable hardware csum on PCIe re(4), which trashes packets intermittently if csum offload is enabled. This problem does not seem to plague PCI re(4). The pattern of trashed packets is not yet identified. From the tcpdump information provided by Joe, the packets' size should not be the direct cause. Hardware bug? Reported-by: Joe Talbott <email@example.com> (RTL8101E, PCIe re(4)) # Same problem is reported to FreeBSD by two RTL8168B(PCIe re(4)) users.
- Don't call m_adj() to make RX buffer's _payload_ on longword aligned, because some re(4) chips (e.g. RTL8101E) require RX buffer to be 8-bytes aligned. This change shows no noticeable performance change. Reported-by: Joe Talbott <firstname.lastname@example.org> - Avoid writing extra hardware registers by writing 2 bytes to IDR4 instead instead of writing 4 bytes, bacause: 1) the extra two registers after IDR5 are reserved. 2) accessing arpcom.ac_enaddr[6,7] should be invalid. - Add a flag field in re_softc and re_hwrev. Currently only one flag, RE_F_HASMPC, is defined. This flag is used to indicate whether the hardware has MPC register or not, so we can avoid writing to MPC's position, if that position is reserved. - Move descriptor ring address setting up before RX/TX enabling, since some re(4) chips (e.g. RTL8101E) will try accessing descriptor ring immediately after RX/TX is enabled, which results in intermittent kernel panic or system hanging. Paniced-by: Joe Talbott <email@example.com> - Avoid calling re_init(), if hw.reX.tx_moderation is changed but NIC is not up yet. - Const-fy global hardware id arrays and nuke unused macro while I'm here. Thank Joe Talbott <firstname.lastname@example.org> to help debugging and provide valuable information (esp. locating the problematic RX/TX enabling :) Thank dillon@ to provide debugging hints. Tested-by: Joe Talbott <email@example.com> (RTL8101E) swildner@ (onboard RTL8169S) (*) me (RTL8169S) # (*) swildner@'s card is still half broken even after this commit :\
Sync re(4) with FreeBSD: - Add support for RealTek 8169SC/8110SC and RTL8101E devices. The latter is a PCIe 10/100 chip. - Add support for RealTek RTL8168(B?) - Fix EEPROM reading code - Disable diagnostic code in re_attach() by default. It is almost useless and has caused much trouble. - Manually padding small IP datagrams to work arround hardware checksum offload bug . Enable IP/TCP/UDP checksum offload after this fix. - Work arround hardware TX bug in some PCIe re(4) devices: The TX command, which is issued when there is transmission in progress, will get lost . So at the end of re_txeof(), if there are still packets sitting in the TX ring, we kick the TX engine again. - Add a sysctl hw.reX.tx_moderation to turn on/off TX moderation. It is on by default. - Move softc related structs from if_rereg.h into newly created if_revar.h Thank Bill Paul (firstname.lastname@example.org) and many other people for their work on this driver. # #  Detailed description of this bug is at: # FreeBSD dev/re/if_re.c rev1.70 by email@example.com # #  Detailed description of this bug is at: # FreeBSD dev/re/if_re.c rev1.71 by firstname.lastname@example.org #