rot@unlisys.in-berlin.de (Robert Rothe) (05/11/91)
hi, i have bad problems connecting a M2266SA (1.05GB) SCSI Disk to a Silicon Graphics Personal Iris 4D (Irix 3.3.1). when booting the machine says: sc0: Unexpected transfer phase. State= 4f Phase = 20 scsi (0,ID,0) transfer aborted (Hardware error) (when trying to open the device when the system is running, the system hangs for 30 seconds, and resets the scsi bus, [I/O Error]) what does this error mean ? is there any way to get this disk run under this system ? the disk runs fine (?) [passed diagostics] on a pc with adaptec aha1542b hostadapter. please respond soon via email. thanx, robert. -- Unlisys, Hohenzollerndamm 7, 1000 Berlin 31 --- Robert Rothe unido!fub!unlisys!rot, rot@unlisys.in-berlin.de, 030 / 88 22 980
rot@unlisys.in-berlin.de (Robert Rothe) (05/13/91)
rot@unlisys.in-berlin.de (Robert Rothe) writes: >i have bad problems connecting a M2266SA (1.05GB) SCSI Disk >to a Silicon Graphics Personal Iris 4D (Irix 3.3.1). >when booting the machine says: >sc0: Unexpected transfer phase. State= 4f Phase = 20 >scsi (0,ID,0) transfer aborted (Hardware error) well, to get the disk running it was necessary to 1. Disable the Synchronous TransferMode (CHN2, JP 8 (Pin15-16) open) 2. Open CHN2, JP 1 (Pin 1-2) (Inquiry Data). after these changes the system boots the first time without complaining.. but with _heaviest_ IO (cpio -p (reading from the fujitsu-drive) sometimes another error occurred: dks0d#s10: Unrecoverable device error: Internal controller error. To get rid of the message above it was necessary 3. To disable the Read-Ahead Cache ! (CHN3/9 JP 3 (Pin 5-6) open). 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 ? many thanx to merritt@climate.gsfc.nasa.gov (John H. Merritt) robert. -- Unlisys, Hohenzollerndamm 7, 1000 Berlin 31 --- Robert Rothe unido!fub!unlisys!rot, rot@unlisys.in-berlin.de, 030 / 88 22 980
kaufman@neon.Stanford.EDU (Marc T. Kaufman) (05/13/91)
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 supposed to be the boot driver for SUN Sparc Stations. I mean, the code could not even handle a Unit Busy response. Marc Kaufman (kaufman@Neon.stanford.edu)
merritt@climate.gsfc.nasa.gov (John H. Merritt) (05/14/91)
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."
tg@utstat.uucp (Tom Glinos) (05/14/91)
I too bought a 2266 in the hopes of connecting a BIG, FAST, and CHEAP drive to what is a relatively fast machine (4D220). The drive came configured from our vendor and it almost worked. A lot of hours later I had a drive that ran. But it ran SLOWWW. Top speed of about 900KB/sec. Way short of the rated 5MB/sec. Inspection of DKS(7M), Kernel Specifications (Tuning and Config Guide), and examination of the dksc.c (kernel scsi driver) all lead to you believe that you can run this drive in synch mode. The documentation states that you can get 1.25-2.5MB/sec (raw) through their SCSI adapter. Experimentation showed that running in synch mode was impossible. SGI had the following to say (heavily edited): "It's not really documented in the manuals-Sorry It might be in Marketing & Eng Spec sheets. . . . Synchronous SCSI is never enabled on IO2 or IP4 machines, because there would be no performance benefit. SCSI transfer rate is limited by how fast data can be pushed from the 3393 into memory, and not by how fast it can be pulled off the SCSI bus. Therefore, it was decided not to enable this feature, since the only thing it could do would be to cause problems." Yes, I too am sorry. Let's get with it SGI. Your manuals are incorrect. Let's get them fixed! (To be fair the cryptic remark in DKS should have set off warning bells) Still not satisfied I'm trying to get the very last drop of performance out of the drive. Why won't it run any faster than 900KB? The drive is rate for 2MB/sec in asynch mode. A call to Fujitsu indicated that "in my configuration 1MB/sec was a good number." The nuance of the phone call was that unless you had some VERY good SCSI equipement your aren't going to get anything near 2MB/sec. In addition there are all sorts of problems when trying to boot with our 3rd party exabyte on the bus as well. The moral of the story is that if you are planning your future storage needs and want to go SCSI then plan on buying a POWERCHANNEL (known as an IO3) or another 3rd party SCSI controller. ======================================================================= tom glinos | "I do not know of a crime man can not commit" tg@utstat.toronto.edu | some 13th century philosopher
jeremy@perf2.asd.sgi.com (Jeremy Higdon) (05/15/91)
In article <1991May14.151513.1347@utstat.uucp>, tg@utstat.uucp (Tom Glinos) writes: > I too bought a 2266 in the hopes of connecting a BIG, FAST, and CHEAP > drive to what is a relatively fast machine (4D220). > > The drive came configured from our vendor and it almost worked. > A lot of hours later I had a drive that ran. But it ran SLOWWW. > Top speed of about 900KB/sec. Way short of the rated 5MB/sec. The actual peak SCSI bus transfer rate of the drive is 4.8 MB/s, but this is only the SCSI bus rate, not the drive rate. The raw drive rate is 3.0 MB/s, but that does not account for intersector gaps, head switches, or single cylinder seeks. In actuality, the maximum sustained transfer rate off the media is about 2.1 to 2.2 MB/s for this drive (million byte MB).
herman@corpane.uucp (Harry Herman) (05/15/91)
In <41691@unlisys.in-berlin.de> rot@unlisys.in-berlin.de (Robert Rothe) writes: [stuff deleted] >well, to get the disk running it was necessary to >1. Disable the Synchronous TransferMode (CHN2, JP 8 (Pin15-16) open) [stuff deleted] >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 ? >many thanx to merritt@climate.gsfc.nasa.gov (John H. Merritt) > robert. >-- >Unlisys, Hohenzollerndamm 7, 1000 Berlin 31 --- Robert Rothe >unido!fub!unlisys!rot, rot@unlisys.in-berlin.de, 030 / 88 22 980 I don't know anything about the SGI, but in order to use synchronous SCSI, both the controller and the drive have to be willing to do it. We purchased a disk drive once that was willing to do synchronous SCSI, but since the controller was not willing to do it, we had to jumper it off. I also do not know if you can do both synchronous and asynchronous SCSI on the same cable or not. If not, then all drives on the cable AND the controller would have to be willing to do synchronous SCSI. Harry Herman herman@corpane
rmilner@zia.aoc.nrao.edu (Ruth Milner) (05/16/91)
In article <5315@dftsrv.gsfc.nasa.gov> merritt@climate.UUCP (John H. Merritt) writes: >For the M2266, this means formatting with 1642 data cylinders, >2 alternates, 15 heads, 85 sectors/track. >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. I have a 2266 on a SPARC IPC running SunOS 4.1.1, formatted with 1650 data cylinders. It is set up as one big partition, and newfs had no problems with it, but only a few hundred MB have been used so far. Does anyone have further information on the Sun patch referred to? I would not like to see data overwritten if I can help it. Thank you. -- Ruth Milner Systems Manager NRAO/VLA Socorro NM Computing Division Head rmilner@zia.aoc.nrao.edu
rlr@alumni.colorado.edu (Roger Rose) (05/16/91)
> I don't know anything about the SGI, but in order to use synchronous > SCSI, both the controller and the drive have to be willing to do it. > We purchased a disk drive once that was willing to do synchronous > SCSI, but since the controller was not willing to do it, we had to > jumper it off. ... If the drive and the host have properly implemented the message system, you shouldn't have had to jumper this out. If someone sends a sync negotiation message to a device that only does async, the recipient should either reject the message or reply with a zero offset. The sender should interpret either of these actions as a request for async. > I also do not know if you can do both synchronous > and asynchronous SCSI on the same cable or not. If not, then all > drives on the cable AND the controller would have to be willing to > do synchronous SCSI. There's no reason not to intermix on a cable as far as the SCSI spec goes. In fact, a single target should be able to talk sync to one device and async to another (and sync with different parameters to a third) and keep everything straight. The sync parameters are supposed to be maintained on a per I_T nexus. This is necessary even on a single-host bus, if the COPY command is used to transfer data across the bus. -- Roger Rose {rlr@boulder.colorado.edu}
chap@art-sy.detroit.mi.us (j chapman flack) (05/22/91)
In article <1991May15.001955.4146@corpane.uucp> herman@corpane.uucp (Harry Herman) writes: >We purchased a disk drive once that was willing to do synchronous >SCSI, but since the controller was not willing to do it, we had to >jumper it off. I also do not know if you can do both synchronous >and asynchronous SCSI on the same cable or not. If not, then all >drives on the cable AND the controller would have to be willing to >do synchronous SCSI. Did the drive actually not work until you disabled synchronous negotiation? If so, that sounds like a bug. Sync. negotiation, as I understand it, is exactly as it sounds: the first time two devices (say, a disk and a host adapter) talk to each other after a reset, they discuss whether they're both willing to do synchronous, and how big a sliding window each is willing to support. If they decide they don't wanna do sync, they do async. There shouldn't be any problem with sync and async on the same bus--art-sy is humming away that way just fine... -- Chap Flack Their tanks will rust. Our songs will last. chap@art-sy.detroit.mi.us -MIKHS 0EODWPAKHS Nothing I say represents Appropriate Roles for Technology unless I say it does.
jesup@cbmvax.commodore.com (Randell Jesup) (05/25/91)
In article <5315@dftsrv.gsfc.nasa.gov> merritt@climate.UUCP (John H. Merritt) writes: >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 Commodore Amiga scsi drivers for the A590, A2091, and A3000 had the same problem. The next (RRSN) A3000 release (and the current A3000 developer betas) have the fix for the internal SCSI controller. There will be a new rom that will be available at some point for A2091 and A590 HD controllers which fixes the 1gig problem (note: 6.6 roms do NOT fix the problem). Seems like most people got caught by this one. Our drivers already had code for using 10-byte reads/writes if a larger-than-256-block transfer was requested, so the modification was trivial. -- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. "No matter where you go, there you are." - Buckaroo Banzai
jesup@cbmvax.commodore.com (Randell Jesup) (05/25/91)
In article <1991May14.151513.1347@utstat.uucp> tg@utstat.uucp (Tom Glinos) writes: > Synchronous SCSI is never enabled on IO2 or IP4 machines, because > there would be no performance benefit. SCSI transfer rate is > limited by how fast data can be pushed from the 3393 into memory, > and not by how fast it can be pulled off the SCSI bus. Therefore, > it was decided not to enable this feature, since the only thing > it could do would be to cause problems." >Still not satisfied I'm trying to get the very last drop of performance >out of the drive. Why won't it run any faster than 900KB? The drive is >rate for 2MB/sec in asynch mode. > >A call to Fujitsu indicated that > "in my configuration 1MB/sec was a good number." > >The nuance of the phone call was that unless you had some VERY good >SCSI equipement your aren't going to get anything near 2MB/sec. Well, the 33c93a can run an ST1480N and a Q210S at full bore at the same time (both running disk performance tests (DiskSpeed 3.1)). The 1480 gets between 1.5 and 2.0MB/s and the quantum gets 700-900K/s (at the same time!) That's on an Amiga A3000, 25Mhz '030, WD33c93a SCSI chip, with Commodore custom DMA/FIFO chip(s) transferring the data to memory with longword DMA cycles. BTW, those speeds above are through the filesystem, which generates direct DMA reads for large aligned transfers when possible. Their interface to the 33c93 might be inefficient (PIO a byte at a time, perhaps). Perhaps the 33c93 is far slower than the 33c93a. -- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. "No matter where you go, there you are." - Buckaroo Banzai
olson@anchor.esd.sgi.com (Dave Olson) (05/26/91)
In <21924@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: | In article <1991May14.151513.1347@utstat.uucp> tg@utstat.uucp (Tom Glinos) writes: | > Synchronous SCSI is never enabled on IO2 or IP4 machines, because | > there would be no performance benefit. SCSI transfer rate is | > limited by how fast data can be pushed from the 3393 into memory, | > and not by how fast it can be pulled off the SCSI bus. Therefore, | > it was decided not to enable this feature, since the only thing | > it could do would be to cause problems." | | >Still not satisfied I'm trying to get the very last drop of performance | >out of the drive. Why won't it run any faster than 900KB? The drive is | >rate for 2MB/sec in asynch mode. | > | >A call to Fujitsu indicated that | > "in my configuration 1MB/sec was a good number." | > | >The nuance of the phone call was that unless you had some VERY good | >SCSI equipement your aren't going to get anything near 2MB/sec. Hmm; I must have missed this. Just to clarify an earlier statement, the 1Mb/sec limit is only on the older machines, and is NOT in the SCSI chip or cable side, but rather in the DMA interface. When it was designed, the hardware engineers never thought that SCSI devices would go faster than 1Mbyte/sec (or at least didn't worry about it). Remember that this was 3 or 4 years ago. Newer machines from ASD with the Power Channel I/O board go full 5Mb/sec (burst), as do ALL of the 4D20, 25, 30, and 35 machines from ESD. Well, actually the older 20's had some non-optimal DMA hardware and timings, due to some last minute changes in the wd 33C93 chip that our designers didn't hear about, so they won't go full speed. With suitable devices (such as SCSI ram disks), we measure sustained (over many Mbytes) transfer rates of > 4.25 Mbytes/s. Drives like the Fujitsu and Wren VII, or any newer drive, should run at full drive speed on the PI's, or ASD machines with the newer I/O board. This is true of both filesystem and raw transfers. | Well, the 33c93a can run an ST1480N and a Q210S at full bore at the | same time (both running disk performance tests (DiskSpeed 3.1)). The 1480 | gets between 1.5 and 2.0MB/s and the quantum gets 700-900K/s (at the same | time!) That's on an Amiga A3000, 25Mhz '030, WD33c93a SCSI chip, with | Commodore custom DMA/FIFO chip(s) transferring the data to memory with longword | DMA cycles. BTW, those speeds above are through the filesystem, which | generates direct DMA reads for large aligned transfers when possible. | | Their interface to the 33c93 might be inefficient (PIO a byte at a | time, perhaps). Perhaps the 33c93 is far slower than the 33c93a. No SGI machines have EVER done SCSI via PIO. All SCSI i/o is always via DMA, no matter how many bytes (or how few). -- Dave Olson Life would be so much easier if we could just look at the source code.
jeremy@perf2.asd.sgi.com (Jeremy Higdon) (05/29/91)
In article <21924@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes: > In article <1991May14.151513.1347@utstat.uucp> tg@utstat.uucp (Tom Glinos) writes: > >Still not satisfied I'm trying to get the very last drop of performance > >out of the drive. Why won't it run any faster than 900KB? The drive is > >rate for 2MB/sec in asynch mode. > > > >A call to Fujitsu indicated that > > "in my configuration 1MB/sec was a good number." > > > >The nuance of the phone call was that unless you had some VERY good > >SCSI equipement your aren't going to get anything near 2MB/sec. > > Well, the 33c93a can run an ST1480N and a Q210S at full bore at the > same time (both running disk performance tests (DiskSpeed 3.1)). The 1480 > gets between 1.5 and 2.0MB/s and the quantum gets 700-900K/s (at the same > time!) That's on an Amiga A3000, 25Mhz '030, WD33c93a SCSI chip, with > Commodore custom DMA/FIFO chip(s) transferring the data to memory with longword > DMA cycles. BTW, those speeds above are through the filesystem, which > generates direct DMA reads for large aligned transfers when possible. > > Their interface to the 33c93 might be inefficient (PIO a byte at a > time, perhaps). Perhaps the 33c93 is far slower than the 33c93a. This disk (2266SA) on a 4D/200 (and up) with PowerChannel (IO3) or 4D/25 or 4D/35 should get 2.1 or 2.2 MB/s through the filesystem. On a machine with an IO2 (4D/100 and up without PowerChannel), 900KB is actually pretty good. When the IO2 was designed, the fast disks were on VME (SMD and ESDI), so 900KB/s was considered good enough for SCSI. The IP4 is actually a little faster. You would probably get about 1.1MB/s.
sgf@cfm.brown.edu (Sam Fulcomer) (05/29/91)
In article <106450@sgi.sgi.com> jeremy@perf2.asd.sgi.com (Jeremy Higdon) writes: > >This disk (2266SA) on a 4D/200 (and up) with PowerChannel (IO3) or 4D/25 >or 4D/35 should get 2.1 or 2.2 MB/s through the filesystem. On a Well, given a gentle enough test, perhaps (but I'd be more inclined to believe 2.0MB/s through the EFS even with a gentle test...). The theoretical maximum sustained transfer rate for the drive should be a bit less than 2.5MB/s (the speed of the media under the head), and once you drop in switch time, seeks and rotational latency, the rate drops a bit more. By a gentle test I mean reads of big chunks from a fairly contiguous file. The EFS is great for big chunks, however once the chunk size drops the FFS becomes a more efficient beast.. I'd think a more realistic expectation would be 2MB/s for reading big chunks of file with fat extents. 1.6MB/s ought to be about right for mixed r/w in large chunks, and 2.2MB/s for reading from rdisk. Mixed r/w's of small chunks can get a little ugly... -- _/**/Sam_Fulcomer sgf@cfm.brown.edu What, me panic: uba crazy Associate Director for Computing Facilities and Scientific Visualization Brown University Center for Fluid Mechanics, Turbulence and Computation