summaryrefslogtreecommitdiffstats
path: root/sys/dev/fxp
Commit message (Collapse)AuthorAgeFilesLines
* All current uses of pci_set_powerstate are bogus, at least in theory.imp2003-07-031-4/+8
| | | | | | | | | | However, they are presently necessary due to bigger bogusness in the pci bus layer not doing the right thing on suspend/resume or on initial device probe. This is exactly the sort of thing that the BURN_BRIDGES option was invented for. Mark all of them as BURN_BRIDGES. As soon as I have the powerstate stuff properly integrated into the pci bus code, I intend to remove all these workarounds.
* Mega busdma API commit.scottl2003-07-011-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg. Lockfunc allows a driver to provide a function for managing its locking semantics while using busdma. At the moment, this is used for the asynchronous busdma_swi and callback mechanism. Two lockfunc implementations are provided: busdma_lock_mutex() performs standard mutex operations on the mutex that is specified from lockfuncarg. dftl_lock() is a panic implementation and is defaulted to when NULL, NULL are passed to bus_dma_tag_create(). The only time that NULL, NULL should ever be used is when the driver ensures that bus_dmamap_load() will not be deferred. Drivers that do not provide their own locking can pass busdma_lock_mutex,&Giant args in order to preserve the former behaviour. sparc64 and powerpc do not provide real busdma_swi functions, so this is largely a noop on those platforms. The busdma_swi on is64 is not properly locked yet, so warnings will be emitted on this platform when busdma callback deferrals happen. If anyone gets panics or warnings from dflt_lock() being called, please let me know right away. Reviewed by: tmm, gibbs
* Drop locks before calling if_input() since it may re-enter fxp_start()njl2003-06-231-0/+10
| | | | | | | | | in the netisr case. This would result in a lock reversal. This fixes the net.isr.enable=1 case. Better performance might be obtained by chaining all packets received, dropping the lock, and then calling if_input() on each one. Reported by: hmp
* Add a new device ID.mux2003-06-121-0/+1
| | | | Submitted by: Tom Alsberg <alsbergt@cs.huji.ac.il>
* Replace if_fxp's handrolled defrag function with m_defrag.silby2003-06-021-14/+3
| | | | | | No actual bug with the existing code, just tidying things up. Submitted by: hmp
* Always set the hardware parse bit in the IPCB structure when thistruckman2003-05-251-6/+43
| | | | | | | | | | | | | | | | | | | | | | | | structure, which is new to the 82550 and 82551, is used to transmit a packet. This appears to fix the packet truncation problem that was observed when using 82550-based fxp cards to transmit ICMP or fragmented UDP packets of certain lengths which only had one to three bytes in the second and final mbuf of the packet. This matches a note in the "Intel 8255x 10/100 Mbps Ethernet Controller Family Open Source Software Developer Manual", which says that the hardware parse bit should be set when sending these types of packets. There have also been unconfirmed reports of similar problems when transmitting TCP packets, which should not be affected by the above mentioned change because the hardware parse bit was already being set if the stack requested hardware checksumming of the packet. If the problem remains, the use of the IPCB structure can be disabled to cause the driver to fall back to using the older 82559 interface with 82550-based cards by setting hint.fxp.UNIT_NUMBER.ipcbxmit_disable to a non-zero value at boot time, or using kenv to set this variable before using kldload to load the fxp driver. Approved by: re (jhb)
* Add a tunable/sysctl "hw.fxp_noflow" which disables flow control supportrwatson2003-05-161-1/+5
| | | | | | | | | | | | | on if_fxp cards. When flow control is enabled, if the operating system doesn't acknowledge the packet buffer filling, the card will begin to generate ethernet quench packets, but appears to get into a feedback loop of some sort, hosing local switches. This is a temporary workaround for 5.1: the ability to configure flow control should probably be exposed by some or another management interface on ethernet link layer devices. Approved by: re (bmah) Reviewed by: mux
* GCC 3.3 complains about anonymous structures in unions, somux2003-05-141-7/+7
| | | | | | | give the fxp_ipcb structure a name in the fxp_rfa structure. Submitted by: peter Approved by: re (jhb)
* Fix the unaligned access problems that some people saw on alphamux2003-05-121-1/+1
| | | | | | | | | by using a __packed keyword for the fxp_rfa structure. The Intel guys who designed this structure with unaligned fields deserve to be shot. Tested by: kris Approved by: re@ (jhb)
* Fix tpyo in last commit.imp2003-04-301-1/+1
| | | | Noticed by: kuriyama-san
* Get rid of the redundant 'gone' field, and overload suspend instead.imp2003-04-302-13/+12
| | | | | | | | | | | | | | Check for suspend before the device polling, rather than after it. Check to see if the current thread owns the lock in ioctl and return EBUSY if it does. This advances the locking to the point that I can eject my fxp card 10 times in a row, but I agree with Jeff Hsu that we need to get the network layer locking finished before chasing more of the races here (actually, he doesn't think this set is worth it even). There's a number of races between FXP_LOCK in detach and all other users of FXP_LOCK, and this gets back to the 'device with sleepers being forcibly detached' problem as well...
* (5) from last commit was omitted by mistake:imp2003-04-291-0/+3
| | | | (5) Return immediately from fxp_intr() if gone is set.
* Fix 5 bugs:imp2003-04-292-8/+11
| | | | | | | | | | | 1) always call fxp_stop in fxp_detach. Since we don't read from the card, there's no need to carefully look at things with bus_child_present. 2) Call FXP_UNLOCK() before calling bus_teardown_intr to avoid a possible deadlock reported by jhb. 3) add gone to the softc. Set it to true in detach. 4) Return immediately if gone is true in fxp_ioctl 5) Return immediately if gone is true in fxp_intr
* Make fxp(4) INTR_MPSAFE (but do not enable MPSAFE just yet):njl2003-04-252-51/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | - Add fxp_start_body() and change fxp_start() to just acquire locks and then call fxp_start_body(). Places that would call fxp_start() with locks held (mutex recursion) now call fxp_start_body() directly. Remove MTX_RECURSE flag from sc_mtx. [gallatin] - Change fxp_attach() to work without the softc lock, saving interrupt hooking until the head of fxp_attach(). - Call ether_ifattach() before overriding ifp parameters. This reverts part of 1.155. - Remove multiple error paths in fxp_attach(). - Teardown interrupt in fxp_detach() before unlocking the softc. - Make sure mutex is not held in fxp_release() - Delete the miibus instance and/or self in fxp_release(), not in fxp_detach(). This can happen if attach fails partway through. - Move ifmedia_removeall to fxp_release() since attach may fail after media have been allocated. - Add locking to fxp_suspend, fxp_resume, fxp_start, fxp_intr, fxp_poll, fxp_tick, fxp_ioctl, fxp_watchdog. - Pass in ifp to fxp_intr_body since its callers sometimes already use it. - Add compatibility define for INTR_MPSAFE for 4.x. [gallatin] - You don't need to bzero softc. Ideas from: gallatin, mux Tested by: >400M packets of dd/ssh, NFS, ping on i386 UP
* Update comment to match reality.sobomax2003-04-161-2/+1
|
* - Don't call pci_enable_io() in drivers (unless needed for resume).mdodd2003-04-161-10/+4
| | | | | - Don't test memory/port status and emit an error message; the PCI bus code will do this now.
* - Express hard dependencies on bus (pci, isa, pccard) andmdodd2003-04-151-2/+4
| | | | | | | | network layer (ether). - Don't abuse module names to facilitate ifconfig module loading; such abuse isn't really needed. (And if we do need type information associated with a module then we should make it explicit and not use hacks.)
* Use pci_enable_{busmaster|io}() instead of directly writing intosobomax2003-04-141-3/+3
| | | | | | PCI configuration register. Submitted by: mdodd
* Before attaching device set PCIM_CMD_PORTEN in addition tosobomax2003-04-141-2/+2
| | | | | | PCIM_CMD_MEMEN and PCIM_CMD_BUSMASTEREN, becaise some braindead BIOSes (such as one found in my vprmatrix notebook) forget to initialize it properly resulting in attachment failure.
* - Call ether_ifdetach() before shutting down the hardware.mux2003-04-111-20/+18
| | | | | | | | | | - Remove a useless device_is_alive() check. - Disable interrupts if bus_child_present() so that this check is more useful. This fixes the hangs I was seeing when unloading the fxp driver. Suggestions from: hsu, njl
* - Clean up the fxp_release() and fxp_detach() functions.mux2003-04-101-46/+46
| | | | | | | | - Be sure to teardown the interrupt first so that "kldunload if_fxp" doesn't panic the box. It's now deadlocking rather than crashing, which isn't really better, but I'm unsure this is fxp(4)'s fault. - Change a bus_dmamap_sync() call to also do a BUS_DMASYNC_PREREAD now that we can pass several operations.
* - Pass a busdma tag and a busdma map to fxp_dma_wait() so thatmux2003-04-081-8/+13
| | | | | it can do the necessary bus_dmamap_sync() calls. - While I'm here, reorder arguments to match other functions.
* Add an XXX comment for the atomic operation in the __alpha__mux2003-04-081-1/+3
| | | | | case so that it doesn't confuse more people. Use the more correct atomic_clear_16() instead of atomic_clear_short().
* - Endian fixes.mux2003-04-081-5/+6
| | | | - 6 -> ETHER_ADDR_LEN.
* Fix the hangs people have been seeing. For some reason, themux2003-04-081-11/+7
| | | | | atomic operation change caused this, so backout it until I can figure out what's wrong with it.
* Correct the maxsize and maxsegsz parameters for themux2003-04-071-7/+7
| | | | | bus_dma_tag_create() calls. Without this, fxp(4) + PAE would consume insane amounts of bounce pages.
* Remove an erroneous htole16(). The byte_count field in themux2003-04-071-1/+1
| | | | | struct fxp_cb_config is a 6-bit field, not a 16-bit integer as in struct fxp_cb_tx.
* Move a bus_dmamap_sync() to the correct place.mux2003-04-061-1/+1
|
* Because alpha can't access memory in 16-bit granularity,mux2003-04-061-7/+11
| | | | | | | | | | | we're using an atomic operation to clear the suspend flag in fxp_start(). Since other architectures may need the same thing, we want to do it all the time and not only in the __alpha__ case. However, we don't want to use atomic operations on 16-bit integers, because those may not be available on any architecture. We're thus faking a 32-bit atomic operation here. This patch also deals with endianness here.
* Revert the s/u_int/u_int8_t/ changes, we can't really use othermux2003-04-061-22/+22
| | | | | | integer types than int with bit-fields in a portable way. Prodded by: bde
* Use __FBSDID.mux2003-04-061-1/+3
|
* Correct the definition of the link_addr and rbd_addr fieldsmux2003-04-061-2/+2
| | | | | in struct fxp_rfa. This should have been committed with my last endianness fixes.
* - Instead of rolling our own alignment-safe function, use le32enc()mux2003-04-061-78/+66
| | | | | | which deals with both endianness and alignment issues. - Collect low-hanging fruits for endianness safety. - Use 0xffffffff instead of -1 where appropriate.
* - Use __FXP_BITFIELDX macros to make the configuration bitfieldmux2003-04-051-81/+99
| | | | | | | | | | | endian safe. - Change some u_int to u_int8_t which make more sense here since we're really defining bytes. That produces the same code due to how bitfields work. - Add the definition of the vlan_drop_en bit (not used yet). - Add some useful comments. Obtained from: NetBSD
* - Change a FXP_NRFABUFS which would have been a FXP_NTXCB.mux2003-04-051-3/+3
| | | | | | - Correct some bus_dmamap_sync() calls. Submitted by: jake
* Setup our interrupt only at the end of fxp_attach(), when allmux2003-04-051-12/+12
| | | | | | other allocations/initializations have been successful. I kinda doubt it will fix the recent breakage that some people are seeing, but this could have caused problems for sure.
* Remove useless initialization.mux2003-04-031-1/+0
|
* Fix fxp(4), this changed shouldn't have crept in.mux2003-04-031-2/+2
| | | | | Pointy hat to: mux Reported by: Pawel Worach <pawel.worach@nordea.com>
* Remove all the bogus volatile qualifiers from the structs definitionsmux2003-04-032-148/+146
| | | | and associated evil casts to discard them.
* Convert the fxp(4) driver to the busdma API.mux2003-04-023-230/+453
| | | | | | | | | | | | | | | This patch is rather big because I had to significantly redesign the driver to make the busdma conversion possible. Most notably, hardware and software structures were carefully splitted to get rid of all the structs overlapping evilness. Special thanks to phk and Richard Puga <puga@mauibuilt.com> for providing me with fxp(4) hardware to do this work. Thanks to marcel for testing this on ia64, and to Fred Clift <fclift@verio.net> for testing this on alpha. Tested on: i386, ia64, alpha
* Correct names for fxp devices. Sort data by devid injdp2003-03-081-20/+20
| | | | | | | | | fxp_ident_table. PR: kern/48699 Submitted by: Sergey A. Osokin <osa@FreeBSD.org.ru> Obtained from: NetBSD (the device strings, that is) MFC after: 4 weeks
* Finish driving a stake through the heart of netns and the associatedpeter2003-03-051-5/+0
| | | | | | ifdefs scattered around the place - its dead Jim! The SMB stuff had stolen AF_NS, make it official.
* Remember to set if_capenable when setting up checksum offload in fxp_attach().wpaul2003-02-271-0/+1
| | | | Pointed out by: jlemon
* As previously threatened, add TCP/IP checksum offload support towpaul2003-02-263-10/+236
| | | | | | | | | | | the fxp driver. This is enabled only for the 82550/82551 chips (PCI revision code 12 or 13). RX and TX checksum offload are both supported. Transmit offload is limited to TCP and UDP only right now: there seems to be a problem with IP header checksumming on transmit in some cases. This chip has hardware VLAN support as well. I hope to enable support for this eventually.
* Back out M_* changes, per decision of the TRB.imp2003-02-191-3/+3
| | | | Approved by: trb
* Add PCI id for fxp(Intel Pro/100 M Mobile Connection).sanpei2003-01-271-0/+1
| | | | | | PR: i386/41915 Submitted by: Ross A. Lippert <ripper@eskimo.com> MFC after: 1 week
* Remove M_TRYWAIT/M_WAITOK/M_WAIT. Callers should use 0.alfred2003-01-211-3/+3
| | | | Merge M_NOWAIT/M_DONTWAIT into a single flag M_NOWAIT.
* network interface driver changes:sam2002-11-141-12/+8
| | | | | | | | | | | | | | o don't strip the Ethernet header from inbound packets; pass packets up the stack intact (required significant changes to some drivers) o reference common definitions in net/ethernet.h (e.g. ETHER_ALIGN) o track ether_ifattach/ether_ifdetach API changes o track bpf changes (use BPF_TAP and BPF_MTAP) o track vlan changes (ifnet capabilities, revised processing scheme, etc.) o use if_input to pass packets "up" o call ether_ioctl for default handling of ioctls Reviewed by: many Approved by: re
* Properly fix the occassional random crash issue that revision 1.142iedowse2002-11-072-31/+24
| | | | | | | | | | | | | | | | | | | just limited to the DEVICE_POLLING case. This removes the FXP_RFA_RNRMARK hack, and replaces it with a softc flag that is used to record when the handling of a no-resource condition was deferred due to running out of DEVICE_POLLING cycles. This was tested on -stable, but the code is essentially the same as in -current. It should only affect the case where DEVICE_POLLING is defined. The details of the mechanism behind the crashes are still uncertain but the most likely cause seems to be some kind of hardware confusion when the no-resource recovery code is accidentally invoked while the receiver is still active. This could have happened if the hardware left the 0x4000 bit of the RFA status word set. The comments in the commit log for revision 1.142 stating that the driver could clash with the hardware writing to this status word were not correct. Tested by: Guy Helmer <ghelmer@palisadesys.com>
* Revision 1.136 introduced two features that may cause undefinediedowse2002-10-301-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | behaviour of the hardware: a possibly reserved bit of the receive descriptor (RFA) `status' field is borrowed to record no-resource (RNR) events, and the same status field is read and written to at a time that may clash with the hardware updating this field. There is no hardware documentation available to determine if these things are safe to do; the second issue almost certainly isn't, and the first is only safe if there is documentation saying that this bit is free to be used by the driver. The PR referenced below provides extremely convincing evidence that the changes cause random crashes on some (unusual) hardware. Since these features are only required by the DEVICE_POLLING case, this commit makes their use conditional on that option. It does not change the DEVICE_POLLING case, but at least people with the rare hardware on which this code causes problems can now avoid the crashes by not enabling DEVICE_POLLING. PR: kern/42260 Reviewed by: luigi Problem revision found by: Pawel Malachowski <pawmal@unia.3lo.lublin.pl> Tested by: Pawel Malachowski <pawmal@unia.3lo.lublin.pl> MFC after: 1 week
OpenPOWER on IntegriCloud