memory simms sizes and Solaris 2.5
2007-12-25 11:06:00
ORIGINAL question:
>Awhile back there was a post about how you could tell what type of memory
>simms were installed in your system.
>
>For Solaris you use the "prtconf -pv" command, go to the memory section
>and look for the "reg" line. Everything is grouped in units of three:
>
>EX:
>prtconf -pv
> .. stuff delted ..
> Node 0xffd5c740
> reg:
> 00000000.00000000.04000000.00000000.04000000.04000000.00000000.10000000.04000000.00000000.14000000.04000000
> available:
> 00000000.17f39000.00013000.00000000.10000000.072f3000.00000000.00000000.08000000
> name: 'memory'
>
> the reg line breaks down to:
>00000000.00000000.04000000 The Last number is 04000000, which is 64MB
>00000000.04000000.04000000 01 is 16MB
>00000000.10000000.04000000 02 is 32MB
>00000000.14000000.04000000 04 is 64MB...
>
>This all seems to break under Solaris 2.5
>
> On a SparcCenter 2000 with 768 MB I get the following..
> Node 0xffd717d8
> reg: 00000000.00000000.30000000
> available: 00000000.2fea6000.00015000.00000000.00000000.2ee43000
> name: 'memory'
>
> how does this translate?
>
> On an Ultra with 256MB of memory I get:
> Node 0xf004e8e8
> reg:
> 00000000.00000000.00000000.08000000.00000000.10000000.00000000.08000000
> available:
> 00000000.17f40000.00000000.00014000.00000000.17c02000.00000000.00100000.00000000.10000000.00000000.07400000.00000000
>.00000000.00000000.08000000
> name: 'memory'
>
>Any know what is going on here?
>Summary to follow..
Thanx to the following for answering:
From: Sean McInerney <seanm@sybase.com>
From: Keith Willenson <keith@oz.health.state.mn.us>
From: Torsten Metzner <tom@math.uni-paderborn.de>
From: David Moline <drm@gcs.com.au>
----------------------------------------------------------------------
From: Sean McInerney <seanm@sybase.com>
Add the diag package and use the prtdiag command. Example below:
System Configuration: Sun Microsystems sun4d SPARCserver 1000E
System clock frequency: 50 MHz
Memory size: 2048Mb
Number of XDBuses: 1
CPU Units: Frequency Cache-Size Memory Units: Group Size
A: MHz MB B: MHz MB 0: MB 1: MB 2: MB 3: MB
--------- --------- ----- ----- ----- -----
Board0: 85 1.0 85 1.0 128 128 128 128
Board1: 85 1.0 85 1.0 128 128 128 128
Board2: 85 1.0 85 1.0 128 128 128 128
Board3: 85 1.0 85 1.0 128 128 128 128
======================SBus Cards=========================================
---cut off SBus output---
Each group is 4 SIMM slots so the SIMMS must be 32MB each.
....Seanm
----------------------------------------------------------------------
From: Keith Willenson <keith@oz.health.state.mn.us>
Well since the number is in hex, 30000000 = 805MB more or less
2ee43000 = 786,706,432 or 786MB
following your translation table above:
01 is 16MB
02 is 32MB
04 is 64MB
08 is 128MB
so it looks like you have 2 x 128MB memory chips and the memory is in
4 groups rather than 3 groups.
00000000.00000000.00000000.08000000 = 128MB
00000000.10000000.00000000.08000000 = 128MB
I'd double check this with other sources, but it sounds right to me :-)
HTH,
K
----------------------------------------------------------------------
From: Torsten Metzner <tom@math.uni-paderborn.de>
Hello Trevor,
that's not true. On my SS20 running Solaris2.5.1 everything is fine.
Remember the summary. The following was mentioned:
"SS10 and SS20's which have EMC and SMC memory controllers and
144bit wide SIMMS. Other memory controllers do things differently so
have different registers."
A eight-digit hexadecimal represents a 48 ( = 144/4 ) bit-digit.
If I understand everything, that's the reason why the data is grouped three
word at a time.
I have no idea about the SIMMS bit wides on an ULTRA, but it seems
obvious ( looking at your example and looking at a machine in our pool
which has 128MB ) that the data is grouped in for words a time. Seems to
be 192bit wide SIMMS for the ULTRA ?
|
|On a SparcCenter 2000 with 768 MB I get the following..
| Node 0xffd717d8
| reg: 00000000.00000000.30000000
| available: 00000000.2fea6000.00015000.00000000.00000000.2ee43000
| name: 'memory'
|
| how does this translate?
|
Hmm, .....
00000000.00000000.30000000 ~ 768 MB yes, but you can't see how it is
installed. I have the same problem on our SS1000. So try the:
/usr/platform/`uname -i`/sbin/prtdiag -v
command {;-)
| On an Ultra with 256MB of memory I get:
| Node 0xf004e8e8
| reg:
| 00000000.00000000.00000000.08000000.00000000.10000000.00000000.08000000
| available:
Yupp:
00000000.00000000.00000000.08000000. 08000000 ~ 128 MB
00000000.10000000.00000000.08000000 08000000 ~ 128 MB
That's only an idea, but it seems obvious. Remember the ULTRA is
64 bit architecture.
Hope this helps,
Torsten.
-------------------------------------------------------------------------------
My address : Torsten Metzner E-Mail: tom@uni-paderborn.de
Universitaet-GH Paderborn Tel.: +49 5251 602641
FB 17 - Mathematik Fax : +49 5251 603836
Warburger Str. 100 Office: D3.204
33098 Paderborn
Germany
-------------------------------------------------------------------------------
----------------------------------------------------------------------
From: David Moline <drm@gcs.com.au>
No, I don't think so.
I'm intrigued, the above information is retrieved from the OBP
device tree (which is built before any OS can play with it), so unless Solaris
2.5 is munging it bad it should reflect the correct information. Although the
output from the Ultra looks correct, maybe it uses groups of 4 (do you
have 2 128Mbyte simms?) since it is a 64 bit architecture. Has the output
from these machine ever been different (ie did it produce the correct results
under Solaris 2.4)?
On a Sparc 5 running 2.5 here the output does report the correct information,
and a Sparc 20 running 2.5.1 also shows the correct information.
Regards
---
David Moline (drm@gcs.com.au) Graphics Computer Systems Pty Ltd, Australia
Ph: +61-3-9888-8522 Fax: +61-3-9808-9151
Comments
Got something to say?
You must be logged in to post a comment.
