Subject: Re: com driver troubles on NetBSD/i386
To: Bill Studenmund <skippy@macro.stanford.edu>
From: Phil Knaack <flipk@ncremp.ag.iastate.edu>
List: port-i386
Date: 05/27/1996 14:00:22
Bill Studenmund writes:

>I don't know much about the com driver, though I think someone mentioned
>that it isn't two-level. My feeling from reading the 4.3 book was that if
>you had low-buffer I/O hardware, use a two-level driver w/ a silo.
>Obviously, this change couldn't make 1.2, but maybe for the future? I'd
>offer to help, but I suspect the folks who know the com driver already
>understand silos. :-)

	Actually, it is a two-level system (unless you're referring to 
something else).

	In the first level, comintr() just stuffs the lsr (line status 
register) contents and the data port contents into an ibuf, and compoll()
which operates on each timeout() clock tick swaps ibufs underneath comintr()
and then takes its time stuffing those out into the tty layer.

>Our problem was that spltty, which was supposed to block the
>silo-to-kernel transfer, was disabling the hardware servicing interrupt
>(the hardware-to-silo connection). Making spltty a soft interrupt (or a
>much-lower-level hardware interrupt) made everything work well.

	While compoll() does spend some time at spltty(), its only for a
few dashing lines while it checks a flag and swaps the ibuf pointers around.
comintr() is established at IPL_TTY, but I don't think that compoll() spends
enough time mucking about to stuff up comintr().


FYI:

	I'm working on this problem a bit, playing around with two 486's 
connected to each other by a 5ft serial cable and an ethernet cable, with
no other activity on the subnet or machines of note.

	I'm not great with some of the complex kernel internals, but I can
work with com.c and other drivers, and would love to correspond privately
with people about suggestions or if I would like to bounce an idea off of
someone.

David Gilbert (in a different message) wrote:

>        Someone mentioned that they had a driver that would make led's
>hung off the parallel port do useful things (like indicate network
>activity) ... maybe they could be use to monitor the interrupt
>activity.  If this were too fast, then maybe it would be possible to
>use a second machine to monitor this process.

	This was me .. I've had my blinkies doing all sorts of things. :)
I'm going to play with this idea, too.

Cheers,
Phil
--
Phillip F Knaack               flipk@iastate.edu
Database Programmer, NCREMP    Student Development Group
ISU Extension                  Project Vincent, Iowa State University