[SunRescue] SPARCserver+SSA Questions (lots :)

[sparcy]

Hey Bjorn + other sun rescuers.

Sorry for the late reply, I've been working my butt of the last couple of
days :(

> 
> > > And sorry for the huge filesizes. These are just raw (unedited) scans
> > > which eventually will show up at www.sunhelp.org hopefully someday.
> > 
> > Excellent pictures, I love 'm ! I'm gonna print these out and hang 'm above
> > my bed :)
> 
> Hehe. I have some pictures of the SC2000(E) too, which are even better
> looking. :-)
> ('Data Center' cabinet, like the 4/x90 series)

jummy!, me want urls, URLS, URLS ! :)
 
<snip>
> > Another thing that struck me was that both system board 1 and 2 have both
> > 4 cpu's on it, so there should be 8 cpu's in total! (I know this arch
> > can support 8, but when linux boots it only tells me it has 4), I know
> > that if I boot my SparcStation20 with "boot -v" it tells me which
> > cpu it sees (e.g. counting them) - but booting this baby with the -v
> > switch tells me a lot - just not much about the cpu's. Is there another
> > way to get this info from the prom ? (I guess I need to look at the
> > raw device node's ... right ?)
> 
> Well, no. If you look carefully, you see that the modules only hold one
> CPU and one 'Cache Controller' each. It's not possible,
> architecture-wise with the XDBus, to run any modules without cache
> onboard.

You're right, I seemed to have been temporarily blind, and missed the big
white letters saying "Cache Controller" ... duh.

Indeed it got 4 cpu's total (still nice enough :)
 
> SPARCserver 1000:	(40MHz backplane)
> runs SM41 and SM51
> 
> SPARCserver 1000E:	(50MHz backplane)
> runs SM61 and SM81
> 
> Another thing which might confuse you is that the SM61 and SM81 have a
> huge heatsink which covers both the CPU and the cache controller,
> assuming (visually) 'just one CPU'. Atleast some (or almost all) of the
> SM41 and SM51 have two seperate heatsinks, one on each chip, which could
> confuse things. (visually looking as 'two CPUs')
> Sounds like you have the 1000-model, without the 'E'.

Hmmm, well there are 2 black 'circles' for each CPU (e.g. the cpu and the
cache controller) and then there are 2 additional silver 'plates' - these
are the extra heat sinks ? (since they are quite far away from the actual
chip)
 
<snip>
> > > The first 2 green lights is sitting there just telling you if either CPU
> > > is working or not. (Green LED off = nonfunctional or non-excistent CPU)
> > > The other ones just have the same function as on the 4/300, 4/400 and
> > > 4/600 CPU's (and probably some Sun3s); activity-LEDS - in a very cool
> > > way. :-)
> > 
> > Cool! So they actually *do* have a meaning ! It's shame they are at the back
> > tho, I've caught myself many times this week hanging my head over the server
> > and looking at those neat lights :-)
> > Excellent tho, I'm gonna have a whack at running 12 compilers and cranking
> > up the load av. just to see how they react.
> 
> Just run a SETI at Home client task (which are single threaded), and you
> should definitly see one of those runner-lights starting to slow down,
> almost to a stop. Could be useful to see if there's any activity on
> either CPU. :-)

This is indeed what it is, although looking closer at it for the last couple
of days it seems that they speed up when the load goes up (?) when the
system is idle for a couple of minutes they just stop all togeter.

<snip great tip for getting out the disk trays> 
> > This is kind of wierd ; indeed they all blink when you power-on, then
> > each drive spins up (you can actually hear this, just like a tiny
> > jet engine powering up) and after a couple of minutes all lines are
> > solid except those 3 ones (they keep blinking). At least that was
> > until yesterday, now only 2 lines keep blinking (the most left and
> > right) ... maybe there's just something wrong with these drives
> > although it's strange that they are all in one line ...
> 
> Try refitting all three trays, as there could be some glitch in the
> connectors. Also check all drives and reseat them properly in their
> positions. After all, you don't know what this machine could have gone
> through. Also look after the software, which should been installed on
> the machine, to try to check things up with the array.
> If all things fail, it could be the interface board on the array.

