On 03/27/08 15:01, PRDEEP KUMAR wrote:
Hi Experts,

  I need the info how to see the memory segments size and the base address
of each segment(Bank)
in solaris using the command/API.

There are no formal APIs for this, but much of the information is
available (in platform-dependent ways).  What platform are you interested in?
Be aware that before building any products that consume such interfaces
that they are Private and subject to change etc - if you want to
build a product to consume such interfaces we should formalize
the interfaces and up their stability or contract them.

 Can I be able to see the infos about the memory controllers
 -How many memory controller the system has?
 -What is the address range it address ?
 -Base address of the memory segment  each memory controller holds ?

Can I be able to view all these in MDB?

I did the AMD memory controller work.  The kernel driver builds up
a picture of the memory system for its own purposes, and
exports a private nvlist via a /dev/mc/* ioctl for use in
our topology enumerators.  They take the information and
mark it up into the topo tree which you can view with
/usr/lib/fm/fmd/fmtopo -V.  e.g., for a chip node:

hc://:product-id=Sun-Ultra-40-M2-Workstation:chassis-id=0720TY21V3:server-id=eno
gas/motherboard=0/chip=0
  group: protocol                       version: 1   stability: Private/Private
    resource          fmri      hc://:product-id=Sun-Ultra-40-M2-Workstation:cha
ssis-id=0720TY21V3:server-id=enogas/motherboard=0/chip=0
    FRU               fmri      hc://:product-id=Sun-Ultra-40-M2-Workstation:cha
ssis-id=0720TY21V3:server-id=enogas/motherboard=0/chip=0
    label             string    CPU 0
  group: authority                      version: 1   stability: Private/Private
    product-id        string    Sun-Ultra-40-M2-Workstation
    chassis-id        string    0720TY21V3
    server-id         string    enogas
  group: chip-properties                version: 1   stability: Private/Private
    vendor_id         string    AuthenticAMD
    family            int32     15
    model             int32     65
    stepping          int32     2
    NodeId            uint32    0x0
    CoherentNodes     uint32    0x2
    SbNode            uint32    0x0
    LkNode            uint32    0x0
    SystemCoreCount   uint32    0x4
    C0Unit            uint32    0x0
    C1Unit            uint32    0x1
    McUnit            uint32    0x2
    HbUnit            uint32    0x3
    SbLink            uint32    0x1
    BroadcastRoutes   uint32[]  [ 3 1 ]
    ResponseRoutes    uint32[]  [ 1 2 ]
    RequestRoutes     uint32[]  [ 1 2 ]

And for a MC node under a chip:

hc://:product-id=Sun-Ultra-40-M2-Workstation:chassis-id=0720TY21V3:server-id=eno
gas/motherboard=0/chip=0/memory-controller=0
  group: protocol                       version: 1   stability: Private/Private
    resource          fmri      hc://:product-id=Sun-Ultra-40-M2-Workstation:cha
ssis-id=0720TY21V3:server-id=enogas/motherboard=0/chip=0/memory-controller=0
    FRU               fmri      hc://:product-id=Sun-Ultra-40-M2-Workstation:cha
ssis-id=0720TY21V3:server-id=enogas/motherboard=0/chip=0
  group: authority                      version: 1   stability: Private/Private
    product-id        string    Sun-Ultra-40-M2-Workstation
    chassis-id        string    0720TY21V3
    server-id         string    enogas
  group: memory-controller-properties   version: 1   stability: Private/Private
    num               uint64    0x0
    revision          uint64    0x20f0020
    revname           string    F
    socket            string    Socket F(1207)
    ecc-type          string    ChipKill 128/16
    base-addr         uint64    0x0
    lim-addr          uint64    0x15fffffff
    node-ilen         uint64    0x0
    node-ilsel        uint64    0x0
    cs-intlv-factor   uint64    0x2
    dram-hole-size    uint64    0x60000000
    access-width      uint64    0x80
    bank-mapping      uint64    0x60
    bankswizzle       uint64    0x0
    mismatched-dimm-support uint64    0x0

The structure and node properties of the topo tree are private to the diagnosis
system at this time.  We are beginning to consider formalizing things, but
that's not soon.  You'll see different structure and properties on Intel
systems, and on sparc platforms.  If we were to contract anything today
it would be at the aboce level - i.e., as a libtopo consumer.

The fmtopo output above isn't the most compact thing in the world.
If you're just interested in having a look at the config then
you can dump the driver nvlists in mdb.  Here's the results on
a U40M2 (2 nodes):

> *mc_list::list mc_t mc_next | ::print mc_t mc_nvl | ::nvlist
mcamd-nvlist-version=01
num=0000000000000000
revision=00000000020f0020
revname='F'
socket='Socket F(1207)'
ecc-type='ChipKill 128/16'
base-addr=0000000000000000
lim-addr=000000015fffffff
node-ilen=0000000000000000
node-ilsel=0000000000000000
cs-intlv-factor=0000000000000002
dram-hole-size=0000000060000000
access-width=0000000000000080
bank-mapping=0000000000000060
bankswizzle=0000000000000000
mismatched-dimm-support=0000000000000000
cslist[0]
    num=0000000000000002
    base-addr=0000000000000000
    mask=00000000fffdffff
    size=0000000080000000
    dimm1-num=0000000000000002
    dimm1-csname='MA1_CS_L[0]'
    dimm2-num=0000000000000003
    dimm2-csname='MB1_CS_L[0]'
cslist[1]
    num=0000000000000003
    base-addr=0000000000020000
    mask=00000000fffdffff
    size=0000000080000000
    dimm1-num=0000000000000002
    dimm1-csname='MA1_CS_L[1]'
    dimm2-num=0000000000000003
    dimm2-csname='MB1_CS_L[1]'
dimmlist[0]
    num=0000000000000002
    size=0000000080000000
    csnums=0000000000000002.0000000000000003
    csnames='MA1_CS_L[0]' + 'MA1_CS_L[1]'
dimmlist[1]
    num=0000000000000003
    size=0000000080000000
    csnums=0000000000000002.0000000000000003
    csnames='MB1_CS_L[0]' + 'MB1_CS_L[1]'
htconfig
    NodeId=00000000
    CoherentNodes=00000002
    SbNode=00000000
    LkNode=00000000
    SystemCoreCount=00000004
    C0Unit=00000000
    C1Unit=00000001
    McUnit=00000002
    HbUnit=00000003
    SbLink=00000001
    BroadcastRoutes=00000003.00000001
    ResponseRoutes=00000001.00000002
    RequestRoutes=00000001.00000002
mcamd-nvlist-version=01

num=0000000000000001
revision=00000000020f0020
revname='F'
socket='Socket F(1207)'
ecc-type='ChipKill 128/16'
base-addr=0000000160000000
lim-addr=000000025fffffff
node-ilen=0000000000000000
node-ilsel=0000000000000000
cs-intlv-factor=0000000000000002
dram-hole-size=0000000000000000
access-width=0000000000000080
bank-mapping=0000000000000060
bankswizzle=0000000000000000
mismatched-dimm-support=0000000000000000
cslist[0]
    num=0000000000000002
    base-addr=0000000000000000
    mask=00000000fffdffff
    size=0000000080000000
    dimm1-num=0000000000000002
    dimm1-csname='MA1_CS_L[0]'
    dimm2-num=0000000000000003
    dimm2-csname='MB1_CS_L[0]'
cslist[1]
    num=0000000000000003
    base-addr=0000000000020000
    mask=00000000fffdffff
    size=0000000080000000
    dimm1-num=0000000000000002
    dimm1-csname='MA1_CS_L[1]'
    dimm2-num=0000000000000003
    dimm2-csname='MB1_CS_L[1]'
dimmlist[0]
    num=0000000000000002
    size=0000000080000000
    csnums=0000000000000002.0000000000000003
    csnames='MA1_CS_L[0]' + 'MA1_CS_L[1]'
dimmlist[1]
    num=0000000000000003
    size=0000000080000000
    csnums=0000000000000002.0000000000000003
    csnames='MB1_CS_L[0]' + 'MB1_CS_L[1]'
htconfig
    NodeId=00000001
    CoherentNodes=00000002
    SbNode=00000000
    LkNode=00000000
    SystemCoreCount=00000004
    C0Unit=00000000
    C1Unit=00000001
    McUnit=00000002
    HbUnit=00000003
    SbLink=00000000
    BroadcastRoutes=00000001.00000009
    ResponseRoutes=00000008.00000001
    RequestRoutes=00000008.00000001

So my system has 2 nodes, no node interleaving.  Node 0 claims
system addresses from 0 to 15fffffff (inclusive) and node 1
system addresses from 160000000 to 25fffffff.  That's a range
of 5.5G for node 0 and exactly 4G for node 1 - despite their
being 4GB of RAM on each node;  the additional address space
on node 0 is a result of dram MMIO hole remapping on that node.

Each node has 2 dimms present, as per the dimmlist.  Each dimm
has size 80000000 or 2G.  One dimm is on dram channel A and
the other on channel B on each node, per the chip-select names
associated with the dimms, and since two chip-select lines are
active to each dimm we see they are dual rank dimms.  We are
configured for 128-bit operation so corresponding ranks on
dimms from corresponding slots on each of channel A and B are
being operated as a single logical 128-bit chip-select - so the
4 available ranks on each node are built up into 2 chip-selects
per node each of 2GB.

Finally since there is a hole in the cs mask 00000000fffdffff
(not all f's) we see that chip-select interleaving is
active, so addresses are being interleaved between the chip-selects
on each node.  That is it's not the case that the first chip-select
has a contiguous chunk of addresses followed by the next
chip-select.  That's why cs 0 starts at 0 (on both nodes - system
addresses are normalized to dram addresss by subtracting the node base address)
and cs 1 starts at 0x20000 - so we're interleaving 128K at a time.

Possibly way more detail there than you need :-)

Cheers

Gavin

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to