Loadable DLKM "module_attach()" function only called once

[kobylka]

Hi all!

I'm developing a PCI LAN driver for HP-UX 11i v1 on HP9000 in form of a "dynamically-configured DLKM" module. The installation of a "dynamically-configured DLKM" module can be summarized into the following steps:

1. Compile (make && cc)
2. Install (kminstall -a module_name)
3. Configure (config -M module_name)
4. Update (kmupdate -M module_name)

Steps 3. and 4. are often done in a single step:

config -M module_name -u

When a module update is requested (step 4.) the DLKM system loads the module, calls its LOAD function, calls its ATTACH function (if registered in LOAD function), and calls the UNLOAD function to unload the module.

After that, when loading the module using

kmadmin -L module_name

its ATTACH function won't be called anymore (despite of being registered in the LOAD function). After subsequent tests with other dynamically-configured DLKM modules it was found that this is the normal behaviour.

The module can be unloaded and loaded again as much as one likes, only its LOAD function will be called but its ATTACH function won't be called anymore.

Consequences of this are that a driver won't be able to use the devices it claimed (in ATTACH function during step 4.) nor the memory it reserved for this devices (must be freed in UNLOAD function during step 4.) rendering the whole "dynamically-configured DLKM" system useless for interface/monolithic drivers.

For statically-configured DLKM this is not an issue because the module is never unloaded.

Now the question...

Am I missing something?
Any compilation flag to solve this?
Any additional master/system file parameter required?


Thanks in advance,

Kobylka


Hardware:
Visualize C3700

% uname -mrs
HP-UX B.11.11 9000/785
%

[Don Morris_1]

When you say "registered in the LOAD function" -- do you mean that you're adding the attach function to the WSIO attach list and then doing a wsio_register_dev_probe() followed by wsio_activate_probe()?

