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.
