On 18/07/13 19:15, Nicholas A. Bellinger wrote:
Hi Benjamin,
Hi Nicholas,
On Wed, 2013-07-17 at 19:02 +0100, Benjamin ESTRABAUD wrote:
Hi,
I'm having a very strange issue after updating Linux to 3.9.10 or
3.10.1: Whenever I call rtslib's FabricModule "load" method on iSCSI or
loopback fabrics, when running the "_create_in_cfs_ine('any')" step, I
get the following exceptions:
[Errno 22] Invalid argument: '/sys/kernel/config/target/iscsi'
[Errno 22] Invalid argument: '/sys/kernel/config/target/loopback'
and the following kernel trace:
[ 1678.147454] request_module() failed for iscsi_target_mod.ko: -2
[ 1678.153769] request_module() failed for tcm_loop.ko: -2
Mmmm, I've not seen this one before..
All other fabric modules are loaded correctly:
# ls /sys/kernel/config/target/
core fc qla2xxx version
And when running the "load_module" step from the "load" method, all
modules including the iSCSI and loopback ones run successfully:
tcm_fc 12826 - - Live 0xc1f26000
tcm_loop 9849 - - Live 0xc1e3e000
tcm_qla2xxx 14904 - - Live 0xc1df6000
iscsi_target_mod 168077 - - Live 0xc1d6b000
target_core_mod 174585 - - Live 0xc1953000
fcoe 16888 - - Live 0xc1613000
libfcoe 44385 - - Live 0xc15ba000
libfc 91365 - - Live 0xc14f7000
So it looks like your using busybox userspace, right..?
We are indeed.
Looking at the error code it seems that "request_module" is given the
wrong module name or something (maybe they have a unique id in them too)
since "-2" should in theory correspond to "ENOENT". What I don't get is
that the module is already loaded. Is this function used to request
access to a running module?
After unloading all of the target related modules, what does the
following commands do..?
modprobe target_core_mod
mkdir -p /sys/kernel/config/target/iscsi
Unfortunately, "rmmod" doesn't work on this distro. Since we never need
to unload modules we never bothered to figure out why it wasn't working.
I've tried on a vanilla kernel 3.10.1 from the 3.10.y branch
(cb5d8be972cfbea114ea56fd63ed5ce1644863df) with the default config
(except for all of the TCM modules and the FCOE ones enabled).
This kernel was running on an Intel platform with an Intel MB and a Xeon
CPU, 2GB of RAM.
All the kernels tested were 32-bit ones.
The config can be looked up here:
https://www.dropbox.com/s/5wjqka859y6q9r2/linux-3.10.config
The differences between the default kernel config and the one I used are
here:
http://bpaste.net/show/7zubjJeL3xEu7wHU2qhu/
Nothing looks out of the ordinary here.
Thanks for checking!
The issue does not happen when running Ubuntu 13.10 (Saucy Salamander)
with an updated kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.1-saucy/
but I don't know how custom these are.
Do you have any idea where the problem could come from? We have to move
to a newer version of the kernel to avail the fixes from LIO and other
drivers but we're trying to avoid moving to 3.7.y or 3.8.y as they are
currently being EOL'd.
No idea at the moment, but I would look in the direction of busybox
running into an issue with request_module()'s usermode helper. Eg: I
suspect that any request_module() call in the kernel will end up failing
with your current setup.
You're right about the fact that "request_module" fails for any module
in our setup. It fails in a strange way, it cannot walk the path to
"/sbin", even though its permissions are 0755. We've tried updating
busybox to the latest (ours was getting a bit old, in fact it was
released at around the same time as 3.6.11, which could have explained
that it was missing facilities for newer kernel calls), but the same
issue occurs. Thanks for pointing us to the direction of the usermode
helper. We'll do more digging on that.
FYI, these two request_module() calls in target_core_configfs.c are only
required by legacy user-space code, so if your using rtslib to load
modules + populate /sys/kernel/config/target/$FABRIC, you should be able
to safely (as a work-around), disable the two request_module() calls
within target_core_register_fabric().
Thanks a million for this suggestion! It worked as a charm. The only
extra thing we needed to do was to load the IBlock or file backstore
module which isn't loaded automatically by the rtslib Fabric loader, and
that was it! This is also a very clean workaround as well considering
that we control the startup script loading the modules, there won't be a
case where the required driver won't be loaded.
Thanks again for your help!
Regards,
Ben.
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
