On Wed, 31 Jul 1996, Dave Burgess wrote:

> I have narrowed my Com port problems down to two possible culprits.
...
> The second is that the wd0 driver is somehow 'stealing' or masking the
> interrupt for the com port.  This is my most likely culprit, because it
> is definitely a problem on the client (my system) end.  I sat in the ISP
> frame room and watched the modem in action.  The modem at that end tries
> to send info to this end.  The modem at this end blythely ignores it.
> The nexty thing the modem at that end sees, it is disconnected and the
> next modem in the pool is called into service.  Note that on the ISP
> end, there isn't the redial sequence that is apparent at this end.  
I had done some experimenting earlier and came to a similar conclusion.
My observations were:
1) If I ftped to a NetBSD machine and had the receiving file /dev/null
   I rairly saw silo overflows and bunched up hash marks.
2) If I ftped to a NetBSD machine and reveived to a file on wd0 i observed
   a rash of silo overflows coralated with disk activity - not so much 
   just writing a block out but when it had to allocate a new inode.  At 
   least seeing disk activity without hearing anything did not seem to cause
   silo overflows but when you heard the disk doing some seeking (presumably
   to allocate another inode) there would be a rash of silo overflows.

However others claimed similar problems who did not have ide drives so it
may be a more general problem.

This was on 1.1 and using 28.8 modems in compressed mode (115200 baud rate).

johnh...

 > 
> I am willing to try the 'unsupported' com driver to see if it fixes this
> problem; all I need is that address...
> 
> -- 
> Dave Burgess  (The man of a thousand E-Mail addresses)
> *bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom
> "Just because something is stupid doesn't mean there isn't someone that 
> doesn't want to do it...."
>