<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"> 
  <channel>
  <title>Voice Operating Systems Hot Issues from Cisco TAC</title>
  <link>http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_tech_note09186a0080937324.shtml</link>
  <description>Hot Issues from Cisco TAC.  Please click the link for complete details.</description>
  <language>en-us</language>

  <managingEditor>wsisk@cisco.com (Wes Sisk)</managingEditor>
  <webMaster>news-at-cisco-rss@cisco.com (Cisco Newsroom)</webMaster>
  <pubDate>Mon, 13 May 2013 09:50:25 EDT</pubDate>
  <lastBuildDate>Mon, 13 May 2013 09:50:25 EDT</lastBuildDate>
  <generator>PERL</generator>

  <docs>http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_tech_note09186a0080937324.shtml</docs>
  <ttl>10080</ttl>

<item>
<title>ServM crashes at servMDataMgr: malloc fails to allocate required memory, Fixed CSCug53756</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug53756</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
The Service Manger services crashes and ServM core is generated. The service crashes as malloc fails to allocate the required memory. This can cause intermittent high CPU/VM usage.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
First seen on Unity Connection 9.1.1
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Contact TAC for temporary Workaround

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug53756</guid>
</item>
<item>
<title>Misleading error message and cause installation fails for upgd 7825H3, Terminated CSCug44559</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug44559</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Rebooting an upgraded 7825H3 with 6GB RAM results in the following error, as does attempting to install CUPS 8.6.4:

Error: not enough physical disks [0 out of 2] of minimum
sdb [size 160] is too small [MIN size 232]
sdb [size 160] is too small [MIN size 232]
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
CUPS 8.6.4 on an MCS 7825H3 with 6GB and 160GB HD x2
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Lowering the RAM to 4GB removes the error, but is not officially supported according to current documentation at:
http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_0/english/compatibility/cupcompatibility8x.html#wp191299

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug44559</guid>
</item>
<item>
<title>A Cisco DB Replicator status incorrectly shown as STOPPED, Open CSCue15816</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue15816</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
A Cisco DB Replicator Service incorrectly status shows up as STOPPED.

++ Both the CLI and GUI will report that the A Cisco DB Replicator service is stopped but the underlying process &quot;dblrpc&quot; would be up and running.
++ DBReplication would remain intact
++ Critical Service Down Alerts would be generated
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
So far,this issue has been seen on CUCM version 8.6 running on vmware platform. There may be other version which may also be affected.  
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Contact Cisco TAC for the workaround of this issue.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue15816</guid>
</item>
<item>
<title>ServM cores due to memory corruption,   CSCud58000</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud58000</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
servM core generated due to memory corruption. This can cause intermittent high CPU/VM usage.

====================================
 backtrace
===================================
#0  0x00291418 in main_arena () from /lib/libc.so.6
#1  0x08078498 in servMEvtHdlr::handleExecResponse (this=0x93b19a8, e=0xb2900540) at servMEvtHdlr.cc:3951
#2  0x0808329b in servMEvtHdlr::handleEvent (this=0x93b19a8, e=0xb2900540) at servMEvtHdlr.cc:524
#3  0x080c71ad in XEEvtDispatcher::run() ()
#4  0x080c12b6 in XEProcShell::run() ()
#5  0x080855ea in main (argc=&lt;value optimized out&gt;, argv=&lt;value optimized out&gt;) at servMMain.cc:117

OR

  ====================================
 backtrace
 ===================================
 #0  0x00307b10 in main_arena () from /lib/tls/libc.so.6
#1  0x080879a6 in servMEvtHdlr::handleExecResponse (this=0x9737d28, e=0xa6e3ba0) at servMEvtHdlr.cc:3951
#2  0x0807c6fe in servMEvtHdlr::handleEvent (this=0x9737d28, e=0xa6e3ba0) at servMEvtHdlr.cc:524
#3  0x080cced6 in XEEvtDispatcher::run ()
#4  0x080c5dc2 in XEProcShell::run ()
#5  0x08088443 in main (argc=1, argv=0xbffdc074) at servMMain.cc:117

OR

  ====================================
 backtrace
 ===================================
 #0  0xb2b002e0 in ?? ()
#1  0x080879a6 in servMEvtHdlr::handleExecResponse (this=0x9374d28, e=0x952ca80) at servMEvtHdlr.cc:3951
#2  0x0807c6fe in servMEvtHdlr::handleEvent (this=0x9374d28, e=0x952ca80) at servMEvtHdlr.cc:524
#3  0x080cced6 in XEEvtDispatcher::run ()
#4  0x080c5dc2 in XEProcShell::run ()
#5  0x08088443 in main (argc=1, argv=0xbfec3ec4) at servMMain.cc:117
&lt;br&gt;


&lt;B&gt;Conditions:&lt;/B&gt;
Seen on the following versions of Unity Connection,
    CUC 9.0.1ES18.11010-18
    CUC 8.5(1)ES92
    CUC 9.1.1.10000-32
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

