SCSI scanner, sym/ncr driver, pt(4)

Stefan Esser se at FreeBSD.org
Mon Jan 30 08:27:05 PST 2006


Oliver Fromme schrieb:
> Matthias Andree <matthias.andree at gmx.de> wrote:
>  > Oliver Fromme <olli at lurza.secnetix.de> writes:
>  > There was a time when sym(4) didn't support the more efficient
>  > LOAD/STORE uncapable 810, 815, 825 chips (the A variants, where they
>  > exist, support LOAD/STORE). sym(4) has learned to use MEMMOVE on these,
>  > however.
>  > 
>  > ncr(4) has never used LOAD/STORE, and lacks support for the 897 chip and
>  > the 1010 family.

I think I can clarify the situation. The NCR driver supports all chips
except for the 1010 (I think it should work with the 895/897, though I
never owned one and haven't checked the sources).

Because of the many problems with the Linux ncr53c8xx driver (which did
not even support SCSI Disconnect), Gerard Roudier ported the BSD NCR
driver to Linux where it was known as the BSD NCR driver at that time.
After he had managed to complete the interface shims, he split the
driver into an OS dependent part (different for BSD and Linux) and the
low level driver code.

While I did not want to give up support for the first generation of NCR
chips (which had to use self modifying code in a lot of places for lack
of better addressing modes in the early NCR SCRIPTS engine), Gerard
simplified the micro code by use of the LOAD/STORE.

Since at that time the NCR chip company had been bought by Hyundai
(IIRC) and named Symbios, Gerard renamed the driver to "sym" (since it
still supported the chips sold by Symbios, but not some of the earlier
chips developed by NCR).

At that time Gerard became a FreeBSD comitter and actively maintained
the "sym" driver on FreeBSD (and also to some degree the "ncr" driver,
which still has much in common with "sym"). A job change meant that
could not keep up maintaining the NCR driver and I was glad to see that
Gerard took over, but it appears, that he has not been active in the
project for several years. I have considered declaring myself maintainer
of both ncr and sym drivers, since I guess that I know there development
and internal structure best, but I'm still extremely short of spare time
(and while I still own some of the hardware used to develop the NCT
driver, none of it is currently installed in any of my systems).

I had started writing an improved NCR driver (which could take advantage
of all possible combinations of features in the different chips), but
when I found that I did not even have time to maintain the existing
driver, I gave up on finishing it. Besides with the sym driver being
maintained and made to support newer chips, the ncr driver was only
relevant for the old chips left behind by sym.

> I've read about that LOAD/STORE and MEMMOVE stuff in the
> manpage, but I'm not a SCSI expert, so that's really only
> gibberish to me, I'm afraid.  Hell, I do not even know if
> my "810" card is an "early NCR 810" which sym(4) keeps
> talking about.

The 810 is early, the 810A is a second generation chip. The 860 is a
faster version of the 810A (or rather the 860 was the sequel to the 810
and offered the enhanced instruction set, the 810A is a slower variant
offering only the original 5MB/s instead of the 860s 10MB/s).

> If you're just a user, the manpages fail to tell whether
> the sym(4) or ncr(4) driver is preferred for an 810 host
> adapter.

If you include both drivers in a kernel, "sym" will be used for all
chips it supports. I might have a look at the man pages, though ...

>  > > But I wonder if the ncr(4) driver offered any advantages.
>  > 
>  > It doesn't. There used to be a time when it worked with the old 810 and
>  > sym(4) didn't, but this no longer holds.

Hmmm, this is news to me. That would require the sym driver to contain
both sets of SCRIPTS code, the one from the NCR driver and the one from
the sym driver.

> OK, so the ncr(4) should be regarded obsolete, right?  In
> that case, the manpage should say so, at least.

I don't think so ... Except if you consider the 53c810 obsolete, though
it is still quite useful for slower SCSI peripherals.

Regards, STefan


More information about the freebsd-scsi mailing list