>der mouse shrieked:

>>> Actually, you can use 36-bit SIMMs, as well.
>> Yes, the hardware FAQ claimed this was possible -- just can't mix and
>> match 33/36...
>
>You can't?  I've never had trouble playing mix-&-match; it always just
>uses the narrowest width of anything I've got in there.


<shrug>  Dunno.  You will note that I said "the hardware FAQ claimed..."
I haven't tried it on the Classic or the LX -- prefering to live
with whatever is there *working*, now...  :-(

>Unless you mean that there's a problem with the <IPX,33,36> triple, and
>I just haven't happened to try that particular one, which certainly
>could be.

>>> at the "ok" PROM prompt), when the machine resets, you will see RAM
>>> tests done, and then a message saying something like "switching to
>>> 33 bit parity mode" or "switching to 36 bit parity mode."
>> Ah, cool!
>
>Yes, it is.  I've used this mode as a memory sizing tool - when I have
>a 72-pin stick of unknown size and width, I set diag-switch? true, pop
>it in, and watch the messages.  If the stick is bad, it sometimes dies;

Oh.  I find it easier to just check the P/N's of the components on
the SIMM.  :>  While I have been delighted at how easy the SPARCs
are to open up, etc., I find the SIMM sockets to be pretty
begrudging when it comes to releasing SIMMs.  Also, FWIW, most
SIMM sockets are really only specified for a *handful* of
insertions (of course, they tend to work much longer than that
but I don't want to troubleshoot a flakey SIMM socket!)

>putting good 4Mx36 sticks on either side of it will usually make it

Ah, that's worth knowing.  I.e. put the suspect SIMM in slot 1
and populate slots 0 and 2 with 4M devices?  Isn't there any
sort of rule regarding "largest devices in lowest slots"?

>not-hang, reducing the failure mode to an error from the memory
>selftest.


Sure would be nice to know the fancy "light flash" codes on the
keyboard!  Had some bad 4M SIMMs in an LX (?) and couldn't even
get the banner/logo to appear!  :-(  But, could see that something
was obviously running by the patterns on the keyboard LEDs

>> Well, one can argue that if you *need* parity, you're already dealing
>> with a flakey system/design!  :>
>
>True.  But doing parity allows to at least find out that your system
>has gone flaky, which is arguably better than silently getting bad
>bits.


Yes, of course.  My comment was intended tongue in cheek.
20 years ago, the ECC systems were often flakey enough that
they *decreased* reliability -- though, as you said, the
system would fail *dead* which could be argued as being
SAFER than failing half way!

--don