Article View: comp.sys.dec
Article #323Re: DECstation 5000/240
From: AJ Casamento
Date: Mon, 06 Apr 1992 18:52
Date: Mon, 06 Apr 1992 18:52
115 lines
6883 bytes
6883 bytes
In article <1992Apr6.180341.11537@vax5.cit.cornell.edu> pniy@vax5.cit.cornell.
edu writes:
>> In article <AJC.92Apr2092400@thendara.pa.dec.com>,
>> ajc@pa.dec.com (AJ Casamento) writes:
>> >
>> > 3rd party disks can be a boot disk. Configuring it as such is more
>> > difficult (and for some drive manufacturer's firmware implementations,
>> > virtually unworkable). But, we're willing to work with any disk drive
>> > manufacturer to overcome this (we're working with three of them right
>> > now, but I'd be willing to hear from HP, Fujitsu, IBM, SUN and anybody
>> > else in the disk drive business as well).
>> >
>> So, what exactly is the probvlem?So, what exato get a Fujitsu disk
>> for the 240 that should be arriving soon, and would definitely
>> like to be able to boot from the disk. Surely "virtually unworkable"
>> is different from impossible, and since one doesn't boot often compared
>> to other uses of the disk, it shouldn't be such a problem. Is it just
>> entering in the drive parameters in the initial system installation?
>> Or what?
>> Arthur Smith
>> (asmith@icose.msd.anl.gov)
Arthur,
It really depends on the disk drive (and I don't have an answer for all
disk drives, just some of the ones that the vendors have been willing to
work on with us).
I'll try to keep this response to a low volume (you folks are undoubtedly
tired of having me go through these SCSI items over and over). The problem
is that consumers tend to believe that SCSI=SCSI=SCSI ad nauseum. That is
not true. Your choices can actually be: Shugart Systems Interface, SCSI-1
SCSI-1 with attention to the Common Command Set working document or SCSI-2
(and in the year-s to come, SCSI-3). And then there's the choice of a CAM
(Common Access Method) implementation for device driver.
DEC has worked very hard on bringing it's SCSI interface up to the most
current standards available. All of our DECstation/VAXstation hardware (from
the DS3100/VS3100 models forward) are SCSI-2 hardware. With Ultrix v4.2 you
can now get CAM SCSI for your software interface. There is no other system
vendor in the market today who has both (even though the CAM comittee included
representatives from the other major system vendors).
However, not all system vendors are at this level. And this leaves the SCSI
peripheral vendors with the problem of having firmware variants to match the
various levels provided by the system vendors. In addition to that, several
of the peripheral vendors are only just beginning to migrate their SCSI-1
devices to a SCSI-2 interface. Many of them miss items in the ANSI SCSI-2 spec
like a 250millisecond response time to a SCSI bus reset. The ANSI SCSI-1 spec
didn't have a time requirement written into it. Some of them miss it by a lot!
(We've got a scanner in house that takes 28 Seconds to respond to a bus reset).
An example of a virtually unworkable issue with a Fujitsu drive is that
"some" Fujitsu drives have a hardware strap that sets asynchronous or synchron-
ous data transfer mode. Now, the ANSI SCSI-1 specification didn't require that
a target (disk, tape, etc.) be able to negotiate synchronous. The ANSI SCSI-2
specification says that a device should be able to negotiate an SDTR (Synchron-
ous Data Transfer Request) or reject it. The hardware strap does neither. It
simply sets the drive in either asynchronous or synchronous data transfer mode.
Ultrix will automatically expect any third party drive to be asynchronous in
nature (the majority are and that was the low pain assignment for most of our
customers). This can be modified by an entry in the scsi_data.c file (or, if
you're running CAM, the cam_data.c file). However, at install/boot time, you
aren't running the device driver, only the console firmware. Since the SCSI-2
specification states that a target should be able to negotiate SDTR, the base
console firmware addresses the drive in an asynchronous fashion. Leaving the
synchronous negotiation to the operating system device driver once the system
is up and running.
Now, assuming that you paid good money for the performance on this disk
drive, you probably want it to run in synchronous mode. However, the only way
we can get this hardware implementation to run is in asynchronous. You may
not be happy with that answer, but we lived up to the ANSI SCSI-2 specification
in our interface.
If we didn't care about you or your business, I'd just let the answer stand
as it is. And, in fact, I can't guarantee a solution. However, if Fujitsu wants
to work on this issue with us, the TRI/ADD Program would be happy to do so. I
meant my previous post. We don't have an axe to grind about who you choose to
buy your SCSI peripherals from. We'll work with any System or Peripheral vendor
that wants to have their SCSI products up and running on DECstation/DECsystem
hardware (and we're working on staffing for the other platforms as well). I
wish that we had enough resources to step all of your through your questions
individually. However, if enough of you call Fujistu, HP, Sun, etc. and tell
them that you want them to work with us to have their hardware working on DEC
platforms, maybe we can solve each vendor once for all of you. That way, we
all win. You get the hardware you want. The other vendors get to sell their
hardware. And DEC sells the systems, software and maybe the service contracts.
That leaves us with a satisfied customer. And a satisfied customer is very
frequently a repeat customer.
Anyway, I hope that this clears things up for you somewhat.
Thanx,
AJ
p.s. By now, of course, none of you really believe me when I promise a "short"
posting...sigh.
**********************************************************************
* AJ Casamento "The question is not whether or *
* Digital's TRI/ADD Program not the opinions are mine; but *
* 100 Hamilton Ave. UCO1-B rather, which of my personalities *
* Palo Alto, CA 94301-1616 do they belong to?" *
* 415.853.6744 *
* ajc@decwrl.dec.com *
**********************************************************************
Technical Details
Message-ID:
<AJC.92Apr6185212@thendara.pa.dec.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!mips!mips!decwrl!pa.dec.com!granite.pa.dec.com!ajcReferences:
<1992Apr2.162301.29772@athena.mit.edu> <AJC.92Apr2092400@thendara.pa.dec.com> <1992Apr6.180341.11537@vax5.cit.cornell.edu>Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.dec Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!mips!mips!decwrl!pa.dec.com!granite.pa.dec.com!ajc From: ajc@pa.dec.com (AJ Casamento) Subject: Re: DECstation 5000/240 In-Reply-To: pniy@vax5.cit.cornell.edu's message of 6 Apr 92 18:03:41 EST Message-ID: <AJC.92Apr6185212@thendara.pa.dec.com> Sender: news@PA.dec.com (News) Organization: Digital Equipment Corporation References: <1992Apr2.162301.29772@athena.mit.edu> <AJC.92Apr2092400@thendara.pa.dec.com> <1992Apr6.180341.11537@vax5.cit.cornell.edu> Distribution: comp Date: 6 Apr 92 18:52:12 Lines: 115