cards:
o RocketRAID 172x series
o RocketRAID 174x series
o RocketRAID 2210
o RocketRAID 222x series
o RocketRAID 2240
o RocketRAID 230x series
o RocketRAID 231x series
o RocketRAID 232x series
o RocketRAID 2340
o RocketRAID 2522
Many thanks to Highpoint for their continued support of FreeBSD.
Submitted by: Highpoint
This includes:
o mtree (for legal/intel_wpi)
o manpage for i386/amd64 archs
o module for i386/amd64 archs
o NOTES for i386/amd64 archs
Approved by: mlaier (comentor)
refactored it to be a generic device.
Instead of being part of the standard kernel, there is now a 'nvram' device
for i386/amd64. It is in DEFAULTS like io and mem, and can be turned off
with 'nodevice nvram'. This matches the previous behavior when it was
first committed.
to gem_attach() as the former access softc members not yet initialized
at that time and gem_reset() actually is enough to stop the chip. [1]
o Revise the use of gem_bitwait(); add bus_barrier() calls before calling
gem_bitwait() to ensure the respective bit has been written before we
starting polling on it and poll for the right bits to change, f.e. even
though we only reset RX we have to actually wait for both GEM_RESET_RX
and GEM_RESET_TX to clear. Add some additional gem_bitwait() calls in
places we've been missing them according to the GEM documentation.
Along with this some excessive DELAYs, which probably only were added
because of bugs in gem_bitwait() and its use in the first place, as
well as as have of an gem_bitwait() reimplementation in gem_reset_tx()
were removed.
o Add gem_reset_rxdma() and use it to deal with GEM_MAC_RX_OVERFLOW errors
more gracefully as unlike gem_init_locked() it resets the RX DMA engine
only, causing no link loss and the FIFOs not to be cleared. Also use it
deal with GEM_INTR_RX_TAG_ERR errors, with previously were unhandled.
This was based on information obtained from the Linux GEM and OpenSolaris
ERI drivers.
o Turn on workarounds for silicon bugs in the Apple GMAC variants.
This was based on information obtained from the Darwin GMAC and Linux GEM
drivers.
o Turn on "infinite" (i.e. maximum 31 * 64 bytes in length) DMA bursts.
This greatly improves especially RX performance.
o Optimize the RX path, this consists of:
- kicking the receiver as soon as we've a spare descriptor in gem_rint()
again instead of just once after all the ready ones have been handled;
- kicking the receiver the right way, i.e. as outlined in the GEM
documentation in batches of 4 and by pointing it to the descriptor
after the last valid one;
- calling gem_rint() before gem_tint() in gem_intr() as gem_tint() may
take quite a while;
- doubling the size of the RX ring to 256 descriptors.
Overall the RX performance of a GEM in a 1GHz Sun Fire V210 was improved
from ~100Mbit/s to ~850Mbit/s.
o In gem_add_rxbuf() don't assign the newly allocated mbuf to rxs_mbuf
before calling bus_dmamap_load_mbuf_sg(), if bus_dmamap_load_mbuf_sg()
fails we'll free the newly allocated mbuf, unable to recycle the
previous one but a NULL pointer dereference instead.
o In gem_init_locked() honor the return value of gem_meminit().
o Simplify gem_ringsize() and dont' return garbage in the default case.
Based on OpenBSD.
o Don't turn on MAC control, MIF and PCS interrupts unless GEM_DEBUG is
defined as we don't need/use these interrupts for operation.
o In gem_start_locked() sync the DMA maps of the descriptor rings before
every kick of the transmitter and not just once after enqueuing all
packets as the NIC might instantly start transmitting after we kicked
it the first time.
o Keep state of the link state and use it to enable or disable the MAC
in gem_mii_statchg() accordingly as well as to return early from
gem_start_locked() in case the link is down. [3]
o Initialize the maximum frame size to a sane value.
o In gem_mii_statchg() enable carrier extension if appropriate.
o Increment if_ierrors in case of an GEM_MAC_RX_OVERFLOW error and in
gem_eint(). [3]
o Handle IFF_ALLMULTI correctly; don't set it if we've turned promiscuous
group mode on and don't clear the flag if we've disabled promiscuous
group mode (these were mostly NOPs though). [2]
o Let gem_eint() also report GEM_INTR_PERR errors.
o Move setting sc_variant from gem_pci_probe() to gem_pci_attach() as
device probe methods are not supposed to touch the softc.
o Collapse sc_inited and sc_pci into bits for sc_flags.
o Add CTASSERTs ensuring that GEM_NRXDESC and GEM_NTXDESC are set to
legal values.
o Correctly set up for 802.3x flow control, though #ifdef out the code
that actually enables it as this needs more testing and mainly a proper
framework to support it.
o Correct and add some conversions from hard-coded functions names to
__func__ which were borked or forgotten in if_gem.c rev. 1.42.
o Use PCIR_BAR instead of a homegrown macro.
o Replace sc_enaddr[6] with sc_enaddr[ETHER_ADDR_LEN].
o In gem_pci_attach() in case attaching fails release the resources in
the opposite order they were allocated.
o Make gem_reset() static to if_gem.c as it's not needed outside that
module.
o Remove the GEM_GIGABIT flag and the associated code; GEM_GIGABIT was
never set and the associated code was in the wrong place.
o Remove sc_mif_config; it was only used to cache the contents of the
respective register within gem_attach().
o Remove the #ifdef'ed out NetBSD/OpenBSD code for establishing a suspend
hook as it will never be used on FreeBSD.
o Also probe Apple Intrepid 2 GMAC and Apple Shasta GMAC, add support for
Apple K2 GMAC. Based on OpenBSD.
o Add support for Sun GBE/P cards, or in other words actually add support
for cards based on GEM to gem(4). This mainly consists of adding support
for the TBI of these chips. Along with this the PHY selection code was
rewritten to hardcode the PHY number for certain configurations as for
example the PHY of the on-board ERI of Blade 1000 shows up twice causing
no link as the second incarnation is isolated.
These changes were ported from OpenBSD with some additional improvements
and modulo some bugs.
o Add code to if_gem_pci.c allowing to read the MAC-address from the VPD on
systems without Open Firmware.
This is an improved version of my variant of the respective code in
if_hme_pci.c
o Now that gem(4) is MI enable it for all archs.
Pointed out by: yongari [1]
Suggested by: rwatson [2], yongari [3]
Tested on: i386 (GEM), powerpc (GMACs by marcel and yongari),
sparc64 (ERI and GEM)
Reviewed by: yongari
Approved by: re (kensmith)
and newer CPUs (including Core 2 and Core / Core 2 based Xeons). The
driver attaches to each cpu device and creates a sysctl node in that
device's sysctl context (dev.cpu.N.temperature). When invoked, the
handler binds to the appropriate CPU to ensure a correct reading.
Submitted by: Rui Paulo <rpaulo@fnop.net>
Sponsored by: Google Summer of Code 2007
Tested by: des, marcus, Constantine A. Murenin, Ian FREISLICH
Approved by: re (kensmith)
MFC after: 3 weeks
- Add custom .c wrappers for the firmware, rather than the standard
firmware(9) generated firmware objects to work around toolchain
problems on ia64 involving linking objects produced by
ld -b -binary into the kernel.
- Move from using Myricom's ".dat" firmware blobs to using Myricom's
zlib compressed ".h" firmware header files. This is done to
facilitate the custom wrappers, and saves a fair amount of wired
memory in the case where the firmware is built in, or preloaded.
- Fix two compile issues in mxge which only appear on non-i386/amd64.
Reviewed by: mlaier, mav (earlier version with just zlib support)
Glanced at by: sam
Approved by: re (kensmith)
NET_NEEDS_GIANT, which will shortly be removed. This is done in a
away that it may be easily reattached to the build before 7.1 if
appropriate locking is added. Specifics:
- Don't install netatm include files
- Disconnect netatm command line management tools
- Don't build libatm
- Don't include ATM parts in rescue or sysinstall
- Don't install sample configuration files and documents
- Don't build kernel support as a module or in NOTES
- Don't build netgraph wrapper nodes for netatm
This removes the last remaining consumer of NET_NEEDS_GIANT.
Reviewed by: harti
Discussed with: bz, bms
Approved by: re (kensmith)
Please note that, this is currently considered as an
experimental feature so there could be some rough
edges. Consult http://wiki.freebsd.org/TMPFS for
more information.
For now, connect tmpfs to build on i386 and amd64
architectures only. Please let us know if you have
success with other platforms.
This work was developed by Julio M. Merino Vidal
for NetBSD as a SoC project; Rohit Jalan ported it
from NetBSD to FreeBSD. Howard Su and Glen Leeder
are worked on it to continue this effort.
Obtained from: NetBSD via p4
Submitted by: Howard Su (with some minor changes)
Approved by: re (kensmith)
o major overhaul of the way channels are handled: channels are now
fully enumerated and uniquely identify the operating characteristics;
these changes are visible to user applications which require changes
o make scanning support independent of the state machine to enable
background scanning and roaming
o move scanning support into loadable modules based on the operating
mode to enable different policies and reduce the memory footprint
on systems w/ constrained resources
o add background scanning in station mode (no support for adhoc/ibss
mode yet)
o significantly speedup sta mode scanning with a variety of techniques
o add roaming support when background scanning is supported; for now
we use a simple algorithm to trigger a roam: we threshold the rssi
and tx rate, if either drops too low we try to roam to a new ap
o add tx fragmentation support
o add first cut at 802.11n support: this code works with forthcoming
drivers but is incomplete; it's included now to establish a baseline
for other drivers to be developed and for user applications
o adjust max_linkhdr et. al. to reflect 802.11 requirements; this eliminates
prepending mbufs for traffic generated locally
o add support for Atheros protocol extensions; mainly the fast frames
encapsulation (note this can be used with any card that can tx+rx
large frames correctly)
o add sta support for ap's that beacon both WPA1+2 support
o change all data types from bsd-style to posix-style
o propagate noise floor data from drivers to net80211 and on to user apps
o correct various issues in the sta mode state machine related to handling
authentication and association failures
o enable the addition of sta mode power save support for drivers that need
net80211 support (not in this commit)
o remove old WI compatibility ioctls (wicontrol is officially dead)
o change the data structures returned for get sta info and get scan
results so future additions will not break user apps
o fixed tx rate is now maintained internally as an ieee rate and not an
index into the rate set; this needs to be extended to deal with
multi-mode operation
o add extended channel specifications to radiotap to enable 11n sniffing
Drivers:
o ath: add support for bg scanning, tx fragmentation, fast frames,
dynamic turbo (lightly tested), 11n (sniffing only and needs
new hal)
o awi: compile tested only
o ndis: lightly tested
o ipw: lightly tested
o iwi: add support for bg scanning (well tested but may have some
rough edges)
o ral, ural, rum: add suppoort for bg scanning, calibrate rssi data
o wi: lightly tested
This work is based on contributions by Atheros, kmacy, sephe, thompsa,
mlaier, kevlo, and others. Much of the scanning work was supported by
Atheros. The 11n work was supported by Marvell.
The name trunk is misused as the networking term trunk means carrying multiple
VLANs over a single connection. The IEEE standard for link aggregation (802.3
section 3) does not talk about 'trunk' at all while it is used throughout IEEE
802.1Q in describing vlans.
The lagg(4) driver provides link aggregation, failover and fault tolerance.
Discussed on: current@
imitating an Ethernet device, so vlan(4) and if_bridge(4) can be
attached to it for testing and benchmarking purposes. Its source
can be an introduction to the anatomy of a network interface driver
due to its simplicity as well as to a bunch of comments in it.
uuencoded format along with their respective LICENSE files.
- Add new share/doc/legal directory to BSD.usr.dist mtree file. This is the
place we install LICENSE files for restricted firmwares.
- Teach firmware(9) and kmod.mk about licensed firmwares. Restricted firmwares
won't load properly unless legal.<name>.license_ack is set to 1, either
via kenv(1) or /boot/loader.conf.
Reviewed by: mlaier, sam
Permitted by: Intel (via Andrew Wilson)
MFC after: 1 month
Originally it wasn't enabled since the hardware wasn't commonplace,
but as 10GE hardware is becoming more widely used, building the module
by default should be beneficial.
Approved by: rwatson (mentor)
MFC after: 2 weeks
PowerPC-based Apple's machines and small utility to do it from
userland modelled after the similar utility in Darwin/OSX.
Only tested on 1.25GHz G4 Mac Mini.
MFC after: 1 month
This driver was ported from OpenBSD by Shigeaki Tagashira
<shigeaki@se.hiroshima-u.ac.jp> and posted at
http://www.se.hiroshima-u.ac.jp/~shigeaki/software/freebsd-nfe.html
It was additionally cleaned up by me.
It is still a work-in-progress and thus is purposefully not in GENERIC.
And it conflicts with nve(4), so only one should be loaded.
s/myri10ge/mxge/g replacement in the myri10ge files. A few contuation
lines were joined because of the regained columns.
- Hook the mxge driver back to the build.
This driver was generously developed and donated by Highpoint.
It is enabled for i386 only at the moment. I will enable it for amd64
shortly.
Obtained from: HighPoint Technologies, Inc.
o Add the scc(4) manpage to the build.
o Update the uart(4) manpage to account for scc(4).
o Update the uart(4) module build to include support for scc(4).
- <netipx> headers [1]
- IPX library (libipx)
- IPX support in ifconfig(8)
- IPXrouted(8)
- new MK_NCP option
New MK_NCP build option controls:
- <netncp> and <fs/nwfs> headers
- NCP library (libncp)
- ncplist(1) and ncplogin(1)
- mount_nwfs(8)
- ncp and nwfs kernel modules
User knobs: WITHOUT_IPX, WITHOUT_IPX_SUPPORT, WITHOUT_NCP.
[1] <netsmb/netbios.h> unconditionally uses <netipx> headers
so they are still installed. This needs to be dealt with.
into a separate module. Accordingly, convert the option into a device
named similarly.
Note for MFC: Perhaps the option should stay in RELENG_6 for POLA reasons.
Suggested by: scottl
Reviewed by: cokane
MFC after: 5 days
in order to support the on-board LANCE in Ultra 1 and to the MI NOTES as
it should work just fine with the AMD PCnet family of chips on all archs
but is not yet meant to replace lnc(4). If a kernel includes all of le(4),
lnc(4) and pcn(4) precedence is given to lnc(4)/pcn(4) for now.
specially crafted module. There are several handrolled sollutions to this
problem in the tree already which will be replaced with this. They include
iwi(4), ipw(4), ispfw(4) and digi(4).
No objection from: arch
MFC after: 2 weeks
X-MFC after: some drivers have been converted
I'm holding off on building on sparc64 and others because I don't know
if this driver has had all the inb/outb removed (I think it has). Nor
do I know if there are byte ordering issues. There are very few word
operations on an NE2000, but I've not had time to audit them all.
Suggested by: Daniel O'Connor
The following repo-copies were made (by Mark Murray):
sys/i386/isa/spkr.c -> sys/dev/speaker/spkr.c
sys/i386/include/speaker.h -> sys/dev/speaker/speaker.h
share/man/man4/man4.i386/spkr.4 -> share/man/man4/spkr.4
drivers I started quite some time before.
Retire the old i386-only pcf driver, and activate the new general
driver that has been sitting in the tree already for quite some
time.
Build the i2c modules for sparc64 architectures as well (where I've
been developing all this on).
interface polling, compiles on 64-bit platforms, and compiles on NetBSD,
OpenBSD, BSD/OS, and Linux. Woo! Thanks to David Boggs for providing this
driver.
Altq, sppp, netgraph, and bpf are required for this driver to operate.
Userland tools and man pages will be committed next.
Submitted by: David Boggs
replacement and has additional features which make it superior.
Discussed on: -arch
Reviewed by: thompsa
X-MFC-after: never (RELENG_6 as transition period)
earlier as no one has stepped up to test recent changes to the driver.
Oddly, the module was actually turned on on ia64 though I'm fairly certain
that no ia64 machine has ever had or will ever have an ISA slot.
Axe borrowed from: phk
o Add minimal kbdmux(4) man page to the source tree (more details to follow);
o Hook up kbdmux(4) to the build.
This concludes the first part of the kbdmux(4) keyboard multiplexer
integration. It now should be possible to use kbdmux(4), however one
must configure kbdmux(4) by hand (i.e. load kbdmux(4) module and use
kbdcontrol(1) to add/remove slave keyboards to/from kbdmux(4)).
MFC after: 1 week
here on in, if_ndis.ko will be pre-built as a module, and can be built
into a static kernel (though it's not part of GENERIC). Drivers are
created using the new ndisgen(8) script, which uses ndiscvt(8) under
the covers, along with a few other tools. The result is a driver module
that can be kldloaded into the kernel.
A driver with foo.inf and foo.sys files will be converted into
foo_sys.ko (and foo_sys.o, for those who want/need to make static
kernels). This module contains all of the necessary info from the
.INF file and the driver binary image, converted into an ELF module.
You can kldload this module (or add it to /boot/loader.conf) to have
it loaded automatically. Any required firmware files can be bundled
into the module as well (or converted/loaded separately).
Also, add a workaround for a problem in NdisMSleep(). During system
bootstrap (cold == 1), msleep() always returns 0 without actually
sleeping. The Intel 2200BG driver uses NdisMSleep() to wait for
the NIC's firmware to come to life, and fails to load if NdisMSleep()
doesn't actually delay. As a workaround, if msleep() (and hence
ndis_thsuspend()) returns 0, use a hard DELAY() to sleep instead).
This is not really the right thing to do, but we can't really do much
else. At the very least, this makes the Intel driver happy.
There are probably other drivers that fail in this way during bootstrap.
Unfortunately, the only workaround for those is to avoid pre-loading
them and kldload them once the system is running instead.
Enhanced SpeedStep (that is, a follow-up of it called Foxton). Until
we actually have support for that, we build to catch regressions in
the framework.
Triggered by: njl
pc98 machines because (a) it is PCIe or PCI-X (b) there's a BIOS that
must run at boot which assumes IBM-AT compatible boot environment.
Noticed by: scottl
o ATA is now fully newbus'd and split into modules.
This means that on a modern system you just load "atapci and ata"
to get the base support, and then one or more of the device
subdrivers "atadisk atapicd atapifd atapist ataraid".
All can be loaded/unloaded anytime, but for obvious reasons you
dont want to unload atadisk when you have mounted filesystems.
o The device identify part of the probe has been rewritten to fix
the problems with odd devices the old had, and to try to remove
so of the long delays some HW could provoke. Also probing is done
without the need for interrupts, making earlier probing possible.
o SATA devices can be hot inserted/removed and devices will be created/
removed in /dev accordingly.
NOTE: only supported on controllers that has this feature:
Promise and Silicon Image for now.
On other controllers the usual atacontrol detach/attach dance is
still needed.
o Support for "atomic" composite ATA requests used for RAID.
o ATA RAID support has been rewritten and and now supports these
metadata formats:
"Adaptec HostRAID"
"Highpoint V2 RocketRAID"
"Highpoint V3 RocketRAID"
"Intel MatrixRAID"
"Integrated Technology Express"
"LSILogic V2 MegaRAID"
"LSILogic V3 MegaRAID"
"Promise FastTrak"
"Silicon Image Medley"
"FreeBSD PseudoRAID"
o Update the ioctl API to match new RAID levels etc.
o Update atacontrol to know about the new RAID levels etc
NOTE: you need to recompile atacontrol with the new sys/ata.h,
make world will take care of that.
NOTE2: that rebuild is done differently from the old system as
the rebuild is now done piggybacked on read requests to the
array, so atacontrol simply starts a background "dd" to rebuild
the array.
o The reinit code has been worked over to be much more robust.
o The timeout code has been overhauled for races.
o Support of new chipsets.
o Lots of fixes for bugs found while doing the modulerization and
reviewing the old code.
Missing or changed features from current ATA:
o atapi-cd no longer has support for ATAPI changers. Todays its
much cheaper and alot faster to copy those CD images to disk
and serve them from there. Besides they dont seem to be made
anymore, maybe for that exact reason.
o ATA RAID can only read metadata from all the above metadata formats,
not write all of them (Promise and Highpoint V2 so far). This means
that arrays can be picked up from the BIOS, but they cannot be
created from FreeBSD. There is more to it than just the missing
write metadata support, those formats are not unique to a given
controller like Promise and Highpoint formats, instead they exist
for several types, and even worse, some controllers can have
different formats and its impossible to tell which one.
The outcome is that we cannot reliably create the metadata of those
formats and be sure the controller BIOS will understand it.
However write support is needed to update/fail/rebuild the arrays
properly so it sits fairly high on the TODO list.
o So far atapicam is not supported with these changes. When/if this
will change is up to the maintainer of atapi-cam so go there for
questions.
HW donated by: Webveveriet AS
HW donated by: Frode Nordahl
HW donated by: Yahoo!
HW donated by: Sentex
Patience by: Vife and my boys (and even the cats)
FreeBSD based on aue(4) it was picked by OpenBSD, then from OpenBSD ported
to NetBSD and finally NetBSD version merged with original one goes into
FreeBSD.
Obtained from: http://www.gank.org/freebsd/cdce/
NetBSD
OpenBSD
Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx)
deserves a big thanks for submitting initial patches to make it
work. I have mangled his contributions appropriately.
The main gotcha with Windows/x86-64 is that Microsoft uses a different
calling convention than everyone else. The standard ABI requires using
6 registers for argument passing, with other arguments on the stack.
Microsoft uses only 4 registers, and requires the caller to leave room
on the stack for the register arguments incase the callee needs to
spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall
and _fastcall, all routines on Windows/x86-64 uses the same convention.
This unfortunately means that all the functions we export to the
driver require an intermediate translation wrapper. Similarly, we have
to wrap all calls back into the driver binary itself.
The original patches provided macros to wrap every single routine at
compile time, providing a secondary jump table with a customized
wrapper for each exported routine. I decided to use a different approach:
the call wrapper for each function is created from a template at
runtime, and the routine to jump to is patched into the wrapper as
it is created. The subr_pe module has been modified to patch in the
wrapped function instead of the original. (On x86, the wrapping
routine is a no-op.)
There are some minor API differences that had to be accounted for:
- KeAcquireSpinLock() is a real function on amd64, not a macro wrapper
around KfAcquireSpinLock()
- NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole
NDIS_BUFFER API a bit to accomodate this.
Bugs fixed along the way:
- IoAllocateMdl() always returned NULL
- kern_windrv.c:windrv_unload() wasn't releasing private driver object
extensions correctly (found thanks to memguard)
This has only been tested with the driver for the Broadcom 802.11g
chipset, which was the only Windows/x86-64 driver I could find.
copies arguments into the kernel space and one that operates
completely in the kernel space;
o use kernel-only version of execve(2) to kill another stackgap in
linuxlator/i386.
Obtained from: DragonFlyBSD (partially)
MFC after: 2 weeks
to elide. This is a somewhat more convenient way of specifying in
e.g. make.conf a list of modules you know you will never need.
PR: kern/76225
Submitted by: David Yeske <dyeske@yahoo.com>
MFC after: 2 weeks
the ISA and CBUS (called isa on pc98) attachments. Eliminate all PC98
ifdefs in the process (the driver in pc98/pc98/mse.c was a copy of the one
in i386/isa/mse.c with PC98 ifdefs). Create a module for this driver.
I've tested this my PC-9821RaS40 with moused. I've not tested this on i386
because I have no InPort cards, or similar such things. NEC standardized
on bus mice very early, long before ps/2 mice ports apeared, so all PC-98
machines supported by FreeBSD/pc98 have bus mice, I believe.
Reviewed by: nyan-san
on UltraSPARC workstations. The driver is based on OpenBSD's SBus
cs4231 driver and heavily modified to incorporate into sound(4)
infrastructure. Due to the lack of APCDMA documentation, the DMA
code of SBus cs4231 came from OpenBSD's driver.
The driver runs without Giant lock and supports both SBus and EBus
based CS4231 audio controller. Special thanks to marius for providing
feedbacks during the driver writing. His feedback made it possible
to write hiccup free playback code under high system loads.
Approved by: jake (mentor)
Reviewed by: marius (initial version)
Tested by: marius, kwm, Julian C. Dunn(jdunn AT opentrend DOT net)
be used to announce various system activity.
The auxio device provides auxiliary I/O functions and is found on various
SBus/EBus UltraSPARC models. At present, only front panel LED is
controlled by this driver.
Approved by: jake (mentor)
Reviewed by: joerg
Tested by: joerg
Users should move to the new geom_vinum implementation instead.
The refcount logic which is being added to devices to enable safe module
unloading and the buf/vm work also in progress would require a major rework
of the (old)-vinum code to comply with the new semantics.
The actual source files will not be removed until I have coordinated with
the geomvinum people if they need any bits repo-copied etc.
VT6122 gigabit ethernet chip and integrated 10/100/1000 copper PHY.
The vge driver has been added to GENERIC for i386, pc98 and amd64,
but not to sparc or ia64 since I don't have the ability to test
it there. The vge(4) driver supports VLANs, checksum offload and
jumbo frames.
Also added the lge(4) and nge(4) drivers to GENERIC for i386 and
pc98 since I was in the neighborhood. There's no reason to leave them
out anymore.
to RS232 bridges, such as the one found in the DeLorme Earthmate USB GPS
receiver (which is the only device currently supported by this driver).
While other USB to serial drivers in the tree rely heavily on ucom, this
one is self-contained. The reason for that is that ucom assumes that
the bridge uses bulk pipes for I/O, while the Cypress parts actually
register as human interface devices and use HID reports for configuration
and I/O.
The driver is not entirely complete: there is no support yet for flow
control, and output doesn't seem to work, though I don't know if that is
because of a bug in the code, or simply because the Earthmate is a read-
only device.
Currently one cannot load the mem.ko module without panicing if mem is
compiled into the kernel and one cannot build a kernel w/o "device mem"
right now either. Thus it is too dangerous to install mem.ko right now
because if one puts 'mem_load="YES"' in /etc/loader.conf they cannot
boot an "old" kernel (at the time that a kernel doesn't have to be built
with "device mem).
their own directory and module, leaving the MD parts in the MD
area (the MD parts _are_ part of the modules). /dev/mem and /dev/io
are now loadable modules, thus taking us one step further towards
a kernel created entirely out of modules. Of course, there is nothing
preventing the kernel from having these statically compiled.
- Remove pflog and pfsync modules. Things will change in such a fashion
that there will be one module with pf+pflog that can be loaded into
GENERIC without problems (which is what most people want). pfsync is no
longer possible as a module.
- Add multicast address for in-kernel multicast pfsync protocol. Protocol
glue will follow once the import is done.
- Add one more mbuf tag
hal_raise_irql(void) doesn't take an argument, but it is called with one.
eg: irql = FASTCALL1(hal_raise_irql, DISPATCH_LEVEL);
This is hidden by the macros on i386, but becomes a compile error on amd64
since the arguments are actually checked.
stuff was here (NFS) was fixed by Alfred in November. The only remaining
consumer of the stub functions was umapfs, which is horribly horribly
broken. It has missed out on about the last 5 years worth of maintenence
that was done on nullfs (from which umapfs is derived). It needs major
work to bring it up to date with the vnode locking protocol. umapfs really
needs to find a caretaker to bring it into the 21st century.
Functions GC'ed:
vop_noislocked, vop_nolock, vop_nounlock, vop_sharedlock.
This adds the former ports registered groups: proxy and authpf as well as
the proxy user. Make sure to run mergemaster -p in oder to complete make
installworld without errors.
This also provides the passive OS fingerprints from OpenBSD (pf.os) and an
example pf.conf.
For those who want to go without pf; it provides a NO_PF knob to make.conf.
__FreeBSD_version will be bumped soon to reflect this and to be able to
change ports accordingly.
Approved by: bms(mentor)
- Unify the conditional assignments section so that architectural
exclusions come first, sorted, then options and !options, sorted
by the option name, also in directory order, then architecture
specific sections, sorted by the architecture name, with i386
being a traditional exception.
Prodded by: bde
Yes, it's what you think it is. Yes, you should run away now.
This is a special compatibility module for allowing Windows NDIS
miniport network drivers to be used with FreeBSD/x86. This provides
_binary_ NDIS compatibility (not source): you can run NDIS driver
code, but you can't build it. There are three main parts:
sys/compat/ndis: the NDIS compat API, which provides binary
compatibility functions for many routines in NDIS.SYS, HAL.dll
and ntoskrnl.exe in Windows (these are the three modules that
most NDIS miniport drivers use). The compat module also contains
a small PE relocator/dynalinker which relocates the Windows .SYS
image and then patches in our native routines.
sys/dev/if_ndis: the if_ndis driver wrapper. This module makes
use of the ndis compat API and can be compiled with a specially
prepared binary image file (ndis_driver_data.h) containing the
Windows .SYS image and registry key information parsed out of the
accompanying .INF file. Once if_ndis.ko is built, it can be loaded
and unloaded just like a native FreeBSD kenrel module.
usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf
into an ndis_driver_data.h file that can be compiled into if_ndis.o.
Contains an .inf file parser graciously provided by Matt Dodd (and
mercilessly hacked upon by me) that strips out device ID info and
registry key info from a .INF file and packages it up with a binary
image array. The ndiscvt(8) utility also does some manipulation of
the segments within the .sys file to make life easier for the kernel
loader. (Doing the manipulation here saves the kernel code from having
to move things around later, which would waste memory.)
ndiscvt is only built for the i386 arch. Only files.i386 has been
updated, and none of this is turned on in GENERIC. It should probably
work on pc98. I have no idea about amd64 or ia64 at this point.
This is still a work in progress. I estimate it's about %85 done, but
I want it under CVS control so I can track subsequent changes. It has
been tested with exactly three drivers: the LinkSys LNE100TX v4 driver
(Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK
(e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It
still needs to have a net80211 stuff added to it. To use it, you would
do something like this:
# cd /sys/modules/ndis
# make; make load
# cd /sys/modules/if_ndis
# ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h
# make; make load
# sysctl -a | grep ndis
All registry keys are mapped to sysctl nodes. Sometimes drivers refer
to registry keys that aren't mentioned in foo.inf. If this happens,
the NDIS API module creates sysctl nodes for these keys on the fly so
you can tweak them.
An example usage of the Broadcom wireless driver would be:
# sysctl hw.ndis0.EnableAutoConnect=1
# sysctl hw.ndis0.SSID="MY_SSID"
# sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc)
# ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up
Things to be done:
- get rid of debug messages
- add in ndis80211 support
- defer transmissions until after a status update with
NDIS_STATUS_CONNECTED occurs
- Create smarter lookaside list support
- Split off if_ndis_pci.c and if_ndis_pccard.c attachments
- Make sure PCMCIA support works
- Fix ndiscvt to properly parse PCMCIA device IDs from INF files
- write ndisapi.9 man page
dcons(4): very simple console and gdb port driver
dcons_crom(4): FireWire attachment
dconschat(8): User interface to dcons
Tested with: i386, i386-PAE, and sparc64.
written by Stuart Walsh and Duncan Barclay (with some kibbitzing by
me). I'm checking it in on Stuart's behalf.
The BCM4401 is built into several x86 laptop and desktop systems. For the
moment, I have only enabled it in the x86 kernel config because although
it's a PCI device, I haven't heard of any standalone NICs that use it. If
somebody knows of one, we can easily add it to the other arches.
This driver uses register/structure data gleaned from the Linux
driver released by Broadcom, but does not contain any of the code
from the Linux driver itself. It uses busdma.
rl(4) driver and put it in a new re(4) driver. The re(4) driver shares
the if_rlreg.h file with rl(4) but is a separate module. (Ultimately
I may change this. For now, it's convenient.)
rl(4) has been modified so that it will never attach to an 8139C+
chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to
match the 8169/8169S/8110S gigE chips. if_re.c contains the same
basic code that was originally bolted onto if_rl.c, with the
following updates:
- Added support for jumbo frames. Currently, there seems to be
a limit of approximately 6200 bytes for jumbo frames on transmit.
(This was determined via experimentation.) The 8169S/8110S chips
apparently are limited to 7.5K frames on transmit. This may require
some more work, though the framework to handle jumbo frames on RX
is in place: the re_rxeof() routine will gather up frames than span
multiple 2K clusters into a single mbuf list.
- Fixed bug in re_txeof(): if we reap some of the TX buffers,
but there are still some pending, re-arm the timer before exiting
re_txeof() so that another timeout interrupt will be generated, just
in case re_start() doesn't do it for us.
- Handle the 'link state changed' interrupt
- Fix a detach bug. If re(4) is loaded as a module, and you do
tcpdump -i re0, then you do 'kldunload if_re,' the system will
panic after a few seconds. This happens because ether_ifdetach()
ends up calling the BPF detach code, which notices the interface
is in promiscuous mode and tries to switch promisc mode off while
detaching the BPF listner. This ultimately results in a call
to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init()
to handle the IFF_PROMISC flag change. Unfortunately, calling re_init()
here turns the chip back on and restarts the 1-second timeout loop
that drives re_tick(). By the time the timeout fires, if_re.ko
has been unloaded, which results in a call to invalid code and
blows up the system.
To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(),
which stops the ioctl routine from trying to reset the chip.
- Modified comments in re_rxeof() relating to the difference in
RX descriptor status bit layout between the 8139C+ and the gigE
chips. The layout is different because the frame length field
was expanded from 12 bits to 13, and they got rid of one of the
status bits to make room.
- Add diagnostic code (re_diag()) to test for the case where a user
has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some
NICs have the REQ64# and ACK64# lines connected even though the
board is 32-bit only (in this case, they should be pulled high).
This fools the chip into doing 64-bit DMA transfers even though
there is no 64-bit data path. To detect this, re_diag() puts the
chip into digital loopback mode and sets the receiver to promiscuous
mode, then initiates a single 64-byte packet transmission. The
frame is echoed back to the host, and if the frame contents are
intact, we know DMA is working correctly, otherwise we complain
loudly on the console and abort the device attach. (At the moment,
I don't know of any way to work around the problem other than
physically modifying the board, so until/unless I can think of a
software workaround, this will have do to.)
- Created re(4) man page
- Modified rlphy.c to allow re(4) to attach as well as rl(4).
Note that this code works for the sample 8169/Marvell 88E1000 NIC
that I have, but probably won't work for the 8169S/8110S chips.
RealTek has sent me some sample NICs, but they haven't arrived yet.
I will probably need to add an rlgphy driver to handle the on-board
PHY in the 8169S/8110S (it needs special DSP initialization).
FIDs to be 128-bits wide and adds support for realms.
Add a new CODA_COMPAT_5 option, which requests support for the old
Coda 5.x interface instead of the new one.
Create a new coda5.ko module that supports the 5.x interface, and make
the existing coda.ko module use the new 6.x interface. These modules
cannot both be loaded at the same time.
Obtained from: Jan Harkes & the coda-6.0.2 distribution,
NetBSD (drochner) (CODA_COMPAT_5 option).
of what uart(4) is and/or is not see the initial commit log of one
of the files in sys/dev/uart (or see share/man/man4/uart.4).
Note that currently pc98 shares the MD file with i386. This needs
to change when pc98 support is fleshed-out to properly support the
various UARTs. A good example is sparc64 in this respect.
We build uart(4) as a module on all platforms. This may break
the ppc port. That depends on whether they do actually build
modules.
To use uart(4) on alpha, one must use the NO_SIO option.
it attaches to all existing NATM network interfaces in the system
and creates a HARP physical interface for each of them. This allows
us to use the same set of ATM drivers for all ATM stuff. It is
possible to use the same interface for HARP, NATM and netgraph at the
same time.
with a ProATM-155 and an IDT evaluation board and should also work
with a ProATM-25 (it seems to work at least, I cannot really measure
what the card emits). The driver has been tested on i386 and sparc64,
but should work an other archs also. It supports UBR, CBR, ABR and VBR;
AAL0, AAL5 and AALraw. As an additional feature VCI/VPI 0/0 can be
opened for receiving in AALraw mode and receives all cells not claimed
by other open VCs (even cells with invalid GFC, VPI and VCI fields and
OAM cells).
Thanks to Christian Bucari from ProSum for lending two cards and answering
my questions.
large to huge amounts of small or medium sized receive buffers. The problem
with these situations is that they eat up the available DMA address space
very quickly when using mbufs or even mbuf clusters. Additionally this
facility provides a direct mapping between 32-bit integers and these buffers.
This is needed for devices originally designed for 32-bit systems. Ususally
the virtual address of the buffer is used as a handle to find the buffer as
soon as it is returned by the card. This does not work for 64-bit machines
and hence this mapping is needed.
build it on the i386 and alpha architectures, where this has been
set up (there is also a sparc64-bitops.h in sys/gnu/ext2fs, but it
appears to be broken and it is not linked up).
This should unbreak the sparc64 LINT build.
built by LINT. Also override a number of knobs for enabling and
disabling various modules in the ALL_MODULES case to further increase
LINT's module coverage.
Submitted by: ru
on friday 13th and without making a universe). This adds struct and
constant definitions for ATM traffic parameters and re-enables the
build of the midway driver.
Tested by: make universe
from the tree until it is fixed. Since it is an atm driver, it isn't
commonly used so this will not negatively impact too many people.
harti can reconnect it when he resurfaces and corrects the en module
problems. This should allow snapshots to start succeeding again.
Reported by: lots of people
It currently supports the PMC Sierra Lite, Ultra and 622 chips and
the IDT 77105. The driver handles media options and state in a consistent
manner for ATM drivers. The next commit to the midway driver will make
it use utopia.
following changes have been done:
- stylify. The original code was too hard to read.
- get rid of a number of compilation options (Adaptec-only, Eni-only, no-DMA).
- more debugging features.
- locking. This is not correct yet in the absence of interface layer locking,
but is correct enough to not to cause lock order reversals.
- remove RAW mode. There are no users of this in the tree and I doubt that
there are any.
- remove NetBSD compatibility code. There was no way to keep NetBSD non-busdma
and FreeBSD busdma code together.
- if_en now buildable as a module.
This has been actively tested on sparc64 and i386 with ENI server and
client cards and an Adaptec card (thanks to kjc).
Reviewed by: mdodd, arr
ethernet controller. The driver has been tested with the LinkSys
USB200M adapter. I know for a fact that there are other devices out
there with this chip but don't have all the USB vendor/device IDs.
Note: I'm not sure if this will force the driver to end up in the
install kernel image or not. Special magic needs to be done to exclude
it to keep the boot floppies from bloating again, someone please
advise.