[SunRescue] HiTechCafe 9GB SGI branded IBM DGHS-09Y disks

[rescue at sunhelp.org]

Thanks for the feedback all...

----------------------------------------------------------------------
Nick Kociuk says:
> i don't really know anything about these drives, but from the scsi spec:
> 
> asc: 0x0b
> ascq: 0x01
> desc: "warning - specified temperature exceeded"
> 
> 0x0b is the sense key for "abort", but looks like it's the asc for
> "warning".

Thanks, i found a document on Ultrastar drives at:
http://www.storage.ibm.com/hardsoft/diskdrdl/technolo/drivetemp/drivetemp.htm

which refers to this.  This doesn't seem right though, as these drives
are *NOT* getting hot (they are in two seperate enclosures and are only
lukewarm to the touch).  I'm going to play with the Mode Page params to
see if perhaps the Customer Threshhold temperature setting is set too
low (default: 50C).  The other setting appears to be a HardCoded "Not to be
Exceeded" maximum engineering value for the casing of 65C.

I'm not finding any description of the byte offset of this value in Mode
Page 0x00 (Vendor Specific page), though.

----------------------------------------------------------------------
Mike N says:
> Where can I get this IBM FLASHDRV ISO?

http://www.pc.ibm.com/qtechinfo/MIGR-4GSU4F.html
(Note: it is possible that the firmware on this CD is tweaked for IBM servers
and you will whack yourself if you use it.  It looks like there's also some
Seagate f/w on it)

This program is designed to boot on x86 from floppy (the ISO image has a
Floppy image you can 'dd' for this) and requires certain SCSI controllers
(Adaptec 2940, as well as other adaptec and some RAID controllers that are
sold with IBM enterprise server platforms).  This program itself does not
want to flash over the SGI firmware, since it's not officially an IBM DGHS,
but i got the drive<->firmware-file table by pressing <F3> (you can also
run the "FDRIVE.EXE" program which has an option to list the table, which
is embedded in some non-text file)

Fortunately the .BIN file is raw data compatible with the Digital UNIX
"SCU" command's "download" function.  I used a DEC 3000/300 to do:

	% scu -f /dev/rrz3c download /var/tmp/gs51is4f.bin save

to overwrite the SGI flashed firmware.  (fwiw, 'scu' on dunix really rocks
for these types of things, and is a big reason to keep the old 3000/300 around)

Before:                          After:                    
Vendor:   SGI                    Vendor:   IBM-PCCO        
Product:  IBM  DGHS09Y           Product:  IBM  DGHS09Y    
Revision: 0190                   Revision: 04F0            


--------------------------------------------------------------------------
Finally, MrBill says:

> Why?  They shoulda worked in a SPARC out of the box, no matter if they
> said "SGI" in the vendor string.

But the firmware doesn't change just the SGI Vendor ID string.  It's actually
different code (some 256KB or so).  It's possible that the SGI version is
a simple Vendor ID string change as well as the different Version Tag (0190),
but it seems unlikely (when the IBM version is 04F0 or something).

I've never had trouble on suns with other IBM Retail/Sun-branded/OEM-generic
disks, so that's why i wanted to flash a known good retail firmware onto it.

Have you used these drives?  Have you used them on a SS20 (esp) or Ultra1
(fas)?  It's possible they work just fine on a different sun box.  Fortunately,
the problem is more an annoyance than a fatal issue, but it's annoying
enough that i really want to get rid of it, but not to disable my system on
a global scale (i.e. disable CMD Tag Queueing globally, etc)

--stephen
--
Stephen Dowdy - Systems Administrator - CS Dept - Univ of Colorado at Boulder
dowdy at cs.colorado.edu  --  http://www.cs.colorado.edu/~dowdy/signature.html