From: David Hogan dhog@lore.plan9.cs.su.oz.au
Subject: Adaptec 2940 (buy NCR/Symbios) [long]
Date: Sat, 31 May 1997 11:57:30 +1000 [thread overview]
Message-ID: <19970531015730.j7KUW3dNWtmX-ZVd2Yh0wFH4LiSZ-SqjCu83XcZ8h5s@z> (raw)
> Before I talk about the Adaptec AIC7xxx series, I would like to back up
> forsyth's kind comments about the Symbios/NCR driver. If you don't have
> an explicit need for an Adaptec controller, then the Symbios/NCR route
> is cheaper, and higher performance. The Symbios 8751 Ultra Wide
> controller now costs 110 quid here, whilst Adaptec is pushing 200 quid
> for equivalents. I can't make comparisons under Plan 9, but under NT
> commerical projects here have found 30% throughput, and better
> reliability by switching to Symbios cards.
Well, it looks like I should have done some research before I
forked out the cash :-)
> So why would I want to do an Adaptec driver? It's all Uncle Bill's
> fault. Under Win95, the only well documented generic SCSI layer is the
> ASPI layer which was invented by Adaptec (though they claim the A stands
> for Advanced). It is possible to use the miniport layer (and hence drive
> any controller) but few applications do (Seagate Backup for WIn95 is an
> example) and the documentation seems to be designed to convince you that
> it only works under NT so it's difficult to believe any part of it. As a
> result, anyone writing software for SCSI will support one proprietary
> controller directly, and then ASPI. This is the case with TWAIN drivers
> for scanners. Since scanners tend to have manufacturer specific
> extensions, each model has it's own TWAIN driver to do the twiddly bits.
> These drivers talk to either the crappy card shipped with the scanner,
> or ASPI.
Easy solution -- don't use Win95! :-)
> I've been in touch with the Linux/FreeBSD guys who were great. I have a
> full reading list for Adaptec. You think you only need one manual. It
> looked like about 10.
I've only ordered 2... Of course, I'm only interested in the 7880 chip,
perhaps you need more if you're supporting all the other variants as well.
> The AIC chip runs microcode much like the NCR, except that there is an
> on-board copy which can be replaced by download. Apparently, Adaptec
> will not document the microcode except under NDA, so Linux/FreeBSD has
> it's own. The microcode sequencer is better than NCRs (it avoids several
> big mistakes). The microcode reproduces the control block concept that
> is used by the unreplaceable (should that be irreplaceable) 8085 machine
> code on the 1540 ISA cards. This suggests to me that we could borrow the
> FreeBSD sequencer, and 'adapt' (ha ha ha) the existing Plan9 aha154x
> driver.
Yep, that's one way of doing it. This would get us up and running
the fastest. I wonder though whether further performance gains
might not be achieveable through the use of microcode which is
tailored toward use with Plan 9. There are probably some "dirty
tricks" with the buffer management which would work here. I need
those docs :-)
Another question I've been thinking about is whether it is better to
compile the microcode at kernel compile time (like the FreeBSD
driver does) or at device initialization time. In the later case,
the microcode could be tuned for the specific type of card (ie
leave out support for features it doesn't have, etc). The driver
could also wire static addresses of command queues into the microcode,
etc.
> There's the usual load of crud to identify the card, download code, read
> and write a microwire EEPROM, patch up for the fact that some wide
> controllers actually are two AIC controllers bolted together, etc etc
I have some code for identifying my card :-) I'm rewriting the PCI
support, I will try to make it available when I've finished.
Bolting two controllers together sounds like a complete nightmare!
How do they maintain synchronization? Won't the data need to be
split/interleaved (depending whether you are writing or reading)?
Yuck yuck yuck...
next reply other threads:[~1997-05-31 1:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-05-31 1:57 David [this message]
-- strict thread matches above, loose matches on Subject: below --
1997-05-30 7:45 Nigel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19970531015730.j7KUW3dNWtmX-ZVd2Yh0wFH4LiSZ-SqjCu83XcZ8h5s@z \
--to=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).