Sun Microsystems, Inc.  Sun System Handbook - ISO 3.4 June 2011 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-71-1005882.1
Update Date:2009-09-27
Keywords:

Solution Type  Technical Instruction Sure

Solution  1005882.1 :   How might the upa-noprobe-mask setting on an Sun Enterprise[TM] 450 become set to something other than 0.  


Related Items
  • Sun Enterprise 450 Server
  •  
Related Categories
  • GCS>Sun Microsystems>Servers>Entry-Level Servers
  •  

PreviouslyPublishedAs
208181


Steps to Follow
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[TM]) 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" occurrences 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.


Product
Sun Enterprise 450 Server

Previously Published As
18861

Change History
Date: 2003-05-20
User Name: Administrator
Action: Migration from KMSCreator
Comment: updated by : Laurie Hutchins
comment : Verified technically accurate by Hardware-systems.
Reviewed and edited by KE.
date : Jun 16, 2000



updated by : Karen Vergakes
comment : This Doc is ok.
date : Jun 12, 2000



updated by : No owner
comment : added note explaining the change in variable
name for upa-noprobe-list
date : Sep 16, 1999
Version: 0
Product_uuid
29656238-0a18-11d6-91d9-a4e449afd809|Sun Enterprise 450 Server

Attachments
This solution has no attachment
  Copyright © 2011 Sun Microsystems, Inc.  All rights reserved.
 Feedback