Interesting. Now that I've run 'explorer' for Oracle support, which
also hung and I had to kill during data collection, I can now issue a
'prtdiag -v' command but only get partial output, nothing after where
the "Environmental Status" would normally have been. Still no response
from a 'ldm list -l' command nor from the Network or Serial Mgmt ports.
Progress, I guess?
alysun20# prtdiag -v
System Configuration: Sun Microsystems sun4v T5240
Memory size: 8192 Megabytes
================================ Virtual CPUs
================================
CPU ID Frequency Implementation Status
------ --------- ---------------------- -------
0 1415 MHz SUNW,UltraSPARC-T2+ on-line
1 1415 MHz SUNW,UltraSPARC-T2+ on-line
2 1415 MHz SUNW,UltraSPARC-T2+ on-line
3 1415 MHz SUNW,UltraSPARC-T2+ on-line
4 1415 MHz SUNW,UltraSPARC-T2+ on-line
5 1415 MHz SUNW,UltraSPARC-T2+ on-line
6 1415 MHz SUNW,UltraSPARC-T2+ on-line
7 1415 MHz SUNW,UltraSPARC-T2+ on-line
8 1415 MHz SUNW,UltraSPARC-T2+ on-line
9 1415 MHz SUNW,UltraSPARC-T2+ on-line
10 1415 MHz SUNW,UltraSPARC-T2+ on-line
11 1415 MHz SUNW,UltraSPARC-T2+ on-line
12 1415 MHz SUNW,UltraSPARC-T2+ on-line
13 1415 MHz SUNW,UltraSPARC-T2+ on-line
14 1415 MHz SUNW,UltraSPARC-T2+ on-line
15 1415 MHz SUNW,UltraSPARC-T2+ on-line
======================= Physical Memory Configuration
========================
Segment Table:
--------------------------------------------------------------
Base Segment Interleave Bank Contains
Address Size Factor Size Modules
--------------------------------------------------------------
0x0 128 GB 16 8 GB MB/CMP0/BR0/CH0/D0
MB/CMP0/BR0/CH1/D0
8 GB MB/CMP0/BR1/CH0/D0
MB/CMP0/BR1/CH1/D0
8 GB MB/CMP1/BR0/CH0/D0
MB/CMP1/BR0/CH1/D0
8 GB MB/CMP1/BR1/CH0/D0
MB/CMP1/BR1/CH1/D0
8 GB MB/CMP0/BR0/CH0/D1
MB/CMP0/BR0/CH1/D1
8 GB MB/CMP0/BR1/CH0/D1
MB/CMP0/BR1/CH1/D1
8 GB MB/CMP1/BR0/CH0/D1
MB/CMP1/BR0/CH1/D1
8 GB MB/CMP1/BR1/CH0/D1
MB/CMP1/BR1/CH1/D1
8 GB MB/CMP0/MR0/BR0/CH0/D2
MB/CMP0/MR0/BR0/CH1/D2
8 GB MB/CMP0/MR0/BR1/CH0/D2
MB/CMP0/MR0/BR1/CH1/D2
8 GB MB/CMP1/MR1/BR0/CH0/D2
MB/CMP1/MR1/BR0/CH1/D2
8 GB MB/CMP1/MR1/BR1/CH0/D2
MB/CMP1/MR1/BR1/CH1/D2
8 GB MB/CMP0/MR0/BR0/CH0/D3
MB/CMP0/MR0/BR0/CH1/D3
8 GB MB/CMP0/MR0/BR1/CH0/D3
MB/CMP0/MR0/BR1/CH1/D3
8 GB MB/CMP1/MR1/BR0/CH0/D3
MB/CMP1/MR1/BR0/CH1/D3
8 GB MB/CMP1/MR1/BR1/CH0/D3
MB/CMP1/MR1/BR1/CH1/D3
================================ IO Devices
================================
Slot + Bus Name + Model
Status Type Path
------------------------------------------------------------------------
----
MB/SASHBA PCIE scsi-pciex1000,58 LSI,1068E
/pci@400/pci@0/pci@8/scsi@0
PCIE2 PCIE network-pciex108e,abcd SUNW,pcie-2xgf
/pci@400/pci@0/pci@9/network@0
PCIE2 PCIE network-pciex108e,abcd SUNW,pcie-2xgf
/pci@400/pci@0/pci@9/network@0,1
MB ETHERNETethernet
disabled /pci@400/pci@0/pci@9/ethernet
MB ETHERNETethernet
disabled /pci@400/pci@0/pci@9/ethernet
PCIE1 PCIE scsi-pciex9005,285 AAC,285
/pci@400/pci@0/pci@c/scsi@0
PCIE3 PCIE network-pciex8086,105e
SUNW,pcie-northstar
/pci@400/pci@0/pci@d/network@0
PCIE3 PCIE network-pciex8086,105e
SUNW,pcie-northstar
/pci@400/pci@0/pci@d/network@0,1
MB/NET0 PCIE network-pciex108e,abcd
SUNW,pcie-neptune
/pci@500/pci@0/pci@8/network@0
MB/NET1 PCIE network-pciex108e,abcd
SUNW,pcie-neptune
/pci@500/pci@0/pci@8/network@0,1
MB/NET2 PCIE network-pciex108e,abcd
SUNW,pcie-neptune
/pci@500/pci@0/pci@8/network@0,2
MB/NET3 PCIE network-pciex108e,abcd
SUNW,pcie-neptune
/pci@500/pci@0/pci@8/network@0,3
PCIE0 PCIE network-pciex108e,abcd SUNW,pcie-2xgf
/pci@500/pci@0/pci@9/network@0
PCIE0 PCIE network-pciex108e,abcd SUNW,pcie-2xgf
/pci@500/pci@0/pci@9/network@0,1
MB ETHERNETethernet
disabled /pci@500/pci@0/pci@9/ethernet
MB ETHERNETethernet
disabled /pci@500/pci@0/pci@9/ethernet
PCIE5 PCIE network-pciex8086,105e
SUNW,pcie-northstar
/pci@500/pci@0/pci@c/network@0
PCIE5 PCIE network-pciex8086,105e
SUNW,pcie-northstar
/pci@500/pci@0/pci@c/network@0,1
MB PCIX usb-pciclass,0c0310
/pci@400/pci@0/pci@1/pci@0/usb@0
MB PCIX usb-pciclass,0c0310
/pci@400/pci@0/pci@1/pci@0/usb@0,1
MB PCIX usb-pciclass,0c0320
/pci@400/pci@0/pci@1/pci@0/usb@0,2
(end of the prtdiag -v output, which ended with exit code of "0").
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Thursday, April 28, 2011 1:09 PM
To: [email protected]
Subject: ldoms-discuss Digest, Vol 45, Issue 24
Send ldoms-discuss mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ldoms-discuss digest..."
Today's Topics:
1. Re: Non-responsive ldm interface (Manek, Joe A (SAIC))
2. Re: Non-responsive ldm interface (Greg Earle)
3. Re: Non-responsive ldm interface (Hudes, Dana)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Apr 2011 10:03:54 -0800
From: "Manek, Joe A (SAIC)" <[email protected]>
To: "Hudes, Dana" <[email protected]>,
<[email protected]>
Subject: Re: [ldoms-discuss] Non-responsive ldm interface
Message-ID:
<776f7f50956d2b48b458ce89957ae91301529...@bp1ancex006.bp1.ad.bp.com>
Content-Type: text/plain; charset="us-ascii"
Thanks. We're at ldom 1.3 on these machines. No joy on restarting the
picld. It restarted but to no affect.
________________________________
From: Hudes, Dana [mailto:[email protected]]
Sent: Thursday, April 28, 2011 9:55 AM
To: Manek, Joe A (SAIC); '[email protected]'
Subject: Re: [ldoms-discuss] Non-responsive ldm interface
There is a known bug in solaris 10. Try restarting picld.
The fix is combo of firmware upgrade to 7.31b (obp 4.30 IIRC - I will
verify) and update solaris to current.
Your obp/ilom doesn' have ldom 2.0
________________________________
From: Manek, Joe A (SAIC) <[email protected]>
To: Hudes, Dana; [email protected]
<[email protected]>
Sent: Thu Apr 28 13:41:18 2011
Subject: RE: [ldoms-discuss] Non-responsive ldm interface
'prtdiag -v' hangs just like 'ldm' commands do. The best I have is from
a console history on our Servial Console Server from (auspicisously)
9/11/2010, but I believe it to still be current.
7, "2010-09-11 14:22:59", "> ", " hypervisor_version = Hypervisor
1.7.9 2010/07/19 15:51"
7, "2010-09-11 14:22:59", "> ", " obp_version = OBP 4.30.9
2010/07/16 09:06"
7, "2010-09-11 14:22:59", "> ", " post_version = POST 4.30.9
2010/07/16 09:40ersion = POST 4.30.9 2010/07/16 09:40
________________________________
From: Hudes, Dana [mailto:[email protected]]
Sent: Thursday, April 28, 2011 8:59 AM
To: Manek, Joe A (SAIC); '[email protected]'
Subject: Re: [ldoms-discuss] Non-responsive ldm interface
Which OBP? Prtdiag -v from control ldom.
________________________________
From: [email protected]
<[email protected]>
To: [email protected] <[email protected]>
Sent: Thu Apr 28 12:45:59 2011
Subject: [ldoms-discuss] Non-responsive ldm interface
Hello all,
I have one of my T5240's which decided to not talk via it's serial or
network mgmt interfaces. This seemed to occur suspiciously during a
recycle of our Cisco/Lantronix Terminal Server. Don't know if something
nasty was inadvertenly sent along the serial connection causing problems
in the Serial Mgmt interface, but now I'm no longer able to do a
'prtdiag -v' on the Control-LDOM or do any 'ldm' which appears to need
to access the Hypervisor. For instance, trival commands such as 'ldm
ls' or 'ldm -V' work fine, but an 'ldm -l' hangs.
I'm also now unable to ssh or http to the Service Processor. Debugging
the ssh connection attempts show it does connect but doesn't actually
complete the connection conversation.
The Global-Zone on Control-LDOM functions w/o issue as do all the
Guest-LDOMs and virtualized resources. Essentially I'm now flying blind
with no console access to Service Processor and no way to
interrogate/modify any LDOM configuration via 'ldm'.
Short of a hard-power cycle, this is a production box, anybody know of
any tricks/techniques to kick the Service Processor in the butt and
restart it w/o the aforementioned power cycle?
Thanks,
Joe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/ldoms-discuss/attachments/2011042
8/a5f4eda1/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 28 Apr 2011 13:55:45 -0700
From: Greg Earle <[email protected]>
To: [email protected]
Subject: Re: [ldoms-discuss] Non-responsive ldm interface
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Apr 28, 2011, at 9:41 AM, Joe A (SAIC) Manek <[email protected]>
wrote:
> Date: Thu, 28 Apr 2011 09:41:18 -0800
> From: "Manek, Joe A (SAIC)" <[email protected]>
> To: "Hudes, Dana" <[email protected]>,
> <[email protected]>
> Subject: Re: [ldoms-discuss] Non-responsive ldm interface
> Message-ID:
>
<776f7f50956d2b48b458ce89957ae91301529...@bp1ancex006.bp1.ad.bp.com>
> Content-Type: text/plain; charset="us-ascii"
>
> 'prtdiag -v' hangs just like 'ldm' commands do.
What happens if you run it under "truss"?
e.g. "/usr/bin/truss /usr/sbin/prtdiag -v"
- Greg
------------------------------
Message: 3
Date: Thu, 28 Apr 2011 17:07:25 -0400
From: "Hudes, Dana" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [ldoms-discuss] Non-responsive ldm interface
Message-ID:
<0cc36eed613aed418a80ee6f44a659db0e07a00...@xch2.windows.nyc.hra.nycnet>
Content-Type: text/plain; charset="us-ascii"
Like I said, it's a known bug with your version of firmware. The fix is
to upgrade to 7.3.0.c (OBP 4.32.2.b) .
Co-requisite is to update your Solaris kernel to 144488-01 or later
________________________________
From: Manek, Joe A (SAIC) [mailto:[email protected]]
Sent: Thursday, April 28, 2011 2:04 PM
To: Hudes, Dana; [email protected]
Subject: RE: [ldoms-discuss] Non-responsive ldm interface
Thanks. We're at ldom 1.3 on these machines. No joy on restarting the
picld. It restarted but to no affect.
________________________________
From: Hudes, Dana [mailto:[email protected]]
Sent: Thursday, April 28, 2011 9:55 AM
To: Manek, Joe A (SAIC); '[email protected]'
Subject: Re: [ldoms-discuss] Non-responsive ldm interface
There is a known bug in solaris 10. Try restarting picld.
The fix is combo of firmware upgrade to 7.31b (obp 4.30 IIRC - I will
verify) and update solaris to current.
Your obp/ilom doesn' have ldom 2.0
________________________________
From: Manek, Joe A (SAIC) <[email protected]>
To: Hudes, Dana; [email protected]
<[email protected]>
Sent: Thu Apr 28 13:41:18 2011
Subject: RE: [ldoms-discuss] Non-responsive ldm interface
'prtdiag -v' hangs just like 'ldm' commands do. The best I have is from
a console history on our Servial Console Server from (auspicisously)
9/11/2010, but I believe it to still be current.
7, "2010-09-11 14:22:59", "> ", " hypervisor_version = Hypervisor
1.7.9 2010/07/19 15:51"
7, "2010-09-11 14:22:59", "> ", " obp_version = OBP 4.30.9
2010/07/16 09:06"
7, "2010-09-11 14:22:59", "> ", " post_version = POST 4.30.9
2010/07/16 09:40ersion = POST 4.30.9 2010/07/16 09:40
________________________________
From: Hudes, Dana [mailto:[email protected]]
Sent: Thursday, April 28, 2011 8:59 AM
To: Manek, Joe A (SAIC); '[email protected]'
Subject: Re: [ldoms-discuss] Non-responsive ldm interface
Which OBP? Prtdiag -v from control ldom.
________________________________
From: [email protected]
<[email protected]>
To: [email protected] <[email protected]>
Sent: Thu Apr 28 12:45:59 2011
Subject: [ldoms-discuss] Non-responsive ldm interface
Hello all,
I have one of my T5240's which decided to not talk via it's serial or
network mgmt interfaces. This seemed to occur suspiciously during a
recycle of our Cisco/Lantronix Terminal Server. Don't know if something
nasty was inadvertenly sent along the serial connection causing problems
in the Serial Mgmt interface, but now I'm no longer able to do a
'prtdiag -v' on the Control-LDOM or do any 'ldm' which appears to need
to access the Hypervisor. For instance, trival commands such as 'ldm
ls' or 'ldm -V' work fine, but an 'ldm -l' hangs.
I'm also now unable to ssh or http to the Service Processor. Debugging
the ssh connection attempts show it does connect but doesn't actually
complete the connection conversation.
The Global-Zone on Control-LDOM functions w/o issue as do all the
Guest-LDOMs and virtualized resources. Essentially I'm now flying blind
with no console access to Service Processor and no way to
interrogate/modify any LDOM configuration via 'ldm'.
Short of a hard-power cycle, this is a production box, anybody know of
any tricks/techniques to kick the Service Processor in the butt and
restart it w/o the aforementioned power cycle?
Thanks,
Joe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/ldoms-discuss/attachments/2011042
8/142f2a08/attachment.html>
------------------------------
_______________________________________________
ldoms-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
End of ldoms-discuss Digest, Vol 45, Issue 24
*********************************************
_______________________________________________
ldoms-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
