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
working. It was, as I predicted, a stupid bug and thanks to the
submitter for spotting it. I'll also re-roll some 3.4-RELEASE install
floppies for this.
originally done to track down yet another case of lost init, and is
not strictly necessary, but it seems more logical to have binaries in
/sbin than in /stand. Previously /sbin and /bin were symlinks to
/stand. Now /bin and /stand are symlinks to /sbin.
as a preprocessor variable only. This broke the build of ppp. This
problem still exists in the old-style directories.
Debugging-help-supplied-by: brian
originally done to track down yet another case of lost init, and is
not strictly necessary, but it seems more logical to have binaries in
/sbin than in /stand. Previously /sbin and /bin were symlinks to
/stand. Now /bin and /stand are symlinks to /sbin.
only way to be sure the build works correctly is to do a 'make all'.
But with these changes, it's easier to test individual targets. In
particular, ensure that the vnode file systems are mounted before
writing to them.
Ensure that we don't get CVS directories on our floppies.
Use kgzip instead of kzip to compress the loader. This saves a few
kB.
Remove some test cruft.
Kill duplicates for programs that have been in the boot crunched image
as well as on the fixit floppy (pwd, newfs, hostname, test). Our
space is really too valuable to have them around there twice. I doubt
pwd needs to be there at all since it's a builtin into sh(1) anyway
(oh, and the same applies to test(1) IIRC), but heck, leave them by
now.
Use the new `fixit' target in MAKEDEV to create the /dev nodes on
the floppy, instead of including the kitchensink...
Finally, tune the values used for creating the floppy. I currently
end up with
Filesystem 1K-blocks Used Avail Capacity iused ifree %iused
/dev/vnn0c 1363 1301 -47 104% 368 14 96%
...which is not quite ideal yet, but at least a working configuration
again.
as redoing all the menus to have proper, or at least non-hallucinogenic,
keyboard accelerators.
This requires my recent update to libdialog to work properly and will
probably also exhibit some other "interesting" behavior while the last
few missing screen clears are found (which is why I'm not going to MFC
immediately). At least now, however, sysinstall does not gratuitously
redraw random screens at the drop of a hat and drive serial console
installers out of their minds.
using make instead of custom scripts) and two floppies instead of
one. The resultant floppy can do everything that the individual
floppies (dial, net, install, isp, router) could do, modulo some bit
rot that has occurred since PicoBSD last compiled. It also includes
all the programs on the fixit floppy, which could thus also die.
/bin currently contains the following files:
-sh dump ln ns sps
[ ed login ping stty
badsect ex ls ps swapon
cat expr mkdir pwd sync
chgrp fdisk mknod pwd_mkdb sysctl
chmod find more rdump syslogd
chown fsck mount reboot tar
chroot ftp mount_cd9660 restore telnet
clri getty mount_msdos rlogin telnetd
cp grep mount_nfs rm test
date gunzip mount_std rmdir traceroute
dd gzip msg route umount
dev_mkdb hostname mt routed vi
df ifconfig mv rrestore view
dhclient inetd natd rsh vm
dhclient-script init netstat sed w
disklabel kget newfs sh zcat
dmesg kill nfs sleep
Structure is in place for using the same build for the other
directories, but I'm no longer sure we need this. The current first
floppy will run fine by itself, but the size of a compressed kernel
has increased by nearly 50% since 3.2, and there's not much space for
anything useful on the remainder of the floppy. The current method
creates a larger mfs and can read as many floppies as the user can
stand. The footprint appears to be round 14 MB.
using make instead of custom scripts) and two floppies instead of
one. The resultant floppy can do everything that the individual
floppies (dial, net, install, isp, router) could do, modulo some bit
rot that has occurred since PicoBSD last compiled. It also includes
all the programs on the fixit floppy, which could thus also die.
/bin currently contains the following files:
-sh dump ln ns sps
[ ed login ping stty
badsect ex ls ps swapon
cat expr mkdir pwd sync
chgrp fdisk mknod pwd_mkdb sysctl
chmod find more rdump syslogd
chown fsck mount reboot tar
chroot ftp mount_cd9660 restore telnet
clri getty mount_msdos rlogin telnetd
cp grep mount_nfs rm test
date gunzip mount_std rmdir traceroute
dd gzip msg route umount
dev_mkdb hostname mt routed vi
df ifconfig mv rrestore view
dhclient inetd natd rsh vm
dhclient-script init netstat sed w
disklabel kget newfs sh zcat
dmesg kill nfs sleep
Structure is in place for using the same build for the other
directories, but I'm no longer sure we need this. The current first
floppy will run fine by itself, but the size of a compressed kernel
has increased by nearly 50% since 3.2, and there's not much space for
anything useful on the remainder of the floppy. The current method
creates a larger mfs and can read as many floppies as the user can
stand. The footprint appears to be round 14 MB.
Work-sponsored-by: Sitara Networks Inc.
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.
- Add AMI and Mylex RAID controllers
- Reflect the demise of the 'eg' and 'ft' drivers
- Various minor cleanups
- Add some initial Microchannel information (this could do with some
fleshing out)
slice, partition, newfs, and install FreeBSD from a tarball on a remote server.
Handy for doing mass-installs for server farms.
Documentation following shortly.
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.
made only the most superficial changes so far to HARDWARE.TXT and
eliminated the stuff I absolutely knew didn't work. That still leaves
a lot of work to do and this is mostly just a place-holder for now.
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.
I backed-out the changes in -current and didn't touch stable at all (I
thought I had my patch order reversed, not what actually happened).
AIEEE! I can't even blame the crack for this one since I broke my
crack pipe a few weeks ago. I think sleep deprivation gets the blame
for this one.
Medal for noticing this one goes to: Jim Bloom <bloom@acm.org>
bringing in DHCP support. The only thing I left out were Poul-Henning's
newfs changes since I'm not sure if he's brought the rest of that support
into -stable yet. If it turns out that this is the case, I'll MFC those
changes too.
Set ALLLANG to install all the languages, otherwise set DOC_LANG
to just the languages (and encodings) you want to install.
Default to building the html-split (lots of small HTML files, with
links to go between them), html (one big honking HTML file), and plain
text versions of the documentation. Does not compress any of the docs
prior to doing the installation.
Testing and feedback: Jack O'Neill <jack@germanium.xtalwind.net>,
Cockups and typos: nik
. Now builds on -STABLE (-CURRENT is broken due to bugs)
. etc directory contents centralized instead of in each
type directory (can exclude & override as desired)
. Removed extraneous language files (lang files for rc really necessary?)
. dialog-based build tool with support for custom floppy builds
. MFS image loads as a mfs_root module instead of compiled into kernel
THIS IS BROKEN ON CURRENT. I'll MFC to -STABLE immediately following.
luigi tells me I have an OK from jkh on the MFC.
Submitted by: luigi
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.
in a previous FreeBSD version. That never happened. Document that
it is due to be replaced, but leave it open-ended as to when.
Also do some mdoc cleanup.
PR: docs/13148
PR: docs/13144
Submitted by: Lee Cremeans <lcremeans@erols.com>
Alex M. Zelkim <phantom@cris.net>
Discussed with: jkh
Originally submitted by: Wayne Self <wself@cdrom.com>
Allow a ppp startup option in rc.conf.
Adjust sysinstall so that it appends to the end of ppp.conf
and uses the generated profile to start ppp in auto mode on
boot.
Submitted by: Josef L. Karthauser <joe@uk.FreeBSD.org>
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.
ifconfig, essentially stealing the lease until the user goes and changes
it. The alternative, sadly, is total dysfunction since bpf isn't in
GENERIC and network connectivity would otherwise fail completely on first
bootup when DHCP configuration was attempted again.
The ultimate answer here is to make either bpf a loadable kernel module
(which security conscious admins will be able to simply remove from /modules)
or come up with a lighter weight mechanism just for dhcp and other apps that
need to see broadcast packets but not otherwise sniff the wire in full
bpf glory.
in some code from C. Stone to parse the lease information. This is still
a WIP and this commit is largely intended to allow others to sync up; the
dhclient code still only works when doing dhcp configuration post-install
and requires a bit more work on the boot floppy before it will truly
work in the minimal bootstrapping role.
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).
