Thread fault signal invokation

[Guest_imported]

Recently our main file and print server has started posting the following type of message on the main console screen :

Thread fault signal invokation: Server xx

'xx' is a number from 01 to under 50, but is never higher then 50.

This is a multi processor system, and within monitor's 'Multiprocessor options / Thread information' area there are a number of these Server xx processes listed, all in a 'Migrating' state. As this is the only multi-processor system we have I can't compare this to see if this is normal or problematic. Normally the above error messages come in lots of two or three, e.g :

Thread fault signal invokation: Server 22

Thread fault signal invokation: Server 27

The only reference to a thread fault invokation in a TID on the Novell web page was referring to a service which wouldn't (and shouldn't) be running on our server, and was referring to a thread fault invokatoin number far higher then the one we are receiving.

Our system is running (to the best of my knowledge)
- Novell 4.11 (SP8)
- Netware Print Server 5.0
- Arcserve 6.1 (schedular, tape server, etc)
- PCounter

The server seems to be running fine regardless of these messages though, and has not abnormally ended or thrown in the towel for any strange reason.

Any help on a reason, description or solution to this would be greatly appreciated

----------------------------------------------------------
'Microsoft - which patches do I have to install today ?'

 

[TheLad]

You have to bear in mind that multi-processing does not work effectively in NetWare 4.x. You might as well remove the second processor (or disable it) for the good that it does. SMP works correctly from NetWare 5.x.

Anyway, check out the following TID from Novell. There is a section on Thread fault signal invokation:

http://support.novell.com/cgi-bin/search/searchtid.cgi?/10052541.htm

-----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------

 

[Guest_imported]

Thanks for the responce
I've read through that TID a while back (before we switched on the second processor) but was hoping there might be a more definate cause which I was missing.

As it hasn't had any outward effect on the system other then the posting of those messages I think I'll just monitor it and see what happens rather then playing around with it.

The anoying part of it is that there are no time stamps with the messages, so we have no idea when they are being detected / displayed. That would at least be able to give us an idea on what operations are running or being initiated at the time.

Cheers anyway.

 

[sobak]

You could enable SNMP on the server then forward all SNMP traps to a syslog daemon. This would at least give you a time stamp since the Syslog Daemon stamps when it received the message. Don't know how indepth you want to go on this but I use this proceedure to monitor my servers for errors. So far it works pretty good for my network.

david e
*end users are just like computers, some you can work with...others just need a simple reBOOTing to fix their problems.*