SS20 memory issue "nothing there"

Hi,

I've got a problem concerning my SS20. After upgrading the
memory I get the message:

....
Probing Memory Bank #3 nothing there
....

although there is DRAM, which is ok in other places. None
of the tests during POST or done at the boot prompt reports
any issues. There are 2x64, 2x32 and 4x16 MB and I've tried
contiguous and some permutations of noncontiguous block
ordering according to the maintenance manual to no avail.

Bank #3 was empty before so I've got nothing to compare with.

Can I savely assume now this is because of a defective socket,
or are there other possibilities? To put it in other words:
can a memory bank get "switched off" or "blinded out" other
than by hardware failure?

I vaguely remember I once read about similar errors in
connection with VSIMM replacement or the like but there is
none.

Regards,
Michael

On 2011-05-01, Michael Moeller <> wrote:
> Hi,
>
> I've got a problem concerning my SS20. After upgrading the
> memory I get the message:
>
> ...
> Probing Memory Bank #3 nothing there
> ...
>
> although there is DRAM, which is ok in other places. None
> of the tests during POST or done at the boot prompt reports
> any issues. There are 2x64, 2x32 and 4x16 MB and I've tried
> contiguous and some permutations of noncontiguous block
> ordering according to the maintenance manual to no avail.
>
> Bank #3 was empty before so I've got nothing to compare with.

Hmm ... which order did you use for installing the SIMMs?

Looking at my dead tree issue of the FEH shows two sequences,
one of which is described as "Does not match the bank order", while the
other says "Does match the bank order".

From the front edge to the SBUS sockets the orders are:


J0201 SIMM 0 SIMM 0

J0202 SIMM 1 SIMM 2

J0203 SIMM 2 SIMM 5

J0301 SIMM 3 SIMM 3

J0302 SIMM 4 SIMM 6

J0303 SIMM 5 SIMM 1

J0304 SIMM 6 SIMM 7

J0305 SIMM 7 SIMM 4

The order to the right is the one which matches the bank order, FWIW.

Also of interest, depending on which order the report is being
given in, is that the most likely "Bank 3" is the one which is also used
for the two VSIMMs. Perhaps the presence of a specific framebuffer
calls for these to contain VSIMMs, not normal SIMMs. It would be
helpful if the report included the J???? numbers.

> Can I savely assume now this is because of a defective socket,
> or are there other possibilities? To put it in other words:
> can a memory bank get "switched off" or "blinded out" other
> than by hardware failure?

It could be something as simple as some dust in the bottom of
one of the SIMM sockets -- and perhaps an important one needed to make
connection to confirm that the SIMM is present.

Of course -- it also could be a zapped gate in an address
decoding chip or something like a surface-mount lead floating high
because of a poor solder joint.

> I vaguely remember I once read about similar errors in
> connection with VSIMM replacement or the like but there is
> none.

But perhaps a framebuffer present calls for VSIMMs -- or the
absence of a framebuffer forces the on-board framebuffer to require a
VSIMM to be present.

There is a mention of needing to run sxconfig (1M) to configure
contiguous memory.

Good Luck,
DoN.

--
Remove oil spill source from e-mail
Email: <> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Thanks for your input.

According to the maintenance manual bank #3 = J0301 = 0c000000.
VSIMM goes to slots 4 and 7. Ordering is 0, 2, 5, 3, 6, 1, 7, 4
from front to back. So it's the 4th position from the front.
This can be verified by plugging in different units which get
ignored all together.

Also according to the manual if using mixed DRAM units (64, 32, 16MB) the
biggest one goes to slot 0 (J0201) with no further restrictions. If you
want to configure contiguous blocks of memory with sxconfig you must use
the ordering 0, 1, 2, etc. This only works with 16 and 64 MB units.

I have no VSIMMs and no memory ist configured for video as stated by
sxconfig -c.

