[cisco-voip] OS 2000.4.2 sr7 upgrade

[Ortiz, Carlos]

All of my servers are dual processor 7835's and 7845's.  I guess I will
be upgrading to 7a ASAP....

-----Original Message-----
From: Justin Steinberg [mailto:jsteinberg at gmail.com] 
Sent: Thursday, June 22, 2006 1:47 PM
To: Ortiz, Carlos; cisco-voip at puck.nether.net; Simon, Bill
Subject: Re: [cisco-voip] OS 2000.4.2 sr7 upgrade

The information in the bug id states that no problems have been
observed with uniprocessor servers.

So does this mean that even the QA lab doesn't get new hardware? :)

justin




On 6/22/06, Ryan Ratliff <rratliff at cisco.com> wrote:
> Lucky?  Check out the bug details to see the registry change that
> caused the problem.  You can then check your server.
>
> -Ryan
>
> On Jun 22, 2006, at 1:34 PM, Ortiz, Carlos wrote:
>
> That's weird.  I upgraded to this about 3 weeks ago and I have no
issue.
> Why would that be???
>
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Ratliff
> Sent: Thursday, June 22, 2006 1:04 PM
> To: Simon, Bill
> Cc: 'cisco-voip at puck.nether.net'
> Subject: Re: [cisco-voip] OS 2000.4.2 sr7 upgrade
>
> This is a known bug and SR7 should no longer be on CCO because of it.
>
> CSCse47327 is the bug.
>
> Please unicast me the SR number and I'll check it out.
>
> -Ryan
>
> On Jun 22, 2006, at 12:59 PM, Simon, Bill wrote:
>
> Yesterday I attempted an upgrade on our cluster from 2000.2.7sr4 to
> 2000.4.2
> then applied sr7.
>
> CallManager version is 4.1(2)sr1.  Cluster hardware all around is HP
> DL-380
> G3 (like MCS-7835 or 7845)
>
> The short story is that after the upgrade and a few hours of
frustrating
> poor or non-existent phone service, we bailed out to a set of mirrors
> taken
> the day before.  The main symptom of a sick CM cluster was that on the
> subscribers where phones registered, CPU loads upon boot went to 100%
> and
> stayed there.  CCM.EXE was the process using most of the CPU.  The
> high load
> caused failed registrations, incredibly slow response times on
> phones, VM
> and gateway ports registering and then going unregistered, and other
> weirdness.
>
> After an hour and a half talking to TAC on a P1 case we were unable
> to wait
> any longer and had to bail out.
>
> The case is still open and we're hoping to get to the bottom of it
> but I'm
> putting this out there in case any of you have seen something like
this,
> have feedback/thoughts, etc.
>
> ---
> Bill Simon - bills at tns.its.psu.edu - (814) 865-2270
> http://tns.its.psu.edu/
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>