Date: Wed, 23 Jul 1997 00:29:43 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: freebsd-scsi@freebsd.org Subject: New DPT Driver Message-ID: <XFMail.970723002943.Shimon@i-Connect.Net>
next in thread | raw e-mail | index | archive | help
Hi Y'all, First! Sorry for the lousy connectivity to sendero-ppp. I will GREATLY improve things in the next few days. I have put version 1.1.10 in the crash directory. Highlights: * Hopefully the last release before checkin into the FreeBSD tree. * The driver should be in the RELENG_2_2 tree. * In the near future, I will continue to publish the driver BEFORE it goes into the depository. * Certain NASTY bugs eliminated. Most dealing with slight timing errors and race conditions too subtle to detect, except through testing. * Some options were eliminated and some were added. Notably the DPT_COMMAND_SPLHIGH; It puts the driver, ever so BRIEFLY into splhigh to insure safe locking of the hardware registers. This is a short term solution but appears very effective. * By the time you read this, there will be a patch against 3.0-current. There will not be many of these patches, only enough to meet demand. The -current driver will support the new SCSI layer planned. As such we would like to limit development on that branch. Bugs will be fixed! Other DPT news: I received a motherboard from a FreeBSD user that is supposed to be really nasty. I finally put it in a box, disks, controller, etc. Will start testing tomorrow. DPT engineering, at the highest level, is taking our reports on troubles on certain platforms very seriously; A test program is on its way, including a FreeBSD release to be installed and tested. I masterdd a CD set for them and it is on the way. Between DPT, certain system vendor and us here, there are some 6 people working on this problem. I received inquiries about the syscon spitting messages like this: ... Leaving %d (%s) alone ... this is the result of two things being defined: 1. In i386/conf/WHATEVER you have ``options DPT_HANDLE_TIMEOUTS'' 2. In dev/dpt/dpt/h you have ``#define DPT_DEBUG_TIMEOUTS'' This combination tells the driver to occasionally check that there are no ``forgotten'' requests in the submitted queue (requests given to the DPT hardware and not heard from yet). the above message simply says that it found something in the queue and it is too young to die. If you start seeing complaints about ``stale'' transactions, or even more so, if you see something like ``... Bad (%d) CCB ...'', please, please report it to me along with the motherboard, slot number in the board, IRQ used, name, rank, SSN, etc. this is a clear indication of corrupt DMA transfers. The next release will be 1.2.0 and will include the IOCTL support for dptmgr. RAID Corner: * Use RAID-(!0) only if data loss is very upsetting. * Use RAID-5 only if storage space is at premium. * Remember that RAID array MTBF is (worst drive MTBF) / (number of drives) A redundant array simply provides a way to recover from this formula. Many people use DPT cotrollers for News Servers, and use RAID-5 configuration. When i grew up, losing the news data was upsetting but not a disaster. Performance in this convoluted database is important. If you agree with this statement, use RAID-0. If this is wrong, use RAID-5. If you need the best performance, in a redundant array, use RAID-1. An interesting combination is to create several RAID-1 arrays, and then have CCD across them in a RAID-0 (striping) arrnagement. REQUEST: Please try and build several different RAID configurations and try to see which is the best solution for news servers. I have enough questions on this matter i think I will start selling tickets :-) For this consider: RAID type (0,1,5) Stripe size Stripe sequence (across busses, etc.) Amount of memory on the DPT Percentage of read-ahead Percentage of cache devoted to read vs. write Nature of cache (write-through, write-back, etc.) Cache arrangement on individual drives. Competition (friendly, no rewards other than (even more) inflated ego :-): Largest RAID array Fastest Array Highest load Nastiest bug If this continues, i will have to cave in and actually setup a web page for all this. Help Needed: I need to build a new, independant version of a dptmgr. I want it to have nothing to do with the DPt provided one, except for compatible API. ANYONE is better than I am in drawing icons, pixmaps, etc. I would like it to be either xforms based or some other nifty tool. I will provide all the necessary kernel interfaces and low level stuff, but the glory of the UI can and should go tom someone else. Thanx for listening! Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970723002943.Shimon>