Mr. Popov shows us how easy it is to test SCSI devices when our operating system is Linux.
A few months ago my ex-boss and I were discussing the latest product of his company and the systems they were using for testing purposes, both in the office and in the factory. “It's all DOS—what you want is cheap,” he told me. I believe that statement summarizes the reason DOS became the operating system of choice for factories and many laboratories. A fully equipped SCSI DOS system needs little memory, a cheap video card and monitor and a relatively cheap SCSI controller. Of course, these days there are many other reasons for using DOS for testing SCSI peripheral devices. There is a vast knowledge base, availability of ASPI-based tools and, most likely, the company already has a hefty investment in test software or in developing its own tests. (ASPI stands for Advanced SCSI Protocol Interface and was developed by Adaptec. It is the de facto SCSI programming interface on DOS and Windows.) Nevertheless, Linux is also a viable SCSI test system, and there are some very good reasons why you should consider Linux for testing your SCSI devices.
Testing a SCSI sequential access device is not a simple matter. These devices (DDS and AIT tape drives, to be specific) are usually used in a server environment where system downtime is not acceptable, especially when the down-time is due to the data backup device hanging the SCSI bus. (DDS, digital data storage, is Sony's 4mm tape drive technology. AIT, advanced intelligent tape, is Sony's new 8mm tape drive technology.) To put such a product on the market, extensive testing needs to be done in quite a few areas. Currently, the testing is performed on PCs running Sony internal tests or Independent Software Vendor (ISV) backup software or OEM proprietary systems running a flavor of UNIX, NT or some other proprietary OS. The qualification cycle of these devices is much longer than that of hard disks, but so is the life cycle of the product. The more systems you can test on and the more types of tests you can run, the more solid your product will be.
Some portions of the SCSI protocol cannot be tested without using a specialized tool, such as an Itech SCSI emulator. This type of tool allows the engineer to develop powerful low-level SCSI tests to test the SCSI protocol handling. For example, with such a tool you might issue a write command, send one or more bytes to the drive, raise ATN (attention control signal) and then, when the drive goes to output data, send an abort or reset message. These tools, however, are quite expensive (in excess of $5000 US) and certainly not all engineers need them, since not all firmware engineers work on the SCSI protocol. By the time the product makes its way to the test lab, most SCSI protocol problems are solved so the lab needs only one of those specialized testers, mainly for use in firmware regression testing.
Yet, with all of the specialized tests we have, some of our most important testing is done on commercial UNIX systems, surprisingly enough with well-written C shell scripts using standard UNIX utilities such as dd, tar and mt. My guess would be that at least half of the firmware problems in the past have been found running these scripts on UNIX systems. Linux has all those utilities, as well as a selection of shells. The same shell scripts running on commercial UNIX systems can easily be ported to Linux, maintaining the same functionality. This means you can supplement the expensive commercial UNIX systems in your lab with a few low-cost PCs running Linux. This alone makes Linux a serious contender in the SCSI testing field.
Walk into a lab where SCSI devices are being tested, and attached to the PCs on a single SCSI bus, you'll usually see a few devices. It's certainly important to test more than one device at a time; however, it rarely makes sense to have more than three or four devices running under the same test. Even if you fully populate the SCSI bus, if one device hangs overnight it sometimes hangs the SCSI bus, not allowing the rest of the devices to continue. It makes no difference, in this case, that you have six other devices attached. What would be better is to attach a second or even third SCSI controller and run different types of tests on each one. That way you can utilize the system more efficiently and thereby get more done in the same amount of time. Furthermore, if one test finds a firmware bug and the bus hangs, the other tests can continue. DOS, however, is not a multitasking operating system, and if you wish to run different tests on each SCSI controller, you'll have to add all that complexity to your test. Well, it's really no wonder I've never seen that done. It's tough enough debugging complex SCSI tests, not knowing whether the failure was due to the test or the device. Adding additional complexity to the test will most certainly take away from the firmware engineer's time who will have to debug what may turn out to be a test problem, not a drive firmware problem. Linux, on the other hand, does not suffer from this limitation. You can write basic tests, add them to your shell script and let the operating system worry about the multitasking. If one test fails because of a hung device, the other tests can continue running.
The standard UNIX utilities provide a high level of functionality testing, but, to complete a test suite, the engineer needs finer control of the SCSI device. The ability to send any SCSI command, including commands with illegal bits set, as well as illegal commands, is a must. This is one area where standard UNIX utilities cannot do the job and an alternative method is needed. Some time ago, I decided it would be nice to have a library of SCSI commands that made it easy to write tests, as well as to expand the library itself. So I started playing with the Linux generic SCSI driver, which seemed the easiest way to go, and I recently released such a library under the GPL. libdat.a contains just about all the sequential-access SCSI commands and, if there is something else you need, adding new commands is quite trivial. The library is packaged with a tape tool called stt, SCSI Tape Utility, which is based on libdat.a. stt adds a powerful capability to my Linux workstation at the office. I can now interactively send any command to the tape drives, as well as reprogram drives and make reprogramming firmware tapes. (These last two features are removed from the GPL version.) It is also an example of how easy it is to write SCSI tests using libdat.a and the generic driver in general. Most importantly, I now find it easier to write tests for my Linux workstation than for proprietary tools. Here's an example of a short C program (the #includes are not shown):
_Inquiry(); /* show device information */
_Space(EOD,0); /* space to End Of Data */
_ReadPosition(); /* show current logical
* position */
_Space(FMK, -2); /* space reverse 2 filemarks */
While the above program doesn't do much, it does show the ease with which the programmer can write tests. The stt utility provides a longer example of a fully functional and useful program based on libdat.a.
You may be happy with your current test setup, but consider the following questions. Could you do more if your OS was more capable? What if you could write C programs and shell scripts, instead of DOS batch files? What if your test system was fully networked? Could you run the log files through a Perl filter to format them and display them on your internal web site? Could you benefit from the standard UNIX utilities, which you don't have to rewrite? Certainly you could benefit from attaching more than one controller to your system and running more than one type of test at the same time while your OS took care of the multitasking. What if there was a generic, easy-to-use SCSI interface and library that gave you full control of your SCSI devices as well as access to all source code? What if you could do your development on a platform with a rich set of development tools, including compilers, debuggers, version control systems, etc? Next time you are considering a platform for your SCSI testing, look at the answers to these questions and do yourself a favor. Consider how much more you could do, if that platform was running Linux.