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
equivalent to SYS_RES_MEMORY for x86 but for alpha, the rman_get_virtual()
address of the resource is initialised to point into either dense-mapped
or bwx-mapped space respectively, allowing direct memory pointers to be
used to device memory.
Reviewed by: Andrew Gallatin <gallatin@cs.duke.edu>
