Xref: utzoo comp.sys.sgi:10063 comp.periphs.scsi:2593 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!haven.umd.edu!mimsy!dftsrv!climate!merritt From: merritt@climate.gsfc.nasa.gov (John H. Merritt) Newsgroups: comp.sys.sgi,comp.periphs.scsi Subject: Re: < Connecting Fujitsu M2266SA to SGI SCSI (SOLVED) > Message-ID: <5315@dftsrv.gsfc.nasa.gov> Date: 13 May 91 17:55:31 GMT References: <41530@unlisys.in-berlin.de> <41691@unlisys.in-berlin.de> <1991May13.160731.6804@neon.Stanford.EDU> Sender: news@dftsrv.gsfc.nasa.gov Reply-To: merritt@climate.UUCP (John H. Merritt) Organization: Goddard Space Flight Center Climate and Radiation Branch Lines: 115 In article <1991May13.160731.6804@neon.Stanford.EDU> kaufman@neon.Stanford.EDU (Marc T. Kaufman) writes: >In article <41691@unlisys.in-berlin.de> rot@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@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@mprgate.mpr.ca> parker@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@ee.lbl.gov John H. Merritt --> merritt@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."