summaryrefslogtreecommitdiffstats
path: root/sys/pci/if_dc.c
Commit message (Collapse)AuthorAgeFilesLines
* Add suspend/resume code mostly merged from fxp/rl driver.iwasaki2002-05-061-0/+81
| | | | | | | This is temporary hack, better and generalized solution probably should be implemented at lower layer(MII or PCI?). Tested by: shoko.araki@soliton.co.jp MFC after: 1 week
* Don't grab the lock until somewhat later in attach to avoid a lockphk2002-05-031-6/+7
| | | | reversal.
* Move us yet closer to IFM_* definitions in NetBSD.phk2002-04-291-6/+6
|
* Change callers of mtx_init() to pass in an appropriate lock type name. Injhb2002-04-041-1/+2
| | | | | | | most cases NULL is passed, but in some cases such as network driver locks (which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used. Tested on: i386, alpha, sparc64
* Remove __P.alfred2002-03-201-67/+62
|
* Add VLAN for the dc(4) driver (ie long frame). The patch is 2 parts.ambrisko2002-01-161-12/+26
| | | | | | | | | | | | | | | | One to notify the system that the MTU for VLAN can be 1500 so the vlan will automatically be configured with a 1500 MTU the other is to ignore the error case if the received frame is to long. The frame size notification came from code in the SIS driver, and the support for long frames derived from the NetBSD Tulip driver. Tested on: 4 port D-Link adapter DFE-570TX 4 Intel 21143 Netgear card with 82c169 PNIC 10/100BaseTX Reviewed by: ru (manpage), wpaul (not objected to), archie Approved by: imp Obtained from: NetBSD
* Fix the "conexant chips don't work in full duplexmode" problem. Accordingwpaul2001-12-191-4/+8
| | | | | | | | | | | | | to Phil Kernick: "The problem is that in full duplex mode, the Conexant chip always reports a carrier lost error, even when the frame is successfully sent. So, if we have a Conexant chip, then ignore carrier lost when in full duplex mode." Since the Xircom chips seem to have the same issue and since we already have a workaround for this, just expand the workaround test to also check for DC_IS_CONEXANT().
* Fix compiler warning in dc_intr(): if the only code that does a "goto"wpaul2001-12-191-0/+3
| | | | | | to a label is inside an #ifdef block, then the label should *also* be inside an #ifdef block. Hide the "done:" label which is only used if DEVICE_POLLING is enabled under #ifdef DEVICE_POLLING.
* Patch up some existing style bugs and some that crept in with thepeter2001-12-151-7/+7
| | | | DEVICE_POLLING stuff.
* Device Polling code for -current.luigi2001-12-141-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Non-SMP, i386-only, no polling in the idle loop at the moment. To use this code you must compile a kernel with options DEVICE_POLLING and at runtime enable polling with sysctl kern.polling.enable=1 The percentage of CPU reserved to userland can be set with sysctl kern.polling.user_frac=NN (default is 50) while the remainder is used by polling device drivers and netisr's. These are the only two variables that you should need to touch. There are a few more parameters in kern.polling but the default values are adequate for all purposes. See the code in kern_poll.c for more details on them. Polling in the idle loop will be implemented shortly by introducing a kernel thread which does the job. Until then, the amount of CPU dedicated to polling will never exceed (100-user_frac). The equivalent (actually, better) code for -stable is at http://info.iet.unipi.it/~luigi/polling/ and also supports polling in the idle loop. NOTE to Alpha developers: There is really nothing in this code that is i386-specific. If you move the 2 lines supporting the new option from sys/conf/{files,options}.i386 to sys/conf/{files,options} I am pretty sure that this should work on the Alpha as well, just that I do not have a suitable test box to try it. If someone feels like trying it, I would appreciate it. NOTE to other developers: sure some things could be done better, and as always I am open to constructive criticism, which a few of you have already given and I greatly appreciated. However, before proposing radical architectural changes, please take some time to possibly try out this code, or at the very least read the comments in kern_poll.c, especially re. the reason why I am using a soft netisr and cannot (I believe) replace it with a simple timeout. Quick description of files touched by this commit: sys/conf/files.i386 new file kern/kern_poll.c sys/conf/options.i386 new option sys/i386/i386/trap.c poll in trap (disabled by default) sys/kern/kern_clock.c initialization and hardclock hooks. sys/kern/kern_intr.c minor swi_net changes sys/kern/kern_poll.c the bulk of the code. sys/net/if.h new flag sys/net/if_var.h declaration for functions used in device drivers. sys/net/netisr.h NETISR_POLL sys/dev/fxp/if_fxp.c sys/dev/fxp/if_fxpvar.h sys/pci/if_dc.c sys/pci/if_dcreg.h sys/pci/if_sis.c sys/pci/if_sisreg.h device driver modifications
* Avoid an unnecessary copy of a packet if it is already in a single mbuf.luigi2001-12-111-2/+6
| | | | | | | | Introduce an additional device flag for those NICs which require the transmit buffers to be aligned to 32-bit boundaries. (the equivalen fix for STABLE is slightly simpler because there are no supported chips which require this alignment there.)
* MFS (merge from stable): rev 1.9.2.28, fix ordering of IFF_RUNNING mods.peter2001-12-071-2/+2
| | | | | | The reason we are required to commit to -current first is so that later MFC's do not risk the loss of existing bug fixes. Even if this was not strictly required in -current, it should still be fixed there too.
* Remove error messages on mbuf allocation failures, nowluigi2001-12-041-10/+2
| | | | | | this is done more safely in kern/subr_mbuf.c Two-days'-delay-thanks-to: @home shutting down service
* Per jlemon request, reintroduce some printf() when anluigi2001-11-291-3/+8
| | | | | | | | | | | | | | mbuf allocation fails, and fix (i hope) a couple of style bugs. I believe these printf() are extremely dangerous because now they can occur on every incoming packet and are not rate limited. They were meant to warn the sysadmin about lack of resources, but now they can become a nice way to panic your system under load. Other drivers (e.g. the fxp driver) have nothing like this. There is a pending discussion on putting this kind of warnings elsewhere, and I hope we can fix this soon.
* For i386 architecture, remove an expensive m_devget() (and theluigi2001-11-291-31/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | underlying unaligned bcopy) on incoming packets that are already available (albeit unaligned) in a buffer. The performance improvement varies, depending on CPU and memory speed, but can be quite large especially on slow CPUs. I have seen over 50% increase on forwarding speed on the sis driver for the 486/133 (embedded systems), which does exactly the same thing. The behaviour is controlled by a sysctl variable, hw.dc_quick which defaults to 1. Set it to 0 to restore the old behaviour. After running a few experiments (in userland, though) I am convinced that doing the m_devget() is detrimental to performance in almost all cases. Even if your CPU has degraded performance with misaligned data, the bcopy() in the driver has the same overhead due to misaligment as the one that you save in the uiomove(), plus you do one extra copy and pollute the cache. But more often than not, you do not even have to touch the payload, e.g. when you are forwarding packets, and even in the often-cited case of NFS, you often end up passing a pointer to the payload to the disk controller. In any case, you can play with the sysctl variable to toggle between the two behaviours, and see if it makes a difference. MFC-after: 3 days
* Remove ifnet.if_mpsafe for now. If this is needed, it won't be neededjhb2001-11-141-1/+0
| | | | | | until much later when the network stack locking is farther along. Approved by: jlemon
* Enable round-robin arbitration between transmit and receive unitluigi2001-10-271-0/+5
| | | | | | | | in the 21143, instead of giving priority to the receive unit. This gives a 10-15% performance improvement in the forwarding rate under heavy load. Reviewed-by: Bill Paul
* Do not call mii_pollstat() from within device tick routines; the statusjlemon2001-09-291-8/+5
| | | | | | information is updated by mii_tick(). Pointed out by: wpaul (a while back)
* Add support for Conexant LANfinity miniPCI controllers. People who havewpaul2001-09-041-3/+27
| | | | | | | | | | laptops with this chip should test this and report back as I don't have access to this hardware myself. People with -stable systems should try the patch at: http://www.freebsd.org/~wpaul/conexant.patch.gz Submitted by: Phil Kernick <Phil@Kernick.org>
* Deal with the condition where we lose link in the middle of transmittingwpaul2001-07-121-1/+1
| | | | | | | | | | | | | | | a bunch of frames. In this case, the dc_link flag is cleared, and dc_start() stops draining the if_snd send queue, which results in lots of 'no buffers available' errors being reported to applications. The whole idea behind not draining the send queue until the link comes up was to avoid having the gratuitous ARP being lost while we're waiting for autoneg to complete after the interface is first brought up. As an optimization, change the test in dc_start() so that we only bail if dc_link is not set _and_ there are less than 10 packets in the send queue. If the queue has many frames in it, we need to drain them. If the queue has a small number of frames in it, we can hold off on sending them until the link comes up. MFC after: 1 week
* Apply patch supplied by Jonathan Chen: use the correct arguments towpaul2001-07-091-2/+2
| | | | | pci_enable_io(). We need to use SYS_RES_IOPORT/SYS_RES_MEMORY instead of PCIM_CMD_PORTEN/PCIM_CMD_MEMEN.
* Change m_devget()'s outdated and unused `offset' argument to actually meanbmilekic2001-06-201-3/+2
| | | | | | | | | | | | | | | | | | | | something: offset into the first mbuf of the target chain before copying the source data over. Make drivers using m_devget() with a first argument "data - ETHER_ALIGN" to use the offset argument to pass ETHER_ALIGN in. The way it was previously done is potentially dangerous if the source data was at the top of a page and the offset caused the previous page to be copied (if the previous page has not yet been appropriately mapped). The old `offset' argument in m_devget() is not used anywhere (it's always 0) and dates back to ~1995 (and earlier?) when support for ethernet trailers existed. With that support gone, it was merely collecting dust. Tested on alpha by: jlemon Partially submitted by: jlemon Reviewed by: jlemon MFC after: 3 weeks
* Apply patch to allow TX underrun handling without issuing a completewpaul2001-02-221-26/+58
| | | | | | chip reset. Just temporarily turn off the transmitter instead. Submitted by: Stephen McKay <mckay@freebsd.org>
* Big round of minor updates:wpaul2001-02-211-3/+3
| | | | | | | | | | | | | | - Use pci_get_powerstate()/pci_set_powerstate() in all the other drivers that need them so we don't have to fiddle with the PCI power management registers directly. - Use pci_enable_busmaster()/pci_enable_io() to turn on busmastering and PIO/memory mapped accesses. - Add support to the RealTek driver for the D-Link DFE-530TX+ which has a RealTek 8139 with its own PCI ID. (Submitted by Jason Wright) - Have the SiS 900/National DP83815 driver be sure to disable PME mode in sis_reset(). This apparently fixes a problem on some motherboards where the DP83815 chip fails to receive packets. (Submitted by Chuck McCrobie <mccrobie@cablespeed.com>)
* Take luigi's suggestion and move the check for nothing to do to before theimp2001-02-201-5/+4
| | | | lock so we don't have lots of null lock/release pairs.
* Add DC_UNLOCK before first return. This caused returns when dc was onimp2001-02-201-1/+3
| | | | | | a shared interrupt. Pointed out by tegge.
* Add a check in the interrupt service routine to return quickly inluigi2001-02-181-1/+4
| | | | | | | | | | | case there is nothing to do. This happens normally when the card shares the interrupt line with other devices. This code saves a couple of microseconds per interrupt even on a fast CPU. You normally would not care, except under heavy tinygram traffic where you can have some 50-100.000 interrupts per second... On passing, correct a spelling error.
* Convert if_multiaddrs from LIST to TAILQ so that it can be traversedphk2001-02-061-4/+4
| | | | | | backwards in the three drivers which want to do that. Reviewed by: mikeh
* Use LIST_FOREACH() to traverse ifp->if_multiaddrs list, instead ofphk2001-02-031-8/+4
| | | | | | | <sys/queue.h> implementation details. Created with: /usr/sbin/sed Reviewed with: /sbin/md5
* Silence compiler warnings.wpaul2001-01-201-2/+2
|
* Bug fixes that I've put together while working on a project in the office:wpaul2001-01-191-6/+12
| | | | | | | | | | | | | | if_vr: handle the case where vr_encap() returns failure: bust out of the packet sending loop instead of panicking. Also add some missing newlines to some printf()s. if_dc: The miibus_read and miibus_write methods keep swapping in and out of MII mode by fiddling with CSR6 for cards with MII PHYs. This is a hack to support the original Macronix 98713 card which has built-in NWAY that uses an MII-like management interface even though it uses serial transceivers. Conditionalize this so that we only do this on 98713 chips, since it does bad things to genuine tulip chips (and maybe other clones).
* Implement MTX_RECURSE flag for mtx_init().bmilekic2001-01-191-1/+1
| | | | | | | | | | | | | | | | | | | All calls to mtx_init() for mutexes that recurse must now include the MTX_RECURSE bit in the flag argument variable. This change is in preparation for an upcoming (further) mutex API cleanup. The witness code will call panic() if a lock is found to recurse but the MTX_RECURSE bit was not set during the lock's initialization. The old MTX_RECURSE "state" bit (in mtx_lock) has been renamed to MTX_RECURSED, which is more appropriate given its meaning. The following locks have been made "recursive," thus far: eventhandler, Giant, callout, sched_lock, possibly some others declared in the architecture-specific code, all of the network card driver locks in pci/, as well as some other locks in dev/ stuff that I've found to be recursive. Reviewed by: jhb
* Use pci_get_powerstate()/pci_set_powerstate() which now exists in thewpaul2000-12-181-24/+16
| | | | | | | | PCI code. This saves each driver from having to grovel around looking for the right registers to twiddle. I should eventually convert the other PCI drivers to do this; for now, these three are ones which I know need power state handling.
* Initialize/grab the mutex earlier in the attach phase, so thatwpaul2000-12-041-2/+3
| | | | | bailing out to the fail: label where we release/destroy the mutex will work without exploding.
* Change the driver to allocate its own callout structure, and modifyjlemon2000-11-251-7/+11
| | | | | | the interface to use callout_* instead of timeout(). Also add an IS_MPSAFE #define (currently off) which will mark the driver as mpsafe to the upper layers.
* Add support for the Accton EN2242 MiniPCI adapter. This is just anwpaul2000-11-141-0/+3
| | | | | | ADMtek Centaur chip, so all we need is the PCI ID. Submitted by: Scott Lang <scottl@FreeBSD.org>
* Grrrr. Remember to bzero() the mediainfo structures after we allocatewpaul2000-11-031-0/+3
| | | | | | | them. If we leave garbage in them, the dc_apply_fixup() routine may try to follow bogus pointers when applying the reset fixup. Noticed by: Andrew Gallatin
* Call dc_apply_fixup() in dc_setcfg() for the MII case.wpaul2000-10-311-0/+4
|
* Grrr. The 'reg' variable in dc_apply_fixup() needs to be a u_int32_t, notwpaul2000-10-301-1/+1
| | | | | a u_int8_t. Pass the conical hat. This should fix certain cardbus 21143 cards that require SROM h0h0magic in order to enable their transceivers.
* Fix typo s/DE_DEVICEID_FE2500/DC_DEVICEID_FE2500/peter2000-10-281-1/+1
|
* Add PCI IDs for some additional cardbus cards. Yes, there really iswpaul2000-10-281-2/+8
| | | | | | | a RealTek 8139 cardbus device. Unfortunately it doesn't quite work yet because the CIS parser barfs on it. Submitted by msmith, with some small tweaks by me.
* Yet another bug fix/optimization for the Davicom DM9100/9102: increasewpaul2000-10-271-0/+5
| | | | | | | | | the PCI latency timer value to 0x80. Davicom's Linux driver does this, and it drastically reduces the number of TX underruns in my tests. (Note: this is done only for the Davicom chips. I'm not sure it's a good idea to do it for all of them.) Again, still waiting on confirmation before merging to stable.
* Set the DC_TX_INTR_ALWAYS and DC_TX_STORENFWD flags for the Davicomwpaul2000-10-251-2/+2
| | | | | | | | | | | | | | | | | | | DM9100/DM9102 chips. Do not set DC_TX_ONE. The DC_TX_USE_TX_INTR flag causes dc_encap() to set the 'interrupt on TX completion' bit only once every 64 packets. This is an attempt to reduce the number of interrupts generated by the chip. You're supposed to get a 'no more TX buffers left' interrupt once you hit the last packet whether you ask for one or not, however it seems the Davicom chip doesn't generate this interrupt, or at least it doesn't generate it under the same circumstances. The result is that if you transmit n packets, where n is less than 64, and then wait 5 seconds, you'll get a watchdog timeout whether you want one or not. The DC_TX_INTR_ALWAYS causes dc_encap() to request an interrupt for every frame. I'm still waiting on confirmation from a couple of users to see if this fixes their problems with the Davicom DM9102 before I merge this into -stable, but this fixed the problem for me in my own testing so I'm willing to make the change to -current right away.
* Remove unnecessary machine/mutex.h include.jhb2000-10-201-1/+0
|
* NEWCARD/Cardbus -jon2000-10-191-9/+174
| | | | | | | | | This commit adds support for Xircom X3201 based cardbus cards. Support for the TDK 78Q2120 MII is also added. IBM Etherjet, Intel and Xircom cards uses these chips. Note that as a result of this commit, some Intel/DEC 21143 based cardbus cards will also attach, but not get link. That is being looked at.
* Remove unneeded #include <machine/clock.h>phk2000-10-151-1/+0
|
* Clean up a few things in dc_setcfg() pointed out to be me bywpaul2000-10-141-4/+9
| | | | aaron@openbsd.com on IRC earlier today.
* Use device_get_nameunit(dev) as the mutex string when callingwpaul2000-10-131-1/+1
| | | | | mtx_init() instead of hard-coded string constant. Also remember to do the mutex changes to the ste driver, which I forgot in the first commit.
* First round of converting network drivers from spls to mutexes. Thiswpaul2000-10-131-31/+49
| | | | | | | | takes care of all the 10/100 and gigE PCI drivers that I've done. Next will be the wireless drivers, then the USB ones. I may pick up some stragglers along the way. I'm sort of playing this by ear: if anyone spots any places where I've screwed up horribly, please let me know.
* Add support for parsing the media blocks from the SROM on 21143wpaul2000-10-051-56/+222
| | | | | | | | | | adapters. This is necessary in order to make this driver work with the built-in ethernet on the alpha Miata machines. These systems have a 21143-PC chip on-board and optional daughtercards with either a 10/100 MII transceiver or a 10baseT/10base2 transceiver. In both cases, you need to twiddle the GPIO bits on the controller in order to turn the transceivers on, and you have to read the media info from the SROM in order to find out what bits to twiddle.
OpenPOWER on IntegriCloud