for the Lite2 fix for always returning EIO in dead_read().
Cleaned up the cdevswitch initializers for all tty drivers.
Removed explicit calls to ttsetwater() from all (tty) drivers. ttsetwater()
is now called centrally for opens, not just for parameter changes.
another specialized mbuf type in the process. Also clean up some
of the cruft surrounding IPFW, multicast routing, RSVP, and other
ill-explored corners.
it to sit right...
The __error() hack gave out the wrong address. It returned the address of
errno in ld.so instead of the address of errno in the main program. Oops.
The hack is now correct, just in time to be obsoleted by elf.
of associated mbuf clusters) in the RX ring from 4 to 16. On my
really fast PI 400Mhz test machines, 4 descriptors (and associated
mbuf clusters) is enough to achieve decent performance without any
RX overruns. However, one person reported problems with the following
scenario:
- P90 system running FreeBSD with a 3c905B-TX adapter, slow IDE hard
disk (Quantum Bigfoot?)
- PII 266 with SCSI disks running LoseNT and also with a 3c905B-TX
- Both machines connected together via crossover cable at 100Mbps
full-duplex
- LoseNT machine writing largs amounts of data (2.5 GB work of
files each in the neighborhood of 1 to 2 MB in size) via samba to
the FreeBSD machine
In this case, the LoseNT machine is sending data very fast. Apparently
there weren't any problems initially because the user was writing to
one particular disk which was relatively fast, however after this disk
filled up and the user started writing to the second slower disk, RX
overruns would occur and sometimes the RX DMA engine would stall after
a 100 to 500MB had been transfered. The xl_rxeof() handler is supposed
to detect this condition and restart the upload engine; I'm not sure
why it doesn't, unless interrupts are being lost and the rx handler
isn't getting called.
This is still an improvement over the Linux driver, which uses 32
descriptors in its receive ring. :)
Problem reported by: Heiko Schaefer <hschaefer@fto.de>
or Elf64 based on the inclusion of the machine dependent header.
I've left the addition of the extra fields to handle the relocation
structures with addend for a separate commit after jdp has had a chance
to review what I've done. The current change is needed to compile
csu/alpha/crt1.c
'three-stage' bootstrap.
There are a number of caveats with the code in its current state:
- The i386 bootstrap only supports booting from a floppy.
- The kernel and kld do not yet know how to deal with the extended
information and module summary passed in.
- PnP-based autodetection and demand loading of modules is not implemented.
- i386 ELF kernel loading is not ready yet.
- The i386 bootstrap is loaded via an ugly blockmap.
On the alpha, both net- and disk-booting (SRM console machines only) is
supported. No blockmaps are used by this code.
Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
before it is installed.
This upsets Bruce because the host boostrap build forces tools to be
static anyway. He says I'm abusing NOTOOLS in src/Makefile by using
it to do a aout->elf transition build. One day I'll find a place to
install host tools like these to allow a true cross build.
They shouldn't be used there either. They should have gone away
about 3 years ago when the statically initialized devswitches went
away, but su.c unfortunately still frobs the cdevswitch in the old
way.
The check for dropping unicast packets not sent to our ethernet
address is after the bpf tap, but not conditioned on it. All packets
received should get handed to bpf, and unicast packets not to us (mac)
should get dropped whether or not there is a bpf listener. I believe
that the common optimization that the interface is in hw promisc mode
iff there is a bpf listener is in general wrong, but more frequently
so on wavelans.
I think Max's fix makes bpf listeners not see unicast packets sent to
others, but I'm not sure.
One can argue that checking on MOD_ENAL is wrong, but the code only
drops packets that shouldn't be received. The correctness condition
is that it be run whenever unicast packets without our mac address can
be received.
PR: kern/7144
Submitted by: Greg Troxel <gdt@ir.bbn.com>
