COMPAT_LINUX are there. It shouldn't be and isn't used after config
time, except to complicate the svr4 module makefile.
Moved options for emulators to a separate section.
-U_KERNEL became negative when all all the genassym.c's were converted
to be cross-built. Related cleanups: PARAM went away, but was still
used here; KERNEL was renamed to _KERNEL, but was still KERNEL here;
the deprecated macros $@ and $< were still used here.
Use "genassym ... > ${.TARGET}", not "genassym -o $@ ...", so that
genassym(1) doesn't need to support -o.
Removed half-baked hard-coded dependencies of *_genassym.o on headers.
These objects should be added to the list of objects in the depend
rule to get full dependencies. This doesn't happen automatically
because they are not linked into the kernel. Half baked dependencies
don't really help.
the misleading comments to that effect.
Prune bogus 'at foo?' (smbus, iicbus, ppbus) appendages on things that
they are meaningless for. It was just eye candy and wasn't used by
anything in the tree. The interconnects were defined by the drivers
themselves and auto discovery.
(The new ppbus code may change this if it uses the resource_get_*() calls
to find it's configured children if self discovery isn't possible)
it's always true on these platforms (and is likely to be on others as
well since loader is the one that is configured for whatever the boot
requirements are)
${GEN_CFLAGS} and -U_KERNEL became negative when all all the
genassym.c's were converted to be cross-built.
Makefile.*:
- Cleanups associated with the old genassym.
- Fixed deprecated spelling of ${.IMPSRC} as "$<".
ethernet adapters that are supported by the aue and kue drivers.
There are actually a couple more out there from Accton, Asante and
EXP Computer, however I was not able to find any Windows device
drivers for these on their servers, and hence could not harvest
their vendor/device ID info. If somebody has one of these things
and can look in the .inf file that comes with the Windows driver,
I'd appreciate knowing what it says for 'VID' and 'PID.'
Additional adapters include: the D-Link DSB-650 and DSB-650TX, the
SMC 2102USB, 2104USB and 2202USB, the ATen UC10T, and the Netgear EA101.
These are all mentioned in the man pages, relnotes and LINT.
Also correct the date in the kue(4) man page. I wrote this thing
on Jan, 4 2000, not 1999.
Kawasaki LSI KL5KUSB101B chip, including the LinkSys USB10T, the
Entrega NET-USB-E45, the Peracom USB Ethernet Adapter, the 3Com
3c19250 and the ADS Technologies USB-10BT. This device is 10mbs
half-duplex only, so there's miibus or ifmedia support. This device
also requires firmware to be loaded into it, however KLSI allows
redistribution of the firmware images (I specifically asked about
this; they said it was ok).
Special thanks to Annelise Anderson for getting me in touch with
KLSI (eventually) and thanks to KLSI for providing the necessary
programming info.
Highlights:
- Add driver files to /sys/dev/usb
- update usbdevs and regenerate attendate files
- update usb_quirks.c
- Update HARDWARE.TXT and RELNOTES.TXT for i386 and alpha
- Update LINT, GENERIC and others for i386, alpha and pc98
- Add man page
- Add module
- Update sysinstall and userconfig.c
is an application space macro and the applications are supposed to be free
to use it as they please (but cannot). This is consistant with the other
BSD's who made this change quite some time ago. More commits to come.
USB ethernet chip. Adapters that use this chip include the LinkSys
USB100TX. There are a few others, but I'm not certain of their
availability in the U.S. I used an ADMtek eval board for development.
Note that while the ADMtek chip is a 100Mbps device, you can't really
get 100Mbps speeds over USB. Regardless, this driver uses miibus to
allow speed and duplex mode selection as well as autonegotiation.
Building and kldloading the driver as a module is also supported.
Note that in order to make this driver work, I had to make what some
may consider an ugly hack to sys/dev/usb/usbdi.c. The usbd_transfer()
function will use tsleep() for synchronous transfers that don't complete
right away. This is a problem since there are times when we need to
do sync transfers from an interrupt context (i.e. when reading registers
from the MAC via the control endpoint), where tsleep() us a no-no.
My hack allows the driver to have the code poll for transfer completion
subject to the xfer->timeout timeout rather that calling tsleep().
This hack is controlled by a quirk entry and is only enabled for the
ADMtek device.
Now, I'm sure there are a few of you out there ready to jump on me
and suggest some other approach that doesn't involve a busy wait. The
only solution that might work is to handle the interrupts in a kernel
thread, where you may have something resembling a process context that
makes it okay to tsleep(). This is lovely, except we don't have any
mechanism like that now, and I'm not about to implement such a thing
myself since it's beyond the scope of driver development. (Translation:
I'll be damned if I know how to do it.) If FreeBSD ever aquires such
a mechanism, I'll be glad to revisit the driver to take advantage of
it. In the meantime, I settled for what I perceived to be the solution
that involved the least amount of code changes. In general, the hit
is pretty light.
Also note that my only USB test box has a UHCI controller: I haven't
I don't have a machine with an OHCI controller available.
Highlights:
- Updated usb_quirks.* to add UQ_NO_TSLEEP quirk for ADMtek part.
- Updated usbdevs and regenerated generated files
- Updated HARDWARE.TXT and RELNOTES.TXT files
- Updated sysinstall/device.c and userconfig.c
- Updated kernel configs -- device aue0 is commented out by default
- Updated /sys/conf/files
- Added new kld module directory
Fixed some style bugs (always use precisely 1 space after `:' in
dependency specifications).
Removed bogus dependency of ${FULLKERNEL} on ${BEFORE_DEPEND}.
pr_input() routines prototype is also changed to support IPSEC and IPV6
chained protocol headers.
Reviewed by: freebsd-arch, cvs-committers
Obtained from: KAME project
now. On one machine with <825a> and <875> controllers, `sym' correctly
attached. On another one with only a <ncr 53c810 fast10 scsi>, the `ncr'
driver correctly attached.
3.3R and then to -current. The pccard support has been left in the
driver, but is presently non-functional because we are using the
isa_compat layer for the moment.
Obtained From: PAO
Sponsored by: Timing Solutions
kernel builds so as not to confuse with perl4 when bootstrapping from old
systems. I don't know if this is still applicable but it shouldn't hurt
to be consistant at least.
Also copy vnode_if.sh to vnode_if.pl. Doing a 'sh vnode_if.sh' when it
was a perl script was kinda silly.
the kernel while the vnode_if.h header is a bunch of inlines to call the
code that is in the kernel. Generating the .h file on the fly is kinda
bogus because it has to match the one compiled into the kernel.
IMHO we should have kern/vnode_if.c and sys/vnode_if.h committed in the
tree but that's another battle.
These drivers were cloned from the ed and ep drivers back in 1994
when PCMCIA cards were a very new thing and we had no other support
for such devices. They treated the PCIC (the chip which controls the
PCCARD slot) as part of their device and generally hacked their way
to success. They have significantly bit-rotted relative to their
ancestor drivers (ed & ep) and they were a dead-end on the evolution
path to proper PCCARD support in FreeBSD.
They have been terminally broken since August 18 where mdodd forgot
them and nobody seems to have missed them enough to fix them since.
I found no outstanding PRs against these drivers.
packet divert at kernel for IPv6/IPv4 translater daemon
This includes queue related patch submitted by jburkhol@home.com.
Submitted by: queue related patch from jburkhol@home.com
Reviewed by: freebsd-arch, cvs-committers
Obtained from: KAME project
which it replaces. The new driver supports all of the chips supported
by the ones it replaces, as well as many DEC/Intel 21143 10/100 cards.
This also completes my quest to convert things to miibus and add
Alpha support.
mention of the various devices that are supported.
Add some text and entry to LINT for 'controller mca0'.
I'd like to turn this option on in GENERIC as well as it
isn't impacting and has a small footprint.
* Bring source file references in line with the style used in
GENERIC (i.e. src/sys/...).
* Update outdated source file references.
* Use proper URL syntax for URLs.
* Update outdated URLs.
PR: 15194
Submitted by: jedgar@fxp.org (Chris D. Faulhaber)
(kern.randompid), which is currently defaulted off. Use ARC4 (RC4) for our
random number generation, which will not get me executed for violating
crypto laws; a Good Thing(tm).
Reviewed and Approved by: bde, imp
Add MD_ROOT and MD_ROOT_SIZE options to the md driver.
Make the md driver handle MFS_ROOT and MFS_ROOT_SIZE options for compatibility.
Add md driver to GENERIC, PCCARD and LINT.
This is a cleanup which removes the need for some of the worse hacks in
MFS: We really want to have a rootvnode but MFS on a preloaded image
doesn't really have one. md is a true device, so it is less trouble.
This has been tested with make release, and if people remember to add
the "md" pseudo-device to their kernels, PicoBSD should be just fine
as well. If people have no other use for MFS, it can be removed from
the kernel.
- Convert to new bus attachment scheme. Thanks to Blaz Zupan for doing
the initial work here. One thing I changed was to have the attach
and detach routines work like the PCI drivers, which means that in
theory you should be able to load and unload the driver like the PCI
NIC drivers, however the pccard support for this hasn't settled down
yet so it doesn't quite work. Once the pccard work is done, I'll have
to revisit this.
- Add device wi0 to PCCARD. If we're lucky, people should be able to
install via their WaveLAN cards now.
- Add support for signal strength caching. The wicontrol utility has
also been updated to allow zeroing and displaying the signal strength
cache.
- Add a /sys/modules/wi directory and fix a Makefile to builf if_wi.ko.
Currently this module is only built for the i386 platform, though once
the pccard stuff is done it should be able to work on the alpha too.
(Theoretically you should be able to plug one of the WaveLAN/IEEE ISA
cards into an alpha with an ISA slot, but we'll see how that turns out.
- Update LINT to use only device wi0. There is no true ISA version of
the WaveLAN/IEEE so we'll never use an ISA attachment.
- Update files.i386 so that if_wi is dependent on card.
Semiconductor CS461x/428x.
- Add support for GUS and CS461x/428x pcm.
- Move newpcm drivers for ISA cards to files.i386. The drivers for
PC98 would be something quite different from those for PC/AT.
Moving requested by: nyan
for IPv6 yet)
With this patch, you can assigne IPv6 addr automatically, and can reply to
IPv6 ping.
Reviewed by: freebsd-arch, cvs-committers
Obtained from: KAME project
o Delete pcic1 from NEWCARD
o Add explicit resource hints to pcic0
o Get attach working with newbus, kinda (it does all the newbus stuff,
but doesn't try to attach the pccard yet, too many panics).
o Disable ie0 and le0 in NEWCARD config. There appears to be a bug in
the isa_compat code wrt memory conflicts with newbus drivers for
reasons unknown.
o Minor cleanups.
that breaks if you try and compile a kernel before building world, as
is presently required to get past the signal changes. I don't
particularly like doing this, but at least it will mean that a 'make world'
will activate the gcc 2.95.2-specific option in bsd.kern.mk.
Document the options available for the ata driver.
Disconnect the atapi devices from the old wd driver to avoid conflicts
(they will go away at some point anyways)
* GC unused options
* Move options that exist on all architectures to conf/options
* Add missing options to LINT
* Sort undocumented options list in LINT
Reviewed by: green
only two conflicts, cdev #98 and cdev #99. These should be fixed.
MAKEDEV should probably be merged as well.
Static majors are (hopefully) going away one day soon.
This file is informational and not machine parsed by anything any more.
to config(8) for static device tables that have not existed for quite
some time. They have been aliases for 'device' for a while, and "tape"
went away entirely as it wasn't used anywhere (except in an example
in LINT.. "fixed").
(yet) compile and link. Renamed pcic back to pcic from pcicx, but
conditionalize its inclusion on pccard being included also. card is
the old and pccard is the new, which is a handy way to have both in
the tree at the same time.
Obtained from: newconfig project
More to follow...
o Gut the compatibility interface, you now must attach with newbus.
o Unit numbers from pccardd are now ignored. This may change the units
assigned to a card. It now uses the first available unit.
o kill old skeleton code that is now obsolete.
o Use newbus attachment code.
o cleanup interfile dependencies some.
o kill list of devices per slot. we use the device tree for what we need.
o Remove now obsolete code.
o The ep driver (and maybe ed) may need some config file tweaks to
allow it to attach. See config files that were committed for examples
on how to do this.
Drivers to be commited shortly.
This is an interrum fix until the new pccard. ed, ep and sio will be
supported by me with this release, although others are welcome to try
to support other devices before new pccard is working.
I plan on doing minimal further work on this code base. Be careful
when upgrading, since this code is known to work on my laptop and
those of a couple others as well, but your milage may vary.
BUGS TO BE FIXED:
o system memory isn't allocated yet, it will be soon.
o No devices actually have a pccard newbus attach in the tree.
BUGS THAT MIGHT BE FIXED:
o card removal, including suspend, usually hangs the system.
Many thanks to Peter Wemm and Doug Rabson for helping me to fill in
the missing bits of New Bus understanding at FreeBSD Con '99.
revision 1.21
date: 1999/10/15 17:29:20; author: imp; state: Exp; lines: +3 -3
Reorganize the attachement point for pcic (it was unattached and
floating before). Attach pccard devices to pcic, one per slot
(although this may change to one per pcic). pcic is now attached to
isa (to act as a bridge) and pccard is attached to pcic, cbb and
pc98ic (the last two are card bus bridge and the pc98ic version of
pcic, neither of which are in the tree yet). Move pccard compat code
into pccard/pccard_compat.c.
THIS REQUIRES A CONFIG FILE CHANGE. You must change your pcic/card
entries to be:
# PCCARD (PCMCIA) support
controller pcic0 at isa?
controller pcic1 at isa?
controller card0
The old system was upside down and this corrects that problem. It
will make it easier to add support for YENTA pccard/card bus bridges.
Much more cleanup needs to happen before newbus devices can have
pccard attachments. My previous commit's comments were premature.
Forgotten by: imp
Been in production for 3 years now. Gives Instant Frame relay to if_sr
and if_ar drivers, and PPPOE support soon. See:
ftp://ftp.whistle.com/pub/archie/netgraph/index.html
for on-line manual pages.
Reviewed by: Doug Rabson (dfr@freebsd.org)
Obtained from: Whistle CVS tree
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.
floating before). Attach pccard devices to pcic, one per slot
(although this may change to one per pcic). pcic is now attached to
isa (to act as a bridge) and pccard is attached to pcic, cbb and
pc98ic (the last two are card bus bridge and the pc98ic version of
pcic, neither of which are in the tree yet). Move pccard compat code
into pccard/pccard_compat.c.
THIS REQUIRES A CONFIG FILE CHANGE. You must change your pcic/card
entries to be:
# PCCARD (PCMCIA) support
controller pcic0 at isa?
controller pcic1 at isa?
controller card0
The old system was upside down and this corrects that problem. It
will make it easier to add support for YENTA pccard/card bus bridges.
Much more cleanup needs to happen before newbus devices can have
pccard attachments. My previous commit's comments were premature.
now lives in the respective bus front end files.
- Add various function prototypes to if_edvar.h
- Clean up some debugging code that snuck into if_ed_isa.c
- Turn on the right bits in files.i386
kernel, but gcc provides a pessimal builtin for it.
Makefile.i386:
Added a variable (CONF_CFLAGS) for configuration-specific compiler flags.
LINT:
Use CONF_CFLAGS to inhibit use of gcc builtins.
Turn on the 'new' if_ep driver which supports:
ISA 3c509
MCA 3c529
EISA 3c579
PCCARD 3c589
I think all we're missing is support for the VME bus and S-100 bus
Etherlink III cards.
The new code has been tested by a number of people and all the important
bits work. I've not been able to test the EISA code but will do so once
my hardware arrives. Since I've changed nothing in the EISA code I suspect
it will perform the same manner as before.
Future changes involve whacking the ISA and PCCARD front ends to use
newbus and to convert the driver to bus_space and make it use ifmedia.
This is the first working network driver that supports MCA bus devices btw.
Enjoy.
be set by a kernel conf option due to the struct buf structural
dependancy (sizing of b_pages[]) creating a conflict with modules
(which are not compiled with kernel config options overrides).
We'll be able to sysctl these two later on when the buffer subsystem
is revamped.
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.
It is about 2.5 microseconds or roughly 3 times faster to use this
"PIIX" timecounter than the "i8254" timecounter. Resolution is
also 3 times better.
The code cheats and don't register the PCI device, because other pieces
of code want to use it too.
Originally spotted by: msmith
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.
a quick think and discussion among various people some form of some of
these changes will probably be recommitted.
The reversion requested was requested by dg while discussions proceed.
PHK has indicated that he can live with this, and it has been agreed
that some form of some of these changes may return shortly after further
discussion.
new system is integrated with the ISA bus code more cleanly and allows
the future addition of more enumerators such as PnPBIOS and ACPI.
This commit also enables the new pcm driver since it is somewhat tied to
the new PnP code.
the highly non-recommended option ALLOW_BDEV_ACCESS is used.
(bdev access is evil because you don't get write errors reported.)
Kill si_bsize_best before it kills Matt :-)
Use the specfs routines rather having cloned copies in devfs.
UMAPFS_DIAGNOSTIC and UNION_DIAGNOSTIC. Uncommented NULLFS_DIAGNOSTIC.
It is as bogus as the above three but since it is already a new-style
option it is easier to use it than to fix it.
discussed on current.
The following variables are defined (for now):
osname (defaults to "Linux")
Allow users to change the name of the OS as returned by uname(2),
specially added for all those Linux Netscape users and statistics
maniacs :-) We now have what we all wanted!
osrelease (defaults to "2.2.5")
Allow users to change the version of the OS as returned by uname(2).
Since -current supports glibc2.1 now, change the default to 2.2.5
(was 2.0.36).
oss_version (defaults to 198144 [0x030600])
This one will be used by the OSS_GETVERSION ioctl (PR 12917) which I
can commit now that we have the MIB. The default version number is the
lowest version possible with the current 'encoding'.
A note about imprisoned processes (see jail(2)):
These variables are copy-on-write (as suggested by phk). This means that
imprisoned processes will use the system wide value unless it is written/set
by the process. From that moment on, a copy local to the prison will be
used.
A note about the implementation:
I choose to add a single pointer to struct prison, because I didn't like the
idea of changing struct prison every time I come up with a new variable. As
a side effect, the extra storage is only needed when a variable is set from
within the prison. This also minimizes kernel bloat when the Linuxulator is
not used; both compiled in or as a module.
Reviewed by: bde (first version only) and phk
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.
MII-compliant PHY drivers. Many 10/100 ethernet NICs available today
either use an MII transceiver or have built-in transceivers that can
be programmed using an MII interface. It makes sense then to separate
this support out into common code instead of duplicating it in all
of the NIC drivers. The mii code also handles all of the media
detection, selection and reporting via the ifmedia interface.
This is basically the same code from NetBSD's /sys/dev/mii, except
it's been adapted to FreeBSD's bus architecture. The advantage to this
is that it automatically allows everything to be turned into a
loadable module. There are some common functions for use in drivers
once an miibus has been attached (mii_mediachg(), mii_pollstat(),
mii_tick()) as well as individual PHY drivers. There is also a
generic driver for all PHYs that aren't handled by a specific driver.
It's possible to do this because all 10/100 PHYs implement the same
general register set in addition to their vendor-specific register
sets, so for the most part you can use one driver for pretty much
any PHY. There are a couple of oddball exceptions though, hence
the need to have specific drivers.
There are two layers: the generic "miibus" layer and the PHY driver
layer. The drivers are child devices of "miibus" and the "miibus" is
a child of a given NIC driver. The "miibus" code and the PHY drivers
can actually be compiled and kldoaded as completely separate modules
or compiled together into one module. For the moment I'm using the
latter approach since the code is relatively small.
Currently there are only three PHY drivers here: the generic driver,
the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding
others later as I convert various NIC drivers to use this code.
I realize that I'm cvs adding this stuff instead of importing it
onto a separate vendor branch, but in my opinion the import approach
doesn't really offer any significant advantage: I'm going to be
maintaining this stuff and writing my own PHY drivers one way or
the other.
- increase the default timeout from 10 seconds to 60 seconds
- add a new kernel option, SCSI_PT_DEFAULT_TIMEOUT, that lets users specify
the default timeout for the pt driver to use
- add two new ioctls, one to get the timeout for a given pt device, the
other to set the timeout for a given pt device. The idea is that
userland applications using the device can set the timeout to suit their
purposes. The ioctls are defined in a new header file, sys/ptio.h
PR: 10266
Reviewed by: gibbs, joerg
that goes to opt_dontuse.h is so an opt_*.h file doesn't get created even
though an option may be used for bringing stuff in via files[.*].
Pointed out by: bde
that are linked into the kernel. The KLD compilation options are
changed to call these functions, rather than in-lining the
atomic operations.
This approach makes atomic operations from KLDs significantly
faster on UP systems (though somewhat slower on SMP systems).
PR: i386/13111
Submitted by: peter.jeremy@alcatel.com.au
we create the pty on the fly when it is first opened.
If you run out of ptys now, just MAKEDEV some more.
This also demonstrate the use of dev_t->si_tty_tty and dev_t->si_drv1
in a device driver.
of 2 weeks ago that this be done, and anyone who wishes to make bpf more
selective according to securelevel or compile-time options is more
than free to do so.
- Add support for calling 32-bit code in other segments
- Add support for calling 16-bit protected mode code
Update APM to use this facility.
Submitted by: jlemon
macros) to the signal handler, for old-style BSD signal handlers as
the second (int) argument, for SA_SIGINFO signal handlers as
siginfo_t->si_code. This is source-compatible with Solaris, except
that we have no <siginfo.h> (which isn't even mentioned in POSIX
1003.1b).
An rather complete example program is at
http://www3.cons.org/cracauer/freebsd-signal.c
This will be added to the regression tests in src/.
This commit also adds code to disable the (hardware) FPU from
userconfig, so that you can use a software FP emulator on a machine
that has hardware floating point. See LINT.
ethernet controllers based on the AIC-6915 "Starfire" controller chip.
There are single port, dual port and quad port cards, plus one 100baseFX
card. All are 64-bit PCI devices, except one single port model.
The Starfire would be a very nice chip were it not for the fact that
receive buffers have to be longword aligned. This requires buffer
copying in order to achieve proper payload alignment on the alpha.
Payload alignment is enforced on both the alpha and x86 platforms.
The Starfire has several different DMA descriptor formats and transfer
mechanisms. This driver uses frame descriptors for transmission which
can address up to 14 packet fragments, and a single fragment descriptor
for receive. It also uses the producer/consumer model and completion
queues for both transmit and receive. The transmit ring has 128
descriptors and the receive ring has 256.
This driver supports both FreeBSD/i386 and FreeBSD/alpha, and uses newbus
so that it can be compiled as a loadable kernel module. Support for BPF
and hardware multicast filtering is included.
gigabit ethernet adapters. This includes two single port cards
(single mode and multimode fiber) and two dual port cards (also single
mode and multimode fiber). SysKonnect is currently the only
vendor with a dual port gigabit ethernet NIC.
The ports on dual port adapters are treated as separate network
interfaces. Thus, if you have an SK-9844 dual port SX card, you
should have both sk0 and sk1 interfaces attached. Dual port cards
are implemented using two XMAC II chips connected to a single
SysKonnect GEnesis controller. Hence, dual port cards are really
one PCI device, as opposed to two separate PCI devices connected
through a PCI to PCI bridge. Note that SysKonnect's drivers use
the two ports for failover purposes rather that as two separate
interfaces, plus they don't support jumbo frames. This applies to
their Linux driver too. :)
Support is provided for hardware multicast filtering, BPF and
jumbo frames. The SysKonnect cards support TCP checksum offload
however this feature is not currently enabled (hopefully it will
be once we get checksum offload support).
There are still a few things that need to be implemeted, like
the ability to communicate with the on-board LM80 voltage/temperature
monitor, but I wanted to get the driver under CVS control and into
-current so people could bang on it.
A big thanks for SysKonnect for making all their programming info
for these cards (and for their FDDI and token ring cards) available
without NDA (see www.syskonnect.com).
On the VAX, it used to be used for special compilation to avoid the
optimizer which would mess with memory mapped devices etc. These days
we use 'volatile'.
- Split syscons source code into manageable chunks and reorganize
some of complicated functions.
- Many static variables are moved to the softc structure.
- Added a new key function, PREV. When this key is pressed, the vty
immediately before the current vty will become foreground. Analogue
to PREV, which is usually assigned to the PrntScrn key.
PR: kern/10113
Submitted by: Christian Weisgerber <naddy@mips.rhein-neckar.de>
- Modified the kernel console input function sccngetc() so that it
handles function keys properly.
- Reorganized the screen update routine.
- VT switching code is reorganized. It now should be slightly more
robust than before.
- Added the DEVICE_RESUME function so that syscons no longer hooks the
APM resume event directly.
- New kernel configuration options: SC_NO_CUTPASTE, SC_NO_FONT_LOADING,
SC_NO_HISTORY and SC_NO_SYSMOUSE.
Various parts of syscons can be omitted so that the kernel size is
reduced.
SC_PIXEL_MODE
Made the VESA 800x600 mode an option, rather than a standard part of
syscons.
SC_DISABLE_DDBKEY
Disables the `debug' key combination.
SC_ALT_MOUSE_IMAGE
Inverse the character cell at the mouse cursor position in the text
console, rather than drawing an arrow on the screen.
Submitted by: Nick Hibma (n_hibma@FreeBSD.ORG)
SC_DFLT_FONT
makeoptions "SC_DFLT_FONT=_font_name_"
Include the named font as the default font of syscons. 16-line,
14-line and 8-line font data will be compiled in. This option replaces
the existing STD8X16FONT option, which loads 16-line font data only.
- The VGA driver is split into /sys/dev/fb/vga.c and /sys/isa/vga_isa.c.
- The video driver provides a set of ioctl commands to manipulate the
frame buffer.
- New kernel configuration option: VGA_WIDTH90
Enables 90 column modes: 90x25, 90x30, 90x43, 90x50, 90x60. These
modes are mot always supported by the video card.
PR: i386/7510
Submitted by: kbyanc@freedomnet.com and alexv@sui.gda.itesm.mx.
- The header file machine/console.h is reorganized; its contents is now
split into sys/fbio.h, sys/kbio.h (a new file) and sys/consio.h
(another new file). machine/console.h is still maintained for
compatibility reasons.
- Kernel console selection/installation routines are fixed and
slightly rebumped so that it should now be possible to switch between
the interanl kernel console (sc or vt) and a remote kernel console
(sio) again, as it was in 2.x, 3.0 and 3.1.
- Screen savers and splash screen decoders
Because of the header file reorganization described above, screen
savers and splash screen decoders are slightly modified. After this
update, /sys/modules/syscons/saver.h is no longer necessary and is
removed.
This is tested, but I really can't say whether it works entirely. I
don't know exactly what to look for when testing it. So let's say this
is open for testing. Send any results to green@FreeBSD.org
Reviewed by: msmith (long ago)
ADMtek AL981 "Comet" chipset. The AL981 is yet another DEC tulip clone,
except with simpler receive filter options. The AL981 has a built-in
transceiver, power management support, wake on LAN and flow control.
This chip performs extremely well; it's on par with the ASIX chipset
in terms of speed, which is pretty good (it can do 11.5MB/sec with TCP
easily).
I would have committed this driver sooner, except I ran into one problem
with the AL981 that required a workaround. When the chip is transmitting
at full speed, it will sometimes wedge if you queue a series of packets
that wrap from the end of the transmit descriptor list back to the
beginning. I can't explain why this happens, and none of the other tulip
clones behave this way. The workaround this is to just watch for the end
of the transmit ring and make sure that al_start() breaks out of its
packet queuing loop and waiting until the current batch of transmissions
completes before wrapping back to the start of the ring. Fortunately, this
does not significantly impact transmit performance.
This is one of those things that takes weeks of analysis just to come
up with two or three lines of code changes.
Implement priorities.
GENERIC, LINT, files:
Remove remarks about ordering of device names.
GENERIC, LINT:
Sort the devices alphabetically in LINT and GENERIC.
A very nice i/o board with 16 open collector outputs (capable of driving 5-40v)
and 16 inputs
Also has 2 16 bit cascadable counters (10Mhz clock) capable of
generating interrupts.
It is a PCI card, and emulates the Intel 8254 timer.
It uses the PLX PCI-9050 PCI bus interface to map the
8254 style hardware and the i/o registers into the IO space.
Developed by Jennifer Clark <jen@vulture.dmem.strath.ac.uk>
Strathclyde University Transparent Telepresence Research Group
a pointer to 'makeoptions' and /etc/make.conf.
Catch a few stray "kernel" hardcoded references.
Move the kernel.debug and related kernel build rules together.
directly into the Makefile. Remove references to swapkernel.c, it's
not generated by config(8) now. (The previous config commits had
generated it, but they had an unused 'char *' in them).
config kernel mumble mumble
line has been obsoleted and removed and with it went all knowledge of
devices on the part of config.
You can still configure a root device (which is used if you give
the "-r" flag) but now with an option:
options ROOTDEVNAME=\"da0s2e\"
The string is parsed by the same code as at the "boot -a" prompt.
At the same time, make the "boot -a" prompt both more able and more
informative.
ALPHA/PC98 people: You will have to adapt a few simple changes
(defining rootdev and dumpdev somewhere else) before config works
for you again, sorry, but it's all in the name of progress.
development that leads to lots of crashes during boot.
I have made a 'reinstall' target (like in ports, and reinstall.debug)
This is most useful if you want to keep /kernel.old as a known bootable
kernel. If you test a new kernel and have to reboot for a fix, a
'make reinstall' will install the new kernel over the top of the old
non-viable one, leaving the old one untouched. This is mainly meant
for development, not general users.
adapter (and some workalikes). Also add man pages and a wicontrol
utility to manipulate some of the card parameters.
This driver was written using information gleaned from the Lucent HCF Light
library, though it does not use any of the HCF Light code itself, mainly
because it's contaminated by the GPL (but also because it's pretty gross).
The HCF Light lacks certain featurs from the full (but proprietary) HCF
library, including 802.11 frame encapsulation support, however it has
just enough register information about the Hermes chip to allow someone
with enough spare time and energy to implement a proper driver. (I would
have prefered getting my hands on the Hermes manual, but that's proprietary
too. For those who are wondering, the Linux driver uses the proprietary
HCF library, but it's provided in object code form only.)
Note that I do not have access to a WavePOINT access point, so I have
only been able to test ad-hoc mode. The wicontrol utility can turn on
BSS mode, but I don't know for certain that the NIC will associate with
an access point correctly. Testers are encouraged to send their results
to me so that I can find out if I screwed up or not.
i386 platform boots, it is no longer ISA-centric, and is fully dynamic.
Most old drivers compile and run without modification via 'compatability
shims' to enable a smoother transition. eisa, isapnp and pccard* are
not yet using the new resource manager. Once fully converted, all drivers
will be loadable, including PCI and ISA.
(Some other changes appear to have snuck in, including a port of Soren's
ATA driver to the Alpha. Soren, back this out if you need to.)
This is a checkpoint of work-in-progress, but is quite functional.
The bulk of the work was done over the last few years by Doug Rabson and
Garrett Wollman.
Approved by: core
only worked for configurations with "swap on generic".
usr.sbin/config/config.y:
- ignore all "swap [on] device ...' specifications except for
warning about them. They haven't done anything related to swap
for almost 4 years, and were previously silently ignored,
except for "swap on generic" which stopped swap${KERNEL}.c
from being generated. Code to support swapping is now deader
than before.
usr.sbin/config/mkswapconf.c:
- don't generate a dummy setconf() function in swap${KERNEL}.c.
sys/i386/conf/files.i386:
- swapgeneric.c is now standard. It should be merged into autoconf.c
so that it doesn't conflict with swap${KERNEL}.c for kernels named
"generic".
sys/i386/i386/autoconf.c:
- don't call setroot() for mfs roots. Since setroot() doesn't do anything
harmful, this was just a waste of time, except possibly for booting with
-a it may have helped prevent an undesireable call to setconf() by
finding a bogus rootdev.
- honor -a for ffs roots. -a now overrides all other ways of specifying
the root device. Previously, -r had precedence over -a, and the -a
handling was usually a no-op.
- don't honor -a for non-ffs roots, since it would currently just get in
the way of a clean panic.
sys/i386/i386/swapgeneric.c:
- don't declare things that are now always declared in swap${KERNEL}.c.
Don't decide things that are now decided in autoconf.c. Code to
support the "generic" case is now dead instead of useless.
perform a cleanup/unifdef sweep over it to tidy things up. The atapi
code is permanently attached to the wd driver and is always probed.
I will add an extra option bit in the flags to disable an atapi probe on
either the master or slave if needed, if people want this.
Remember, this driver is destined to die some time. It's possible that
it will loose all atapi support down the track and only be used for
dumb non-ATA disks and all ata/atapi devices will be handled by the new
ata system.
ATAPI, ATAPI_STATIC and CMD640 are no longer options, all are implicit.
Previously discussed with: sos
Sense ${DEBUG} to decide on building kernel.debug or not.
Use a common install and install.debug target to minimize duplication.
(I deleted the ELF transition kernel warning, it was getting dated..)
Requested-by: ache
bde
dg
Modify targets for debug kernels: when -g was specified, make will
now build a debug kernel called kernel.debug, and create a stripped
version called kernel at the same time. The two targets install and
install.debug are otherwise unchanged.
Requested-by: dillon
Update man page accordingly.
2. Config complains if you use -g:
Debugging is enabled by default, there is no ned to specify the -g option
3. Config warns you if you don't use -s:
Building kernel with full debugging symbols. Do
"config -s BSD" for historic partial symbolic support.
To install the debugging kernel, do make install.debug
(BSD was the name of the config file I used; I print out the same
name).
4. Modify Makefile.i386, Makefile.alpha, Makefile.pc98 and config to
work if a kernel name other than 'kernel' is specified. This is
not absolutely necessary, but useful, and it was relatively easy.
I now have a kernel called /crapshit :-)
5. Modify Makefile.i386, Makefile.alpha, Makefile.pc98 "clean" target
to remove both the debug and normal kernel.
6. Modify all to install the stripped kernel by default and the debug
kernel if you enter "make install.debug".
7. Update version number of Makefiles and config.
Networks Tigon 1 and Tigon 2 chipsets. There are a _lot_ of OEM'ed
gigabit ethernet adapters out there which use the Alteon chipset so
this driver covers a fair amount of hardware. I know that it works with
the Alteon AceNIC, 3Com 3c985 and Netgear GA620, however it should also
work with the DEC/Compaq EtherWORKS 1000, Silicon Graphics Gigabit
ethernet board, NEC Gigabit Ethernet board and maybe even the IBM and
and Sun boards. The Netgear board is the cheapest (~$350US) but still
yields fairly good performance.
Support is provided for jumbo frames with all adapters (just set the
MTU to something larger than 1500 bytes), as well as hardware multicast
filtering and vlan tagging (in conjunction with the vlan support in
-current, which I should merge into -stable soon). There are some hooks
for checksum offload support, but they're turned off for now since
FreeBSD doesn't have an officially sanctioned way to support checksum
offloading (yet).
I have not added the 'device ti0' entry to GENERIC since the driver
with all the firmware compiled in is quite large, and it doesn't really
fit into the category of generic hardware.
Well, better late than newer, but things has been hectic
around here, sorry for the long delay.
DMA support has been added to the ATA disk driver.
This only works on Intel PIIX3/4, Acer Aladdin and Promise controllers.
The promise support works without the BIOS on the board,
and timing modes are set to support up to UDMA speed. This
solves the problems with having more than one promise controller
in the same system.
There is support for "generic" DMA, that might work on other
controllers, but now you have been warned :)
More chipset specific code will come soon, I have to find testers
with the approbiate HW, more on that when I have it ready.
The system now uses its own major numbers, please run MAKEDEV
with the devices you need (ad?, acd?, afd?, ast?).
For now the disk driver will also attach to the old wd major
so one can at least boot without this step, but be warned, this
will eventually go away. The bootblocks will have to be changed
before one can boot directly from an "ad" device though.
Fixed problems:
All known hang problems should be solved
The probe code has been sligthly changed, this should solve
the reports I have lying around (I hope).
Hangs when accessing ata & atapi device on the same channel simultaniously.
A real braino in ata_start caused this, fixed.
As usual USE AT YOUR OWN RISK!!, this is still pre alpha level code.
Especially the DMA support can hose your disk real bad if anything
goes wrong, agaiin you have been warned :)
But please tell me how it works for you!
Enjoy!
-Søren
