dmesg diaglogd error.

[someone_4]

Hello,

Would anyone have any info on this error? I see it in dmesg and syslog.log


DIAGNOSTIC SYSTEM WARNING:
The diagnostic logging facility has started receiving excessive
errors from the I/O subsystem. I/O error entries will be lost
until the cause of the excessive I/O logging is corrected.
If the diaglogd daemon is not active, use the Daemon Startup command
in stm to start it.
If the diaglogd daemon is active, use the logtool utility in stm
to determine which I/O subsystem is logging excessive errors.

[Tim D Fulford · Accepted solution]

1 - Check using top if there are any run-away processes. Sometimes this is the case (diaglogd, diagmond, cclogd). If this is the case try restarting diagnostics.
# /sbin/init.d/diagnostic stop
# /sbin/init.d/diagnostic start

2 - If the above fails to resolve the problems you could have a disk / card failing... try using xstm (X version of stm) or mstm (menu version of stm) to look at all IO type of devices. also "ioscan -f" may be of some help.

Generally I have found one of the above does the trick. If not I'm sure other bright sparks will come forward with more info.

Tim

[James R. Ferguson]

Hi Richard:

My first guess is to see if you can relate the I/O errors to a tape backup session. As suggested, you may want to use 'stm' logtools to look for/at errors.

Regards!

...JRF...

[S.K. Chan]

Another possiblity for this error is that you got a mismatch between STM and some fiber channel (FC) drivers version. I can't remember the details but this has happened to me once and I got my STM upgraded to the latest version to make it happy. 2 things you need to check closely..
1) In syslog.log is this all the error you see ? Do you see some other message that ask for you to run "resdata" to get more information from the STM log ? If you don't then most likely this is due to the "mismatch" that I mentioned above.
2) Run stm and look at any possible IO errors. If you can't find any, again, possibility of the above is very likely.

[someone_4]

Hey everyone ..
I ran cstm to track it down and ioscan -fnC disk.
It ended up being a fiber card on my N class server that was conected via fiber to an XP-256. We tried a differnt fiber cable but that was not it. So we called HP ... they had someone on site replaced the card and we were ready to go. What was happening from this was that our informix engine was getting high checkpoints and timming out because it was trying to access the disk on the XP though the bad fiber card. Once the fiber card was replaced everything was good.

Thanks everyone,
~ richard