On Sat, Jan 22, 2005 at 09:48:49AM +0000, Dieter wrote:
> Depends on what hardware devices you need to talk to.  If I only needed
> SCSI disk and SCSI tape I would be perfectly happy with the driver support.
> 
> But in these days of "convergence" I need to talk to things like
> 
> 	USB scanner (doesn't talk at the 480 Mbps speed for some reason)
> 	IEEE 1394 (firewire) camera (no driver at all as far as I can tell)
> 	HD-3000 tuner (no driver at all as far as I can tell)
> 
> SCSI disks haven't been keeping up (small capacity and expensive) so I added
> a 250 GB ATA disk.  I/O to the ATA disk causes problems with rs-232 and ethernet.
> 
> 	com1: 5 silo overflows, 0 ibuf floods
> 	de1: abnormal interrupt: transmit underflow
> 
> I'm guessing a latency problem servicing interrupts, but that's just a guess.

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.
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).

So, for this issue, it looks more like a PCI configuration issue, like
wrong settings for the PCI latency timers. Or just an incompatibility
between PCI implementations of the different component of your system
These do exists.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--