I submitted patches to Dave in response to brokenness of module (not driver) loading in 2.16.15, and the patched behavior was evident in 2.16.16. I.e., my patches were thus not the source of the problems you had, but were apparently a response to the same problem(s) you had and just might not have completely resolved them. That's pretty much consistent with what I first wrote about this issue last night, i.e., that I tried to fix it but don't know if I did it completely or not.
But you say "in 2.16.15 forward, if the module is not found, it is never loaded." That's not my recollection at all. What I found was that in 2.16.15, if a module was not at first found to be loaded, it might actually get loaded, but the attempt would return failure state/status, thus falsely indicating that it didn't load. But since 2.16.16, my tests have shown that module loading works OK, as far as my tests go (I_PUSH/I_FIND). I just tested with 2.16.18, and I_PUSH/I_FIND still work OK for me.
As I recall, the person who reported the problem with 2.16.15 was satisfied with the patched behavior of 2.16.16 as well.
-John
Brian F. G. Bidulock wrote:
John,
Well, whoever made changes between 2.16.14 and 2.16.15 broke module ("module" as opposed to "driver") demand loading altogether. Which is where I started having problems.
In 2.16.14 if lis_findmod could not find a module by name and KMOD is configured, it would attempt to load module "streams-%s".
In 2.16.15 forward, if the module is not found, it is never loaded.
I'm patching back to the 2.16.14 lis_findmod. I'll send a patch in a little while.
--brian
On Sun, 15 Feb 2004, John A. Boyd Jr. wrote:
Let me restate in the form of a suggestion - instead of clearing the name, you might want to look at how to get the state change to work, so as to prevent this problem. The author apparently intended clearing the _INITED state flag to have somewhat the effect as your clearing of the name...
-John
Brian F. G. Bidulock wrote:
There is a module loading bug in head/mod.c When a module is unregistered the f_name component is left alloing lis_findmod to find it an lis_loadmod will attempt to lock a destroyed semaphore. The problem can be recreated by manually loading a streams kernel module (modprobe), unloading it (rmmod) and then demand loading it (e.g. I_PUSH). The result is a kernel oops.
The patch below fixes the problem (but may break other things).
--brian
Index: head/mod.c =================================================================== RCS file: /home/common/cvsroot/LiSnew/head/mod.c,v retrieving revision 1.1.1.4 diff -U3 -r1.1.1.4 mod.c --- head/mod.c 22 Nov 2003 23:01:43 -0000 1.1.1.4 +++ head/mod.c 15 Feb 2004 18:05:31 -0000 @@ -742,6 +742,7 @@ lis_up(&slot->f_sem) ; lis_sem_destroy(&slot->f_sem) ; slot->f_state &= ~LIS_MODSTATE_INITED ; + slot->f_name[0] = '\0';
printk("STREAMS module \"%s\" unregistered, id %d\n", name, id);
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
