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. ;-)