InfoDoc ID |
|
Synopsis |
|
Date |
18861 |
|
How might the upa-noprobe-mask setting on an e450 become set to something other than 0 |
|
16 Jun 2000 |
This is information from bugid 4175796:
The 'upa-noprobe-mask' should be "0" to reflect working system
hardware.
The only way any bits *should* be set in 'upa-noprobe-mask' is if the
system (OpenBoot) takes a hardware RESET while actively probing the CPU or
other UPA device (PCI HBAs, or AFB/FFB framebuffers). If this happens,
then the "slot" (CPU, PCI, FFB) is left marked in 'upa-noprobe-mask' as
a "don't-touch-cuz-we-get-a-RESET" slot, and OpenBoot procedes to probe
the rest of the system. This should be immediately evident in watching the
ttya initialization output ('diag-switch?' set to "true") -- both the
initial event that results in the bit(s) being set in 'upa-noprobe-mask'
as well as all subsequent "skipping over the slot" occurences due to
bits being set in 'upa-noprobe-mask'. (Typically what would happen is that
OpenBoot just hangs [the system bus hangs] when probing a bad device;
the RESET event is the user power-cycling the hung system.)
(Parenthetically, I will add that I have seen "random NVRAM corruption"
nail 'upa-noprobe-mask', but should be a very rare event.)
Arguably, the "banner" output should report the number of
"happy" CPUs, and not the number of CPU cards detected plugged in,
ignored, failed, or otherwise. This can be separately RFE'ed if desired.
Also, arguably, OpenBoot should be more, ah, "vocal" in complaining
about devices specifically skipped due to 'upa-noprobe-mask' being
non-zero (perhaps it should abort the auto-boot sequence, if the
'auto-boot-on-error?' flag is set to false?)
Booting Unix from CDROM (or anything else) should have nothing to do
with bits getting set in 'upa-noprobe-mask'.
The 'upa-noprobe-mask' should never be non-zero as it leaves Sun.
NOTE:
Depending on the version of OBP on an e450, the upa-noprobe-mask
variable may be named differently. It may be seen in one of the
following forms.
upa-noprobe-list
upa-noprobe-mask
and on the latest versions of OBP it is a hidden variable
.upa-noprobe-mask
You will need to use printenv -a at the OK prompt to see this
variable with the most current version of OBP. Although the
name of the variable has changed a couple of times, it's function
remains the same.
SUBMITTER: Bill Shearer
APPLIES TO: Hardware, Hardware/Ultra Enterprise/Servers/Enterprise 450, Operating Systems/Solaris/Solaris 2.x, AFO Vertical Team Docs, AFO Vertical Team Docs/Hardware
ATTACHMENTS:
Copyright (c) 1997-2003 Sun Microsystems, Inc.