the 802.3 frames generated by the DC21040 (which does automatic padding
of less-than-minimum frames) and the frames generated by the 'ed'
driver, I've found that there is indeed a bug in the size of "ETHER_MIN_LEN"
as reported by several people, John Hay being the most recent. The driver
was actually setting the length to 6+6+2+50 (64 bytes), which when adding
in the CRC (which is automatically appended to the frame and not included
in the length), the minimum frame is 4 bytes larger than it is supposed to
be. All of this is confirmed by tcpdump showing 50 bytes of data for
minimum frames from the 'ed' cards and 46 bytes from 'de' cards. This
analysis has also revealed that there is garbage in the un-filled in
portion at the end of the minimum frames from the 'ed' driver; I don't
plan to fix this.
For those where it was easy, drivers were also fixed to call
dev_attach() during probe rather than attach (in keeping with the
new design articulated in a mail message five months ago). For
a few that were really easy, correct state tracking was added as well.
The `fd' driver was fixed to correctly fill in the description.
The CPU identify code was fixed to attach a `cpu' device. The code
was also massively reordered to fill in cpu_model with somethingremotely
resembling what identifycpu() prints out. A few bytes saved by using
%b to format the features list rather than lots of ifs.
properly from the beginning:
1) The `kern_devconf' struct should be a part of the driver's
`softc' structure (now it is).
2) The `description' should say what the device actually is,
rather than just giving a model number (now it does).
3) The device should be registered even if the probe fails, so
that it can be reconfigured later.
4) For netifs, the device state should follow the IFF_UP flag.
Other network interfaces should follow this example. (Please?) Eventually
there should be a rundown routine doing the equivalent of setting IFF_UP
off, and perhaps more if warranted.
- /sys/i386/isa/if_ed.c doesn't quite know how to deal with SMC EtherEZ
ethernet cards. The EtherEZ looks just like the Elite Ultra, except it
has only 8K of shared memory. The only way to have it properly detected
is to zero and test a few bytes of memory just about the first 8K region.
If it clears properly, it's an Elite Ultra, otherwise it's an EtherEZ.
I've also got an EtherEZ patch for netboot (Makefile, ether.c and ether.h).
- /sys/i386/isa/syscons.c wraps at the next to the last column rather than
the last column, like it should. You don't really notice this unless you
use certain programs that write all the way out to, say, the 80th column,
like VMSmail. Along with a one-line fix for this are some changes to
implement a non-blinking cursor. Put 'options "NOBLINK_CURSOR"' in your
config file and give it a try. :)
Submitted by: wpaul
and into ether_input(). It was silly to have bpf want this one way and
ether_input want it another way. Ripped out trailer support from the few
remaining drivers that still had it.
and all SCSI devices (except that it's not done quite the way I want). New
information added includes:
- A text description of the device
- A ``state''---unknown, unconfigured, idle, or busy
- A generic parent device (with support in the m.i. code)
- An interrupt mask type field (which will hopefully go away) so that
. ``doconfig'' can be written
This requires a new version of the `lsdev' program as well (next commit).
else has been probed. This feature could go away again, if we can curb the
problem another way.
if_ed.c, syscons.c: Set the above flag. ed# because it needs it, syscons
because it looks stupid to "detect" the display you have already filled up
with text :-)
bt742a.c: Check bt_cmd() return-val during probe, thus failing on adaptec's.
Also silenced various printf's during the probe.
isa.c: Probe devices with the above flag set before the rest. Reduce the
number of "conflict" messages per device to one.
***
Please test the GENERIC-kernel now, if nobody can make it fail, GENERICAH
and GENERICBT has a finite and short life-expectancy...
***
of mb_offset given the right sequence of 1 and 0 byte mbufs. This bug
was discovered by John Hood who also provided this fix - which is a
rewrite of the routine (and is easier to understand than the code I wrote).
Submitted by: John Hood <cgull@smoke.marlboro.vt.us>
the first place was so that BPF could grok trailer packets. I've since
decided that this is a job for tcpdump to decipher (if at all). Also
fixed up checks for received packet length to better cope with ancient
starlan boards.
- Delete redundant declarations.
- Add -Wredundant-declarations to Makefile.i386 so they don't come back.
- Delete sloppy COMMON-style declarations of uninitialized data in
header files.
- Add a few prototypes.
- Clean up warnings resulting from the above.
NB: ioconf.c will still generate a redundant-declaration warning, which
is unavoidable unless somebody volunteers to make `config' smarter.
``changes'' are actually not changes at all, but CVS sometimes has trouble
telling the difference.
This also includes support for second-directory compiles. This is not
quite complete yet, as `config' doesn't yet do the right thing. You can
still make it work trivially, however, by doing the following:
rm /sys/compile
mkdir /usr/obj/sys/compile
ln -s M-. /sys/compile
cd /sys/i386/conf
config MYKERNEL
cd ../../compile/MYKERNEL
ln -s /sys @
rm machine
ln -s @/i386/include machine
make depend
make
finally have the f**king documentation!):
1) Changed all the numeric register offsets to symbolic ones (it should
have been this way originally).
2) If 16 bit, disable the shared memory when not using it. Apparantly
switching between 8/16bit mode makes the Ultra unhappy unless
this is done (i.e. it trashes the bus).
Yes, I know that IFADDR ioctl is supposed to be deprecated... Note
that the patch was modified by me to fit better into the driver. -DG
...
While porting CAP to 386bsd/pk0.2.4 and now to FreeBSD Release 1.0
I found a couple of bugs associated with the packet filter. Here
are the fixes. I'm posting them here because they apply to
FreeBSD and 386bsd/pk0.2.4 and possibly to other *BSD.
The first occurs when using the packet filter to write raw
ethernet packets. The header consisting of the sender and
destination addresses and the protocol is removed and later
added back on, but with the byte order of the protocol reversed.
The fix ensures that the byte order in the protocol field is
swapped when it is removed.
The second fix ensures that SIOCGIFADDR works for BPF as claimed
in the man pages, by adding it to the ed driver. Similar fixes
will be needed for other ethernet drivers.
Dave Matthews.
