ggm@brolga.cc.uq.oz.au (George Michaelson) (09/25/90)
I've just tried plugging a Fujitsu 2263SA 600Mb drive into my DS3100.
After downgrading the thing to SCSI I it passed test -c ok.
when I booted vmunix it hung the kernel probing the rz devices.
It also had to be SCSI device 0 to not hog the bus, irrespective of
internal jumper settings.
-Has anybody got any comments on getting this or other 3rd party drives
to work on a DS3100? It is known to work on the MIPS M120.
-George
--
G.Michaelson
Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
The University of Queensland, St Lucia, QLD Australia 4067. grr@cbmvax.commodore.com (George Robbins) (09/25/90)
In article <1990Sep25.083654.9716@brolga.cc.uq.oz.au> ggm@brolga.cc.uq.oz.au (George Michaelson) writes: > > I've just tried plugging a Fujitsu 2263SA 600Mb drive into my DS3100. > After downgrading the thing to SCSI I it passed test -c ok. > when I booted vmunix it hung the kernel probing the rz devices. > > It also had to be SCSI device 0 to not hog the bus, irrespective of > internal jumper settings. I'm not sure what you mean by "hog the bus" - I doesn't sound like you're getting enough action to judge this. Are you booting from some other drive temporarily change to unix number X? If so, can you get the system up without the new drive installed? You may have to change your config file as far as where root/swap/dump live (or use the generic kernel (maybe)). Have you gotten the drive to work as some other unit, with probing and newfs and all that? You might have to create an appropriate SCSI device entry to match the drive ID info in /sys/data/scsi_data.c, it might be a problem with some of those magic option bits. > -Has anybody got any comments on getting this or other 3rd party drives > to work on a DS3100? It is known to work on the MIPS M120. I recently plugged a pair of Conner CP3200's (200 MB each) into my pet DS3100. Not too surprisingly (DEC uses Conner drives w/DEC ID's), they worked without any problems, even with the default SCSI device description. Does anybody know the DEC part number for the internal drive mounting brackets, or a third party source that will sell just the brackets? -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
rwa@cs.athabascau.ca (Ross Alexander) (09/26/90)
About putting SCSI drives onto a DS[23]100 - I just stuck an AT&T DM300S (which is really an HP 97536T) and an Exabyte EXB-8200 onto my DS2100 running Ultrix 4.0 (plus mandatory patch). It all just worked the first time. DEC, take a bow :-) -- -- Ross Alexander rwa@cs.athabascau.ca (403) 675 6311 ve6pdq
ggm@brolga.cc.uq.oz.au (George Michaelson) (09/26/90)
grr@cbmvax.commodore.com (George Robbins) writes: >In article <1990Sep25.083654.9716@brolga.cc.uq.oz.au> ggm@brolga.cc.uq.oz.au (George Michaelson) writes: >> >I'm not sure what you mean by "hog the bus" - I doesn't sound like you're >getting enough action to judge this. Are you booting from some other >drive temporarily change to unix number X? If so, can you get the system >up without the new drive installed? You may have to change your config >file as far as where root/swap/dump live (or use the generic kernel (maybe)). If the device is switched on, and you boot rz(0,4)vmunix off the rz55, irrespective of what the SCSI daisychain number of the drive was, the kernel hung during the "device probe" phase. After approx 15 sec the drive could be heard to do a SCSI reset. I agree "hog the bus" was misleading but with most of the jumper/switch settings we tried, when the disk was anywhere but SCSI slot 0 it would respond to a test -c once, and then its green "I have the bus" light would stay on and thereafter test -c reported NO attached devices. Not even the CPU on slot 6!! >Have you gotten the drive to work as some other unit, with probing >and newfs and all that? no because You cannot "see" a device that is not switched on during kernel boot phase, and I cannot boot a kernel with the device switched on. >You might have to create an appropriate SCSI device entry to match the >drive ID info in /sys/data/scsi_data.c, it might be a problem with some >of those magic option bits. I have been sent an appropriate scsi_data.c by somebody in Switzerland. Im hoping to try it this afternoon but I think he should take the "glory" if it works & post the details, not me! George -- G.Michaelson Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 377 4079 Postal: George Michaelson, Prentice Computer Centre The University of Queensland, St Lucia, QLD Australia 4067.
braun@dri.com (Kral) (09/26/90)
In article <1990Sep25.083654.9716@brolga.cc.uq.oz.au> ggm@brolga.cc.uq.oz.au (George Michaelson) writes: > >I've just tried plugging a Fujitsu 2263SA 600Mb drive into my DS3100. > >-Has anybody got any comments on getting this or other 3rd party drives >to work on a DS3100? It is known to work on the MIPS M120. > Myself and one other customer in this area have MV3100's; we both started out with 2263S's as external SCSI drives. We discovered a cacheing bug in the drive's ROM which corrupted disk data (exact circumstances unknown). We were running Ultrix 3.x, the other guy was running VMS, presumable 5.x. Fuji claims to have a fix in a ROM upgrade. However, I gave back the drives and went for RZ56s, so I can't say whether this really fixed the problem. -- kral * 408/647-6112 * ...!uunet!drivax!braun * braun@dri.com That which does not kill us Makes us stronger - Nietzche
loganj@yvax.byu.edu (09/28/90)
> -Has anybody got any comments on getting this or other 3rd party drives > to work on a DS3100? It is known to work on the MIPS M120. We have two DS3100's booting from 600 MB HP (HP97548) drives and two other DS3100's booting from 1.2 GB HP (HP97549) drives. These are SCSI drives with five year warranties. So far we haven't had any problems. We obtained the 600 MB HP97548 drives for $2835 and the 1.2GB HP97549 for $3735 from Anthem Electronics of Salt Lake City, phone (801) 973-8555. Regards, jim loganj@yvax.byu.edu loganj@byuvax.bitnet
bernerus@utcrt2.utc.chalmers.se (Christer Bernerus) (09/28/90)
We have 2 Fuji's running on our DS3100, the thing to do is to disable syncronous SCSI on the disk. Then Ultrix boots fine here. Chris.
rsk@oldfield.tmc.edu (Rich Kulawiec) (09/28/90)
In article <1990Sep25.083654.9716@brolga.cc.uq.oz.au> ggm@brolga.cc.uq.oz.au (George Michaelson) writes: >-Has anybody got any comments on getting this or other 3rd party drives >to work on a DS3100? It is known to work on the MIPS M120. I've got four DS3100's connected to CDC Wren V's; in fact one of them has four of these drives plus an exabyte. Works like a champ. I'm running them without the cache-readahead bit turned on, by the way; my understanding is that the two ways to turn on that bit were (1) hook up the drive to a Sun-4 and use its disk formatter to enable the bit or (2) hook up the drive to a NeXT and use the program posted by Paul O'Neill some time ago. Well, I haven't got either machine, so my drives are still running without that bit set. -- Be seeing you, Rich Kulawiec rsk@cs.colostate.edu, rsk@ecn.purdue.edu, pur-ee!rsk
iglesias@draco.acs.uci.edu (Mike Iglesias) (09/28/90)
In article <9750@ccncsu.ColoState.EDU> rsk@oldfield.tmc.edu (Rich Kulawiec) writes: >I've got four DS3100's connected to CDC Wren V's; in fact one of them >has four of these drives plus an exabyte. Works like a champ. > >I'm running them without the cache-readahead bit turned on, by the >way; my understanding is that the two ways to turn on that bit >were (1) hook up the drive to a Sun-4 and use its disk formatter >to enable the bit or (2) hook up the drive to a NeXT and use the >program posted by Paul O'Neill some time ago. Well, I haven't got >either machine, so my drives are still running without that bit set. Under Ultrix 4.0, I've used /etc/rzdisk to change the "readahead cache disable" (RCD) bit on Maxtor drives. You want the bit to be 0 to enable the readahead cache. I used the following command: # /etc/rzdisk -c ask /dev/rrzxc where the 'x' in /dev/rrzxc is the drive number you want to tweak. I just check one of our 5000s with a CDC drive on it, and it appears that this bit is not in the same place as it is on the Maxtor drives (page 8 of the drive parameters), so I guess you're out of luck using rzdisk on CDC drives. Mike Iglesias University of California, Irvine Internet: iglesias@draco.acs.uci.edu BITNET: iglesias@uci uucp: ...!ucbvax!ucivax!iglesias
paul@caen.engin.umich.edu (Paul Killey) (09/29/90)
Other scsi problems include not having the switches set correctly on the drive that determine powering the scsi termination. If that is goofed up, so is the scsi bus, and you get the problem where you can't see the disk (or much of anything) on the bus. decs are more susceptible to that than are other brands. We run maxtor drives here (8380, 4380, 8760, lxt-200) on decs. Also have had luck with micropolis and cdc or seagate or whatever they are now. I've noticed that the bits controlling different read ahead/caching parameters seem to be different on different drives. I hacked up my own formatter. When you format your drives, you might as well change the zone (for bad block forwarding) to be a track, and not a cylinder. I think the sun formatter does this for you automagically. However, I noticed that formatting disks on a sun 3 (emulex whatever scsi controller) was kind of a loser, at least for running disks on the decs, because of other parameters it (silently) changes. rzdisk on 3.1 is a no-op for this, because you change the params with the -c thing, but then it goes ahead and ignores the modified params and formats the disk with the old (unchanged) saved params. I am going to do an exhaustive search of all scsi option combos and plot some results. I am still mystified as to why fast bus and fast disk do not add up to fast throughput. While I'm at it, changing disk from synch to asynch will fix some problems, but the real fix is usually getting newer firmware that fixes a bug involved in some size data transfers. E.g. level 9 dumps would hang, because of this, because of how dump would be seeking around and reading bits and pieces to see what should be saved. level 0 dumps did not hang because dump knew it had to save everything anyway, and skipped that part. Sometimes turning off cacheing is also a fix for that. --paul
grunwald@foobar.colorado.edu (Dirk Grunwald) (09/29/90)
it's on page 0x38, or decimal 56. Mine looks like this, and I have the read-ahead enabled. Could someone without read ahead enabled mail me theirs, or post it? That should indicate the bit to change. I suspect that you need to switch byte 0 from 0x10 to 0x11, but don't listen to me. Anyone have any documentation on this page? More output (y/n)? y Page 56 - unknown or unsupported page: PS 1 Page code 56 Page length 14 Byte 0 0x11 Byte 1 0xff Byte 2 0x40 Byte 3 0x0 Byte 4 0x0 Byte 5 0x0 Byte 6 0x0 Byte 7 0x0 Byte 8 0x0 Byte 9 0x0 Byte 10 0x0 Byte 11 0x0 Byte 12 0x0 Byte 13 0x0
gibson@b11.ingr.com (Stan Gibson) (10/04/90)
In article <270379F7.4803@orion.oac.uci.edu> Mike Iglesias <iglesias@draco.acs.uci.edu> writes: > >I just check one of our 5000s with a CDC drive on it, and it appears that >this bit is not in the same place as it is on the Maxtor drives (page 8 >of the drive parameters), so I guess you're out of luck using rzdisk >on CDC drives. CDC drives use mode select page 38 ( bit 4 of byte 2)to enable/disable read-ahead. This was commonly used among vendors of SCSI-1 drives. The SCSI-II spec defines the read-ahead page a page 8. The Maxtor drives support this page. Some of the XT8000's series Maxtors support BOTH pages.