*BSD News Article 98963


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!news.cs.su.oz.au!inferno.mpx.com.au!news.unimelb.edu.au!munnari.OZ.AU!news.Hawaii.Edu!news.caldera.com!enews.sgi.com!nntprelay.mathworks.com!news.mathworks.com!fu-berlin.de!irz401!orion.sax.de!uriah.heep!news
From: j@uriah.heep.sax.de (J Wunsch)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: DPT with FreeBSD
Date: 3 Jul 1997 18:01:03 GMT
Organization: Private BSD site, Dresden
Lines: 220
Message-ID: <5pgpcv$e9o@uriah.heep.sax.de>
References: <01bc873d$47e05410$103a05cf@kamal>
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
NNTP-Posting-Host: localhost.heep.sax.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Newsreader: knews 0.9.6
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F  93 21 E0 7D F9 12 D6 4E
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:43914

"Kamal Singh" <kamal@tesys.com> wrote:

> I am trying to configure DPT controller card with FreeBSD.Can
> someone please help me how to do that and from where I can download
> their patches?

Here's Simon's original announcement:

Message-ID: <XFMail.970613104732.Shimon@i-Connect.Net>
X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD
Date: Fri, 13 Jun 1997 10:47:32 -0700 (PDT)
Organization: Atlas Telecom
From: Simon Shapiro <Shimon@i-Connect.Net>
To: FreeBSD-hackers@FreeBSD.ORG, FreeBSD-SCSI@FreeBSD.ORG
Subject: Announcement:  New DPT RAID Controller Driver Available

Hi Everyone!

[ I am NOT an employee of Distributed Processing Technology.  I do not
  represent DPT, not do i represent Atlas Telecom, my employer;  I do
  it all by myself...  ]

DPT manufactures RAID controllers for PC's.  These controllers allow 
you to create and manage RAID-{0,1,5} arrays and accomplish very high
speed and reliability in disk storage.

Up to 64MB of ECC cache can be installed on a controller and up to 3
SCSI busses attached.

I have recently completed a FreeBSD driver for these controllers and
made it publicly available to FreeBSD users.

The driver supports the PM3334{U,W,D} which is a PCI controller 
sporting a 68030 processor, up to 3 SCSI ultra-wide-differential
busses.  It is also available (I think) as narrow, non-ultra and
definitely single-ended.

The driver was tested thoroughly only with the above controller but
should also work with lower-end PCI cards.  It will NOT work with 
non-PCI DPT Host Bus Adapters, nor do I have plans to add this
support.

The driver is still, in some ways, work in progress:

The character I/O (to allow you to ``talk'' to the controller) is
stable but not functional.  So is support for in-driver RAID.

The character I/O will allow you to run RAID configuration and
management by opening /dev/dpt{0-n} and performing IOCTL, READ, and
WRITE to the controller.

These controls will allow you to monitor power supplies in the disk
bay, fans, temperature, etc.  It will also alow you to monitor disk
I/O statistics, error logs, and performance statistics.

In addition, you can destroy, build, and repair RAID arrays, with the
system running.  Interfaces will include a library, SNMP MIB, X based
interface and some command line interfaces.  The interface also allows
you to dynamically configure hot spares (devices that will
automatically go on-line when another device fails).

The in-driver RAID allows you to build RAID arrays that span HBAs. 
This interface is O/S independent, so, you can have a boot device that
will boot NT, Win95, Dos, FreeBSD, Linux, Unixware, Netware, etc. from
a RAID array that spans disks.

Extensive testing was done on the driver to assure high reliability.
Highly qualified help was enlisted in reviewing and debugging the code.

Having said that, the code only runs on 7-8 test machines and 2-3
workstations.  It should be considered ALPHA and no mission critical
data should be put on it, before YOU are satisfied with the product.

The driver is available, now from sendero-ppp.i-connect.net and from
ftp-i.connect.net, in the /crash directory.

All this wonderful stuff is O/S independent, and RAID arrays, hot
spares and normal devices all appear as standard disks to the O/S.
The large cache can increase performance, on busy systems,
dramatically, while reducing system load incredibly.

The driver was tested with DPT firmware 07H and 07L.  DPT provides
(what amounts to) lifetime of free support and firmware upgrades.
Firmware can be FLASH'ed in from the ftp.dpt.com server.

Later versions of the driver will allow flash rom updates from Unix.

I would like you to help me in posting an announcement on the proper
FreeBSD lists and in checking it in.

All the work was done against RELENG_2_2, and the patch provided was
made, today, against a pristine source tree.

For your convenience, I am also providing the latest DPT firmware and
DOS utility to manage the controller, until the Unix interfaces are
done.

