I recommend 2 things: 1) Use live upgrade to install the current 10_Recommended cluster on the control domain 2) After rebooting onto the updated os, use the procedure for updating your firmware from a local disk file specified in the fw readme. That will clear your problem if the upload to prom succeeds. I am not sure how to reset the SP from solaris but it should be in the sp manual. It obviously is possible and I would dig thru the script that does the upload to find it. But try just installing the new fw.
If you get your sp reset and don't update sp and os this will recur repeatedly. ----- Original Message ----- From: Manek, Joe A (SAIC) <[email protected]> To: Hudes, Dana; [email protected] <[email protected]> Sent: Thu Apr 28 18:53:06 2011 Subject: RE: [ldoms-discuss] ldoms-discuss Digest, Vol 45, Issue 24 I absolutely believe you, I was just hoping that someone might have hacked up a workaround to get the SP reset so that I might gain access to my Serial/Network Mgmt ports and/or ldm interface. Thanks. -----Original Message----- From: Hudes, Dana [mailto:[email protected]] Sent: Thursday, April 28, 2011 2:46 PM To: Manek, Joe A (SAIC); '[email protected]' Subject: Re: [ldoms-discuss] ldoms-discuss Digest, Vol 45, Issue 24 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
