vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| I have a 9 GB (hence reasonably old) disk which refuses to be seen even at the OK prompt with a probe-scsi in a SPARC 20. One might conclude the disk is dead, but it seems to work fine in a Ultra 80. Both machines run Solaris 9, although I patched the SS20 last night, so it is more up to date. U80 # uname -a SunOS sparrow 5.9 Generic_117171-15 sun4u sparc SUNW,Ultra-80 SS20 # uname -a SunOS webserver 5.9 Generic_118558-16 sun4m sparc SUNW,SPARCstation-20 I've had this problem before with Compaq disks not being seen a SPARC 20 but worked fine after I'd done something with them in a Ultra 80. I have only partitioned and labeled this is the U80, but that was certainly insufficient to get it working. Perhaps I'll try formatting it. Any other suggestions - other than make a door stop of it? I have plenty of door stops and don't need another 9 GB in the U80, but could do with it on an SS20. Here's format.dat info written on a U80. # New disk/partition type saved on Sun Nov 6 15:02:43 2005 # disk_type = "COMPAQ-HB00931931-03F1" \ : ctlr = SCSI : ncyl = 8150 : acyl = 2 : pcyl = 8152 \ : nhead = 10 : nsect = 218 : rpm = 7200 partition = "COMPAQ-HB00931931-03F1 9GB" \ : disk = "COMPAQ-HB00931931-03F1" : ctlr = SCSI \ : 2 = backup, wm, 0, 17767000 : 7 = usr, wm, 0, 17767000 dave k |
| |||
| On Sun, 06 Nov 2005 15:53:04 +0000, Dave <nospam@nowhere.com> wrote: >I have a 9 GB (hence reasonably old) disk which refuses to be seen even >at the OK prompt with a probe-scsi in a SPARC 20. One might conclude the >disk is dead, but it seems to work fine in a Ultra 80. Both machines run > Solaris 9, although I patched the SS20 last night, so it is more up to >date. The sun4m esp fast scsi controller is 8 bit only. I'm unsure whether the upper 8 bits of the wide (16 bit) sca connector are terminated properly or have been left open. Some wide hard disks hang unless both lower and upper 8 bits are properly terminated. Maybe jumpering the drive to single ended may help. Jumpers for drive id or termination have to be removed. You may try a SunSwift fas wide scsi controller. Mit freundlichen Grüßen Frank-Christian Krügel |
| |||
| Frank-Christian Kruegel wrote: > On Sun, 06 Nov 2005 15:53:04 +0000, Dave <nospam@nowhere.com> wrote: > > >>I have a 9 GB (hence reasonably old) disk which refuses to be seen even >>at the OK prompt with a probe-scsi in a SPARC 20. One might conclude the >>disk is dead, but it seems to work fine in a Ultra 80. Both machines run >> Solaris 9, although I patched the SS20 last night, so it is more up to >>date. > > > The sun4m esp fast scsi controller is 8 bit only. I'm unsure whether the > upper 8 bits of the wide (16 bit) sca connector are terminated properly or > have been left open. Some wide hard disks hang unless both lower and upper 8 > bits are properly terminated. > > Maybe jumpering the drive to single ended may help. Jumpers for drive id or > termination have to be removed. Thanks for that. I checked and found the disk was already jumped SE. I removed the jumper (what else to try?) but no luck. I tried a few other jumpers, but no improvement. What was odd though is that a) The disk is seen if it is the *only* disk in the machine. b) The disk is seen if it the lower slot (SCSI ID=3), but not if its in the upper one (ID=1). And no, there are not any jumpers installed on any of the SCSI ID select pins. Anyway, it is at least semi-resolved. I've put an operating system on it and it boots OK now. Just needs to be in the lower slot, otherwise it can't be seen on the bus. > You may try a SunSwift fas wide scsi controller. It gets away from the compactness of the SS20 though. I think I'd rather get a disk that works. I've often found Compaq disks "funny". Don't know what they do, but whereas a normal Seagate, IBM or whatever seems to work with no hassle, those badged Compaq seem to present me more hassles. |
| |||
| Dave wrote: > Frank-Christian Kruegel wrote: > >> On Sun, 06 Nov 2005 15:53:04 +0000, Dave <nospam@nowhere.com> wrote: >> >> >>> I have a 9 GB (hence reasonably old) disk which refuses to be seen >>> even at the OK prompt with a probe-scsi in a SPARC 20. One might >>> conclude the disk is dead, but it seems to work fine in a Ultra 80. >>> Both machines run Solaris 9, although I patched the SS20 last night, >>> so it is more up to date. >> >> >> >> The sun4m esp fast scsi controller is 8 bit only. I'm unsure whether the >> upper 8 bits of the wide (16 bit) sca connector are terminated >> properly or >> have been left open. Some wide hard disks hang unless both lower and >> upper 8 >> bits are properly terminated. >> >> Maybe jumpering the drive to single ended may help. Jumpers for drive >> id or >> termination have to be removed. > > > Thanks for that. > > I checked and found the disk was already jumped SE. I removed the jumper > (what else to try?) but no luck. I tried a few other jumpers, but no > improvement. > > What was odd though is that > > a) The disk is seen if it is the *only* disk in the machine. > > b) The disk is seen if it the lower slot (SCSI ID=3), but not if its in > the upper one (ID=1). And no, there are not any jumpers installed on > any of the SCSI ID select pins. > > Anyway, it is at least semi-resolved. I've put an operating system on it > and it boots OK now. Just needs to be in the lower slot, otherwise it > can't be seen on the bus. That's rather odd. There is no physical or logical difference between the upper and lower drive bays aside from SCSI ID AFAIK. I suspect your upper bay is b0rked somehow, and won't work with any disk as a result. I have a couple of spare SS20 backplane & cable assemblies here (Toronto, Canada), perhaps you could try one if the logistics aren't too complicated. Triffid |
| |||
| Triffid wrote: >> Thanks for that. >> >> I checked and found the disk was already jumped SE. I removed the >> jumper (what else to try?) but no luck. I tried a few other jumpers, >> but no improvement. >> >> What was odd though is that >> >> a) The disk is seen if it is the *only* disk in the machine. >> >> b) The disk is seen if it the lower slot (SCSI ID=3), but not if its >> in the upper one (ID=1). And no, there are not any jumpers installed >> on any of the SCSI ID select pins. >> >> Anyway, it is at least semi-resolved. I've put an operating system on >> it and it boots OK now. Just needs to be in the lower slot, otherwise >> it can't be seen on the bus. > > > That's rather odd. There is no physical or logical difference between > the upper and lower drive bays aside from SCSI ID AFAIK. Yes, I thought it odd too. > I suspect your upper bay is b0rked somehow, and won't work with any disk > as a result. That is not so. Here you can see the Compaq disk that presents me trouble in the lower slot (ID=3) and a Seagate one in the top one (ID=1) ok probe-scsi Target 1 Unit 0 Disk SEAGATE ST39103LC 0001LS482885 Copyright (c) 1999 Seagate All rights reserved Target 3 Unit 0 Disk COMPAQ HB00931931 03F168224A01GAGSPCQ3F1 09RI9904200012259H7007 E32284 Q59H6952B09E31916 1999 ok After I swap the disks around, using the same machine, the Compaq one can no longer be seen. ok probe-scsi Target 3 Unit 0 Disk SEAGATE ST39103LC 0001LS482885 Copyright (c) 1999 Seagate All rights reserved ok That behaviour is repeatable. But when I move the disks to another SS20, both can be seen in any position, but I'm pretty sure they had the same problem in yet another SS20. > I have a couple of spare SS20 backplane & cable assemblies here > (Toronto, Canada), perhaps you could try one if the logistics aren't too > complicated. Thanks, but I am in the UK, so a long way from you, but in any case I have five SS20's here. > Triffid It all seems very odd. But I have had problems with other Compaq disks in SS20's before, so this is not a total surprise to me. |
| |||
| Dave wrote: > Triffid wrote: > >>> Thanks for that. >>> >>> I checked and found the disk was already jumped SE. I removed the >>> jumper (what else to try?) but no luck. I tried a few other jumpers, >>> but no improvement. >>> >>> What was odd though is that >>> >>> a) The disk is seen if it is the *only* disk in the machine. >>> >>> b) The disk is seen if it the lower slot (SCSI ID=3), but not if its >>> in the upper one (ID=1). And no, there are not any jumpers installed >>> on any of the SCSI ID select pins. >>> >>> Anyway, it is at least semi-resolved. I've put an operating system on >>> it and it boots OK now. Just needs to be in the lower slot, otherwise >>> it can't be seen on the bus. >> >> >> >> That's rather odd. There is no physical or logical difference between >> the upper and lower drive bays aside from SCSI ID AFAIK. > > > Yes, I thought it odd too. > >> I suspect your upper bay is b0rked somehow, and won't work with any >> disk as a result. > > > That is not so. > > Here you can see the Compaq disk that presents me trouble in the lower > slot (ID=3) and a Seagate one in the top one (ID=1) > > > ok probe-scsi > Target 1 > Unit 0 Disk SEAGATE ST39103LC 0001LS482885 > Copyright (c) 1999 Seagate > All rights reserved > Target 3 > Unit 0 Disk COMPAQ HB00931931 03F168224A01GAGSPCQ3F1 > 09RI9904200012259H7007 > E32284 Q59H6952B09E31916 1999 > ok > > > After I swap the disks around, using the same machine, the Compaq one > can no longer be seen. > > ok probe-scsi > Target 3 > Unit 0 Disk SEAGATE ST39103LC 0001LS482885 > Copyright (c) 1999 Seagate > All rights reserved > ok > > > That behaviour is repeatable. > > But when I move the disks to another SS20, both can be seen in any > position, but I'm pretty sure they had the same problem in yet another > SS20. Aha! Is there a difference in OBP version between these two SS20s? Are the SCSI controllers the same? >> I have a couple of spare SS20 backplane & cable assemblies here >> (Toronto, Canada), perhaps you could try one if the logistics aren't >> too complicated. > > > Thanks, but I am in the UK, so a long way from you, but in any case I > have five SS20's here. > >> Triffid > > > > It all seems very odd. But I have had problems with other Compaq disks > in SS20's before, so this is not a total surprise to me. > |
| |||
| In article <4372c5e7@212.67.96.135>, Dave <nospam@nowhere.com> wrote: >Triffid wrote: > >>> Thanks for that. >>> >>> I checked and found the disk was already jumped SE. I removed the >>> jumper (what else to try?) but no luck. I tried a few other jumpers, >>> but no improvement. >>> >>> What was odd though is that >>> >>> a) The disk is seen if it is the *only* disk in the machine. >>> >>> b) The disk is seen if it the lower slot (SCSI ID=3), but not if its >>> in the upper one (ID=1). And no, there are not any jumpers installed >>> on any of the SCSI ID select pins. >>> >>> Anyway, it is at least semi-resolved. I've put an operating system on >>> it and it boots OK now. Just needs to be in the lower slot, otherwi4>>> it can't be seen on the bus. >> >> >> That's rather odd. There is no physical or logical difference between >> the upper and lower drive bays aside from SCSI ID AFAIK. > >Yes, I thought it odd too. > >> I suspect your upper bay is b0rked somehow, and won't work with any disk >> as a result. > >That is not so. > >Here you can see the Compaq disk that presents me trouble in the lower >slot (ID=3) and a Seagate one in the top one (ID=1) > > >ok probe-scsi >Target 1 > Unit 0 Disk SEAGATE ST39103LC 0001LS482885 > Copyright (c) 1999 Seagate > All rights reserved >Target 3 > Unit 0 Disk COMPAQ HB00931931 03F168224A01GAGSPCQ3F1 > 09RI9904200012259H7007 > E32284 Q59H6952B09E31916 1999 >ok > > >After I swap the disks around, using the same machine, the Compaq one >can no longer be seen. > >ok probe-scsi >Target 3 > Unit 0 Disk SEAGATE ST39103LC 0001LS482885 > Copyright (c) 1999 Seagate > All rights reserved >ok > > >That behaviour is repeatable. Is one of these hardwired to SCSI Target 3, and the other one is picking it up from the slot/position. Like IDE in cable select mode. So one would be switching 1 and 3, and the other stuck on 3 and 3, and colliding in one of the configurations. Is there a way to force it to target 2 ?? > >But when I move the disks to another SS20, both can be seen in any >position, but I'm pretty sure they had the same problem in yet another >SS20. > > >> I have a couple of spare SS20 backplane & cable assemblies here >> (Toronto, Canada), perhaps you could try one if the logistics aren't too >> complicated. > >Thanks, but I am in the UK, so a long way from you, but in any case I >have five SS20's here. > >> Triffid > > >It all seems very odd. But I have had problems with other Compaq disks >in SS20's before, so this is not a total surprise to m< > |
| |||
| x@x.x wrote: > In article <4372c5e7@212.67.96.135>, Dave <nospam@nowhere.com> wrote: > >>Triffid wrote: >> >> >>>>Thanks for that. >>>> >>>>I checked and found the disk was already jumped SE. I removed the >>>>jumper (what else to try?) but no luck. I tried a few other jumpers, >>>>but no improvement. >>>> >>>>What was odd though is that >>>> >>>>a) The disk is seen if it is the *only* disk in the machine. >>>> >>>>b) The disk is seen if it the lower slot (SCSI ID=3), but not if its >>>>in the upper one (ID=1). And no, there are not any jumpers installed >>>>on any of the SCSI ID select pins. >>>> >>>>Anyway, it is at least semi-resolved. I've put an operating system on >>>>it and it boots OK now. Just needs to be in the lower slot, otherwi4>>> it can't be seen on the bus. >>> >>> >>>That's rather odd. There is no physical or logical difference between >>>the upper and lower drive bays aside from SCSI ID AFAIK. >> >>Yes, I thought it odd too. >> >> >>>I suspect your upper bay is b0rked somehow, and won't work with any disk >>>as a result. >> >>That is not so. >> >>Here you can see the Compaq disk that presents me trouble in the lower >>slot (ID=3) and a Seagate one in the top one (ID=1) >> >> >>ok probe-scsi >>Target 1 >> Unit 0 Disk SEAGATE ST39103LC 0001LS482885 >> Copyright (c) 1999 Seagate >> All rights reserved >>Target 3 >> Unit 0 Disk COMPAQ HB00931931 03F168224A01GAGSPCQ3F1 >> 09RI9904200012259H7007 >> E32284 Q59H6952B09E31916 1999 >>ok >> >> >>After I swap the disks around, using the same machine, the Compaq one >>can no longer be seen. >> >>ok probe-scsi >>Target 3 >> Unit 0 Disk SEAGATE ST39103LC 0001LS482885 >> Copyright (c) 1999 Seagate >> All rights reserved >>ok >> >> >>That behaviour is repeatable. > > > Is one of these hardwired to SCSI Target 3, and the other one is picking > it up from the slot/position. Like IDE in cable select mode. > > So one would be switching 1 and 3, and the other stuck on 3 and 3, > and colliding in one of the configurations. > > Is there a way to force it to target 2 ?? No, the SCA backplane in SS20s is hardwired to IDs 1 and 3. Only way to change it is with a soldering iron :-) Triffid >>But when I move the disks to another SS20, both can be seen in any >>position, but I'm pretty sure they had the same problem in yet another >>SS20. >> >> >> >>>I have a couple of spare SS20 backplane & cable assemblies here >>>(Toronto, Canada), perhaps you could try one if the logistics aren't too >>>complicated. >> >>Thanks, but I am in the UK, so a long way from you, but in any case I >>have five SS20's here. >> >> >>>Triffid >> >> >>It all seems very odd. But I have had problems with other Compaq disks >>in SS20's before, so this is not a total surprise to m< >> |
| |||
| Triffid wrote: >> That behaviour is repeatable. >> >> But when I move the disks to another SS20, both can be seen in any >> position, but I'm pretty sure they had the same problem in yet another >> SS20. > > > Aha! > > Is there a difference in OBP version between these two SS20s? Are the > SCSI controllers the same? Yes, they are all 2.25. I have 5 SS20's and blew my own eproms, so they are even from the same image. |
| ||||
| Triffid wrote: > No, the SCA backplane in SS20s is hardwired to IDs 1 and 3. > > Only way to change it is with a soldering iron :-) > > Triffid I've not tried it, but I would not be surprised if you could jumper the other SCSI id's on the disks themselves, assuming they have the pins, which some of my SCA drives to. If a disk is set by the SS20 to 1, but you put a link on the 4 position of the drive, I suspect you could make the ID of the combo 4+1=5. However, you are never going to be able to get an even SCSI id, since number 1 is jumpered on the SS20. |