On Sat, Jan 22, 2005 at 06:19:19PM +0000, Dieter wrote:
> > > 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.
> 
> I'm getting deja-vu here.  I'm sure I read about this problem 15-20 years ago.
> 
> Awhile back I tried reducing the MTU, which greatly reduced, perhaps eliminated
> the problem, but then it didn't like large incoming packets.
> 
> I'm planning on upgrading to gigabit Ethernet, do any of the giga chips/boards
> have enough buffer space to avoid this stupid problem?

Even the tulip driver has enouth buffer, it just needs to be switched to
store and forward mode. BTW, if you're using the de driver, I guess you're
running a quite old release. Maybe the new tlp driver would switch to
store and forward mode automatically in such situation.

> 
> > 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).
> 
> This is on alpha, single CPU.  Is there some knob in the wd driver I can
> turn to get it to not hold the bus too long?

It's not in wd, it a PCI setting issue, probably the same as reported in
http://mail-index.netbsd.org/port-alpha/2005/01/13/0000.html

There's a proposed hack here, you can try to adapt it to pciide.
Also use pcictl dump to check the latency timer setting or the devices.

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