summaryrefslogtreecommitdiffstats
path: root/sys/dev/re
Commit message (Collapse)AuthorAgeFilesLines
* The TCP checksum offload handling in the 8111B/8168B and 8101E PCIe canwpaul2007-01-251-1/+6
| | | | | | | | | | | | | | | apparently be confused by short TCP segments that have been manually padded to the minimum ethernet frame size. The driver does short frame padding in software as a workaround for a bug in the 8169 PCI devices that causes short IP fragments to be corrupted due to an apparent conflict between the hardware autopadding and hardware IP checksumming. To fix this, we avoid software padding for short TCP segments, since the hardware seems to autopad and checksum these correctly (even the older 8169 NICs get these right). Short UDP packets appear to be handled correctly in all cases. This should work around the IP header checksum bug in the 8169 while not tripping the TCP checksum bug in the 8111B/8168B and 8101E.
* It seems that enabling Tx and Rx before setting descriptor DMAyongari2007-01-231-15/+17
| | | | | | | | | | | | | addresses shall access invalid descriptor DMA addresses on PCIe hardwares and then panicked the system. To fix it set descriptor DMA addresses before enabling Tx and Rx such that hardware can see valid descriptor DMA addresses. Also set RL_EARLY_TX_THRESH before starting Tx and Rx. Reported by: steve.tell AT crashmail DOT de Tested by: steve.tell AT crashmail DOT de Obtained from: NetBSD MFC after: 1 week
* o In re_newbuf() and re_encap() if re_dma_map_desc() aborts the mappingmarius2007-01-161-47/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix re_setmulti() so that it works correctly for PCIe chips wherewpaul2007-01-111-2/+19
| | | | | the multicast hash table are in reverse order compared to older devices.
* - Use the re_tick() callout instead of if_slowtimo() for drivingmarius2006-12-201-35/+23
| | | | | | | | | re_watchdog() in order to avoid races accessing if_timer. - Use bus_get_dma_tag() so re(4) works on platforms requiring it. - Remove invalid BUS_DMA_ALLOCNOW when creating the parent DMA tag and the tags that are used for static memory allocations. - Don't bother to set if_mtu to ETHERMTU, ether_ifattach() does that. - Remove an unused variable in re_intr().
* Fix typo.yongari2006-11-211-1/+1
|
* Add TSO support.yongari2006-11-211-10/+24
| | | | Tested by: wilko, Pieter de Goeje < pieter AT degoeje DOT nl >
* o Correctly set IFCAP_VLAN_HWCSUM as re(4) can do VLAN tagging/checksumyongari2006-11-211-5/+17
| | | | | offloading in hardware. o Correctly set media header length for VLAN.
* Don't set RL_CFG1_FULLDUPLEX bit. The RL_CFG1_FULLDUPLEX bit inyongari2006-11-211-1/+1
| | | | config register 1 is only valid on 8129.
* Move ethernet VLAN tags from mtags to its own mbuf packet header fieldandre2006-09-171-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | m_pkthdr.ether_vlan. The presence of the M_VLANTAG flag on the mbuf signifies the presence and validity of its content. Drivers that support hardware VLAN tag stripping fill in the received VLAN tag (containing both vlan and priority information) into the ether_vtag mbuf packet header field: m->m_pkthdr.ether_vtag = vlan_id; /* ntohs()? */ m->m_flags |= M_VLANTAG; to mark the packet m with the specified VLAN tag. On output the driver should check the mbuf for the M_VLANTAG flag to see if a VLAN tag is present and valid: if (m->m_flags & M_VLANTAG) { ... = m->m_pkthdr.ether_vtag; /* htons()? */ ... pass tag to hardware ... } VLAN tags are stored in host byte order. Byte swapping may be necessary. (Note: This driver conversion was mechanic and did not add or remove any byte swapping in the drivers.) Remove zone_mtag_vlan UMA zone and MTAG_VLAN definition. No more tag memory allocation have to be done. Reviewed by: thompsa, yar Sponsored by: TCP/IP Optimization Fundraise 2005
* - Consistently use if_printf() only in interface methods: if_start(),glebius2006-09-151-18/+21
| | | | | | | | if_watchdog, etc., or in functions used only in these methods. In all other functions in the driver use device_printf(). - Use __func__ instead of typing function name. Submitted by: Alex Lyashkov <umka sevcity.net>
* Make 8139C+ work again which was broken since rev 1.68.yongari2006-09-081-0/+8
| | | | | | | | | | | Ever since rev 1.68 re(4) checks the validity of link in re_start. But rlphy(4) got a garbled data due to a different bit layout used on 8139C+ and it couldn't report correct link state. To fix it, ignore BMCR_LOOP and BMCR_ISO bits which have different meanings on 8139C+. I think this also make dhclient(8) work on 8139C+. Reported by: Gerrit Kuehn <gerrit AT pmp DOT uni-hannover DOT de> Tested by: Gerrit Kuehn <gerrit AT pmp DOT uni-hannover DOT de>
* Fix re(4) breakge introduced in tree from rev 1.68.yongari2006-08-031-6/+5
| | | | | | | | This should fix incorrect configuration of station address on big-endian architectures. Reviewed by: wpaul Tested on: sparc64
* Another small update to the re(4) driver:wpaul2006-08-011-23/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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.
* Fix the following bugs in re(4)wpaul2006-07-301-21/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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.
* Properly detect the RTL8168(B?) again. RealTek sent me a bunch of samplewpaul2006-06-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add support for the RealTek 8169SC/8110SC and RTL8101E devices. Thewpaul2006-06-261-137/+252
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Rename device name in the last commit. According to PR, the ID isglebius2006-05-241-3/+3
| | | | | | | more likely to belong to chips of 8168 family. PR: kern/96734 Submitted by: Sven Petai <hadara bsd.ee>
* Add support for RTL8111B chip, that can be found on some mainboards,glebius2006-03-221-0/+3
| | | | | | for example ASUS P5PL2. Tested by: Vadim Frolov <vadim uch.net>
* Correctly switch IFCAP_VLAN_HWTAGGING on and off.glebius2006-03-031-6/+12
| | | | Reported & tested by: Peter Blok <pblok bsd4all.org>
* Copy MAC address to fix alignment problems.ticso2006-02-201-2/+8
| | | | | Tested on alpha (AS600) with RTL8169S Suggested by: jhb
* Do not touch ifp->if_baudrate in miibus aware drivers.glebius2006-02-141-4/+0
|
* - Fix VLAN_INPUT_TAG() macro, so that it doesn't touch mtag inglebius2005-12-181-2/+5
| | | | | | | | | case if memory allocation failed. - Remove fourth argument from VLAN_INPUT_TAG(), that was used incorrectly in almost all drivers. Indicate failure with mbuf value of NULL. In collaboration with: yongari, ru, sam
* Check IFF_DRV_RUNNING in the re_intr() loop. It can disappear,glebius2005-11-221-4/+6
| | | | | | since re_rxeof() drops the lock for some time. Reported & tested by: XueFeng Deng <dsnofe yahoo.com.cn>
* - Store pointer to the link-level address right in "struct ifnet"ru2005-11-111-2/+2
| | | | | | | | | | rather than in ifindex_table[]; all (except one) accesses are through ifp anyway. IF_LLADDR() works faster, and all (except one) ifaddr_byindex() users were converted to use ifp->if_addr. - Stop storing a (pointer to) Ethernet address in "struct arpcom", and drop the IFP2ENADDR() macro; all users have been converted to use IF_LLADDR() instead.
* The controller -> device switch happened in 4.0, fix commentimp2005-10-221-1/+1
|
* Only allow the sk(4) driver to attach to revision 2 of the LinkSys EG1032jhb2005-10-141-0/+13
| | | | | | | | 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
* - Don't pollute opt_global.h with DEVICE_POLLING and introduceglebius2005-10-051-0/+4
| | | | | | | | | opt_device_polling.h - Include opt_device_polling.h into appropriate files. - Embrace with HAVE_KERNEL_OPTION_HEADERS the include in the files that can be compiled as loadable modules. Reviewed by: bde
* Big polling(4) cleanup.glebius2005-10-011-40/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | o Axe poll in trap. o Axe IFF_POLLING flag from if_flags. o Rework revision 1.21 (Giant removal), in such a way that poll_mtx is not dropped during call to polling handler. This fixes problem with idle polling. o Make registration and deregistration from polling in a functional way, insted of next tick/interrupt. o Obsolete kern.polling.enable. Polling is turned on/off with ifconfig. Detailed kern_poll.c changes: - Remove polling handler flags, introduced in 1.21. The are not needed now. - Forget and do not check if_flags, if_capenable and if_drv_flags. - Call all registered polling handlers unconditionally. - Do not drop poll_mtx, when entering polling handlers. - In ether_poll() NET_LOCK_GIANT prior to locking poll_mtx. - In netisr_poll() axe the block, where polling code asks drivers to unregister. - In netisr_poll() and ether_poll() do polling always, if any handlers are present. - In ether_poll_[de]register() remove a lot of error hiding code. Assert that arguments are correct, instead. - In ether_poll_[de]register() use standard return values in case of error or success. - Introduce poll_switch() that is a sysctl handler for kern.polling.enable. poll_switch() goes through interface list and enabled/disables polling. A message that kern.polling.enable is deprecated is printed. Detailed driver changes: - On attach driver announces IFCAP_POLLING in if_capabilities, but not in if_capenable. - On detach driver calls ether_poll_deregister() if polling is enabled. - In polling handler driver obtains its lock and checks IFF_DRV_RUNNING flag. If there is no, then unlocks and returns. - In ioctl handler driver checks for IFCAP_POLLING flag requested to be set or cleared. Driver first calls ether_poll_[de]register(), then obtains driver lock and [dis/en]ables interrupts. - In interrupt handler driver checks IFCAP_POLLING flag in if_capenable. If present, then returns.This is important to protect from spurious interrupts. Reviewed by: ru, sam, jhb
* - Use if_printf() and device_printf() in re(4) and remove rl_unit fromjhb2005-09-291-54/+49
| | | | | | | | | | | | | | | | 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)
* Make sure that we call if_free(ifp) after bus_teardown_intr. Since weimp2005-09-191-2/+2
| | | | | | | could get an interrupt after we free the ifp, and the interrupt handler depended on the ifp being still alive, this could, in theory, cause a crash. Eliminate this possibility by moving the if_free to after the bus_teardown_intr() call.
* Don't recommend re_detach() (like in vr(4)) as anotherru2005-09-151-2/+1
| | | | | | | | | possible method to prevent panicing in interrupt handler after re_shutdown(), sometimes seen on SMP systems. This would work here only because re_detach() clears IFF_UP (to prevent another race) and it was demonstrated that it's not enough to call vr_detach() in vr_shutdown() to prevent a panic.
* re_detach() fixes:ru2005-09-151-15/+7
| | | | | | | | | | | - Fixed if_free() logic screw-up that can either result in freeing a NULL pointer or leaking "struct ifnet". - Move if_free() after re_stop(); the latter accesses "struct ifnet". This bug was masked by a previous bug. - Restore the fix for a panic on detach caused by racing with BPF detach code by Bill by moving ether_ifdetach() after re_stop() and resetting IFF_UP; this got screwed up in revs. 1.30 and 1.36.
* In re_shutdown() mark interface as down since otherwise we will panic ifsobomax2005-08-181-0/+7
| | | | | | | | | | | interrupt comes in later on, which can happen in some uncommon cases. Another possible fix is to call re_detach() instead of re_stop(), like ve(4) does, but I am not sure if the latter is really RTTD, so that stick with this one-liner for now. PR: kern/80005 Approved by: silence on -arch, no reply from selected network gurus
* Propagate rename of IFF_OACTIVE and IFF_RUNNING to IFF_DRV_OACTIVE andrwatson2005-08-091-7/+7
| | | | | | | | | | | | | | IFF_DRV_RUNNING, as well as the move from ifnet.if_flags to ifnet.if_drv_flags. Device drivers are now responsible for synchronizing access to these flags, as they are in if_drv_flags. This helps prevent races between the network stack and device driver in maintaining the interface flags field. Many __FreeBSD__ and __FreeBSD_version checks maintained and continued; some less so. Reviewed by: pjd, bz MFC after: 7 days
* Recognize D-Link DGE-528(T) Gigabit as an re(4) device.tobez2005-08-051-0/+2
| | | | | | Submitted by: Andrus Nomm <andrus@members.ee> PR: 76780 MFC After: 1 week
* Modify device drivers supporting multicast addresses to lock if_addr_mtxrwatson2005-08-031-0/+2
| | | | | | | | over iteration of their multicast address lists when synchronizing the hardware address filter with the network stack-maintained list. Problem reported by: Ed Maste (emaste at phaedrus dot sandvine dot ca> MFC after: 1 week
* Use correct pointer type. This should fix non-functional re(4)yongari2005-07-011-1/+1
| | | | | | driver on 64bit architectures. Approved by: re (scottl)
* Move if_alloc() up so it's before mii_phy_probe().brooks2005-06-111-6/+7
|
* Stop embedding struct ifnet at the top of driver softcs. Instead thebrooks2005-06-101-14/+23
| | | | | | | | | | | | | | | | | | | | 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
* Remove bus_{mem,p}io.h and related code for a micro-optimization on i386nyan2005-05-291-2/+0
| | | | | | and amd64. The optimization is a trivial on recent machines. Reviewed by: -arch (imp, marcel, dfr)
* Unbreak build with POLLING. I should really listen and test with NOTESmlaier2005-03-131-1/+1
| | | | instead of the module build.
* ALTQ support for re(4).mlaier2005-03-121-6/+14
| | | | | | Submitted by: Chris Dionissopoulos, Theo Schlossnagle PR: kern/78681 MFC after: 2 weeks
* Use BUS_PROBE_DEFAULT in preference to 0 and BUS_PROBE_LOW_PRIORITY inimp2005-03-011-1/+1
| | | | | preference to some random negative number to allow other drivers a bite at the apple.
* Bring in support for SUGOI LAN GIGA NIC made by System TALKS, Inc fromimp2005-01-221-0/+3
| | | | | | | | | a RealTek 8169SB. PR: 74262 Submitted by: Yoshikazu GOTO-san # Submitter notes that he's unsure of the revision string for 8169SB
* Start each of the license/copyright comments with /*-, minor shuffle of linesimp2005-01-061-1/+1
|
* Disable checksum offloading by default. It seems to produce corrupted packetscognet2005-01-051-2/+2
| | | | | | | with some revisions of the chip (particularly when using multiple TX descriptors). MFC after: 1 week
* In re_detach(), remove an extra call to ether_ifdetach().cognet2005-01-021-1/+0
| | | | | | This fixes a panic that occurs when unloading the kernel module. MFC after: 3 days
* fix jumbo frames as much as they can be fixed for re. We now cap the MTUjmg2004-09-281-16/+54
| | | | | | | | | | | 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
* trim trailing white space..jmg2004-09-201-2/+2
| | | | | | call the re mutex by it's name.. MFC after: 3 days
OpenPOWER on IntegriCloud