> At last the "transmit underflow" is that the tulip chip couldn't read data
> fast enouth from the host memory: to minimize latency, ethernet chips start
> transmitting on the wire before they have read the full packet from host
> memory. Now, if they can't read data fast enouth, they have to stop
> transmitting, which means that the packet is lost. It doens't have anything
> to do with interrupts, it's a pure PCI issue.

That is the most stupid 'feature' ever invented [1], I'm not sure whether
netbsd's drivers use it - I've never done so, such features often increase
the cpu load and interrupt load so are a net loss.

> The serial problem could be the same (if a device grabs the PCI bus for too
> long, then the serial chip's fifo will overflow). On i386, serial interrupts
> are above splhigh, which means no other subsystems can block them (exept
> IPIs on SMP systems).

I see serial underruns on this i386 system - which is not MP.
OTOH I can't make it happen often enough to have tried to determine
the interrupted PC, nor the previous interrupt.

	David

[1] I believe this was first introduced in order to improve the performance
of some NetWare benchmarks - especially those using a single connection
given the 512 byte packets and a window of 1 packet.  For a server - which
will expect to service multiple requests this is a fruitless waste of
processing power.

-- 
David Laight: david@l8s.co.uk