Get rid of ac->ac_ipaddr and arpwhohas() since they assume that
an interface has only one address.
Obtained from: BSD/OS 2.1, via Rich Stevens <rstevens@noao.edu>
from Larry Peterson &co. at Arizona:
- Header prediction for ACKs did not exclude Fast Retransmit/Recovery.
- srtt calculation tended to get ``stuck'' and could never decrease
when below 8. It still can't, but the scaling factors are adjusted
so that this artifact does not cause as bad an effect on the RTO
value as it used to.
The paper also points out the incr/8 error that has been long since fixed,
and the problems with ACKing frequency resulting from the use of options
which I suspect to be fixed already as well (as part of the T/TCP work).
Obtained from: Brakmo & Peterson, ``Performance Problems in BSD4.4 TCP''
Add support for LKM operation.
Change M_NOWAIT on buffer memory allocation to M_WAIT in hopes we'll be
able to get ourselves a nice fat buffer from the kernel if we suspend.
Note: The LKM support looks kinda screwy in two areas, where I found
problems with the kernel proper. First, calling dev_attach()
at module load time will cause a panic. I haven't investigated.
Secondly, I had to manually call qcam_drvinit() to register the
device softc structure by hand at module load time. This seems
bogus, it should be called as a core part of the module load
process for character/block device drivers.
vm_offset_t is currently unsigned long but should probably be plain
unsigned for i386's to match the choice of minimal types to represent
for fixed-width types in Lite2. Anyway, it shouldn't be assumed
to be unsigned long.
I only fixed the type mismatches that were detected when I changed
vm_offset_t to unsigned. Only pointer type mismatches were detected.
device have reference count problems. We mark the underlying object
ono-persistent, and account for the reference count that the VM system
maintainsfor the special device close. This should fix the removable
device problem.
isn't supplying all the proper header info here! Last commit of fe0
entry should have had the following Submitted by line also).
Submitted-by: Masahiro SEKIGUCHI <seki@sysrap.cs.fujitsu.co.jp>
1. Create 2 x 8k transmit buffer blocks in place of the 16k block previously.
With this change the speed as tested with ttcp on a 2Mbit link went up
from 206kbyte/s to 236kbyte/s.
2. Change the rest of the functions to also have the definition of the
return value on a sepperate line.
3. Remove some unused variables.
4. Add code to recover from DMA underruns.
5. Reorder ar_get_packets() to handle errors better.
6. Only allocate a mbuf cluster if the data is more than the mbuf.
(and in a second diff in addition to the above)
7. Stops the occasional DMA underruns that occurred when 2 channels
are running at 2Mbit/s.
Submitted by: John Hay <jhay@mikom.csir.co.za>
but didn't actually do anything with it (*blush*).
This should fix bde's test case where the test program set SA_RESETHAND
and when reading it back, it was gone.
Tweak/optimize SA_NODEFER so that the implementation is a little simpler
and does not incur (slight) overhead for every signal at delivery time.
between ignoring options specified in the setsockopt call if IP_HDRINCL is set
(the UCB choice when VJ's code was brought in) vs allowing them (what everyone
else did, and what is assumed by programs everywhere...sigh).
Also perform some checking of the passed down packet to avoid running off
the end of a mbuf chain.
Reviewed by: fenner
regarding the "real" problem with maps that we have been having
over the last few weeks. He noted that the first_free pointer was
left dangling in certain circumstances -- and he was right!!! This
should fix the map problems that we were having, and also give us the
advantage of being able to simplify maps more aggressively.
loader is also present in the coff loader. It was possible to get one
more page allocated than needed, which would cause brk()/malloc()/etc
to fail with ENOMEM when it tried to re-allocate the space.
Also, change a bcopy() from kernel to user space to a copyout().
