kernel parameter gvid_no_claim_dev on Itanium says dynamic

[Larry Reinhart]

Ok, I'm confused. The kernel parameter gvid_no_claim_dev on some of our Itanium servers says its dynamic but on others it says not dynamic. The servers are RX3600s running HP-UX 11.23.

The command used to gather the data was:
/usr/sbin/kctune -P name,current,dynamic,next_boot

The HP documentation on it says it is not dynamic.
"Restrictions on Changing
Changes to this tunable take effect at the next reboot."

So, a couple of questions.
1. How could this be with some saying dynamic and some saying not dynamic?
2. How do I put the parameter back to saying it is not dynamic?


Thanks and best regards,
Larry

[Don Morris_1 · Accepted solution]

Just off the top of my head -- what does `kctune -v gvid_no_claim_dev` show on the systems which claim it is dynamic? Any chance it shows this as a User Defined Tunable -- and if so, is the gvid module in the system file for the current configuration?

I'm having a hard time persuading my test box to let me set a User Defined tunable via stale entries in the system file at the moment -- but I thought that if you have a system file entry for a tunable and no kernel module actually defines that tunable it is interpreted as a User Defined tunable instead, and a User Defined Tunable would be dynamic in nature. With the gvid module being optional and being required for this tunable to be recognized as a kernel parameter, it does seem like a possible scenario.

Which would possibly answer (1). For (2), if I'm right it would be to persuade gvid to load anyway... but frankly, I wouldnt' force it. If gvid doesn't load, you certainly don't need it to claim anything -- so the tunable is irrelevant.

[Larry Reinhart]

Hi Don,
Here are the results of the command you asked for. The first is on an Itanium that says its not dynamic. The second is on a host that says its dynamic.

# kctune -v gvid_no_claim_dev
Tunable gvid_no_claim_dev
Description PCI Vendor/Device ID that gvid driver should not claim
Module gvid_core
Current Value 0 [Default]
Value at Next Boot 0 [Default]
Value at Last Boot 0
Default Value 0
Constraints gvid_no_claim_dev >= 0
gvid_no_claim_dev <= 4294967295
Can Change At Next Boot Only


# kctune -v gvid_no_claim_dev
Tunable gvid_no_claim_dev
Description PCI Vendor/Device ID that gvid driver should not claim
Module gvid_core
Current Value 0 [Default]
Value at Next Boot 0 [Default]
Default Value 0
Constraints gvid_no_claim_dev >= 0
gvid_no_claim_dev <= 4294967295


Note that the only difference is the Can Change line.

This is not a high priority. It just puzzles me in the inconsistency. The boxes should have been built identically. I'll check more into the hardware to see if there are differences.

[Don Morris_1]

What's `kcmodule -v gvid_core` give for those two?

[Larry Reinhart]

For the host that says non-dynamic:
# kcmodule -v gvid_core
Module gvid_core [4B0315E2]
Description GAIA Core Graphics Driver
State static (best state)
State at Next Boot static (best state)
Capable static unused
Depends On module gvid:0.0.0
module libgraf:0.0.0
interface HPUX_11_23:1.0

For the host that says dynamic:
# kcmodule -v gvid_core
Module gvid_core [4B0B7C1A]
Description GAIA Core Graphics Driver
State unused
State at Next Boot unused
Capable static unused
Depends On module gvid:0.0.0
module libgraf:0.0.0
interface HPUX_11_23:1.0

[Larry Reinhart]

Another piece of information:
On the host that says not dynamic:
# ioscan -kfn | grep -i vid
graphics 0 0/0/3/0 gvid_core CLAIMED INTERFACE PCI Display (1002515e)

On the host that says dynamic:
# ioscan -kfn | grep -i vid
Nothing is returned.

Hmmm... It does not look like these boxes are built identically. This may be why there is a difference in dynamic-tiscity.

[Don Morris_1]

Yeah, that fits then -- the gvid module is unused on the one box. And I found a reference CR (QXCR1000894472) that had this behavior for a tunable affiliated with a Dynamically Loadable Kernel Module. From kctune's point of view -- until the owning module is loaded, the tunable is defined but is relatively meaningless, and can be set to whatever you want. When and if the module is loaded, then the tunable restrictions are enforced.

In this case, gvid is not a dynamic module - but since it isn't loaded (because it isn't needed) the same principle applies. If it ever were loaded, the tunable would revert to requiring a reboot to modify.

[Larry Reinhart]

Cool. That makes sense. Thanks Don for all the help!
I'm closing this thread.

[Larry Reinhart]

See Don's explanation for the solution. :)