Yeah I tried that, I also put those disks in a different spot but there
are still 2 which keep blinking, I guess these disks are broken (I'll
put 'm in my SS20 to see if they are really broken)

All disks are Seagate Barracude except those 3 which are Quantum disks,
this probably explains it too, I always found Quantum disks to be of
poor quality. (I crashed 2 quantum bigfoot's in one year in my PC)

> Have you seen the drives in the front, behind the plastic cover and that
> metal plate?
> There you have a SCSI-controller which hangs directly on the XDBus, thus
> providing a "systemwide" controller without depending on either
> systemboard. Looks like it has a serial-port too. Neat stuff.

I'm not sure, what I thought (but this doesn't seem to be the case) that
the controllers were actually located somewhere in the tray, but I can't
find anything there (except disks) - should I look elsewhere, or am I
just missing the obvious (again :)
 
> > That number, 6229, means (at least that's what I gathered) from the
> > online docs just the array ID, so nothing scary about that number,
> > as far as finding out what the blinking lines and the blinking
> > led at the back of the array mean, still no luck, I looked at
> > the document you pointed out but there's nothing about either
> > the LCD (well some info but not much) or about the LED at the
> > back ... I'm gonna keep looking for this info.
> 
> Please report back to our S.H.R (Sun Hardware Reference) maintainer.
> This is useful info.
> 

I'm not sure what you mean, who's the S.H.R. ?

I did verify this btw, indeed it seems that 6229 (which is actually
B229 - I know now) are the last 4 digits of the id code of the array.

I booted up the old solaris stuff and actually got a connection to the
array now! (I hadn't tested the actual software yet), indeed the
ssaadm utility gives me the full ID code and other usefull info.

<snip> 
> > Wow. Thanks for the explanation, great to get some insight on the technical
> > details. I looked at the processor in the array and it's a MicroSPARC-II
> > (STP 1012PGA, MB 86904 to be precise) - so this must be a 110/112/114 model
> > then right ? (btw is there a mark/sticker somewhere which tells me what this
> > is exactly (e.g. 110, 112 or 114) - I've looked in various places but
> > still haven't been able to find it.
> 
> I haven't found any sticker either, just looked at the FEH, telling me
> that there were two models with either MicroSPARC or MicroSPARC-II. I
> think I even have the "-110" mark on my arrays, which further proved the
> fact.

Yeah, the ssaadm told me it was a 110.

To be exact :

SSA110, Rev 1.0, firmware Rev: 3.6
 
> > I've never played around with FC, but
> > it certainly looks good, I gathered there's even an ANSI standard for
> > it (and there aren't that many ANSI compliant standards for hardware
> > communication protocols) so I'm gonna look a little closer at this,
> > I find it quite remarkable that Sun already had this kind of technolage
> > in the early nineties actually.
> 
> Sun has been running this for quite some years now, but I think there
> was a marketing step to further improve the interface and possibly make
> it more "open" to other vendors. Earlier everyone relied on SCSI, which
> was limited in certain cases.
> There are many forums, resellers and products today, but everyone seems
> to have forgotten that Sun was one of the pioneers of FC earlier.
> 
> As for now, we've invested in a Compaq (Digital) RAIDarray 8000 with
> FC-AL interface, hubs and some servers. Cool to the the massive
> throughput of this baby. Just formatting a RAID-set keeps the controller
> busy with 45MB/s throughput. :-)

Wanna trade ? 

:)

I always loved Digital (still got a little cluster of 4 digital PC boxes
running, in fact this email is going through one of them, the mail server)
 
> > I'm certainly gonna play a little more with Solaris (it's still on one
> > of the disks in the server) - it seems though that there's actually
> > array support in the linux kernel though! It's called pluto
> > (for the kernel hackers among us :
> > /usr/src/linux-2.2.*/drivers/scsi/pluto.c, and /usr/src/drivers/fc4/*.c)
> > which calls a soc module to set up initial communication with the array
> > (sending&recieving packets over the FC) and then tries to communicate
> > with the array itself.
> 
> Cool. Things are going forward for the S/Linux project as it seems.
> Too bad we don't have any 4/400 support yet. :-(
> I'll take a closer look at this. Looks interesting.

Yeah, I still haven't got the array up under linux tho, I think I'm gonna
bug the author of the FC code with it :)

The source code talks about a micro code from the solaris soc driver but
I haven't been able to figure out where I should find this, do you know
by any chance where this could be located ?

  
Again, thanx for all the great info, it's really cool to get this kind
of help!

Cheers,
sparcy.