to either enqueue or free their mbuf chains, but tcp_usr_send() was
dropping them on the floor if the tcpcb/inpcb has been torn down in the
middle of a send/write attempt. This has been responsible for a wide
variety of mbuf leak patterns, ranging from slow gradual leakage to rather
rapid exhaustion. This has been a problem since before 2.2 was branched
and appears to have been fixed in rev 1.16 and lost in 1.23/1.28.
Thanks to Jayanth Vijayaraghavan <jayanth@yahoo-inc.com> for checking
(extensively) into this on a live production 2.2.x system and that it
was the actual cause of the leak and looks like it fixes it. The machine
in question was loosing (from memory) about 150 mbufs per hour under
load and a change similar to this stopped it. (Don't blame Jayanth
for this patch though)
An alternative approach to this would be to recheck SS_CANTSENDMORE etc
inside the splnet() right before calling pru_send() after all the potential
sleeps, interrupts and delays have happened. However, this would mean
exposing knowledge of the tcp stack's reset handling and removal of the
pcb to the generic code. There are other things that call pru_send()
directly though.
Problem originally noted by: John Plevyak <jplevyak@inktomi.com>
New function getmemsize_pc98 is added in this commit, since PC98 is
quite different in obtaining memory size from IBM-PC. Many lines of
this function is shareable with IBM-PC's getmemsize function, but
sharing needs many #ifdef PC98 statements. Therefore, I gave up
sharing code with IBM-PC's and just added new function.
having different speed links in a bundle. This would manifest itself
by having the link occasionally hang, but revive when a new connection
is made....
Make ``show mp'' a bit prettier.
o Show more information about missing MP fragments in ``show mp''.
o Do away with mbuf_Log(). It was showing mbuf stats twice on
receipt of LCP/CCP/IPCP packets.... ???!!?
o Pre-allocate a bit extra when creating LQR packets to avoid having
to allocate another mbuf in mbuf_Prepend().
happens if you have a BIOS with a 'Plug & Play OS' setting and you leave
it set to 'Yes.' This is wrong for FreeBSD (and LoseNT): it should be set
to 'No.' Apparently it's still possible to map the iobase of the NIC and
have the card work by reading the config space manually (which is what
the driver does if pci_map_port() fails) but we need to warn the user to
do fix their machine anyway. Anyway, warn the user to check the 'Plug &
Play OS' setting in their BIOS if mapping the io space fails.
The driver now identifies the IBM PCI-PCI Bridge fitted to newer
Matrox cards and initialises it.
Sumitted by: Anton Berezin <tobez@plab.ku.dk>
The Protein Laboratory, University of Copenhagen
