from useful drivers such as the 3D DRI drivers I will be porting for
hardware accelerated OpenGL. The hardware will still be reported during
boot using the nomatch system.
Approved by: jkh
the PIRQD bit.
This fixes the problem of uhub0 hanging forever during boot when USB
keyboard support is switched on in the BIOS on motherboards with Intel
chipsets (UHCI).
Approved by: The Sheep
conversion to eliminate the compatability shims without making any
significant changes. This eliminates the shim warnings.
Obtained from: n_himba (tweaked by me, don't blame him for this)
Approved by: jkh
bus_delete_resource.
Fixes a problem when the probe succeeded, but the attach failed. The
release of the resources was done inproperly.
Approved by: jkh
are using an old unconverted driver. Most (if not all) of the drivers
for common hardware are newbus these days. However, we don't want
to encourage people to take the easy way out and write new drivers
using the shims. This is just passive "encouragement".
Reviewed by: phk
the receive code so that it correctly chains receive descriptors together
and handles the case that only a part of a packet is done at the time
we get here.
This is just to make sure we initialize the chip correctly: we need to
make the sure the port select bit in CSR6 is set properly so that we
use the internal PHY for 10/100 support. (The eval boards I have also
include an external HomePNA PHY, but I need to play with that more
before I can support it.)
Collect together the components of several drivers and export eisa from
the i386-only area (It's not, it's on some alphas too). The code hasn't
been updated to work on the Alpha yet, but that can come later.
Repository copies were done a while ago.
Moving these now keeps them in consistant place across the 4.x series
as the newbusification progresses.
Submitted by: mdodd
packets into a single buffer, and set the DC_TX_COALESCE flag for the
Davicom DM9102 chip. I thought I had escaped this problem, but... This
chip appears to silently corrupt or discard transmitted frames when
using scatter/gather DMA (i.e. DMAing each packet fragment in place
with a separate descriptor). The only way to insure reliable transmission
is to coalesce transmitted packets into a single cluster buffer. (There
may also be an alignment constraint here, but mbuf cluster buffers are
naturally aligned on 2K boundaries, which seems to be good enough.)
The DM9102 driver for Linux written by Davicom also uses this workaround.
Unfortunately, the Davicom datasheet has no errata section describing
this or any other apparently known defect.
Problem noted by: allan_chou@davicom.com.tw
makes it a little easier to notice that parity checking an 8bit sram
isn't working.
Turn on scb and internal data-path parity checking for all pci chips types.
We were only doing this for ultra2 chips.
After clearing the parity interrupt status, clear the BRKADRINT. This
avoids seeing a bogus BRKADRINT interrupt after external SCB probing
once normal interrupts are enabled.
controllers will run at U2 speeds until I can complete the U160 support
for this driver.
Correct a termination buglet for the 2940UW-Pro.
Be more paranoid in how we probe and enable external ram, fast external
ram timing and external ram parity checking. We should now work on
20ns and 8bit SRAM parts.
Perform initial setup for the DT feature on cards that support it.
Factorize and clean up code. Use tables where it makes sense, etc.
Add some delays in dealing with the board control logic. I've never
seen this code fail, but with the ever increasing speed of processors,
its better to insert deterministic delays just to be safe. This stuff
is only touched during probe and attach, so the extra delay is of no
concern.
driver seems relatively functional, but could use some souping up,
particularly in the performance area. This has both NetBSD and FreeBSD
attachment code and a fair amount of effort has been put into making
it easy to port to different *BSD platforms.
The basic design is a one tfd per mbuf transmit (with no transmit
related interrupts- tfds are gc'd as needed). The receive ring
uses a 2K buffer per rfd with a +2 byte adjust for the ethernet
header (so the payload is aligned). There's support that *almost*
works for doing large packets- the rfd chaining code works, but there's
some problem with getting good checksums at the IP reassembly level
(ditto for doing short tfd's too).
The chip has support for TCP checksums insertion for transmit and
TCP checksum calculation on receive (for both you have to do some
appropriate backoff && twiddling), but this isn't in place.
This is nearly entirely reverse engineered from the released Intel
driver, so there's a lot of "We have to do this but do not know why"
stuff. There is somebody who has the chip specs who works in FreeBSD
but they're being a bit standoffish about even sharing hints which
is somewhat annoying. It's also apparent that all I had to work with
were the first rev boards.
This driver has been lightly tested on intel && alpha, but only
point-to-point. There may be some issues with switches- use of
boot time environment variables that override EEPROM settings
(e.g., 'set wx_ilos=1' which inverts the sense of optical signal
loss) may help with this.
I had this out for review for three weeks, and nobody said anything
negative or positive, ergo, this checkin has no 'reviewed by' field
which I would have preferred.
down, the dc driver and receiver can fall out of sync with one another,
resulting in a condition where the chip continues to receive packets
but the driver never notices. Normally, the receive handler checks each
descriptor starting from the current producer index to see if the chip
has relinquished ownership, indicating that a packet has been received.
The driver hands the packet off to ether_input() and then prepares the
descriptor to receive another frame before moving on to the next
descriptor in the ring. But sometimes, the chip appears to skip a
descriptor. This leaves the driver testing the status word in a descriptor
that never gets updated. The driver still gets "RX done" interrupts but
never advances further into the RX ring, until the ring fills up and the
chip interrupts again to signal an error condition. Sometimes, the
driver will remain in this desynchronized state, resulting in spotty
performance until the interface is reset.
Fortunately, it's fairly simple to detect this condition: if we call
the rxeof routine but the number of received packets doesn't increase,
we suspect that there could be a problem. In this case, we call a new
routine called dc_rx_resync(), which scans ahead in the RX ring to see
if there's a frame waiting for us somewhere beyond that the driver thinks
is the current producer index. If it finds one, it bumps up the index
and calls the rxeof handler again to snarf up the packet and bring the
driver back in sync with the chip. (It may actually do this several times
in the event that there's more than one "hole" in the ring.)
So far the only card supported by if_dc which has exhibited this problem
is a LinkSys LNE100TX v2.0 (82c115 PNIC II), and it only seems to happen
on one particular system, however the fix is general enough and has low
enough overhead that we may as well apply it for all supported chipsets.
I also implemented the same fix for the 3Com xl driver, which is apparently
vulnerable to the same problem.
Problem originally noted and patch tested by: Matt Dillon
probes are at the 'chip' level and will get overridden by pcic_p if it is
compiled in. It's still nice to get the better probe message if it's not...
Requested by: imp
is an application space macro and the applications are supposed to be free
to use it as they please (but cannot). This is consistant with the other
BSD's who made this change quite some time ago. More commits to come.
frames would be handled incorrectly due to bad usage of m_pullup() in
the case where the frame wraps from the end of the receive buffer back
the beginning.
Also, when manually extending small packets to pad them to the minimum
frame length during transmission, zero out the pad area to make some
really paranoid people happy.
the 3c450-TX HomeConnect. Like the 3cSOHO100-TX OfficeConnect, this NIC
uses the same ASIC as the 3c905B/3c905C but is targeted for a particular
market segment (home users). It is somewhat less expensive than the
3c905B/3c905C ($49, according to the 3Com web site), comes with its
own custom driver kit and is bundled with various goofy Windows software
packages designed to demonstrate the niftyness of home networking (networked
game demos, etc...).
Changes are:
- Add PCI ID to list in if_xlreg.h.
- Update xl_devs table in if_xl.c.
- Update xl_choose_xcvr() to consider the HomeConnect the
same as all the other 10baseT/100baseTX cards.
- Add a flag DC_TX_INTR_ALWAYS which causes the transmit code to
request a TX done interrupt for every packet. The PNIC seems to need
this to insure that the sent TX buffers get reaped in a timely fashion.
- Try to unreset the SIA as soon as possible after resetting the whole
chip.
- Change dcphy to support either 10/100 or 10Mbps only NICs. The
built-in 21143 ethernet in Compaq Presario machines is 10Mbps only
and it doesn't work right if we try to advertise 100Mbps modes during
autoneg. When restricted to only 10mbps modes, it works fine.
Note that for now, I detect this condition by checking the PCI
subsystem ID on this NIC (which has a Compaq vendor/device ID).
Yes, I know that's what the SROM is supposed to be for. I'm deliberately
ignoring the SROM wherever possible. Sue me.
The latter two fixes allow if_dc to work correctly with the built-in
ethernet on certain Compaq Presario boxes. There are liable to be quite
a few people using these as their home systems who might want to try
FreeBSD; may as well be nice to them.
Now if anybody out there has an Alpha miata with 10Mbps ethernet and
can show me the output from pciconf -l on their system, I'd be grateful.
used to edit the old-style isa_devtab config tables to insert a mapping
for a pci device into the isa tables so that the wdc driver could probe
it later. This has been #if 0'd since April.
attaching to the device via chip*, use the newbus nomatch method to report
the device. This leaves them unattached so that a driver can be easily
loaded to grab them later.
background ]
Rename sys/pci/pci_ioctl.h to sys/sys/pciio.h to make it easier for
userland programs to use this interface. Reformat the file, and add a
BSD-style copyright to it.
Add a new man page for pci(4). The PCIOCGETCONF, PCIOCREAD, and PCIOCWRITE
ioctls are documented, but the PCIOCATTACHED ioctl is not documented
because it is not implemented.
Change includes of <pci/pci_ioctl.h> to <sys/pciio.h> or remove them
altogether. In many cases, pci_ioctl.h was unused.
Reviewed by: steve
- Convert to using TX descritor polling similar to the xl driver (the
ST201 is a clone of the 3c90xB chipset and offers the same transmit
polling scheme). This should reduce TX overhad a little.
- Make sure to reset PHY when switching mode, as in the starfire driver.
- Fix instances of free() that should be contigfree().
- Remove dead code.
case. The idea is to reduce how often we call mii_tick(), however currently
it may not be called often enough, which prevents autonegotiation from
being driven correctly.
This should improve the chances of successfully autonegotiating media
settings on non-MII 21143 NICs. (Still waiting for confirmation from
some testers, but the code is clearly wrong in any case.)
Don't arbitrarily limit the initiator ID of the card to something <= 7.
Fix a bug in the checksum code that would incorrectly prevent a valid
checksum of zero. (cp)
Don't touch rely on seeprom data when configuring termination. We may
not have seeprom data. (cp)
Treat all ULTRA2 capable adapters the same way when reading or writing
the BRDCTL register. We previously only did this correctly for aic7890/91
chips. This should correct some problems with termination settings on
aic7896/97 adapters. (cp)
Changes marked with "(cp)"
Pointed out by: Chuck Paterson <cp@bsdi.com>
before selecting a mode. The Seeq PHY chips on the Adaptec cards that
use the AIC-6915 controller seem to need it in order to get them to
change modes correctly.
This corrects a problem that I noticed where my ANA-62022 board failed
to correctly program the full duplex bit in the macconfig1 register
when the interface was brought up. Running ifconfig sf0 would mask this
problem in some cases because polling the PHY status would cause the
miibus code to notice that full duplex was now needed and the statchg
callback would be invoked to configure the duplex setting. However it
would still get it wrong other times.
Also changed sf_miibus_statchg() to program the IPG register to match
the duplex setting in accordance with Adaptec manual's recommendations
(0x15 for full duplex, 0x11 for half duplex).
which it replaces. The new driver supports all of the chips supported
by the ones it replaces, as well as many DEC/Intel 21143 10/100 cards.
This also completes my quest to convert things to miibus and add
Alpha support.
device_add_child_ordered(). 'ivars' may now be set using the
device_set_ivars() function.
This makes it easier for us to change how arbitrary data structures are
associated with a device_t. Eventually we won't be modifying device_t
to add additional pointers for ivars, softc data etc.
Despite my best efforts I've probably forgotten something so let me know
if this breaks anything. I've been running with this change for months
and its been quite involved actually isolating all the changes from
the rest of the local changes in my tree.
Reviewed by: peter, dfr
by identifying the version in the PCI drivers.
The OHCI driver just presets this to 1.0 as it is not specified in the
PCI registers anywhere. This should be revisited once USB 2.0 is in
wide spread use.
rather than an "it's mine!" so that other newbus-aware drivers can
bid for the device too. This should allow the sym driver to out-bid
the ncr driver for devices it supports without having to modify ncr.c
at all. ncr would then function as a catch-all.
parameter a char ** instead of a const char **. This make these
kernel routines consistent with the corresponding libc userland
routines.
Which is actually 'correct' is debatable, but consistency and
following the spec was deemed more important in this case.
Reviewed by (in concept): phk, bde
pci_probe_nomatch, so it won't be in the way when loading USB as a module.
The reason for them being there in the first place is that every
motherboard comes with USB kit and this way it looks more pretty (peter).
The real solution will be to define some method of detaching a driver
after it has attached.
out of the PCI CLASS reg and store it in the softc. Use the getenv_quad
function to get a WWN override from the environment. Look for a config
value for same. Make slightly less lame the wwn seed construction.
is documented to be 0x18 in the Adaptec manual, however there appears to
be a newer board rev with code 0x19. I added a #define for this and
updated the probe code so that this board will be properly identified
in the probe messages. (Currently it's just identified generically as
an AIC-6915 chip.)
"rw" argument, rather than hijacking B_{READ|WRITE}.
Fix two bugs (physio & cam) resulting by the confusion caused by this.
Submitted by: Tor.Egge@fast.no
Reviewed by: alc, ken (partly)
- Fix a bug in rl_rxeof() handler: in the case where the packet wraps
from the end of the receive buffer back to the beginning, we need to
insure that at least sizeof(ether_header) bytes make it into the first
mbuf. If we don't, then doing eh = mtod(m, struct ether_header *)
loses. To avoid this, we use m_pullup() to suck at least MHLEN -
RL_ETHER_ALIGN bytes into the first mbuf, which should also help
small packets fit into a single mbuf.
Pointed out by: Philip A. Prindeville <philipp@zembu.com>
- Make the transmit threshold autotuning: start off with a small value
and jack it up when TX underruns are detected.
- Also improve TX error recovery: kick the chip in the head with a
reset/init sequence to make sure it recovers afer a transmit error.
have you is prototyped). Removed code versions in md struct- not used
any more. Allocate transfer dma maps and xflist stuff in mbxdmasetup based
upon isp->isp_maxcmds. Allow for multiple calls to mbxdmasetup (for
isp_reset cases).
In order to make this work, I created a pseudo-PHY driver to deal with
Macronix chips that use the built-in NWAY support and symbol mode port.
This is actually all of them, with the exception of the original MX98713
which presents its NWAY support via the MII serial interface.
The mxphy driver actually manipulates the controller registers directly
rather than using the miibus_readreg()/miibus_writereg() bus interface
since there are no MII registers to read. The mx driver itself pretends
that the NWAY interface is a PHY locayed at MII address 31 for the sole
purpose of allowing the mxphy_probe() routine to know when it needs to
attach to a host controller.
- When setting/clearing promisc mode, just update the filter, don't
reset the whole interface.
- Call xl_init() in xl_ifmedia_upd() when setting miibus media modes. This
fixes a problem with the 3c905B-COMBO where switching from 10base5/AUI
or 10base2/BNC to a 10/100 mode doesn't always work right.
- Attempt to reset the interface in xl_init() so that we know we're getting
the receive and transmit rings reset properly.
* Change the hack used on the alpha for mapping devices into DENSE or
BWX memory spaces to a simpler one. Its still a hack and should be
a seperate api to explicitly map the resource.
* Add $FreeBSD$ as necessary.
Rather than teaching pci_ioctl about hoses, we just pass down a magic number
& let the platform code figure out what the hose is based on what the bus
number is.
concept approved by dfr
The old algorithm was:
if class == storage and subclass != SCSI device must be IDE
This results in claiming 'raid' and 'other' storage devices as IDE,
which is typically not the case.
Reviewed by: sos
- Move intrhook stuff into kernel.h
- Remove all occurrences of #device <device.h>
- Add kernel.h were necessary (nowhere)
- delete device.h
This file contained the structures for cfdata (old style config) and is no
longer used. It was included by most drivers.
It confuses the remote debugger as the definition of 'struct device' in
device.h is found before the one in bus_private.h.
For unknown devices the output will now be
pci0: unknown card (vendor=0x109e, dev=0x0878) at 14.1 irq 19
instead of
pci0: unknown card DD^0878 (vendor=0x109e, dev=0x0878) at 14.1 irq 19
Before this change, the code used to take the PCI vendor id and translate it
into a three letter ASCII name.
For PnP devices, the vendor id _does_ map to a nice ASCII name
(eg Creative Labs PnP ID maps to "CTL", ESS PnP ID maps to "ESS")
But there is no such mapping for PCI devices, as can be seen by the
example above where the Brooktree PCI vendor ID maps to "DD^"
The PCI Special Interest Group confirmed they do not have any mappings
from vendor ID to ASCII.
and/or when using the card.
o Convert the driver to using bus_space. This allows alphas with
fxp's to boot, rather than panic'ing because rman_get_virtual()
doesn't really return a virtual address on alphas.
o Fix an alpha unaligned access error caused by some misfeature of
gcc/egcs: if link_addr & rbd_addr in the fxp_rfa struct are 32 bit
quantities, egcs will assume they are naturally aligned. So it will do
a ldl & some shifty/masky to twiddle 16 bit values in fxp_lwcopy().
However, if they are 16-bit aligned, the ldl will actually be done on
a 16-bit aligned value & we will panic with an unaligned access
error... Changing their definition to an array of chars seems to fix
this. I obtained this from NetBSD.
I've tested this on both i386 & alpha.
have been there in the first place. A GENERIC kernel shrinks almost 1k.
Add a slightly different safetybelt under nostop for tty drivers.
Add some missing FreeBSD tags
This means that we will not have to have a bpf and a non-bpf version
of our driver modules.
This does not open any security hole, because the bpf core isn't loadable
The drivers left unchanged are the "cross platform" drivers where the respective
maintainers are urged to DTRT, whatever that may be.
Add a couple of missing FreeBSD tags.
there are stubs compiled into the kernel if BPF support is not enabled,
there aren't any problems with unresolved symbols. The modules in /modules
are compiled with BPF support enabled anyway, so the most this will do is
bloat GENERIC a little.
declaration for the interface driver from "foo" to "if_foo" but leave the
declaration for the miibus attached to the interface driver alone. This
lets the internal module name be "if_foo" while still allowing the miibus
instances to attach to "foo."
This should allow ifconfig to autoload driver modules again without
breaking the miibus attach.
for the AN985 "Centaur" chip, which is apparently the next genetation
of the "Comet." The AN985 is also a tulip clone and is similar to the
AL981 except that it uses a 99C66 EEPROM and a serial MII interface
(instead of direct access to the PHY registers).
Also updated various documentation to mention the AN985 and created
a loadable module.
I don't think there are any cards that use this chip on the market yet:
the datasheet I got from ADMtek has boxes with big X's in them where the
diagrams should be, and the sample boards I got have chips without any
artwork on them.
submitter, who *still* hasn't bothered to answer me back.
The thing which the submitter completely failed to mention is that
his 3c900B-TPO card has the transceiver selection in the EEPROM set
to "auto." You can tweak the setting using the 3C90XCFG.EXE utility
that 3Com provides with the card. I'm not sure if it's supposed to
default to auto or if the user fiddled with it. Currently, the xl
driver only does autoselection for 10/100 NICs (i.e. those with NWAY
autonegotiation capabilities). For the 10baseT, 10base5, 10base2,
10baseFL and 100baseFX cards, the driver sets the default media to
whatever the EEPROM transceiver selector says. The problem is that
the "auto" selection is mistakenly identified as "10/100 NWAY
autoselection mode" and this is not handled correctly: the default
media ends up being chosen as 100baseTX, which doesn't work because
we've only added 10baseT media types to the ifmedia word. This leads
to a panic in ifmedia_set() (something else which the submitter never
bothered to mention).
A workaround for this is to re-run the 3C90XCFG.EXE utility and change
the transceiver selection to something besides "auto." I have also
patched the driver to watch for the "auto" setting in the non-miibus
case and select a reasonable default based on the card type instead of
falling through to 100baseTX and exploding.
PR: misc/13665
This whole idea isn't going to work until somebody makes the bus/kld
code smarter. The idea here is to change the module's internal name
from "foo" to "if_foo" so that ifconfig can tell a network driver from
a non-network one. However doing this doesn't work correctly no matter
how you slice it. For everything to work, you have to change the name
in both the driver_t struct and the DRIVER_MODULE() declaration. The
problems are:
- If you change the name in both places, then the kernel thinks that
the device's name is now "if_foo", so you get things like:
if_foo0: <FOO ethernet> irq foo at device foo on pcifoo
if_foo0: Ethernet address: foo:foo:foo:foo:foo:foo
This is bogus. Now the device name doesn't agree with the logical
interface name. There's no reason for this, and it violates the
principle of least astonishment.
- If you leave the name in the driver_t struct as "foo" and only
change the names in the DRIVER_MODULE() declaration to "if_foo" then
attaching drivers to child devices doesn't work because the names don't
agree. This breaks miibus: drivers that need to have miibuses and PHY
drivers attached never get them.
In other words: damned if you do, damned if you don't.
This needs to be thought through some more. Since the drivers that
use miibus are broken, I have to change these all back in order to
make them work again. Yes this will stop ifconfig from being able
to demand load driver modules. On the whole, I'd rather have that
than having the drivers not work at all.
strategy used in the 3Com Linux driver. The new strategy is to use transmit
descriptor polling -- that is, the NIC polls the descriptors to see when
new packets are available for transmission. The advantage to the new scheme
is that no register accesses are needed in the transmit routine. The old
scheme requires several register accesses to stall the TX engine, update the
TX DMA list pointer register, then unstall the TX engine. Hopefully the new
scheme will provide improved transmit performance with less CPU overhead.
This only affects the 3c90xB or 3c90xC cards, not the 3c90x cards. This
means the original 3c900 and 3c905 cards are unaffected. Newer cards include
the 3c900B series, the 3c905B, 3c980, 3c980B, 3c905C and 3c905C, and the
3cSOHO100-TX OfficeConnect.
close PR #13757, however I'm waiting on user feedback before declaring the
PR officially closed. Among other things, this improves UDP transmit
performance, and tx underruns are now detected and the TX start threshold
adjusted accordingly.
Bug fix: xmradio nolonger experiences a 6Mhz offset after running FXTV
New feature: Automatic Tuner selection for AVerMedia cards with
configuration EEPROMs on (ie the Bt878 based cards)
length for mini receive ring. The max length was MHLEN, however the mbufs
are actually shortened to MHLEN - ETHER_ALIGN to force payload alignment.
PR: 13793
It's GPL'ed of course, but looking over it tonight I learned of Yet Another
Fast EtherLink XL Adapter: the 3c980C server adapter. This is basically
an updated version of the 3c980 that uses the Tornado ASIC instead of the
earlier Hurricane ASIC. The only change here is to add the new PCI device
ID (0x9805) and corresponding table entries.
I have an 82559 card with the same id as the other 8255[78] chips, but
that was made with a date code of 0699 (June 99). The submitter shows
this working with the probe etc, but doesn't actually say it works as
on the ethernet. :-) Assuming it does, this is a RELENG_3 merge candidate.
Submitted by: Steven E Lumos <slumos@sam.ISRI.UNLV.EDU>
the Davicom DM9100 and DM9102 chipsets, including the Jaton Corporation
XPressNet. Datasheet is available from www.davicom8.com.
The DM910x chips are still more tulip clones. The API is reproduced
pretty faithfully, unfortunately the performance is pretty bad. The
transmitter seems to have a lot of problems DMAing multi-fragment
packets. The only way to make it work reliably is to coalesce transmitted
packets into a single contiguous buffer. The Linux driver (written by
Davicom) actually does something similar to this. I can't recomment this
NIC as anything more than a "connectivity solution."
This driver uses newbus and miibus and is supported on both i386
and alpha platforms.
SiS 900 and SiS 7016 PCI fast ethernet chipsets. Full manuals for the
SiS chips can be found at www.sis.com.tw.
This is a fairly simple chipset. The receiver uses a 128-bit multicast
hash table and single perfect entry for the station address. Transmit and
receive DMA and FIFO thresholds are easily tuneable. Documentation is
pretty decent and performance is not bad, even on my crufty 486. This
driver uses newbus and miibus and is supported on both the i386 and
alpha architectures.
Doug Rabson's work, with a few tweaks from Warner Losh and I. There are
still some quirks to resolve, but the old driver is presently breaking
the build.
Fix a bug where video capture locks up on channel changes.
Many thanks to Juha for solving this.
Submitted by: Juha Nurmela <Juha.Nurmela@quicknet.inet.fi>
external NatSemi PHY chip was programmed to respond to MII address 24.
In the 3c905B ASICs, the transceiver is internal but it's still mapped
to MII address 24. But *some* 3Com 3c905B ASIC revisions map the
transceiver control registers to *all* MII addresses (0 through 31).
The miibus code probes for PHYs at all MII addresses and because of
this unusual behavior, it will attempt to map the same PHY registers
several times over, which doesn't work.
Naturally, the 3c905B NIC that I tested happened not to exhibit this
behavior.
The fix is to tweak xl_miibus_readreg() and xl_miibus_writereg()
to only respond when attempting to read from MII address 24. This
is safe to do since the 3Com documentation indicates that the PHY
and/or internal transceiver will always be mapped to address 24,
and there are no 3Com XL NICs with more than one PHY.
New Features:
Greatly improved VBI capture support. (mainly for the AleVT port)
Supports select() on /dev/vbi
Improved RISC program for RGB+VBI capture to capture both evenodd
VBI data even when only capturing even only (or odd only) video
Based on code from Juha Nurmela <Juha.Nurmela@quicknet.inet.fi>
Support for Hauppauge 627 and Temic 4006
Submitted by: Maurice Castro <maurice@atum.castro.aus.net>
Bug Fix:
Fix bug in AverMedia card detection.
Break out the detection logic for the aic7855 and properly report
these chips as 7855s instead of 7850s.
The 2940AU_CN is an aic7860 based card, not aic7860.
Not setting CACHETHEN turned out to be a bad idea. It can cause
spurious corruption under heavy PCI load with multiple masters.
due to the fact that there are non-MII cards supported by the same
driver and I don't have all of the cards available for testing. There's
also the 3c905B-COMBO which has MII, AUI and BNC media ports all in one
package. Supporting the COMBO is difficult because we have to add the
10base5 and 10base2 media types to the same ifmedia struct as the
MII-attached types, however there is no way to force the miibus and
child PHYs into existence before xl_attach() completes, so there is
no ifmedia struct available in xl_attach(). What we do inistead is
use the mediainit method as a callback: when a child PHY is attached,
it calls the miibus mediainit routine which selects a default media.
This routing also calls the NIC driver's mediainit method (if it
implements one) at which point we can safely add the other media
types.
This fixes, at least, panics in ncr_attach() on i386's with about 5MB
of memory. The restriction was a hack to leave some low memory for ISA
DMA, but on i386's we now allocate pages from the top down, so all the
restriction did was cause our allocations to fail when there is no free
memory above 1MB.
had to get the ML 6692 PHY driver working correctly, which is harder than
it sounds. "Bitrate" ThunderLAN devices should still be supported (i.e
the older 10Mbps Netflex 3/P, which use the TNETE110 chip that has no
MII support). The ThunderLAN has an internal PHY which makes things a
little complicated, but these are the basic rules:
- For devices with just the ThunderLAN, the internal PHY is used to
provide 10baseT, and 10base5/10baseT support. Autonegotiation will
work, but only with 10baseT links. The only thing that really gets
negotiated is whether the link is full or half duplex.
- For devices with the ThunderLAN and an external 10/100 PHY (like the
Compaq Netelligent 100Mbps cards, or the internal Netflex 3/P with
100Mbps upgrade daughter card), the external PHY is used for 10baseT
and 100baseTX modes. The internal PHY is still used to support
10base5/10base2, though you have to select them manual with ifconfig.
- For devices with the ThunderLAN and the ML6692 PHY, both the internal
and external PHYs are used, though it will appear as though the 6692
PHY will be used to support 10baseT and 100baseTX modes. In reality,
the internal PHY will be used for 10baseT, but this fact will be hidden
from the user. The 10base5/10base2 modes can also be selected manually
as with above.
in 4 byte chunks. It turns out that with the 82c169C on the Netgear
FA-310TX Rev D2, if you tell the chip you have reserved a buffer of 1518
bytes, it will actually treat it as 1516 bytes since 1518 is divisible
by four. Consequently, a packet of 1514 bytes will always end up consuming
two buffers: the last coupleof bytes will spill over into the next
descriptor. This causes the pn_rx_bug_war() routine to trip unnecessarily.
I'm not sure if the 82c169B or 82c168 chips behave the same way; I'll
have to check them. In any case, this change should work just as well
with them. Note that the FA-310TX Rev D2 also has a Broadcom PHY
instead of a Level One LXT970 PHY, however this shouldn't make any
difference as far as the driver is concerned.
This change also allows me to do a way with one rounding overation in
pn_rx-buf_war().
Diskslice/label code not yet handled.
Vinum, i4b, alpha, pc98 not dealt with (left to respective Maintainers)
Add the correct hook for devfs to kern_conf.c
The net result of this excercise is that a lot less files depends on DEVFS,
and devtoname() gets more sensible output in many cases.
A few drivers had minor additional cleanups performed relating to cdevsw
registration.
A few drivers don't register a cdevsw{} anymore, but only use make_dev().
PCI fast ethernet controller. Currently, the only card I know that uses
this chip is the D-Link DFE-550TX. (Don't ask me where to buy these: the
only cards I have are samples sent to me by D-Link.)
This driver is the first to make use of the miibus code once I'm sure
it all works together nicely, I'll start converting the other drivers.
The Sundance chip is a clone of the 3Com 3c90x Etherlink XL design
only with its own register layout. Support is provided for ifmedia,
hardware multicast filtering, bridging and promiscuous mode.
events, in order to pave the way for removing a number of the ad-hoc
implementations currently in use.
Retire the at_shutdown family of functions and replace them with
new event handler lists.
Rework kern_shutdown.c to take greater advantage of the use of event
handlers.
Reviewed by: green
to achieve a delay is pretty mean.
Andrew reports:
"The tulip_delay_300ns() is, well, bloody stupid on machines with a
heavily loaded PCI bus. It tries to do a delay by assuming PCI reads
will take a certain amount of time & issues a large amount of
(expensive, 5% CPU when your PCI bus is heavily loaded) pci reads.
Locally, we've replaced the calls to tulip_delay_300ns(sc) in the EMIT
macros with a simple DELAY(1) and not seen any problems. Plus we've
gained about 50Mb/sec throughput on our gigabit network cards because
of the added PCI bus bandwidth available."
Also, I do not understand why, but this change appears to stop the
Transmit Fifo underrun on one of my systems (but not the Alpha PC164SX).
This shouldn't make that much of a difference since the mii bus isn't
touched all that often, but perhaps when it does get accessed and hence
hammers the register, it was causing the chip to get upset.
Submitted by: Andrew Gallatin <gallatin@cs.duke.edu>
the aic7890/91/96/97 cards. This could cause the system to go into
a long retry/recovery loop during probe.
Fix the alignment argument to bus_dma_tag_create().
Don't set the CACHETHEN bit in dscommand0 for Ultra2 controllers
until we know more about its behavior. The description for this
bit makes it sound like it could cause problems with certain
PCI chipsets.
a module. Also modified the code to work on FreeBSD/alpha and added
device vr0 to the alpha GENERIC config.
While I was in the neighborhood, I noticed that I was still using
#define NFPX 1 in all of the Makefiles that I'd copied from the fxp
module. I don't really use #define Nfoo X so it didn't matter, but
I decided to customize this correctly anyway.
Isn't really that useful.
chip0: <PCI to Other bridge (vendor=10e0 device=8849)> at device 0.0 on pci0
is more in keeping with the spirit of the rest of the code.
Previous behavior with regard to truely unknown bridges unchanged.
"<Anti-Bill> Tell you what: you have commit privs now. You do it."
reset command.
I observed some anomalous behavior while testing a 3c905C with a
Dell PowerEdge 4300/500 dual PIII 500Mhz system. The NIC would seem
to work correctly most of the time but would sometimes fail to receive
certain packets, in particular NFS create requests. I could mount
an NFS filesystem from the PowerEdge and do an ls on it, but trying
to do a "touch foo" would hang. Monitoring traffic from another host
revealed that the client was properly sending an NFS create request
but the server was not receiving it. It *did* receive it when I
ran the same test with an Intel fxp card.
I don't understand the exact mechanics of this strange behavior, but
resetting the receiver and transmitter seems to get rid of it. I used
to perform an RX and TX reset in xl_init(), but stopped doing it there
because on 3c905B and later cards this causes the autoneg session to
restart, which would lead to the NIC waiting a long time before exchanging
traffic after being brought up the first time. Apparently the receiver
and transmitter resets should be performed at least once when initializing
the card.
Hopefully this will cure problems that people have been having with the
3c905C -- this was the only strange behavior that I have observed with
the 3c905C so far which does not appear with the 3c905B or 3c905.
- device_print_child() either lets the BUS_PRINT_CHILD
method produce the entire device announcement message or
it prints "foo0: not found\n"
Alter sys/kern/subr_bus.c:bus_generic_print_child() to take on
the previous behavior of device_print_child() (printing the
"foo0: <FooDevice 1.1>" bit of the announce message.)
Provide bus_print_child_header() and bus_print_child_footer()
to actually print the output for bus_generic_print_child().
These functions should be used whenever possible (unless you can
just use bus_generic_print_child())
The BUS_PRINT_CHILD method now returns int instead of void.
Modify everything else that defines or uses a BUS_PRINT_CHILD
method to comply with the above changes.
- Devices are 'on' a bus, not 'at' it.
- If a custom BUS_PRINT_CHILD method does the same thing
as bus_generic_print_child(), use bus_generic_print_child()
- Use device_get_nameunit() instead of both
device_get_name() and device_get_unit()
- All BUS_PRINT_CHILD methods return the number of
characters output.
Reviewed by: dfr, peter
