On Thu, Apr 24, 2008 at 8:07 AM, Andrew Gabriel <Andrew.Gabriel at sun.com>
wrote:
> Mike Gerdts wrote:
> > On a V490 with a QGE (e.g X4444A) installed before Solaris is
> > installed, ce0 - ce3 will be the QGE and the onboard interfaces will
> > be ce4 and ce5.
> >
>
> Oh, OK. When I asked about this (albeit, probably 7-8 years ago), I was
> told OBP guaranteed to enumerate on-board devices first. Looks like that's
> not true (or maybe something goes wrong between OBP and Solaris). I know it
> never was true on x86 -- in the general case, I don't think we've anyway of
> knowing if a PCI device is tracked onto the motherboard, or in a PCI card
> slot.
After path_to_inst has been "fixed":
$ grep '"ce"' /etc/path_to_inst
"/pci at 8,600000/pci at 1/pci at 0/network at 0" 2 "ce"
"/pci at 8,600000/pci at 1/pci at 0/network at 1" 3 "ce"
"/pci at 8,600000/pci at 1/pci at 4/network at 2" 4 "ce"
"/pci at 8,600000/pci at 1/pci at 4/network at 3" 5 "ce"
"/pci at 9,700000/network at 2" 0 "ce"
"/pci at 9,600000/network at 1" 1 "ce"
Without looking at any other references, I can see:
ce2 - ce5 appear to be on the same QGE and ce0 and ce1 are likely on
the system board (shortest device path).
If you dig a bit further you can see:
$ prtpicl -v -c network | egrep -e ':(version|devfs-path|board-model)'
:board-model 501-6522
:version Sun PCI Quad Gigaswift 10/100/1000Base-T FCode 2.12 03/11/11
:devfs-path /pci at 8,600000/pci at 1/pci at 0/network at 0
:board-model 501-6522
:version Sun PCI Quad Gigaswift 10/100/1000Base-T FCode 2.12 03/11/11
:devfs-path /pci at 8,600000/pci at 1/pci at 0/network at 1
:board-model 501-6522
:version Sun PCI Quad Gigaswift 10/100/1000Base-T FCode 2.12 03/11/11
:devfs-path /pci at 8,600000/pci at 1/pci at 4/network at 2
:board-model 501-6522
:version Sun PCI Quad Gigaswift 10/100/1000Base-T FCode 2.12 03/11/11
:devfs-path /pci at 8,600000/pci at 1/pci at 4/network at 3
:version Gigaswift FCode 2.11 03/09/10
:devfs-path /pci at 9,700000/network at 2
:version Gigaswift FCode 2.11 03/09/10
:devfs-path /pci at 9,600000/network at 1
Further, if you take a look at the output of prtfru, you can see that
this type of mapping is already done for many parts. Consider the
following description of the DIMM in slot J2900 (which should be
printed on the system board next to the slot):
/frutree/chassis/centerplane/cpu-mem-slot?Label=A/cpu-mem-module/cpu-module?Label=0
/frutree/chassis/centerplane/cpu-mem-slot?Label=A/cpu-mem-module/cpu-module?Label=0/dimm-slot?Label=J2900
/frutree/chassis/centerplane/cpu-mem-slot?Label=A/cpu-mem-module/cpu-module?Label=0/dimm-slot?Label=J2900/dimm-module
(contain
er)
SEGMENT: SD
/ManR
/ManR/UNIX_Timestamp32: Wed Feb 9 01:01:06 CST 2005
/ManR/Fru_Description: 1024 MB NG SDRAM DIMM
/ManR/Manufacture_Loc: IFPT PORTUGAL
/ManR/Sun_Part_No: 5016109
/ManR/Sun_Serial_No: 003A78
/ManR/Vendor_Name: Infineon (formerly Siemens)
/ManR/Initial_HW_Dash_Level: 02
/ManR/Initial_HW_Rev_Level: 50
/ManR/Fru_Shortname: DIMM
/Fru_Type: 1024 MB DIMM
/DIMM_R
/DIMM_R/DIMM_Speed: 75
/DIMM_R/DIMM_Size: 1024
I think it is *just* a matter of being sufficiently motivated to
generate the appropriate data for libpicl and/or libfru to use and
then getting some more user-friendly tools than prtpicl and prtfru to
tell people about their hardware.
--
Mike Gerdts
http://mgerdts.blogspot.com/
