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 Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
CS1000M SG/CP PIV Rls 6.0 Stuck in split mode. 5
- Thread starter jake82nd
- Start date
-
1
- #2
You are probably going to have to get a maintenance window and sysload both sides. You could try the CUTOVR command to put call processing on the current inactive core but that will cause an INI, and then sysload the core that is active now and then try and join them. But more than likely just sysload both and hopefully it will come up fine. Make sure you have a current back up.
- Thread starter
- #3
- Thread starter
- #5
We are on release 7.5 and CUTOVR command worked so I wonder if there is an issue with 6.0?
Anyway, yes, I was trying to JOIN also as my cores were in split mode (from network work).
Did you unplug the HSP (High Speed Pipe)? My vendor told me to do that and INI the inactive side. I had to be patient and plug the HSP back in and I could then issue a JOIN and saw things go into redundant syncing mode.
The only remaining issue I had is that recent changes such as building phones and moves that occured while the system was in split mode (about two months) the changes no longer existed so I was probably missing a step - not sure what that would be? I ended up just rebuilding the phones and fixing the moves that took about 45 minutes total.
Anyway, yes, I was trying to JOIN also as my cores were in split mode (from network work).
Did you unplug the HSP (High Speed Pipe)? My vendor told me to do that and INI the inactive side. I had to be patient and plug the HSP back in and I could then issue a JOIN and saw things go into redundant syncing mode.
The only remaining issue I had is that recent changes such as building phones and moves that occured while the system was in split mode (about two months) the changes no longer existed so I was probably missing a step - not sure what that would be? I ended up just rebuilding the phones and fixing the moves that took about 45 minutes total.
- Thread starter
- #8
try the split command first, i have ran into an issue where if you STAT CPU in LD135, it shows SYCNING, we had to split before it would JOIN again.
__________________________________________________________
Find a job you love and you'll never work a day in your life. - Confucius
__________________________________________________________
Find a job you love and you'll never work a day in your life. - Confucius
- Thread starter
- #10
-
1
- #11
you might have to log into the INACTIVE cpu and see what is happening on it, it might complaining about the FMD or something... check to see if it has the patches in LD 143 MDP issp, if it's split, check it's health in ld 135 and FMD in 137 (Stat FMD)
might be the HSP cable as Tman suggested also (is it the official one form AVAYA or NORTEL?).
__________________________________________________________
Find a job you love and you'll never work a day in your life. - Confucius
might be the HSP cable as Tman suggested also (is it the official one form AVAYA or NORTEL?).
__________________________________________________________
Find a job you love and you'll never work a day in your life. - Confucius
-
1
- #12
Correct that is what our vendor told me (unplug the HSP; INI inactive). Good thing I took good notes. He did not mention doing a CUTOVR but since the system came back and said that I did it anyway (probably didn't have to).
I plugged it in about 1 minute after I performed the INI on the inactive side. Once things rebooted I was able to issue a JOIN command successfully. Don't we just love HA systems
Like I said I still had the database issue so if you had a lot of recent changes you might have some issues. It could be that the CUTOVR command does something weird. I still don't have an answer about that. Our vendor is too busy with Hurricane Sandy to address my questions.
I plugged it in about 1 minute after I performed the INI on the inactive side. Once things rebooted I was able to issue a JOIN command successfully. Don't we just love HA systems
Like I said I still had the database issue so if you had a lot of recent changes you might have some issues. It could be that the CUTOVR command does something weird. I still don't have an answer about that. Our vendor is too busy with Hurricane Sandy to address my questions.
- Thread starter
- #13
-
2
- #14
Firebird Scrambler
Systems Engineer
As you have release 6, read the following below.
Problem
Unable to join CPU.
Cannot Join, the redundant partition is not synced, try CUTOVER first.
SRPT046 LCS: Cannot Join, the redundant partition is not synced, try CUTOVER first.
0x8b85038 (tRptD): (30/7/05 14:23:42.836) SRPT045 LCS: Disk has not finished sync, set it to split.
switch
Solution
Remove 'inactive.dr', under '/e' drive, on both hard disks.
The file may only be shown on the active CPU
to remove (On Rel 6 anyway)
cd /e
del inactive.dr
The system will then allow you JOIN the system
All the best
Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK
If it's working, then leave it alone!.
Problem
Unable to join CPU.
Cannot Join, the redundant partition is not synced, try CUTOVER first.
SRPT046 LCS: Cannot Join, the redundant partition is not synced, try CUTOVER first.
0x8b85038 (tRptD): (30/7/05 14:23:42.836) SRPT045 LCS: Disk has not finished sync, set it to split.
switch
Solution
Remove 'inactive.dr', under '/e' drive, on both hard disks.
The file may only be shown on the active CPU
to remove (On Rel 6 anyway)
cd /e
del inactive.dr
The system will then allow you JOIN the system
All the best
Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK
If it's working, then leave it alone!.
* for you FBS. I have asked our vendor if this is why our 7.5 Rls would not join either. It used to be 5.5 so I am thinking that the file still exists so it still causes the issue. Would have saved me some headache with being on the inactive database.
When my system was at 6.0 it would irregularly just go into split mode during midnight routines, and I would also have to unplug the HSP and INI the inactive side before I would be able to get it to join. I finally found a patch, which fixed it from going into split mode; only applied to certain type of processors. Not able to locate the document that had the patch number, and other info, so can’t be of any better help.
- Thread starter
- #19
We got a maintenance window last night. We tried to unplug the hsp and ini. the inactive side, and tried reloading the inactive side to no avail. We then loaded the latest patches from merl and ini. both sides to no avail. We then reloaded both sides, that got us out of split mode but still could not join. At this point we ini. the inactive side and then we could join. Thanks to all for your input.
Firebirdscrambler didn't have the "Ba!!s" to try what you suggested. Thanks for the input!
Firebirdscrambler didn't have the "Ba!!s" to try what you suggested. Thanks for the input!
We had problems with 6.0 and early on with 7.5 HA with CPPM processors where if we SCPU the cores the inactive one would be stuck in SYNCING, and had a similar issue when I split the system for maintenance once. Finally captured the serial output as the newly inactive core rebooted and found in during the reboot there was an exception in task tDiskRed, which I deduced might mean "disk redundancy". INI of the inactive core would then not have the problem and fix the issue; sometimes it took more than one INI. I remember it took several deplist patching cycles to fix it.
- Status
Similar threads
- Locked
- Question