Hi again,
getting a small load of of old powermacs yesterday for free, i decided, finding a powermac 7100/66 amongst only of minor interest, to scrap it for spares. My intention is to use its harddrive (Quantum ProDrive LPS [is 800-08-97 some kind of produkt label?]) in order to revive a dead NeXTStation collecting dust in a shelf.
So my problem would be first configure it and second how to configure it :D Meaning has anyone any kind of idea how to set the jumpers on this drive or where to obtain such information as well as which scsi id should be set for the internal drive - i think to remember reading somwhere 6 would be ideal for some reason? i myself i#m not that familiar with the finer workings of scsi. :(
I've got all mine set to ID 0 for the internal drive. The biggest trick will be to get the OS to recognize it correctly, but if it's 4GB or less that shouldn't be too hard.
If it's 9/18/36, you'll have to partition, newfs and BuildDisk from an existing NeXT, probably - but there may be someone here who knows how to make a large disk dance during installation. (Also note that OPENSTEP handles large disks a bit better than NeXTSTEP, but over 36GB will end up with googobs of wasted space.)
Hello.
It doesn't matter that much what SCSI ID You are going to use for the internal positioning. NeXTstep is just looking for a bootable device the other way around as most other SCSI computers do: it starts with the highest ID down to the lowest. So if You decide to use ID 6 it will most likely the first device that the system will recognize - depens on the boot parameters You have configured.
There are several documents from Quantum about their jumper settings. But one problem exists with most Quantum drives: they just have a jumper position for termination in general but non for the type of termination. As long as a NeXTstation can only use one internal drive on the SCSI chain this one has to be terminated and it has to provide termination power from the drive - and exactly this last oneoption is missing at most Quantum drives I know. I've been testing several Quantum drives in my machines and none of them worked when they were the only ones in a NeXT-System.
But I think others made differnt experiences with this...
If You are going to try this Quantum drive anyway I would advise to use a SCSI cable with at least two plugs for drives, one is holding the SCSI drive and the other one an active termination plug, of course the third plug connects to the mainboard. I didn't try this because in lack of such a termination plug for flat SCSI cables but it sounds very logically to me. By the way: most PPC Macs had some sort of active SCSI termination on their mainboard (more exactly the SCSI controller) and that is why most PPC Macs using Quantum drives weren't in need of a dedicated jumper termination on the drive itself.
J
Quote from: "PowerPC"Meaning has anyone any kind of idea how to set the jumpers on this drive...
If you read me the jumper labels, then I can probably help, otherwise look here:
http://www.peripheral.com/manuals/quantum_ucg.pdf
Quote from: "Jenne"NeXTstep is just looking for a bootable device the other way around as most other SCSI computers do: it starts with the highest ID down to the lowest. So if You decide to use ID 6 it will most likely the first device that the system will recognize
That information is incorrect. The device enumeration [bsd (x,0,0)] is based on SCSI ID. So the lowest SCSI ID (it doesn't matter if it's 0, or 1, or 2, etc up to 6), will be assigned DEVICE ID 0 [the x, as in bsd(0,0,0)]. The second lowest SCSI ID (say it's 5) will be assigned DEVICE ID 1 [the x, as in bsd(1,0,0)]. Assignment is always from lowest to highest.
As for termination power (from drive, to drive, or from bus), my memory is betraying me, although usually a safe bet is "from drive" and I believe NeXT docs said to set it to "from bus" for cube internals. Check the NeXT docs on channelu.com/NeXT/ because I don't recall at the moment.
Quote from: "da9000"That information is incorrect. The device enumeration [bsd (x,0,0)] is based on SCSI ID. So the lowest SCSI ID (it doesn't matter if it's 0, or 1, or 2, etc up to 6), will be assigned DEVICE ID 0 [the x, as in bsd(0,0,0)]. The second lowest SCSI ID (say it's 5) will be assigned DEVICE ID 1 [the x, as in bsd(1,0,0)]. Assignment is always from lowest to highest.
Well, not incorrect, but misunderstandable, now as I'm reading it. It is not NextStep that does that SCSI ID Check from 6 down to 1 or whatever, it is the SCSI controller of the hardware that starts "calling" devices from the highest ID down to the lowest. You are absolutly correct about the bsd settings, anyway.
Quote from: "da9000"As for termination power (from drive, to drive, or from bus), my memory is betraying me, although usually a safe bet is "from drive" and I believe NeXT docs said to set it to "from bus" for cube internals. Check the NeXT docs on channelu.com/NeXT/ because I don't recall at the moment.
Now this is strange to me. I tried many times to set the termination power from bus within my cube but that never worked. Only combination confirmed working was the termination power from drive but as long as I never managed to get more than one drive working within the cube and that one uses a "buggy" SCSI controller chip I think I should try that way of termination once more, maybe this will allow more drives in my cube.
Thanks for the hint!
J
Quote from: "Jenne"it is the SCSI controller of the hardware that starts "calling" devices from the highest ID down to the lowest. You are absolutly correct about the bsd settings, anyway.
Jenne, either I don't understand what you're saying or I don't know of any SCSI controller that goes from a high SCSI ID to a low one. All SCSI controllers that I have ever come in contact with, including the NCR53cxx of the NeXT machines goes from SCSI ID 0 to SCSI ID 7 and assigns those to DEVICE IDs.
And to clarify for all:
There are 2 sections that concern SCSI devices during boot up:
1) Hardware. This is what I wrote above, and the whole SCSI ID vs DEVICE ID issue. In order for a NeXT machine to use the desired boot device you have to specify the correct bsd(x,0,0) command or make sure the boot device is the first scanned by the SCSI bus, which means it has to have the lowest SCSI ID (opposite of what Jenne wrote at the top, and to which I responded before).
2) Software. Once you've instructed the hardware/firmware/EEPROM/BIOS/CMOS/whatever you want to call it to use the appropriate boot device, it then reads the kernel file (sdmach for for SCSI devices and odmach for Optical disk devices) and mount the ROOT FILESYSTEM. It then uses DEVICE FILES to access the rest of the disk and/or filesystem. DEVICE FILES are things such as /dev/rsd0a or rsd1a, etc, where the X in /dev/rsdXa should be equivalent to the DEVICE ID in the hardware section. Therefore, if your boot SCSI ID is 1, and it's the first device (there's no device with SCSI ID 0), then its DEVICE ID is 0, which means the DEVICE FILE (in the boot command "bsd(X,0,0)sdmach rootdev=/dev/rsdXa", or in /etc/fstab) should contain a zero (0), as in /dev/rsd0a. The previous assumed that your root filesystem resides in your boot device.
Here, I found the appropriate section (the term they use is "Device number"):
. Determine the device number and name of the newly attached hard disk.
Each SCSI device is assigned a device number at boot time. The SCSI device with the lowest SCSI ID is assigned device number 0; the SCSI device with the next lowest ID is assigned device number 1; and so on. The device name of a disk with device number n is /dev/sdna. So, a disk with device number 1 is /dev/sd1a. Here's an example that matches SCSI IDs with device numbers:
SCSI ID Device Number
1 0
3 1
6 2
It's here:
http://www.channelu.com/NeXT/NeXTStep/3.3/nsa/07_Peripherals.htmld/index.html#7aAnd a related topic:
http://www.channelu.com/NeXT/NeXTFAQ-html/NeXTFAQ.060.htmlQuote from: "Jenne"
Now this is strange to me. I tried many times to set the termination power from bus within my cube but that never worked. Only combination confirmed working was the termination power from drive but as long as I never managed to get more than one drive working within the cube and that one uses a "buggy" SCSI controller chip I think I should try that way of termination once more, maybe this will allow more drives in my cube.
Thanks for the hint!
It's strange to me too Jenne, but I can't help much more at this moment and without trying the exact combination myself. But I'll try. Let me look at the docs for the termination issue...
OK, I didn't find it this time. I might have been either in the installation manual or NeXT Answers (anyone know if they're available as web pages on a server? I know you can find them either in the peak archives or the nextcomputers.org files section as a tar-ball). Other than those two sources, check here, although I don't have time to read at the moment:
http://groups.google.com/group/comp.sys.next.hardware/search?hl=en&group=comp.sys.next.hardware&q=termination+power&qt_g=Search+this+groupGood luck
Quote from: "Jenne"Only combination confirmed working was the termination power from drive but as long as I never managed to get more than one drive working within the cube
Two things:
1) "from drive" should usually be a safe bet, because drives are powered, and if they've got the switch/jumper it most likely does what it says it does
2) I read, but have not had much experience with this, that *ONLY 1* drive must be set to power "from drive". The other drives in the chain should not supply power to the bus. Perhaps this was the missing key? Did you try it like so?
Quote from: "da9000"Jenne, either I don't understand what you're saying or I don't know of any SCSI controller that goes from a high SCSI ID to a low one. All SCSI controllers that I have ever come in contact with, including the NCR53cxx of the NeXT machines goes from SCSI ID 0 to SCSI ID 7 and assigns those to DEVICE IDs.
I've been reading this several times in different documents I own and of course on the internet: any NeXT-system checks the SCSI chain from the highest ID down to the lowest meaning that the system begins looking for a drive with ID 7 first, further on to 6, down to 5 and so on. When I do have some time I will write it down here along with the necessary source notes. As long as this is stated for -> any <- NeXT-system as far as I remember I think this unusual way of checking the SCSI chain must be located somewhere in the hardware and not in the OS.
To get some sort of confirmation to what I read and what I remember I've been doing a little bit of testing yesterday night. I pulled the hard drive off my slab and connected an MO, a Zip and a Jaz externally. I inserted the matching media into every drive after setting the SCSI IDs as follows (and of course I double checked the correct termination):
MO: 1
Zip: 3
Jaz: 6
The physical order of the drives in chain was as follows (from first position closest to the slab's SCSI port down to the farest):
MO (bootable NeXTstep on it)
Zip (just some files)
Jaz (bootable NeXTstep on it)
Now I waited until the drive medias spinned down and then I started the slab. I began to watch the drives' LEDs very closely. As long as those ones are pretty slow compared to hard drives I gave this setup the best chance for my testing. Guess what: the first LED blinking was that of the Jaz! Physically last in chain! Of course it took the MO as boot device, the boot parameters were set this way.
So I changed the setup for further testing. As long as I understood the boot parameters as taking the drive with the lowest SCSI ID as a bootable drive (when there is a bootable system on it) I exchanged the media in all drives: no bootable OS on any of them. Again, the Jaz LED was the first one to blink.
Again, I changed the setup: I moved the Jaz to position 1 (closest to the slab) the Zip in the middle and the MO at the end of the chain. Again, the Jaz LED blinked as the first one!
This is strange to me, too but it corresponds to what I read. I've been dealing with SCSI voodoo on Macs many times in so far I do not wonder about any strange SCSI behaviour but I still don't understand why I can not use two or more drives in my cube.
Maybe I'm going to test my setup once again with my cube and my color slab, maybe there something will be different.
J
Alright, now I see what you're talking about. You're talking about the PHYSICAL scan order. I was talking about the LOGICAL scan order or I guess more correctly "reporting" order. But the important part is that the physical order does not matter in the end. It's the logical that is used as the basis for assigning DEVICE IDs (or Device Numbers), and then those are used for looking for bootable partitions, from 0 to 1 to 2, to 3, for 4 devices, etc, up to 6 for 7 devices.
I like your method for testing, btw. Was the Zip the 2nd in order, and the MO the 3rd in order? You didn't say.
Now, as far as your cube problems, did you try my second post about having only 1 drive with termination "from drive" ?
Quote from: "da9000"I read, but have not had much experience with this, that *ONLY 1* drive must be set to power "from drive". The other drives in the chain should not supply power to the bus. Perhaps this was the missing key? Did you try it like so?
I tried many combinations:
at any time any drive at the physically LAST position at the SCSI cable was terminated on the drive itself and it was always the only drive that dealt with termination in any way - all other drives where not dealing with termination in any way.
After some time I got rid of older Quantum drives. These can only be terminated but the kind of termination can not be set via jumpers. So I began to test those somewhere in the middle of the SCSI cable, sometimes with higher, sometimes with lower SCSI IDs as the drive with the termination set to power from drive: at no time any of my 5 (!) Quantum drives was recognized. So I moved over to Seagates (damn, what a noise trying three of them in a cube!). No change. Just the drive with termination set was recognized.
So I tried several CD drives at the end and at the middle of the SCSI cable. When using a low SCSI ID it was recognized, but not the hard drive. The other way around when the CD had a higher ID than the hard drive: not recognized.
For some strange reason it doesn't matter how many drives I use -> externally <- , those are all recognized!
J
Strange indeed... Did you list the drive models in another thread? I don't recall, but list them at least once and if I have any similar drives and time I'll definitely try to cross-check your findings Jenne.
Just double-checking: I assume you also tried different cables? Sometimes you never know...
I always reduce SCSI troubles to hardware first before searching an error within the software - especially my old UMAX Pulsar was a very intense teacher for me in this ;-)
Regarding the cables I tested about four different ones as long as the cube's cable doesn't provide many possibilities to connect drives to it but thatt didn't change anything.
To describe my testing setup in the more visual way:
First testing:
Slab (no HD) -> MO (ID 1, NeXTstep) -> Zip (ID 3, Files) -> Jaz (ID 6, terminated, NeXTstep)
Second testing:
Slab (no HD) -> MO (ID 1, Files) -> Zip (ID 3, Files) -> Jaz (ID 6, Files, terminated)
Third testing:
Slab (no HD) -> Jaz (ID 6, Files) -> Zip (ID 3, Files) -> MO (ID 1, Files, terminated)
The longer I think about it the more I begin to think about the KIND of termination. Within this testing I always used an active termination block connected to the housing of the specified drive and not a termination setting via jumpers. I don't know what KIND of termination this active block provides but it must be different somehow from the possibility to define the termination kind on the drive itself. As long as "ready made" Zip and Jaz drives only provide ID 5 and 6 I can not set them to ID 3 or 2 for example, so I had to use my internal Zip and Jaz built into older metal housings. Maybe I will try this testing again with "ready made" Iomega drives and only with ID 5 and 6 sometime...
J
Just another comment:
I do not own one of these termination blocks that can be placed at the end of an -> internal <- cable, I only own those that can be connected to housings. Maybe I manage to get me one of these internal ones, perhaps this will be a solution to my cube chain problems but I fear it will be nearly impossible to find one of these cable terminators...
J
Jenne, you forgot to tell me which device lights came on after the Jaz drive :p
As for termination, as far as I know when a drive has termination on it (usually all or most SE drives, but of course no LVD drives), then it's *not* an active termination. Also to clarify, the terms "termination power" and "from drive", "to bus", "from bus", etc are refering to just powering the terminators, active or not (I'm not sure where active terminators get their power, but most likely from the same source as non-active, therefore at least 1 device, drive or chipset *has* to provide termination power no matter what).
Anyhow, active termination is superior, so yes, using active terminators would make many such problems go away. I actually have an "internal" terminator for putting it on the inside chain, but unfortunately it's not active and you're all the way in Switcherland. Kinda far... If you can get your hands on a 50pin active terminator, that would be the best, I believe, for checking these kinds of problems.
Oh, silly me...
Ok, now the order of the blinking lights... It was always the same order, no matter which testing setup I used, because I didn't change the SCSI ID of the dedicated drive:
First: Jaz
Second: Zip
Third: MO
This also corresponds to the physical scan of the chain from "top" to " bottom". Maybe I will have to re-check this when using other IDs.
J
Quote from: "Jenne"This also corresponds to the physical scan of the chain from "top" to " bottom"
That's what I wanted to confirm ;)
Confirmed.
:D
J