Subject: Re: More about API CS20's
To: Anders Hogrelius <ahs@hogrelius.nu>
From: Stephen Jones <smj@cirr.com>
List: port-alpha
Date: 07/14/2007 12:34:12
On Jul 14, 2007, at 9:13 AM, Anders Hogrelius wrote:
> I loaded the latest version of the SRM firmware (6.6.10) for the  
> DS20L on mine and it works perfectly. Tru64 even identifies the  
> onboard temp and voltage sensors correctly which means I don't have  
> to disable the systems health daemon anymore. With the CS20  
> firmware it complains about a faulty PSU and temp sensor.

Wow, that is good news and quite surprising that a fix like that  
would be incorporated this late in the game.
Do you know what other fixes were made between 5.8-81 and 6.6.10?  I  
suppose with a little work a consolidated
list could be made.  I know that you can get enough info to at least  
to 6.0, so it shouldn't take much work.
The question is if its the newer versions actually help with making  
the platform more stable and probably not.

> A bit more research revealed that Compaq actually made DS20L's with  
> both the Adaptec SCSI controller as well as the Symbios Logic  
> controller. Both types of riser cards exist for the DS20L but with  
> different part ID's and the Compaq/DEC firmware for the DS20L  
> identifies the Symbios Logic controller correctly. -Too bad there  
> aren't any drivers in Tru64 for it.

I thought that there was a way but installing to an IDE drive first,  
at least this procedure seems to outline that:
http://howto.unixdev.net/Tru64-CS20-HOWTO.html

> The DS20L seems to be more than just inspired by the API CS20...

I think that the understanding is that API basically built the CS20  
and then sold or licensed the design back
to Compaq.  They're great machines as long as you keep them cool and  
their fans clear.  SDF has about 24 of
these, so we're on the platform for at least the next 5 years and it  
would be great to be able to refurb some
of or old PSes that have failed.  One interesting thing is that with  
NEB 2.1 we've seen the longest duration
of uptime under an MP kernel with a significant 24/7 user load.  3.x  
doesn't get anywhere near as close, which
is a shame.  And its impossible to debug because its a situation  
where the one processor hangs and if you can
get to the debugger, you can't get any info on that hung processor.