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.
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.
compiles cleanly on the Alpha. (On the alpha, the port type is an int,
not a short).
Cast a couple of pointers to ints via 'uintptr_t' rather than 'unsigned
int' since uintptr_t is long (64 bit) on Alpha, as are pointers.
#define COMPAT_PCI_DRIVER(name,data) DATA_SET(pcidevice_set,data)
.. to 2.2.x and 3.x if people think it's worth it. Driver writers can do
this if it's not defined. (The reason for this is that I'm trying to
progressively eliminate use of linker_sets where it hurts modularity and
runtime load capability, and these DATA_SET's keep getting in the way.)
AX88140A with power management and magic packet support. Correct the
addresses of the PCI power management registers and add some code to
detect the revision ID of the AX88141 and identify it in the probe
messages.
No other changes are needed since the AX88141 is functionally
identical to the AX88140A.
- Normally, the driver allocates an mbuf cluster for each receive
descriptor. This is because we have to be prepared to accomodate up to
1500 bytes (a cluster buffer can hold up to 2K). However, using up a
whole cluster buffer for a tiny packet is a bit of a waste. Also,
it seems to me that sometimes mbufs will linger in the kernel for
a while after being passed out of the driver, which means we might
drain the mbuf cluster pool. The cluster pool is smaller than the
mbuf pool in general, so we do the following: if the packet is less
that MINCLSIZE bytes, then we copy it into a small mbuf chain and
leave the mbuf cluster in place for another go-round. This saves
mbuf clusters in some cases while still allowing them to be used
for heavy traffic exchanges with lots of full-sized frames.
- The transmit descriptor has a bit in the control word which allows
the driver to request that a 'TX OK' interrupt be generated when
a frame has been completed. Sometimes, a frame can be fragmented
across several descriptors. The manual for the real DEC 21140A says
that if this happens, the 'TX interrupt request' bit is only valid
in the descriptor of the last fragment. With the ASIX chip, it seems
the 'TX interrupt request' bit is only valid in the descriptor of
the _first_ fragment. Actually, the manual contains conflicting
information, but I think it's supposed to be the first fragment.
To play it safe, set the bit in both the first and last fragment to
be sure that we get a TX OK interrupt. Without this fix, the driver
can sometimes be late in releasing mbufs from the transmit queue
after transmission.
on the ASIX AX88140A chip. Update /sys/conf/files, RELNOTES.TXT,
/sys/i388/i386/userconfig.c, sysinstall/devices.c, GENERIC and LINT
accordingly.
For now, the only board that I know of that uses this chip is the
Alfa Inc. GFC2204. (Its predecessor, the GFC2202, was a DEC tulip card.)
Thanks again to Ulf for obtaining the board for me. If anyone runs
across another, please feel free to update the man page and/or the
release notes. (The same applies for the other drivers.)
FreeBSD should now have support for all of the DEC tulip workalike
chipsets currently on the market (Macronix, Lite-On, Winbond, ASIX).
And unless I'm mistaken, it should also have support for all PCI fast
ethernet chipsets in general (except maybe the SMC FEAST chip, which
nobody seems to ever use, including SMC). Now if only we could convince
3Com, Intel or whoever to cough up some documentation for gigabit
ethernet hardware.
Also updated RELNOTEX.TXT to mention that the SVEC PN102TX is supported
by the Macronix driver (assuming you actually have an SVEC PN102TX with
a Macronix chip on it; I tried to order a PN102TX once and got a box
labeled 'Hawking Technology PN102TX' that had a VIA Rhine board inside
it).