However, in my point of view at boot time the machine must show all
accessible memory regardless of my configurations.

What about NVRAM? Is it possible to mess things up there in regard of
memory?

Regards,
Michael



On Mon, 2 May 2011, DoN. Nichols wrote:

> On 2011-05-01, Michael Moeller <> wrote:
>> Hi,
>>
>> I've got a problem concerning my SS20. After upgrading the
>> memory I get the message:
>>
>> ...
>> Probing Memory Bank #3 nothing there
>> ...
>>
>> although there is DRAM, which is ok in other places. None
>> of the tests during POST or done at the boot prompt reports
>> any issues. There are 2x64, 2x32 and 4x16 MB and I've tried
>> contiguous and some permutations of noncontiguous block
>> ordering according to the maintenance manual to no avail.
>>
>> Bank #3 was empty before so I've got nothing to compare with.
>
> Hmm ... which order did you use for installing the SIMMs?
>
> Looking at my dead tree issue of the FEH shows two sequences,
> one of which is described as "Does not match the bank order", while the
> other says "Does match the bank order".
>
> From the front edge to the SBUS sockets the orders are:
>
>
> J0201 SIMM 0 SIMM 0
>
> J0202 SIMM 1 SIMM 2
>
> J0203 SIMM 2 SIMM 5
>
> J0301 SIMM 3 SIMM 3
>
> J0302 SIMM 4 SIMM 6
>
> J0303 SIMM 5 SIMM 1
>
> J0304 SIMM 6 SIMM 7
>
> J0305 SIMM 7 SIMM 4
>
> The order to the right is the one which matches the bank order, FWIW.
>
> Also of interest, depending on which order the report is being
> given in, is that the most likely "Bank 3" is the one which is also used
> for the two VSIMMs. Perhaps the presence of a specific framebuffer
> calls for these to contain VSIMMs, not normal SIMMs. It would be
> helpful if the report included the J???? numbers.
>
>> Can I savely assume now this is because of a defective socket,
>> or are there other possibilities? To put it in other words:
>> can a memory bank get "switched off" or "blinded out" other
>> than by hardware failure?
>
> It could be something as simple as some dust in the bottom of
> one of the SIMM sockets -- and perhaps an important one needed to make
> connection to confirm that the SIMM is present.
>
> Of course -- it also could be a zapped gate in an address
> decoding chip or something like a surface-mount lead floating high
> because of a poor solder joint.
>
>> I vaguely remember I once read about similar errors in
>> connection with VSIMM replacement or the like but there is
>> none.
>
> But perhaps a framebuffer present calls for VSIMMs -- or the
> absence of a framebuffer forces the on-board framebuffer to require a
> VSIMM to be present.
>
> There is a mention of needing to run sxconfig (1M) to configure
> contiguous memory.
>
> Good Luck,
> DoN.
>
> --
> Remove oil spill source from e-mail
> Email: <> | Voice (all times): (703) 938-4564
> (too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
> --- Black Holes are where God is dividing by zero ---
>

On 2011-05-03, Michael Moeller <> wrote:
> Thanks for your input.
>
> According to the maintenance manual bank #3 = J0301 = 0c000000.
> VSIMM goes to slots 4 and 7. Ordering is 0, 2, 5, 3, 6, 1, 7, 4
> from front to back. So it's the 4th position from the front.
> This can be verified by plugging in different units which get
> ignored all together.
>
> Also according to the manual if using mixed DRAM units (64, 32, 16MB) the
> biggest one goes to slot 0 (J0201) with no further restrictions. If you
> want to configure contiguous blocks of memory with sxconfig you must use
> the ordering 0, 1, 2, etc. This only works with 16 and 64 MB units.

O.K.

> I have no VSIMMs and no memory ist configured for video as stated by
> sxconfig -c.

O.K.

> However, in my point of view at boot time the machine must show all
> accessible memory regardless of my configurations.

One would think that it should.

I still consider the possibility of a piece of housedust or lint
insulating one or two crucial pins in the SIMM socket. You may need a
small bright light (perhaps one of the flexible LED ones) and a
magnifier to scan the pins. I have run into this both in the DIMM
sockets and the CPU sockets in more recent Sun Blade 1000 and 2000
machines.

But is is also possible that a static zap (from someone who did
not know to take anti-static precautions while changing SIMMs and cards)
has taken out part of the data transfer pins on interface chips on the
system board.

> What about NVRAM? Is it possible to mess things up there in regard of
> memory?

I don't have a SS-20 up right now, but I don't remember anything
in the NVRAM parameters which might control memory addressing.

I presume that the NVRAM battery is still good, so the hostid is
correct? If not, it simply might think that it cannot have any memory
there.

Does that version of the OPM have a diagnostic switch or two?

An SS-5 has the following:

================================================== ====================
diag-file: data not available.
diag-device=net
diag-switch?=false
================================================== ====================

While a SB-2000 has this:

================================================== ====================
diag-passes=1
diag-file: data not available.
diag-device=disk:f
diag-script=none
diag-level=min
diag-switch?=false
================================================== ====================

In any case -- what happens when you set "diag-switch?" to
"true" and then reboot?

And for that matter -- which version of the OBP do you have?
Back then, IIRC, the only way to update it was by changing a plug-in
ROM -- not like the more recent machines where the OBP is in NVRAM, so
you can upgrade it at will (pending ability to download the latest
version, of course). Yep -- boot prom is socketed at U1005 in either
version of the system board. I seem to remember some of the DIMM
arrangements being sensitive to which version of the OBP you have.

Good Luck,
DoN.

--
Remove oil spill source from e-mail
Email: <> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

DoN. Nichols wrote:

> I still consider the possibility of a piece of housedust or lint
> insulating one or two crucial pins in the SIMM socket. You may need a
> small bright light (perhaps one of the flexible LED ones) and a
> magnifier to scan the pins.
>
Bright idea! Inspecting the socket with a light and a magnifier I found
one of the tiny metal clips of bank #3 deformed. Using a small fixing
pin I carefully moved it back to position. Slot #3 is back again!

> Does that version of the OPM have a diagnostic switch or two?
>
> An SS-5 has the following:
>
> ================================================== ====================
> diag-file: data not available.
> diag-device=net
> diag-switch?=false
> ================================================== ====================
>
For the sake of completeness: it's like the above.

> In any case -- what happens when you set "diag-switch?" to
> "true" and then reboot?
That's when it tells me it has 224 MB instead of 256 (with a 32MB DIMM
at slot #3).


I seem to remember some of the DIMM
> arrangements being sensitive to which version of the OBP you have.
That's interesting. I'll keep that in mind.

Thanks again for insisting on the magnifier!

Regards,
Michael

On 2011-05-04, Michael Moeller <> wrote:
> DoN. Nichols wrote:
>
>> I still consider the possibility of a piece of housedust or lint
>> insulating one or two crucial pins in the SIMM socket. You may need a
>> small bright light (perhaps one of the flexible LED ones) and a
>> magnifier to scan the pins.
>>
> Bright idea! Inspecting the socket with a light and a magnifier I found
> one of the tiny metal clips of bank #3 deformed. Using a small fixing
> pin I carefully moved it back to position. Slot #3 is back again!

Great! I wasn't expecting a bent pin, but that can certainly do
it. (As is obviously the case here.)

[ ... ]

> I seem to remember some of the DIMM
>> arrangements being sensitive to which version of the OBP you have.
> That's interesting. I'll keep that in mind.
>
> Thanks again for insisting on the magnifier!

You're welcome. Now I guess it is time to try to find some more
of the larger SIMMs for the system, now that can see all slots.

Enjoy,
DoN.

--
Remove oil spill source from e-mail
Email: <> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---