< Connecting Fujitsu M2266SA to SGI SCSI (SOLVED) >

[John H. Merritt]

In article <1991May13.160731.6804 at neon.Stanford.EDU> kaufman at neon.Stanford.EDU (Marc T. Kaufman) writes:
>In article <41691 at unlisys.in-berlin.de> rot at unlisys.in-berlin.de (Robert Rothe) writes:
>
>>the drive runs fine so far..
>>but i wonder why i have to slow down the device soo much to get it running
>>with the sgi-machine ? is it the fault of the disk, the scsi-driver or the 
>>scsi-adapter ?
>
>Well, I don't know about SGI's drivers, but I was absolutely appalled to see
>that there was essentially no code to recover from errors in a driver that is

I found these articles in another news group and I am providing them here
for informational purposes.  

---- cut ----
In an attempt to stem the flood of responses to my query
(*not* that I'm complaining!!! :-) I'm summarizing what
I've found out about 1.2Gb disks and Sun (and DEC) systems.

First - There's a firmware bug on the Fujitsu M2266 drive
that makes it imperitive to disable the drive's read-ahead
cache (jumper 5-6 on bank CN3/CN9). Fujitsu is apparantly
distributing upgraded proms (to their distributors... contact
the vendor you bought the drive from) that fix the problem.
This problem is only apparant on Sun systems, and causes a
large number of read errors on the drive.

Second - There's a problem with the M2266 being on a SCSI bus
with other devices. We've found that if the drive is on a
bus with tape drives (either 1/4" or exabyte), the drive must
be first on the bus. This might be linked to termination in
some way, though others have had the same problem.

Third - When the drive is formatted, parameters must be
carefully chosen to keep the addressing within SCSI-1 limits.
For the M2266, this means formatting with 1642 data cylinders,
2 alternates, 15 heads, 85 sectors/track. This is 16 cylinders
short of the full disk capacity. We did have this information
direct from Fujitsu when we installed the disk initially.
This limitation works fine on a Sun. Apparantly, however,
DEC systems wrap around when they reach high sector addresses,
and scribble on the beginning of the disk. This happened to
us last week (with a different M2266 drive) on a DECstation
5000 - we'd attributed it to another cause, but it caused us
some grief.

Apparantly, DEC will extend their addressing with Ultrix 4.2,
and I've heard rumours from Sun tech support that there's a
patch available for SunOS that allows the same support in
SunOS 4.1.1.

Also, contrary to what some people have reported, the drive
*does* work fine in synchronous mode on a SPARCstation 2 (and
on a 1+ as well). The problem some people have seen with
synchronous mode might be related to the SCSI bus ordering
(the second point above).

I hope this clears up some of the questions that people had...

-- 
Ross Parker			| Why do they put me down?
				| Make out that I'm a clown?
parker at mprgate.mpr.ca		| I drink scotch whisky all day long
uunet!ubc-cs!mprgate!parker	| Yeah I'm gonna save my money
				| (gonna put it all away...)
(604)293-5495			| 'Cause I'm a Scotsman



In article <1991May9.191941.2377 at mprgate.mpr.ca> parker at mprgate.mpr.ca (Ross Parker) writes:

>   I've set up a Fujitsu 2266 disk on a Sun SPARC 2 system, and
>   am experiencing some problems.

>   The numbers I've used to format the drive (on the advice of
>   Fujitsu) are: 1642 cylinders, 2 alternates, 15 heads, 85
>   sectors. The disk logic can actually address 1658 cylinders
>   (plus alternates), but Sun's format chokes with that.

>   I'm running SunOS 4.1.1 on the SPARC 2.

Well, if it's worth anything my new Fujitsu 1.2 GB (can't find the
model number off hand - sorry!) came formatted at 1653 2 15 85, I
reformatted it with the same values on a Sparc 2 and it's been running
on an IPC as its main drive for a month with no problems. Both running
4.1.1

John



The `magic limit' for old SCSI is 2 097 152 blocks.  These drives have
512-byte blocks, so that is 1 073 741 824 bytes.  This limit occurs
because the 6-byte SCSI read and write commands store the block number
in 21 bits.

The solution is to use the 10-byte SCSI read and write commands, which
have a 32 bit field and can address 4 294 967 296 blocks or, with 512
byte blocks) 2 199 023 255 552 (2 terabytes).  With 1024 byte blocks
the addressibility doubles; the 10-byte command are unlikely to be a
problem for some time.

How many SCSI disk controllers (targets) do *not* support 10-byte
commands?  My driver assumes all disks do, for now, but it would be
easy to choose 6-or-10 based on the capacity returned or, if necessary,
each block number.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov


              John H. Merritt --> merritt at climate.gsfc.nasa.gov
              Applied Research Corporation at NASA/GSFC
              "I am generally intolerant of ignorance,
               but I have made an exception in your case."