Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
blown over by the Hurricane and had a house dropped on you by the Tornado.
Now it's time to have your parade rained on by... the Typhoon!
This commit adds driver support for 3Com 3cR990 10/100 ethernet
adapters based on the Typhoon I and Typhoon II chipsets. This is actually
a port of the OpenBSD driver with many hacks by me.
No Virginia, there isn't any support for the hardware crypto yet. However
there is support for TCP/IP checksum offload and VLANs.
Special thanks go to Jason Wright, Aaron Campbell and Theo de Raadt for
squeezing enough info out of 3Com to get this written, and for doing
most of the hard work.
Manual page is included. Compiled as a module and included in GENERIC.
a KLD. Still doesn't work well except in the PCMCIA case (now if only
pccardd(8) could load and unload drivers dynamically...). Mainly, it
tries to find fdc0 on the PCI bus for whatever obscure reasons, but i
need someone who understands driver(9) to fix this. However, it's at least
already better than before, and i'm tired of maintaining too many private
changes in my tree, given the large patches bde submitted. :)
Idea of a KLD triggered by: Michael Reifenberger <root@nihil.plaut.de>
could only get a chance of testing it under 4.3, but together with the
if_oltr.c fixes at least it seems to work now. If someone has the chance
to test this under -current, please do.
Unfortunaltey, the TR code itself (if_iso88025subr.c) is not written
in a way that would allow to make a seaparate KLD out of it. By now,
just link it directly into the oltr KLD since it's probably the POLA
to be able to load the TR code together with the only TR hardware
driver we've got by now.
I've got one single unexplained panic (in doreti_switch or somewhere
there, calling a 0xc1XXXXXX address that did no longer belong to the
kernel at all) after unloading the modules once, thus i don't propose
a MFC of this module despite my testing has been done solely on 4.3,
unless someone is really going to test this stuff in -current.
gigabit ethernet controller chip. This device is used on some
fiber optic gigE cards from SMC, D-Link and Addtron. Jumbograms and
TCP/IP checksum offload on receive are supported. Hardware VLAN
filtering is not, because it doesn't play well with our existing
VLAN code. Also add manual page.
There is a 4.x version of this driver available at
http://www.freebsd.org/~wpaul/Level1/4.x if anyone feels adventurous
and wants to test it. I still need to do performance testing and
tuning with this device.
(For my next trick, I will make the 3Com 3cR990 sit up and beg.)
systems were repo-copied from sys/miscfs to sys/fs.
- Renamed the following file systems and their modules:
fdesc -> fdescfs, portal -> portalfs, union -> unionfs.
- Renamed corresponding kernel options:
FDESC -> FDESCFS, PORTAL -> PORTALFS, UNION -> UNIONFS.
- Install header files for the above file systems.
- Removed bogus -I${.CURDIR}/../../sys CFLAGS from userland
Makefiles.
and DP83821 gigabit ethernet MAC chips and the NatSemi DP83861 10/100/1000
copper PHY. There are a whole bunch of very low cost cards available with
this chipset selling for $150USD or less. This includes the SMC9462TX,
D-Link DGE-500T, Asante GigaNIX 1000TA and 1000TPC, and a couple cards
from Addtron.
This chip supports TCP/IP checksum offload, VLAN tagging/insertion.
2048-bit multicast filter, jumbograms and has 8K TX and 32K RX FIFOs.
I have not done serious performance testing with this driver. I know
it works, and I want it under CVS control so I can keep tabs on it.
Note that there's no serious mutex stuff in here yet either: I need
to talk more with jhb to figure out the right way to do this. That
said, I don't think there will be any problems.
This driver should also work on the alpha. It's not turned on in
GENERIC.
This driver supports PCI Xr-based and ISA Xem Digiboard cards.
dgm will go away soon if there are no problems reported. For now,
configuring dgm into your kernel warns that you should be using
digi. This driver is probably close to supporting Xi, Xe and Xeve
cards, but I wouldn't expect them to work properly (hardware
donations welcome).
The digi_* pseudo-drivers are not drivers themselves but contain
the BIOS and FEP/OS binaries for various digiboard cards and are
auto-loaded and auto-unloaded by the digi driver at initialisation
time. They *may* be configured into the kernel, but waste a lot
of space if they are. They're intended to be left as modules.
The digictl program is (mainly) used to re-initialise cards that
have external port modules attached such as the PC/Xem.
the video switch by another. Exactly as VESA does on top of VGA.
It adds linear framebuffer to S3 VESA 1.2 cards.
Obtained from: The original S3 ISA code comes from
Peter Horton <pdh@colonel-panic.com>
Add detach routine and turn driver into a module so it can be loaded
and unloaded. Also take a stab at implementing multicast packet
reception so that this NIC will work with IPv6. Promiscuous mode
doesn't seem to work, but I'm not sure why. It works well enough that
I can run dhclient on it and put it on the office network though.
Also ripped out spl stuff and replaced it with mutexes.
now in dirs called sys/*/random/ instead of sys/*/randomdev/*.
Introduce blocking, but only at startup; the random device will
block until the first reseed happens to prevent clients from
using untrustworthy output.
Provide a read_random() call for the rest of the kernel so that
the entropy device does not need to be present. This means that
things like IPX no longer need to have "device random" hardcoded
into thir kernel config. The downside is that read_random() will
provide very poor output until the entropy device is loaded and
reseeded. It is recommended that developers do NOT use the
read_random() call; instead, they should use arc4random() which
internally uses read_random().
Clean up the mutex and locking code a bit; this makes it possible
to unload the module again.
support which use National Semiconductor DP8393X (SONIC) as ethernet
controller. Currently, this driver is used on only PC-98.
Submitted by: Motomichi Matsuzaki <mzaki@e-mail.ne.jp>
Obtained from: NetBSD/pc98
Previously, these cards were supported by the lnc driver (and they
still are, but the pcn driver will claim them first), which is fine
except the lnc driver runs them in 16-bit LANCE compatibility mode.
The pcn driver runs these chips in 32-bit mode and uses the RX alignment
feature to achieve zero-copy receive. (Which puts it in the same
class as the xl, fxp and tl chipsets.) This driver is also MI, so it
will work on the x86 and alpha platforms. (The lnc driver is still
needed to support non-PCI cards. At some point, I'll need to newbusify
it so that it too will me MI.)
The Am79c978 HomePNA adapter is also supported.
This provides support for the Adaptec SCSI RAID controller family,
as well as the DPT SmartRAID V and VI families.
The driver will be maintained by Mark and Adaptec, and any changes
should be referred to the MAINTAINER.
shouldn't be built by default. pcic and pccard are going to go
through some changes and I'll not be testing them on the alpha so I
don't want to break them for the FreeBSD/alpha folks.
Make the umass driver depend on this module.
Makes it possible to compile the kernel without SCSI support and load it
when for example a USB floppy is conencted.
be a permanent rule, because this device may eventually be deemed
"effectively compulsory", and built by default directly into the
kernel. For the moment, however, this is useful for debugging and
development.
Reviewed by: dfr
accept filters are now loadable as well as able to be compiled into
the kernel.
two accept filters are provided, one that returns sockets when data
arrives the other when an http request is completed (doesn't work
with 0.9 requests)
Reviewed by: jmg
2. Newbusify the driver.
3. Build as a module.
4. Use correct minor numbers when creating device files.
5. Correctly lock control characters.
6. Return ENXIO when device not configured.
Submitted by: Tor Egge <Tor.Egge@fast.no>
7. Fix the baud_table.
Submitted by: Elliot Dierksen <ebd@oau.org>
Note:
- the old driver still lives in src/sys/i386/isa, so that you can
revert to it if something goes wrong.
- The module does not detach very well. Attaching works fine.
are two supported chips, the NetChip 1080 (only prototypes available)
and the EzLink cable. Any other cable should be supported however as they
are all very much alike (there is a difference between them wrt
performance).
It uses Netgraph.
This driver was mostly written by Doug Ambrisko and Julian Elischer and
I would like to thank Whistle for yet another contribution. And my
aplogies to them for me sitting on the driver for so long (2 months).
Also, many thanks to Reid Augustin from NetChip for providing me with a
prototype of their 1080 chip.
Be aware of the fact that this driver is very immature and has only been
tested very lightly. If someone feels like learning about Netgraph however
this is an excellent driver to start playing with.
vintage system, well before the ppbus changes. When I called it an
"example" module, I meant as an example for the rest of the ppbus client
drivers, not that it was worthless. I'll mail my 5.8MB world.log to
anybody who doesn't believe me.
Wrongly accused by: obrien
NICs. (Finally!) The PCMCIA, ISA and PCI varieties are all supported,
though only the ISA and PCI ones will work on the alpha for now.
PCCARD, ISA and PCI attachments are all provided. Also provided an
ancontrol(8) utility for configuring the NIC, man pages, and updated
pccard.conf.sample. ISA cards are supported in both ISA PnP and hard-wired
mode, although you must configure the kernel explicitly to support the
hardwired mode since you have to know the I/O address and port ahead
of time.
Special thanks to Doug Ambrisko for doing the initial newbus hackery
and getting it to work in infrastructure mode.
USB-EL1202A chipset. Between this and the other two drivers, we should
have support for pretty much every USB ethernet adapter on the market.
The only other USB chip that I know of is the SMC USB97C196, and right
now I don't know of any adapters that use it (including the ones made
by SMC :/ ).
Note that the CATC chip supports a nifty feature: read and write combining.
This allows multiple ethernet packets to be transfered in a single USB
bulk in/out transaction. However I'm again having trouble with large
bulk in transfers like I did with the ADMtek chip, which leads me to
believe that our USB stack needs some work before we can really make
use of this feature. When/if things improve, I intend to revisit the
aue and cue drivers. For now, I've lost enough sanity points.
