Cannot load module iscsi_initiator_mod under Fedora Core 5

[Albert Pauw]

Since my previous post was more than 30 days old and never answered it
was (I assume automatically) closed.

For Fedora 5 we are now at kernel 2.6.16-1.2111_FC5 and I am still not
able to startup core-iscsi.

Here's the modprobe of the module iscsi_initiator_mod:

[root@orange core-iscsi-v1.6.2.5]# modprobe -v iscsi_initiator_mod
insmod
/lib/modules/2.6.16-1.2111_FC5/kernel/drivers/scsi/iscsi_initiator_mod.ko
FATAL: Error inserting iscsi_initiator_mod
(/lib/modules/2.6.16-1.2111_FC5/kernel/drivers/scsi/iscsi_initiator_mod.ko):
Invalid argument

Here's the modinfo:

[root@orange core-iscsi-v1.6.2.5]# modinfo iscsi_initiator_mod
filename:
/lib/modules/2.6.16-1.2111_FC5/kernel/drivers/scsi/iscsi_initiator_mod.ko
description: PyX iSCSI Initiator Driver Core 1.x Release
license: GPL
vermagic: 2.6.16-1.2111_FC5 686 REGPARM 4KSTACKS gcc-4.1
depends: scsi_mod
srcversion: AB2B506F5B90655D65A2083
parm: iscsi_sg_tablesize:i
parm: iscsi_cmd_per_lun:i
parm: iscsi_can_queue:i

And here's the last bit of dmesg:

iscsi_initiator_mod: falsely claims to have parameter iscsi_can_queue

Since I can't start it up anymore (with FC3 and FC4 it worked fine) it
is useless for me as it is right now and I am stuck.

Any help appriciated.

Thanks,

Albert

[Nicholas A. Bellinger]

On Sat, 2006-05-13 at 09:21 -0700, Albert Pauw wrote:
> Since my previous post was more than 30 days old and never answered it
> was (I assume automatically) closed.
>
> For Fedora 5 we are now at kernel 2.6.16-1.2111_FC5 and I am still not
> able to startup core-iscsi.
>
> Here's the modprobe of the module iscsi_initiator_mod:
>
> [root@orange core-iscsi-v1.6.2.5]# modprobe -v iscsi_initiator_mod
> insmod
> /lib/modules/2.6.16-1.2111_FC5/kernel/drivers/scsi/iscsi_initiator_mod.ko
> FATAL: Error inserting iscsi_initiator_mod
> (/lib/modules/2.6.16-1.2111_FC5/kernel/drivers/scsi/iscsi_initiator_mod.ko):
> Invalid argument
>

Hrmm, IIRC we changed the module parameters in
iscsi_initiator_linux_scsi_defs.h to use module_param() macro instead of
the legacy MODULE_PARM() macro.

> Here's the modinfo:
>
> [root@orange core-iscsi-v1.6.2.5]# modinfo iscsi_initiator_mod
> filename:
> /lib/modules/2.6.16-1.2111_FC5/kernel/drivers/scsi/iscsi_initiator_mod.ko
> description: PyX iSCSI Initiator Driver Core 1.x Release
> license: GPL
> vermagic: 2.6.16-1.2111_FC5 686 REGPARM 4KSTACKS gcc-4.1
> depends: scsi_mod
> srcversion: AB2B506F5B90655D65A2083
> parm: iscsi_sg_tablesize:i
> parm: iscsi_cmd_per_lun:i
> parm: iscsi_can_queue:i
>

Is this the lastest FC development kernel? Mabye check kernel source
sources and see if something changed with regard to module_param() in
include/linux/moduleparam.h. Also, please feel free to CC this to the
FC kernel list, as mabye this could be related to a toolkit, modutils
breakage? Are other built kernel modules loading OK? Also on a side
note, have the 4KSTACKS been used in your previous builds?

Thanks!

--
Nicholas A. Bellinger <n...@kernel.org>

[Albert Pauw]

Here's the bit in the kernel source which matches the kernel version:

