Explorer is a set of shell scripts and runs prtdiag among other things. Read the reaedme for the firmware patch if you don't take my word that this is a known bug in your revision firmware. It comes to this: update or suffer more until you do.
----- Original Message ----- From: [email protected] <[email protected]> To: [email protected] <[email protected]> Sent: Thu Apr 28 18:14:28 2011 Subject: Re: [ldoms-discuss] ldoms-discuss Digest, Vol 45, Issue 24 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 _______________________________________________ ldoms-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
