First of all lots of "Thank You"s to NeXTchef who gave me the most needed hint!
Problem: after installing NS 3.3 on almost any available and compatible Seagate or Quantum harddisk I always faced the problem to get dropped into the boot manager after a clean and complete install. Sometimes it said "SCSI BUS HUNG", sometimes it only booted while the external CD drive connected, sometimes nothing happened at all.
One of the things I was thinking about had to do with the correct SCSI ID and SCSI termination. In fact I had to deal with those many years while using Apple hardware but I never was used to NeXT-specific topics on this.
What I messed up:
While SCSI guidelines always prey that every SCSI ID has to be provided only once on a special BUS I was beginning to wonder about the fact that the boot command
bsd (0,0,0)
is somewhat colliding with the installation boot command
bfd (0,0,0)
starting the installation from the floppy drive in combination with any compatible CD drive. Regarding the numbers "0,0,0" I was always wondering how this can work as long as the floppy drive and any harddisk are adressed through these boot parameters as SCSI ID "0". As long as the harddisk and the floppy drive are connected to the same mainboard inside a NeXTstation this could only mean a collision of SCSI IDs - and that is why I always got dropped into the boot manager.
Now after setting the harddisk ID to "1" with jumpers everything wors as expected!
Thanks again to NeXTchef I also noticed that almost every Seagate HD I own has to be terminated and has to obtain the termination power from the drive itself (both to be configured with jumpers, too).
Now I own about 6 HDs with clean installed NeXTstep 3.3. Once again: lots of You know what to
NeXTchef!
J
Glad I could help someone else out for a change. :)
Lord knows I have asked my fair share of questions here, and someone has always been there with an answer or suggestion to keep me going in the right direction.
Just trying to give back when I can.
Chef
You did give back a very valuable information, indeed.
Both boot commands bsd(0,0,0) and bfd(0,0,0) are adressing drives at the SCSI ID "0", in other words: when follwing the installation instructions of NeXT (or Apple) it is not obvoius that the internal SCSI harddisk is set to SCSI ID "1" as a factory default state. It is also not obvious that the boot parameters
bsd, bsd(0,0,0) or just sd
are only adressing a (hard)disk in general, but not a drive at the SCSI ID "0" in special - otherwise it would not be explainable that my drive with the physically set ID "1" is booting off the command "bsd(0,0,0). It is also not obvious that the harddisk
has to be SCSI ID "1" and in case of the NeXTstation terminated and recieving the power from the drive - the NeXTcube can be configured in diffenrent ways in dependency of the drives installed.
J
Now that you've found the NeXT boot HD SCSI id should be set to "1", I'll add why I think it should be set to "1", not "0". When I was studying how to make clone drives, I read in some document (I don't recall which document) that the NeXT computer boot drive should be #1 so that it can be terminated and then an external boot drive (also terminated) can be attached to boot the system even with the internal drive operational. The external drive with SCSI id #0 will have a lower number and will be chosen to boot. The SCSI chain will also be terminated at both ends (SCSI #0 and SCSI #1) as needed. I use an external drive set to #0 to test new clones of drives - it works perfectly every time.
According to the NetBSD next68k FAQ:
The ROM Monitor bsd() command defaults to booting from the lowest SCSI ID drive which is usually the internal hard drive at ID 0. To boot from the next SCSI hard drive, you would use bsd(1,0,0) which will boot from the next highest SCSI ID drive -- not necessarily SCSI ID 1.
http://www.netbsd.org/Ports/next68k/faq.htmlThe thing to remember is that it is not the scsi id set on the drive directly that determines what is used for x in bsd(x,0,0) . The SCSI id's set to the drive determine how to arrange them, from lowest to highest, in order to determine the boot number to use.
SCSI ID boot command
0 bsd() or bsd(0,0,0)
2 bsd(1,0,0)
6 bsd(2,0,0)
SCSI ID boot command
1 bsd() or bsd(0,0,0)
4 bsd(1,0,0)
6 bsd(2,0,0)Note the SCSI ID's are different in the second example, but the boot number is still the same
Chef
Oh! Here it is:
"NeXTstep 3.3 Network andSystem Administration Manual
Chapter 7: Attaching Peripherals"
http://www.channelu.com/NeXT/NeXTStep/3.3/nsa/07_Peripherals.htmld/index.html"8. Once the build is complete, turn off the computer and disk drive, then make the appropriate settings on your external disk drive to assign it SCSI target 0. Turn on the disk drive, then the computer. The computer will now boot off the external drive.
Since the internal hard disk is shipped as SCSI target 1 (other internal disks are shipped with a different SCSI target number, but all are higher than 0), setting the external disk as SCSI target 0 assigns it the device name /dev/sd0a (the boot device). The internal disk becomes /dev/sd1a."
Only thing I wanted to add is that when you see such weirdness with SCSI systems such as: "works with X device connected, but not with it's taken out", it almost always points to SCSI bus termination issues (and power of termination, either from drive or bus, or both), and ID issues. 99% of the time it's that stuff that bites ya.
Then again, there is the 1% of the time, which is caused by problematic hardware such as the drives themselves (IBM? from what folks here say), and SCSI controller chips. For example the very very popular DIP WD33c93 chips with revision 04 and below are notorious for having problems with multiple devices on the same bus. Many SGIs, SUNs, Amigas and other machines used those.
Quote from: "da9000"Only thing I wanted to add is that when you see such weirdness with SCSI systems such as: "works with X device connected, but not with it's taken out", it almost always points to SCSI bus termination issues (and power of termination, either from drive or bus, or both), and ID issues. 99% of the time it's that stuff that bytes ya.
Absolutely true in my experience! I've had endless SCSI problems on this level as well. So just wondering, in a setup of only one drive in a station (or cube), how should I set termination (power)? So many setting to figure out. I think I've tried all of them but ended up being able to boot the cube only with an external scsi drive or CD-ROM attached.
Quote from: "Otto"
So just wondering, in a setup of only one drive in a station (or cube), how should I set termination (power)? So many setting to figure out. I think I've tried all of them but ended up being able to boot the cube only with an external scsi drive or CD-ROM attached.
Ok, if that is true: it only boots with an external CDROM, then that points out that the external CDROM is terminating the SCSI bus (externally), thus it works. Now remember, you need 2 terminators. One on each side of the bus. So, the internal hard drive, assuming it's the last device on the SCSI cable, MUST have termination on it (usually present as a resistor network). I usually let the drive provide termination power (I'm not 100% sure, but I believe that even if the SCSI bus does provide termination power, it's ok for the drive to also provide termination power. The problem occurs when neither provides termination power).
Now the part I don't recall is if the NeXT motherboard auto-terminates the external SCSI port. Looking at my cube motherboard, I don't see any resistor networks, so I assume it's auto-terminated. Which means (if you have a cube), that the external CDROM shouldn't be needed in your case, therefore it's some other problem you're having...
Quote from: "da9000"Now the part I don't recall is if the NeXT motherboard auto-terminates the external SCSI port.
Reading all my available documents I noticed that there is no auto-termination in any NeXT-computer, no matter if internal or external. You will always have to terminate the SCSI chain on Your own.
J
Quote from: "Jenne"Quote from: "da9000"Now the part I don't recall is if the NeXT motherboard auto-terminates the external SCSI port.
Reading all my available documents I noticed that there is no auto-termination in any NeXT-computer, no matter if internal or external. You will always have to terminate the SCSI chain on Your own.
J
OK, then the CDROM is needed, as it provides the termination for the external port.
That's strange though, because aren't the computers supposed to be booting without external SCSI devices as well? I'll look into getting termination power from the drive.
Quote from: "Otto"That's strange though, because aren't the computers supposed to be booting without external SCSI devices as well? I'll look into getting termination power from the drive.
Yes, it is. That was part of the reason I was thinking about auto-termination as well. I know my cube doesn't have any external devices... Perhaps his is an older 030? I don't know about those.
Nope, it's actually drive specific, so I suspect I'm termination certain types of drives wrong.
Well even if the drive auto-terminates ITS end, I don't believe it can terminate the external port end. The motherboard can do it, or an external terminator, which never came with NeXT boxes, which leads me to think that the motherboard SCSI chipset does auto-sense & auto-terminate (many SCSI chipsets do this)
While experimenting with my NeXT-computers because they were not booting from any device in the beginning I've been reading almost any document available about this topic.
The book "Network and System Administration" mentions several times, that a Cube can only handle two SCSI hard drives (in fact someone out there in the internet managed to place a second drive into a station, too...). I don't know if this limitation depends on the SCSI chipset or the room inside a cube or station (well, the station is self explanatory in this). But what I learned about drives is that the last one within (!) a Next-machine has to be terminated and has to recieve termination power from the drive. Especially Seagate drives are heavily depending on this configuration. Some of my Quantum drives did work, too but some of them didn't. Those rather old drives (capacity from 320 MB up to 1 GB) do not have a jumper bridge to configure the termination.
I learned, that it can cause quite a lot of troubles to mix drives from different companies. The Seagates refused to work together with Quantums and some of the Quantums also refused to do their job together when the sector sizes were different.
I also learned that it does not make very much sense just to terminate the drives You work with and setting their ID and then placing it somewhere on the ribbon cable (which itself also can cause some problems by the way). Watching the cable from the connector to the mainboard up to its end I learned that the drive closest to the mainboard should bear the lowest ID while the last one has to bear the highest. All drives in between should follow the simple step by step counting:
1. drive (closest to mainboard) = ID 1 (<-essential for being the boot device!)
2. drive = ID 2
3. drive (the last one) = ID 3
I tried to use several CD-ROM drives inside (!) the cube, some Apple and one Panasonic device but then the SCSI chain does not work anymore, maybe because You only can set a general termination to CD-ROM drives but not with termination power from drive in special.
Hoping this is of some use...
J
A little addition:
some CD-ROM drives must be configured in a special way to work within NEXTSTEP or some other UNIX distributions. An example: I'm using a Pioneer CD-ROM DR-706s. This one has the ability to be configured for different default sector sizes. When using it in factory default state (2048 byte sector size) it refuses to be usable as an internal drive in my cube no matter what kind of SCSI ID or termination. But when changed to 512 byte sector size it works.
I don't understand that really but as long as this drive works it doesn't bother me too much.
J
Quote from: "Jenne"
The book "Network and System Administration" mentions several times, that a Cube can only handle two SCSI hard drives (in fact someone out there in the internet managed to place a second drive into a station, too...). I don't know if this limitation depends on the SCSI chipset or the room inside a cube or station (well, the station is self explanatory in this).
It's a physical space limitation. The chipsets, at least the NCR that's used in the NeXT machines doesn't have such a limit.
Quote from: "Jenne"
But what I learned about drives is that the last one within (!) a Next-machine has to be terminated and has to recieve termination power
That's what I was saying before... The _last_ drive in the SCSI chain (both inside and outside the machine, if there's anything outside), MUST be terminated.
Quote from: "Jenne"
them didn't. Those rather old drives (capacity from 320 MB up to 1 GB) do not have a jumper bridge to configure the termination.
If they don't have a jumper for termination, then you need to insert a resistor "pack" or network of resistors.
Quote from: "Jenne"
I learned, that it can cause quite a lot of troubles to mix drives from different companies. The Seagates refused to work together with Quantums and some of the Quantums also refused to do their job together when the sector sizes were different.
In my experience that's not true at all. The only case it might be true is with the different sector sizes (512 vs 1024 usually), and even that is iffy based on my experience.
Quote from: "Jenne"
I also learned that it does not make very much sense just to terminate the drives You work with and setting their ID and then placing it somewhere on the ribbon cable (which itself also can cause some problems by the
No, you don't terminate each drive you work with. Only the ones in the ends of the SCSI chain (usually what one would call the first and last drive).
Quote from: "Jenne"
way). Watching the cable from the connector to the mainboard up to its end I learned that the drive closest to the mainboard should bear the lowest ID while the last one has to bear the highest. All drives in between should follow the simple step by step counting:
1. drive (closest to mainboard) = ID 1 (<-essential for being the boot device!)
2. drive = ID 2
3. drive (the last one) = ID 3
In my experience the above is nonsense. IDs are only important for differentiating drives and setting boot-order. They have nothing to do with cable-order.
Quote from: "Jenne"
I tried to use several CD-ROM drives inside (!) the cube, some Apple and one Panasonic device but then the SCSI chain does not work anymore, maybe because You only can set a general termination to CD-ROM drives but not with termination power from drive in special.
The termination (and ID possibly) was wrong in the cases where things didn't work.
Quote from: "Jenne"A little addition:
some CD-ROM drives must be configured in a special way to work within NEXTSTEP or some other UNIX distributions. An example: I'm using a Pioneer CD-ROM DR-706s. This one has the ability to be configured for different default sector sizes. When using it in factory default state (2048 byte sector size) it refuses to be usable as an internal drive in my cube no matter what kind of SCSI ID or termination. But when changed to 512 byte sector size it works.
I don't understand that really but as long as this drive works it doesn't bother me too much.
J
Yes, this issue is totally different from SCSI & termination problems. Basically many drives can be set to read 512byte or 1024byte or 2048byte sectors. This is the hardware side of the drive (the chips on it, etc). So if your program requests 1byte, a drive set to 2048byte sectors will read an entire 2048byte sector. This is by the way the default sector size for ISO data CDs. 2048 data bytes + 256 CRC = 2304 byte sectors. That's why if you write to a CDROM in RAW mode, you get MUCH more than the touted 650MB. It's because you're using the CRC bytes, which are 1/10 of the sector size. So a 74minute CD, can store 650MB of checksummed data, or about 731MB of RAW data (in which case it's important to realize that a single scratch will cause serious errors on your files, unless it's audio of course, which will cause the music to skip or make funny noises, depending on the sampling and filtering capabilities of your DSP/DAC)
Anyways, this setting is a one off thing: just set it to 512 and forget it. It will not affect any SCSi or termination issues you're having. It will just make the drive work or not work, no matter what the termination issues
Hello da9000.
Just to get some things right: I know that only the physically last drive within a SCSI chain has to be terminated and that it does not make any sense at all to terminate every drive, this wasn't new to me, sorry for placing misunderstandable lines.
Although I know it theoretically doesn't matter if you are placing the SCSI IDs as I would do it (first position ID 1, second ID 2 etc.) my cube teaches me different. The same drives I've been using in the cube work as You described in my several Macs (wife isn't around so I had some time to change drives...). When I change them back to the cube there are tons of SCSI errors and system panics. When reconfiguring them back to the way I described it before they do their job. Well, at least most of the time.
I've been checking IDs and termination settings now many many times and I've been cross-checking them many many times and in fact not every working surrounding in my cube does make sense to me regarding the SCSI rules.
For example: my Quantum drives do have a jumper bridge for termination in general (just like most CD-ROM drives), but they don't have a special jumper setting for recieving termination power from drive. When I'm using the Quantum as the physically last drive in the chain (of course terminated) there are those system panics and it doesn't matter if there are CD-ROM drives or other harddrives (Quantum or Seagate) physically in the chain, too. Those panics do NOT appear when I'm using a Seagate as the last drive, terminated and recieving power from drive.
I can not explain this and I don't understand it at all.
Another weird thing: when connecting the CD-ROM (Pioneer DR-706s) as the physically last device in the chain (terminated of course) the SCSI bus simply begins to hang from time to time, sometimes while booting, sometimes while system started and running. Connecting the CD-ROM somewhere in the middle or beginning of the SCSI chain (not terminated) it works like a charm.
And a last one: I remember that I once tried to hook up two harddrives and a single CD-ROM into the cube. Besides all the SCSI troubles I only managed to connect one HD and the CD ROM or two HDs, but not all of the
three together.
All this leads me to the conclusion that the SCSI controller chip must be some sort of very different to others. As I wrote somewhere else before: I'm pretty much familiar with SCSI troubles within the Mac but the NeXT machines do anything else from what I'm expecting.
J
Quote from: "Jenne"
Just to get some things right: I know that only the physically last drive within a SCSI chain has to be terminated and that it does not make any sense at all to terminate every drive, this wasn't new to me, sorry for placing misunderstandable lines.
No worries. I just wanted to make sure.
Quote from: "Jenne"
Although I know it theoretically doesn't matter if you are placing the SCSI IDs as I would do it (first position ID 1, second ID 2 etc.) my cube teaches me different. The same drives I've been using in the cube work as You described in my several Macs (wife isn't around so I had some time to change drives...). When I change them back to the cube there are tons of SCSI errors and system panics. When reconfiguring them back to the way I described it before they do their job. Well, at least most of the time.
I believe you. Something else is going on which needs solving. Obviously the Mac proves the correct functionality.
Quote from: "Jenne"
For example: my Quantum drives do have a jumper bridge for termination in general (just like most CD-ROM drives), but they don't have a special jumper setting for recieving termination power from drive. When I'm using the Quantum as the physically last drive in the chain (of course terminated) there are those system panics and it doesn't matter if there are CD-ROM drives or other harddrives (Quantum or Seagate) physically in the chain, too. Those panics do NOT appear when I'm using a Seagate as the last drive, terminated and recieving power from drive.
I can not explain this and I don't understand it at all.
If I understood your writing correctly, I think the following is an explanation:
Your Quantum doesn't provide termination power. The cube's SCSI bus doesn't either (can someone please verify this?). Therefore when you have the Quantum at the end, its resistors aren't powered, therefore termination fails, therefore the SCSI errors.
When you move the Seagate at the end (so Quantum has no resistors/termination), the Seagate powers the resistors, termination works, and all is good.
Does this make sense?
Quote from: "Jenne"
Another weird thing: when connecting the CD-ROM (Pioneer DR-706s) as the physically last device in the chain (terminated of course) the SCSI bus simply begins to hang from time to time, sometimes while booting, sometimes while system started and running. Connecting the CD-ROM somewhere in the middle or beginning of the SCSI chain (not terminated) it works like a charm.
Does it provide termination power?
Quote from: "Jenne"
And a last one: I remember that I once tried to hook up two harddrives and a single CD-ROM into the cube. Besides all the SCSI troubles I only managed to connect one HD and the CD ROM or two HDs, but not all of the
three together.
All this leads me to the conclusion that the SCSI controller chip must be some sort of very different to others. As I wrote somewhere else before: I'm pretty much familiar with SCSI troubles within the Mac but the NeXT machines do anything else from what I'm expecting.
J
It could be possible that something else is the matter. Synchronus vs asynchronus mode? The cube can only do async, but perhaps one drive doesn't like async. I don't know. Can you give us specs about your NeXT? Perhaps your firmware is old? Also, give your Quantum model #'s and firmware revisions. Perhaps someone else has the same drive (I have a bunch of Quantums) and can give it a try (plus it's black listed here for the next person to try this with his NeXT.
I don't think I can diagnose remotely, but I do know that certain SCSI controller chips do have problems with multiple devices. As I mentioned before a prime example is the WDC33c93 used in many many old skool machines. Unfortunately the NCR SCSI chip in the cube is soldered and you can't replace it easily...
An experiment that I would perform, would be trying your failing combination of drives with a friend's cube, although I imagine that might be very hard: I don't have any friends with a cube, not within driving distance anyhow! :)
Also another experiment would be to find a SCSI controller (PC or Mac) with the same NCR SCSI controller as your cube (mine says NCR 53C90A / click here and then zoom lense to see it in detail:
http://picasaweb.google.com/adonisoamigas/MyBlackBeautyMyPrecious/photo#5039085892904985906). Then try the combination there, in Linux, by preference, so you can get some real debug info from the setup.
Lastly, always debug your SCSI problems with one drive at a time. Add a drive each time and see which one causes the headaches. Perhaps it is just a single drive/controller combination.
Either way, good luck
Will take quite a lot of time to find out all the needed specs but I will hang on ;)
Thanks anyway, I already began to think in strange ways....
J
Quote from: "Jenne"Will take quite a lot of time to find out all the needed specs but I will hang on ;)
All part of the job... part of problem solving :)
BTW, I added some stuff to the previous post of mine (link to my motherboard. It's a little hard to spot it if you don't know which chip it is, but it's the closest chip by NCR to the SCSI plug on the motherboard)
Quote from: "Jenne"
Thanks anyway, I already began to think in strange ways....
J
No problem! I know how these things can be... I've fought only too many times with my computer systems until they worked or I just smashed them to bits so they would definitely not work from then on :) (many many hard drives went this way, hehe)
Oh, I'm no "chip fetishist" so could You mark it graphically somehow? Looks like there are many chips close to the plug...
Another weird thing in between: I use to hook up an external JAZ drive containing my complete NEXTSTEP 3.3 for restoration purposes. Takes much less time than a clean install. So now I tried this: while using only ONE (and terminated recieveing power from drive) Seagate the BuildDisk thing works as it should. But using more drives (even same model and revision) or more drives from different companies the process fails - the external JAZ uses ID 0 and is terminated, all the internal drives are using higher IDs and the last one is terminated,too. Seems to proove my intention that at least my cube is not able to handle more than two SCSI devices at the same time when connected internal. This does not happen when using more drives: one internal and about three different (JAZ, tape and CD-ROM) externally.
J
Quote from: "Jenne"Oh, I'm no "chip fetishist" so could You mark it graphically somehow? Looks like there are many chips close to the plug...
I can't at the moment. But lets try again:
Look between the WHITE cache slot (like memory slot, but only one, sitting by itself), and where you plug in the SCSI cable (black connector, with 50 pins sticking out). As you have the motherboard with the BACK SIDE (where you plug the monitor), towards you, look at the black SCSI connector and when it ends, and the next connector begins (to the right), look up. There's a medium-sized SQUARE chip with the words "NCR" on it, and then 53c???
Quote from: "Jenne"
Another weird thing in between: I use to hook up an external JAZ drive containing my complete NEXTSTEP 3.3 for restoration purposes. Takes much less time than a clean install. So now I tried this: while using only ONE (and terminated recieveing power from drive) Seagate the BuildDisk thing works as it should. But using more drives (even same model and revision) or more drives from different companies the process fails - the external JAZ uses ID 0 and is terminated, all the internal drives are using higher IDs and the last one is terminated,too. Seems to proove my intention that at least my cube is not able to handle more than two SCSI devices at the same time when connected internal. This does not happen when using more drives: one internal and about three different (JAZ, tape and CD-ROM) externally.
J
Too weird... :(
So here comes my little data information. The NMI monitor tells me this:
SCSI Controller 53C90A
NEXT ROM MONITOR 2.4 v65
32 MB RAM
(and lots more)
The drives:
Seagate ST32430 N Rev 0492 (<- in fact most stable drive so far)
Seagate ST31230 N Rev A01
Seagate ST32151 N Rev unknown, maybe 0284 (owning two identical drives)
Seagate ST32155 N Rev unknown, maybe 0594
Seagate ST31230 N Rev unknown, maybe 0510
Quantum Fireball 4GB drive Rev unknown
Quantum Fireball Rev 04-B S300Z (former original Apple drive)
Almost 3 Quantums refuse to be mounted or formatted already... so no infos here :(
J
I'll try to see if I have any of the same and give them a try
Dear All,
would any of you be so kind to share the specifications / pictures of the resistors arrays installed on hard drive Seagate ST 1480 as terminator?
Mine has none and I must terminate the SCSI chain with a CD ROM reader :!:
All I could find is that it must be 220/330 ohm resistor modules (SIP's), not much else. Must have 8 pins too.
Thanks in advance for your help!
Quote from: "paolo.bertolo"
Thanks in advance for your help!
I don't have the st1480 information but you might have better luck simply adding an internal scsi terminator to the cable. There are 'piggy-back' terminators that share a cable connector with a drive that would work in a NeXT machine.