The root cause of the issue is found to be the same as that of CSCug53756. Upgrade to the version which has the fix for CSCug53756 or contact TAC for a temporary workaround.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud58000</guid>
</item>
<item>
<title>ESXi needs coredump partition configured by default in BE6K, Open CSCug37572</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug37572</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Crash of ESXi operating system does not save coredump information when ESXi crashes on Business Edition (BE) Unified Communications Manager (UCM) running on Unified Computing Servers (UCS).
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
ESXi crash on BE servers on UCS without a manually configured coredump partition within the ESXi OS.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Manually configure coredump partition on the ESXi per the following document: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&amp;docType=kc&amp;docTypeID=DT_KB_1_1&amp;externalId=1000328

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug37572</guid>
</item>
<item>
<title>TFTP Certificate Mismatch btw DB and file system after DRS restore, Fixed CSCtz83937</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtz83937</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
ITL file verification fails (verify by CLI - show itl). TFTP cannot upload ITL file to phone. 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
During MCS to UCS or cluster to cluster migration, if DRS backup was executed cluster wide but restore is executed node wise instead of cluster wide, this issue is likely to occur 
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Executed CLI - &quot;show itl&quot;   ITL file should get verified successfully. Signer certificate&#39;s serial number should match with the Certificate in ITL file having SAST role (System Administrator Security Token). 
If found improper, stop &quot;Cisco Certificate Change Notification service&quot; in all the nodes.
Delete affected node&#39;s CallManager certificate from other node&#39;s CallManager-trust.
Regenerate CallManager certificate in affected node.
Start &quot;Cisco Certificate Change Notification service&quot; in all the nodes (First PUB and then SUBs - Must). Check certificates are replicated properly.
Execute CLI - &quot;show itl&quot; to verify ITL file again.
If CallManager certificate is regenerated and if cluster is in secure/mixed mode, CTL Provider needs to be run to issue certificates to phones.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtz83937</guid>
</item>
<item>
<title>implement proper restart of vm from viclientcpi-, Fixed CSCtn75005</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtn75005</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
when running cucm in a virtual machine, if you choose to restart the virtual machine from the vi Client, the cucm application will not shut down properly and the informix database could become corrupted.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
restarting cucm through the vi client
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
do not restart the virtual machine using the vi client, instead, use the OS admin GUI, or using the CLI command &quot;utils system restart&quot;


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtn75005</guid>
</item>
<item>
<title>Unable to install VMWare Tools on CUCM in FIPS mode, Fixed CSCue38229</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue38229</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
VMWare Tools installation on CUCM will fail with the error &quot;VWWare Tools is installed, but it has not been (correctly) configured for this running kernel.&quot;
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
FIPS mode is enabled.
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
Disable FIPS mode and perform the installation again.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue38229</guid>
</item>
<item>
<title>Disable the embedded ICH9R software raid based BIOS on 7825H4, Fixed CSCta43492</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta43492</link>
<description>Issue:

New Deployment
Customer is installing CallManager 7.1.2 Appliance on a new MCS-7825-H4 server. The install proceds correctly however the next time the server boots it displays the following messages:
Controller #00: ICH9R SATA RID
No logical drives found
No int 13 drives to support
BIOS not installed


Explanation:
These are normal messages during POST. 
The 7825H4 has a hardware raid controller (E200), and it is not using the embedded motherboard ICH9R software raid based BIOS controller.  Since the drives are not connected to that controller, those messages are printed out during the systems POST.
This should not be affecting install or system function in any way.  Later in the POST process, the E200 is initialized and will detect the drives and the array.


What is Required:
These messages are misleading and will prompt the customer to open TAC cases. What is needed is that during the CM Install the Embedded RAID should be disabled if they are not going to be used.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta43492</guid>
</item>
<item>
<title>catalina.out file gets too big when there is problem to start tomcat, Fixed CSCso50705</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCso50705</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;
Cisco Tomcat service log catalina.out file grows very large in size and stops to get rotated. The file could 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Under certain error conditions such as Database problems or Certificate problems Tomcat services or applications running within Tomcat we could be logging excessive amount of data in the catalina.out log file. This excessive logging error condition interferes with the log file management system and interrupts file rotation.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None to restore the log file rotation or clean up the excessive catalina.out file manually. Contact TAC who can assist further.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCso50705</guid>
</item>
<item>
<title>7835/45 I3 after update to uEFI 1.07 won&#39;t boot to to new uEFI version, Terminated CSCtq84756</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtq84756</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
MCS 7835/45-I3 server is stuck during boot.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
When a 7835/45-I3 server is rebooted after uEFI firmware has been upgraded from version 1.07 to version 1.08 or later, then server gets stuck at the boot. This happens due to a bug in uEFI firmware version 1.07 which prevents server from picking up the new firmware during system boot.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
When server is stuck during boot, press &quot;F3&quot; to force server to pickup the new firmware update. Alternatively, a complete AC power cycle maybe required. Once server has been forced to pickup the new firmware, then problem will not repeate.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtq84756</guid>
</item>
<item>
<title>7.1(2b)su1 upgrade rules to prevent install over ineligible ES&#39;s, Fixed CSCtb50376</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb50376</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Upgrades from CUCM 7.1(2b)su1, also known as 7.1.2.31900-x, don&#39;t display any es&#39;s less than or equal to 7.1.2.310xx-x as valid upgrades.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Only applicable for customers running CUCM 7.1(2b)su1, also known as 7.1.2.31900-x. The upgrade rules included with this fix prevent customers from installing an Engineering Special that does not contain all of the fixes in 7.1(2b)su1.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Upgrade to an es in the 7.1.2.32xxx-x range or higher


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb50376</guid>
</item>
<item>
<title>Raid Rebuild on 7825-Hx Servers Should Recognize &quot;Ready&quot; state of HD, Fixed CSCsx58834</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx58834</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Drive Mirror is Not Occuring on MCS-7825-Hx servers
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

The spare drive plugged in the servers is in &quot;Ready&quot; state, instead of &quot;hot spare&quot;
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

During Initail Bootup, the drive should be set as &quot;hot spare&quot; during bootup in Array Configuration Utility.
Or
Call TAC to set the state of the drive correctly so mirror process can start.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx58834</guid>
</item>
   
</channel>
</rss>