Testing was done on several industrial PC's.  Either Pentium-100 or
PentiumPro-200.  The systems had 54-128MB of RAM and 1-2 controllers
each.  There were a minimum of 6 disks per SCSI channel per controller
and all possible combinations of devices and configurations tried.

Testing was assisted by few simple utilities:

blob.c:  Creates a unique barber pole, exactly 16MB in length and
         neatly slicable to sectors.

st.c:  performs random seek tests on a given file/device.

nasty:  A nasty little shell script to spawn 256 sessions of dd 
        (or st) and try to see what breaks - Nothing.

Tunable Parameters:  As this is still an evolving driver, there are
(too many) tunable parameters.  the following are of interest:

DPT_COMMAND_SPLHIGH:  Forces the actual submitting of a command to the
                      DPT to run at very high priority.  Can/should be
                      OFF.

DPT_OPENNINGS:  How many concurrent SCSI commands to send to a given
                device.  Should be positive integer.  Currently less
                than 64.  The driver will bump this number up for
                devices that are very busy.  It has nothing to do with
                linked/queued commands, as the DPT does linking
                automagically.  Leave at 2, nice number.

DPT_VERIFY_HINTR:  Certain noisy motherboards generate bogus data on
                   the PCI bus.  If you get mysterious crashes, enable
                   this option and tell me what you see on the console.
                   Leave OFF unless you are seeing crashes you cannot 
                   explain.

DPT_RESTRICTED_FREELIST:  Under normal conditions, the driver will 
                          queue as many requests as the O/S submits.
                          With this option ON, the driver will
                          restrict itself to no more requests than the
                          DPT can accept (normal firmware == 64).
                          Leave OFF for normal operation.

DPT_TRACK_CCB_STATES:  When enabled will track, in details, the queue
                       management.  Only meaningful when combined with
                       VERIFY_HINTR.  Leave OFF.

DPT_MEASURE_PERFORMANCE:  Enables certain internal metrics.  There is
                          currently no clean way to extract these.
                          Leave OFF for slightly better performance.

DPT_USE_SINTR:  The driver can work either in a traditional manner
                (as far as command submittal is concerned), or use
                Software interrupts for queue management.  Leaving it
                OFF will give slightly better performance at low loads
                while dramatically slow things down at high loads.
                Running the ``nasty'' script, OFF will give you Load
                average of 110-120 at peak load.  Turning it ON will
                take LA to 5-9.  Yup.  No typo here.  Disk subsystem
                performance will stay very close, though.

DPT_FREELIST_IS_STACK:  If ON, more optimal use of the processor's 
                        cache will be realized, at a cost of slightly
                        increased chance of cache overruns.  Try both
                        ways and tell me.

Performance:  With DPT_USE_SINTR off, we get about 3.5-4MB/Sec on
              single disks and about 15-18 on RAID-0 arrays. 
               As Expected, RAID-1 performance is in the 10MB/Sec,
               and RAID-5 is about 15 READ and 5-7 WRITE.
               There is still excessive instrumentation and
               monitoring code in the driver.  When complete, much 
               of this will go away.

System Load:  It is interesting to learn that with DPT_USE_SINTR
              off, the dd test reaches LA of about 110-120  with 64 
              dd's.  
              With DPT_USE_SINTR on, the load goes down to about 5-9.
              If this was a FreeBSD vs. Linux or FreeBSD vs. NT I
              would have left this statement alone at this point :-))
              The reality is that the system's real load is almost
              identical. The difference probably comes from how LA 
              is computed and interacting with the I/O queues.
              System responsiveness was excellent in all cases.

Support:  The DPT driver is an integral part of my employer's 
          strategic product for the next few years.  As the architect
          for that product, I can assure you it will be supported.  
          Even in the unlikely event that my employer will not have
          vested interest in this driver, I will personally continue
          to support it.

Thanx:  In no particular order:

    Mike Neuffer:  For helping so much with the early low-level wire 
                   twitching code and for deciphering, in realtime the
                   documentation.  Fragments of his Linux driver should
                   still be scattered throughout the driver.

    Justin Gibbs: For lots of patience, knowledge of FreeBSD SCSI,
                  excellent aic7xxx driver, form which I stole code
                  shamelessly and many hours of debugging.

    Dan Eischen:   For the hours spent hunting bugs, common sense and
                  friendly help.

    Mark Salyzyn: For explaining, again and again, how a DPT card
                  works and for critical debugging.

    The Atlas Telecom PrePay Team for listening and patiently waiting
    for me to get back to the keyboard and finish this code.


I can be reached at my indicated e-mail address, or at 503.799.2313.

Simon


-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)