Subject: Re: esp Disconnect Problems - Apologies
To: None <port-sparc@NetBSD.ORG>
From: Matthew Jacob <mjacob@feral.com>
List: port-sparc
Date: 10/16/1996 09:28:09
Uhh... Let me make one thing perfectly. clear.....
(yow! Foot in mouth. Tastes Bad.)
Folks - here is what I did *not* intend to do:
- Cast aspersions toward the current state of NetBSD.
- Cast aspersions toward the current NetBSD esp driver.
- Cast aspersions twoard anyone working on NetBSD or on
the SPARC port....
I was simply startled about the re-emergence of some issues which
I had hoped had gone away years ago.
In general I've been impressed with the quality of NetBSD (yes,
Chris- NetBSD (and Linux) *does* have an impact on vendors). I
have stayed away from the being involved in the SPARC port for a
long time for a variety of reasons (partly because it would hard for
me to be objective due to past employment), but recently I've
started dropping back in, and I should have just kept my mouth
shut....
To answer James' somewhat piquant (but understandable) statements:
Yes, sure- I'd like to do a bit of work on the ESP. One of things
the ESP chip suffers from is the 8-10+ interrups/per SCSI command,
which is why chip sets like the Adaptec AIC, the NCR script engine,
the Qlogic ISP, and the newer Western Digital chips (I don't remember
the part# off the top of my head- SGI's Onyx systems have them) series
have gone the microprogrammed route in an attempt to get (analogous to
RISC processors) <= interrupt/SCSI command. Another way to slice
the performance pie is to make, particularly on SPARC, the interrupts
really lightweight and not have to buy a register window (i.e., do
the interrupts in the trap window- the only performance cost here
is chip cache stuff, whereas a real interrupt frame has to possibly
spin registers windows to/from the stack - beaucoup expensive- I see
stuff in locore.s && intr.c for this- I disagree with the notion
that it should only allow one fast interrupt per level)..at any rate,
I digress.
Sure- I'd like to work on the ESP again. I'd promise to do it only
from Spec sheets and SunOS header files and their publised SBus
developer's kit (has DMA, DMA+, ESC gate array info). I'd have to
do it unconnected with other work probably. Well- I'll probably
start working on it, and when I get somewhere, I'll speak up again
(hopefully w/o putting my foot in my mouth...)