/* This is the fundamental function for registering boot/module
parameters. perm sets the visibility in driverfs: 000 means it's
not there, read bits mean it's readable, write bits mean it's
writable. */
#define __module_param_call(prefix, name, set, get, arg, perm)
\
static char __param_str_##name[] = prefix #name;
\
static struct kernel_param const __param_##name
\
__attribute_used__
\
__attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void
*)))) \
= { __param_str_##name, perm, set, get, arg }

#define module_param_call(name, set, get, arg, perm)
\
__module_param_call(MODULE_PARAM_PREFIX, name, set, get, arg,
perm)

/* Helper functions: type is byte, short, ushort, int, uint, long,
ulong, charp, bool or invbool, or XXX if you define param_get_XXX,
param_set_XXX and param_check_XXX. */
#define module_param_named(name, value, type, perm)
\
param_check_##type(name, &(value));
\
module_param_call(name, param_set_##type, param_get_##type,
&value, perm); \
__MODULE_PARM_TYPE(name, #type)

#define module_param(name, type, perm) \
module_param_named(name, name, type, perm)

> breakage? Are other built kernel modules loading OK? Also on a side
> note, have the 4KSTACKS been used in your previous builds?

open-iscsi works fine as far as module loading is concerned.
Forgive me my ignorance, but how do I change the 4KSTACKS?

Thanks,

Albert

P.S. Used the latest FC5 kernel as of now (2.6.16-1.2122_FC5).

[Brian]

Albert Pauw wrote:
>
> P.S. Used the latest FC5 kernel as of now (2.6.16-1.2122_FC5).

I'm seeing the same problem with kernel 2.6.16-1.2133_FC5smp.

My system also reports that iscsi_initiator_mod falsely claims to have
parameter iscsi_can_queue.

--b

[Albert Pauw]

Yep, same here, with all kernels following the one I mentioned.

It's a shame, as core-iscsi worked quite well before, hopefully
Nicholas will find some time to fix it.

Albert

[n...@kernel.org]

Hey guys..

Sorry about the misunderstanding on this. The module_param() change
(which originally fixed the problem) has been released as v1.6.2.6 in
the usual place. I believe include/linux/moduleparam.h is present in
>=v2.6.0 so no breakage breakage within our v2.6 userbase will appear.

On a releated note, as Mike Mazarick mentioned earlier, a reposititory
for bits like these would definately increase participation. For
v1.6.x branch that is currently stable, the longer release times tend
to cause less confusion as far as users are concerned, but for new v2.0
development purposes (and bugfixes too!) I think that core-iscsi really
needs the online repository. I imagine most devs are fimilar with
subversion so this would be my choice of SCM, but it may also make
sense to keep a git tree for other kernel development purposes.

Mike and Bryan , as far as the former is concered shall we go ahead and
get this setup? The normal subversion server and online HTTP access
would be ideal. I know that Bryan has been busy with Core-iSCSI/Boot
and other fun console hacking. Can someone get this setup in the next
few days and we grant access to long-term devs and testers?

Thanks again gentlemen!

--nab

[is...@digitaltadpole.com]

I think I'd like to do one better than that, but will need some help
setting it up. A repository is only a piece of what is needed.

What we should provide is a place to give individuals a means to check
out the latest kernels/distributions with all of the linux iscsi
products so they can verify their setup for any release or combination
that they pull out of the repository.

As an outline, I'd suggest using qemu or Xen (or both) to allow virtual
machines preloaded with several distributions to be used by folks on
the iscsi mailing lists (core-iscsi, iet, open-iscsi) so they could
verify the operation of their setup. They could build their own
virtual machine using their distribution and/or look at reference
implementations.

If we were also clever, we would include a automatic regression test
suite and an automated daily build for each of the software products.

http://www-128.ibm.com/developerworks/linux/library/l-dsf.html#N10052
http://ltp.sourceforge.net/

Supposedly, the product listed above provides a path for automated
testing in a kernel development framework. However, I've just heard
of it, and haven't worked/played with this at all.

This will all progress faster if others will step up to the plate and
help a little. Any volunteers? Please email off list if you are
interested and willing to put some time in to help or this will go at
the normal pace of most of my extra-curricular activities (very slow).

Currently we're trying to get virtual bridging, tun/tap, bonding, and
(hopefully) diskless iscsi boot all working together so we can set up
private virtual environments on "bare metal" - no disk - servers
(earlier kernels would give most functions, but not ALL to us). We've
got an initrd for diskless boot almost ready, and hopefully, Nic's
recent code update will take us all the way there.

Regards,

Mike Mazarick

[Albert Pauw]

I can confirm that it compiles, installs, and loads fine on FC5 latest
release.

Thanks.

I will test it tonight and let you know if I find any problems.

Albert

[Brian Vowell]

ditto. 

Just tested with kernel 2.6.16-1.2133_FC5smp, and everything went fine.


--b