jimb@gvlv2.gvl.unisys.com (Jim Burwell) (01/21/91)
Our organization recently got two HP 1.2 GB SCSI2 drives. They are strange critters! After finding a SCSI ID which SunOS liked, and getting the other jumpers for other things set properly, Sun's format command finally noticed it. But when I attempted to low-level format the drive, it returned an error (drive not ready or something). I figured it was formatted at the factory, so I tried to label it. I set up the partitions, and issued the label command, and voila! It worked fine. (Actually, the first time it complained about not being able to write any backup labels, so I lied to format and told it that the drive had 2 fewer useable cylindars than it actually had. Then it worked with no complaints). I then exited format, and tried newfs. Bingo, it worked with no problem. I then installed SunOS 4.1.1 on it, switched the SCSI ID to 0 to make it sd0 (after changing the original sd0 to SCSI ID 1), and attemped to boot the machine. The machine (a Sun 3/160) powered up, then complained that the SCSI bus was continuosely busy. Puzzled, I played with jumpers, etc. Nothing worked. I then set up a nfs-boot for that machine on our server, and booted from that. From here, I had no problem mounting, reading, and writing the drive! I verified that the drive had a bootblock, etc, and tried to boot it again: >b sd() Boot sd(0,0,0) scsi bus continually busy (or something to that effect) I then netbooted: >b ie() -a And when it asked where the root was: Root partition ? sd0a vm_boot: bad-read (blah blah) (This isn't exact. from memory.) STRANGE. I just can't touch the drive until AFTER Unix is booted. It appears to me that the bootstrap and boot programs arn't sending the drive some initialization command to make it become ready. Perhaps it needs a SCSI start-unit command, but I don't see why, since I have the jumper for auto-spin-up set, and the drive does spin-up on power-up. Maybe the firmware on the drive needs a start-unit or something. All I know is that the drive seems to be untouchable until after Unix notices it on boot; after Unix prints things like this: sd0 at sc0 slave 0 sd0: <Micropolis 1325 cyl 1022 alt 2 hd 8 sec 17> sd1 at sc0 slave 1 sd2 at sc0 slave 8 sd2: <HP 97549.SUNOS cyl 1906 alt 2 hd 16 sec 64> Is there a special bootstrap program needed to boot from HP drives ? Or do I need new firmware for the drive or something? I really want this drive to be the system drive, since this drive is an embedded SCSI2 drive, and the "old" system drive was just a little Micropolis ST-506 70MB 1325. SLOW! Also, does anyone know how Sun binds SCSI IDs to device names ? ID 0 maps to sd0, ID 1 maps to SD2. What ID does sd1 map to ? PLEASE mail me any info you have about this !
kevin@corp.sun.com (02/14/91)
In article <1361@brchh104.bnr.ca> faatcrl!jimb@gvlv2.gvl.unisys.com (Jim Burwell) writes: >Also, does anyone know how Sun binds SCSI IDs to device names ? ID 0 maps >to sd0, ID 1 maps to SD2. What ID does sd1 map to ? On the older machines, it is a config line like this: disk sd0 at si0 drive 0 flags 0 where the drive number is target*8 + lun (logical unit number). We ususally set up the config file so that 0 and 1 were the disks on the first controller, and 2 & 3 the logical units on the second controller. disk sd2 at si0 drive 8 flags 0 # target 1, lun 0 disk sd3 at si0 drive 9 flags 0 # target 1, lun 1 A little known fact is that you can enter the numbers in octal as well as decimal, which makes things easier for SCSI devices. The above lines would then read: disk sd2 at si0 drive 010 flags 0 # target 1, lun 0 disk sd3 at si0 drive 011 flags 0 # target 1, lun 1 The unit number (as in sd#) is mostly arbitrary - what comes in the drive field is what counts for SCSI addressing. For the newer (open prom) systems, the addressing is explicit, and the drive number is again arbitrary. It is a good idea to keep them sequential and monotonically ascending. disk sd0 at scsibus0 target 3 lun 0 # first hard SCSI disk l & h, kev