kernel module load failure

[Bernardo Pastorelli]

I'm trying to load a WSIO kernel module soon after a machine reboot (I'm running HP-UX 11.11), but the load fails.
I execute the following steps:
1) install the module using kminstall, config and so on. The module is correctly installed: I can load it using kmadmin -L
2) reboot the machine
3) rlogin on to the machine as soon as the rlogin daemon is up and running
4) execute kmadmin -L to load the module
kmadmin fails with the message "No locks available". From a tusc trace of kmadmin -L it appears that the failing function is modload: it fails with errno 46 (ENOLCK). This errno is not documented in HP-UX documentation. Does anyone has an idea of the reasons of this failure? How can I avoid or workaround it?

BTW, if I re-execute the load command some time after the boot, it completes with success.

Regards,
Bernardo

[T G Manikandan]

It is crossing the nflock parameter in the kernel.

The default is 200.

Increase the parameter.


Thanks

[Bernardo Pastorelli]

If I change the module to a Misc type instead of WSIO, I don't have the problem. Why the behaviour is different? Is it possible to have a WSIO module behave like a Misc one?

Regards,
Bernardo

[Bill Hassell]

errno 46 is indeed documented:

from /usr/include/sys/errno.h:
#define ENOLCK 46 /* System record lock table was full */

from man 2 errno:
"[ENOLCK] System lock table is full. Too many files have file locks on them, or there are too many record locks on files, or there are too many instances of a reading or writing process sleeping until an enforcement mode lock clears. This error may also indicate system problems in handling a lock request on a remote NFS file. This error is also currently returned for all attempts to perform locking operations on a remote NFS file that has its locking enforcement mode bit set, since the stateless nature of NFS prevents maintaining the necessary lock information."

[Bill Hassell · Accepted solution]

The previous post was a cut-n-paste from my errno script (attached). It grabs the errno number or symbolic name and matches it to the errno man page. Saves a lot time in decoding an error number or symbolic name.