Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Option81C sysload

Status
Not open for further replies.

ccmjgb

Vendor
Feb 1, 2011
317
US
Hi,

An Option81C 're-booted' and it resulted in a few remotes not coming back online. A few line cards (e.g. conf/ts ...) also failed to come back online and had to be manually reset. The maintenance provider pulled logs and they indicated that the system had a sysload event... it was explained that something triggered the switch to re-boot, but the triggering factor could not be determined. There was no power disruption or interuption so I'd like to find out the consensus on what may have caused a sysload and what steps can be taken to prevent this problem. Would software upgrades/patching/firmware be the 1st step?

Thank you for all your imput as it is very appreciated.

ccmjgb
 
if you can get your provider to give you a copy of the history report (unless the history file is too small) it would provide you with a starting point. If you have the information, most the of people here cand decipher what you have and will let you know where you can start to look.

>LD 22

req: prt
type: ahst


Hope this helps.

John Anaya
Signet6 Network Sciences
ACSS/ACIS - CS1000 Rls 7.5/Call Pilot 5
ACSS/ACIS - SME - IP Office 8.0
APSS/APDS - Avaya UC Services

Public Profile
 
Unfortunately the history is cleared on a sysload
 
the old history is cleared. but the sysload codes from the current sysload should be there. If not you would have to get into the rdtail and pull back the information. this information is not lost in a sysload.

John Anaya
Signet6 Network Sciences
ACSS/ACIS - CS1000 Rls 7.5/Call Pilot 5
ACSS/ACIS - SME - IP Office 8.0
APSS/APDS - Avaya UC Services

Public Profile
 
You might want to consider going into "pdt" and printing off the rdtail data. This file will record data before and after the sys load and is very useful when fault finding is required.

All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

If it's working, then leave it alone!.
 
Hi firebirdscrambler, just getting acquainted with the Option81... could you please outline the LD & commands to get to pdt and printing the detail you are referring to... Thank you!
 
If you are unfamiliar with the PBX then the last place you want to do into is PDT. This is the root of the OS, kinda like DOS but it's called Vxworks. If you don't know what you are doing in there you can reak havoc on your phone system. Suffice it to say that all the events leading up to the sysload will be gone, it gets wiped out on a sysload. There may be issues during the sysload that may point you in the right direction, but previous data will be gone.
 
Hi kcflhrc, thank you for the input... I definately do not want to destabilize the system - any log pulling from the PDT would be done with much care now that you mention the sensitive nature of the PDT... I have manuals, but it so much faster/efficient when the questions are posted and answered by expereinced people... some of the documentation is clear but actually getting responses from you guys really helps sort things out and buffers the un-certainty that comes with inexperience...

it seems your opinion is different that the 2 replies above, which point to the PDT and they mention that the logs are not lost due to a sysload... is this not the case?

thank you!

 
Going into "pdt" is like going into root on Linux. One wrong move can be very nasty!. The rdtail logs will record history of events before and after a serious problem, but not if it actually has no power to the CPU. Usually events prior to the problem would give some clues what happened.

All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

If it's working, then leave it alone!.
 
so the sysload left the Option with several cards disabled... the maintenance holder reset most cards manually with the expection of the CONF/T card on the shelf where processor 0 is located.... at first it appeared to be a bad CONF/T card so a replacement was brought in and this card could not be brought online either... so the recommendation was to INIT the processor 0 card to help clear the issues... it was also noticed that after the sysload took place, end-users began to report intermittent can't be heard issues.... the INIT was performed and this cleared the end-user reports so now back to the CONF/T enabling - any suggestions if the card doesn't come back up? thank you!

BTW... Firebirdscramber, the batteries seem to be in fair shape, there are a few terminals that have very minor build up and the rectifier shows no alarms (I'll be calling the rectifier MFR to see if any logs can be pulled from the control unit which would indicate power drops etc...)

Thank you again!
 
Have you tried to enable the conference and TDS? If so what message did it give you back?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top