How to disable ct_query messages?

[Michael Denney]

I keep getting the following messages in dmesg:

vmunix: ct_query failed. hw_path = 4/1/0
vmunix: ct_query failed. hw_path = 6/2/0

Here is ioscan -fnH #/#/# of those paths:

fc 4 4/1/0 td CLAIMED INTERFACE HP Tachyon TL/TS Fibre Channel Mass Storage Adapter
/dev/td4

fc 3 6/2/0 td CLAIMED INTERFACE HP Tachyon TL/TS Fibre Channel Mass Storage Adapter
/dev/td3

These 2 hba are plugged into a fiber switch, however nothing in the switch is zoned to the WWN of these hba. In another words, the HBA's are plugged into the swtich, but nothing is visible to the hba. Thus the ioscan showing no usable devices past the hba.

How can I disable the kernel(or something?) from creating these messages?

Thanks for all your help!

[Jeff Schussele]

Michael,

With no disk devices zoned to the HBAs you'll get these whenever:

1) The system is booted
2) An ioscan command scans these HBAs
3) Whenever an fcmsutil command interrogates the HBA(s)

They are *not* indicative of a problem & I don't think you can disable them. You needn't worry about them - they are merely informational.
Here's a TKB doc on this - UMASSKBRC00011649

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000072497483

Rgds,
Jeff

[Michael Denney]

Jeff,

I knew it wasn't a real problem, rather just informative. The thing is we record all the new dmesg on each server, then email the dmesg results to a special email account the on call admin has to review for potential problems.

Since these cards are not a problem, we want to disable the messages until we actually start to use the cards. I'm thinking creating an init.d script to disable these 2 cards after start up..ie "fcmsutil /dev/td4 disable".

As long as all the admins know to enable the cards when ready to use.

thanks for reply Jeff!

[Jeff Schussele]

Oh & I should add that you *might* be able to get rid of the messages by either:

1) Zone the HBAs at the swithch - just don't zone any LUNs from the array to those WWNs.
2) Unplug the fibres.

HTH,
Jeff

[Jeff Schussele · Accepted solution]

Understood.
I might question your using dmesg to "capture" events. It's a relatively small circular buffer & depending on the frequency of that capture you could get a "big" event and actually miss the beginning of it.
I'd probably favor a cron job that manipulates the syslog file & diffs/greps it as the source for that e-mail. diff will get the new events since the last scan & grep can weed out the unimportant stuff.

My 2 cents,
Jeff

BTW - is this the Michael that used to work in KC?

[Michael Denney]

Hi Jeff,

You pointed me in the right direction. I was leary about doing a zone set in the san switch because there is production on that switch also. However, I found some fiber "loop back" plugs. So, i unplugged the fiber from the hba and plugged in the "loop back" device. This caused the link light to come on and now ioscan shows a FCP device under the hba. Viola, no more ct_query messages during an ioscan.

Yes, I use to work with you in Lee's Summit. Good to hear from you, thanks for the help! Give my regards to Dawn and Sridhar.

Regards,
Michael

[OSY Unix 1-4-2 (A-Team)]

Hi,

same thing here, but no cables were connetcted to the HBAs. Seems to be a driver problem. We are also getting messages like "1/0/8/1/0/4/0: Fibre channel host port is OFFLINE, can not scan". A new driver version should fix the problem (e.g. FibrChanl-00 B.11.11.12).

Regards

CR

[Florian Heigl (new acc)]

You could also look if You can set the adapters offline in hpfcmsconf - I don't know for sure, if this will catch them before the message is generated.

The loop plug or a zoning to nirvana is the better solution, I think, as it will keep You from getting additional messages in EMS logs.