[i.e. are you following the guidelines for WSIO interface Drivers at: http://docs.hp.com/en/dlkm-62001/ch01s03.html#chddgghj ]?

[kobylka]

Thanks for your reply.

With "registered in the LOAD function" I mean that the drivers attach function is attached to the WSIO PCI queue/chain (it's a PCI LAN card) using the specific interface for dynamically configured DLKMs
("HP-UX 11i v1 DDG - HP 9000 Computer Systems - Edition 5" Chapter 16. p.451):

"New support functions have been added to WSIO to allow interface drivers to add and remove their _attach() functions from the attach list. These functions are:

int mod_wsio_attach_list_add(list_type, &attach_func);

int mod_wsio_attach_list_remove(list_type, &attach_func);

The list_type specifies the attach list to use; valid entries are MOD_WSIO_CORE, MOD_WSIO_PCI, and MOD_WSIO_EISA. Both functions return 0 on success and 1 on failure."

The first is called in the LOAD function, the second in the UNLOAD function. Thus the driver_attach() function should be called every time the module loads, not only once during kmupdate (step 4.).

For now I'm not using a device probe routine.

Kind regards,

Kobylka

[Don Morris_1]

Ok... well, from the doc I cited - that's your problem then:

--begin quote---

Device probes are normally associated with interface drivers during the initialization of the WSIO Context Dependent Input/Output (CDIO) at boot time. Since this is only done once, loadable interface drivers must explicitly connect the device probe to the driver's drv_info structure:

void wsio_activate_probe(char *probe_name, struct drv_info *drv_infop);

probe_name is the name of the probe as registered by wsio_register_dev_probe() or wsio_register_probe_func(). drv_infop is a pointer to the drv_info structure for this driver. In general, use a probe provided by the system. For example, parallel_scsi_probe or side_probe. See the HP-UX Driver Development Guide for complete information.

--end quote---

and in the same code:

--- begin quote---
/* The following step is only required for dynamically
* loaded modules: attach the probe function to the
* drv_info structure */
wsio_activate_probe("probe_name", wsio_info.drv_info);

--- end quote ---

You certainly need to do what you're doing, but that's the minimum for static and dynamic drivers. Dynamic drivers such as yours need the extra step of the probe functionality, from what I can tell.

[kobylka]

I followed your advice and added a probe function to my driver, but didn't work. The same behaviour as with the PCI attach function occurs here with the probe function, that is, the probe function is only called once when updating the module (kmupdate) as part of the module installation.

To clarify the problem I modified the example dlclass.c DLKM (dynamically configured) module to print debug info. The following output corresponds to the kmupdate step:

Only with PCI attach function
----------------------------------------

dlclass> Loading
dlclass> Attached PCI function!
dlclass> Attaching <-- PCI attach function
Found device!
10/1/6/0 dlclass <-- Claimed device
dlclass> Unloading
dlclass> Deattached PCI function!

After that, trying to load the module results in:

[243] kmadmin -L dlclass
kmadmin: Module dlclass loaded, ID = 8
[244]

dlclass> Loading
dlclass> Attached PCI function!

No PCI attach function is called (no matter how often it gets loaded/unloaded).

Adding a probe function follows the same behaviour. During module installation (kmupdate step):

With PCI attach and Probe functions
--------------------------------------------------

dlclass> Loading
dlclass> Attached PCI function!
dlclass> Registered probe function!
dlclass> Attaching <-- PCI attach function
Found device!
10/1/6/0 dlclass <-- Claimed device
dlclass> Probing <-- Probe function
dlclass> PROBE_FIRST
dlclass> Unloading
dlclass> Unregistered probe function!
dlclass> Deattached PCI function!

After that, trying to load the module results in:

[245] kmadmin -L dlclass
kmadmin: Module dlclass loaded, ID = 8
[246]

dlclass> Loading
dlclass> Attached PCI function!
dlclass> Registered probe function!

No PCI attach and no Probe functions are called.


Kind regards,

Kobylka

[Don Morris_1]

Ok... I see a "Registered Probe function" there, did you not issue a printf for when you call wsio_activate_probe() as well [I would have had a "Activating Probe function"] or are you not calling to activate?

[kobylka]

The probe function is registered AND activated. This is a requirement for dynamic DLKMs (as you cited in your previous post).

I didn't add a printf for this to keep it simple and because this routine does NOT return a value.


Here's the load function:

static int dlclass_load(void *arg)
{

...

/* Register with WSIO */
if (!wsio_install_driver(&dlclass_wsio_info))
{
...
}

...

/* Attach to PCI chain */
status = mod_wsio_attach_list_add(MOD_WSIO_PCI, &dlclass_attach);

...

/* Register Probe function */
status = wsio_register_dev_probe(DRV_NAME, dlclass_probe, "dlclass");

...

/* Activate Probe function */
wsio_activate_probe("dlclass", dlclass_wsio_info.drv_info);

return 0;

} /* End of LOAD */

[Don Morris_1]

Ok... since I only know what you tell me, I have to be paranoid and ask these things.

Just to eliminate another possibility -- what do you get if you:

printf("Drv class: %s\n", dlclass_wsio_info.drv_info->name);

status = wsio_register_dev_probe(DRV_NAME, dlclass_probe, dlclass_wsio_info.drv_info->name);

printf("Register status: %d.\n", status);

wsio_activate_probe(dlclass_wsio_info.drv_info->name, dlclass_wsio_info.drv_info);

?

I just want to be sure that WSIO and you agree on the name field of the drv_info structure since that's what the probe is supposed to match.

[kobylka]

No prob, ask as much as you like, I will try to answer as best as I can. With your code the result is the same (during kmupdate step in module installation):


dlclass> Loading
dlclass> Attached PCI function!
Drv class: dlclass
Register status: 0.
dlclass> Attaching
Found device!
10/1/6/0 dlclass
dlclass> Probing
dlclass> PROBE_FIRST
dlclass> Unloading
dlclass> Unregistered probe function!
dlclass> Deattached PCI function!


Attach and probe functions are called correctly. When loading again:

[221] % kmadmin -L dlclass
kmadmin: Module dlclass loaded, ID = 8
[222] %

dlclass> Loading
dlclass> Attached PCI function!
Drv class: dlclass
Register status: 0.


No attach, no probe. The driver is coded following strictly the DDG and DDR to not incur in such subtle errors. If there would have been an error setting up the names in

wsio_register_dev_probe()

and/or

wsio_activate_probe()

the probe function would not have been called (no match would have been found).

Full code for the modified dlclass driver is attached so you can see exactly what is going on.

I think the main question here is why the PCI attach function is only called once during module installation. This way you can claim your devices and initialize needed memory, yes, but it will all get lost because an immediate unload follows (as part of the module installation too, so no way to control it). The side effect is that there will be claimed devices but no way to access them (pci attach function won't be called anymore).

This doesn't make any sense EXCEPT that the dynamic-configured flavour of DLKMs are only suitable for non interface/monolithic drivers, just for pseudo or normal device drivers, those that do not touch real hardware.

I really appreciate your effort and interest, Don Morris. Thank you ;)