The most recent pulls of the Linux-2.6 git tree has broken wireless. The problem
was bisected with commit acae05156551fd7528fbb616271e672789388e3c, entitled
"module: create a request_module_nowait()", indicated as the faulty change. This
is seen with driver b43 on my system, and 2 reports for driver iwlagn:
http://marc.info/?l=linux-wireless&m=123916157630571&w=2 and
http://marc.info/?l=linux-wireless&m=123913015021457&w=2.
For b43, the logged error messages are:
phy0: Failed to initialize wep: -2
b43: probe of ssb0:0 failed with error -2
With this driver, module ssb is selected from the PCI ID. It then loads b43,
which triggers the loading of rfkill, mac80211, cfg80211, led-class, and
input-polldev. It appears that the nowait method is killing the chain somewhere.
If I unload and reload b43, then all these modules load correctly and wireless
works.
If this commit is reverted, wireless works OK.
I will be happy to try any patches to make request_module_nowait() work with
wireless networking.
Larry
Larry Finger wrote:
> The most recent pulls of the Linux-2.6 git tree has broken wireless. The problem
> was bisected with commit acae05156551fd7528fbb616271e672789388e3c, entitled
> "module: create a request_module_nowait()", indicated as the faulty change. This
> is seen with driver b43 on my system, and 2 reports for driver iwlagn:
> http://marc.info/?l=linux-wireless&m=123916157630571&w=2 and
> http://marc.info/?l=linux-wireless&m=123913015021457&w=2.
>
> For b43, the logged error messages are:
rusty... I still suspect your "int to bool" conversion stuff ;-)
the rest is pretty close to syntactic noop
On Wednesday 08 April 2009 14:41:06 Arjan van de Ven wrote:
> Larry Finger wrote:
> > The most recent pulls of the Linux-2.6 git tree has broken wireless. The problem
> > was bisected with commit acae05156551fd7528fbb616271e672789388e3c, entitled
> > "module: create a request_module_nowait()", indicated as the faulty change. This
> > is seen with driver b43 on my system, and 2 reports for driver iwlagn:
> > http://marc.info/?l=linux-wireless&m=123916157630571&w=2 and
> > http://marc.info/?l=linux-wireless&m=123913015021457&w=2.
> >
> > For b43, the logged error messages are:
>
> rusty... I still suspect your "int to bool" conversion stuff ;-)
One way to find out. Here's the reversion:
diff --git a/include/linux/kmod.h b/include/linux/kmod.h
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -29,12 +29,10 @@
#ifdef CONFIG_MODULES
/* modprobe exit status on success, -ve on error. Return value
* usually useless though. */
-extern int __request_module(bool wait, const char *name, ...) \
- __attribute__((format(printf, 2, 3)));
-#define request_module(mod...) __request_module(true, mod)
-#define request_module_nowait(mod...) __request_module(false, mod)
-#define try_then_request_module(x, mod...) \
- ((x) ?: (__request_module(false, mod), (x)))
+extern int __request_module(int wait, const char *name, ...) __attribute__ ((format (printf, 2, 3)));
+#define request_module(mod...) __request_module(1, mod)
+#define request_module_nowait(mod...) __request_module(0, mod)
+#define try_then_request_module(x, mod...) ((x) ?: (__request_module(0, mod), (x)))
#else
static inline int request_module(const char *name, ...) { return -ENOSYS; }
static inline int request_module_nowait(const char *name, ...) { return -ENOSYS; }
diff --git a/kernel/kmod.c b/kernel/kmod.c
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -64,7 +64,8 @@ char modprobe_path[KMOD_PATH_LEN] = "/sb
* If module auto-loading support is disabled then this function
* becomes a no-operation.
*/
-int __request_module(bool wait, const char *fmt, ...)
+
+int __request_module(int wait, const char *fmt, ...)
{
va_list args;
char module_name[MODULE_NAME_LEN];
Hi,
finally, I was able to have a running 2.6.30-rc1 Linux kernel with my
iwl3945 WLAN-hardware.
Yes, iwl3945 is also affected/broken.
The below patch by Rusty is *not* fixing the problem in my case.
As Larry [1] mentionned reverting commit
acae05156551fd7528fbb616271e672789388e3c "module: create a
request_module_nowait()" worked for me, too.
>From dmesg output [iwl3945 error]:
[...]
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver
for Linux, 1.2.26kds
iwl3945: Copyright(c) 2003-2009 Intel Corporation
iwl3945 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwl3945 0000:10:00.0: setting latency timer to 64
iwl3945 0000:10:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels
iwl3945 0000:10:00.0: Detected Intel Wireless WiFi Link 3945ABG
iwl3945 0000:10:00.0: irq 29 for MSI/MSI-X
phy0: Selected rate control algorithm 'iwl-3945-rs'
iwl3945 0000:10:00.0: Failed to register hw (error -2)
iwl3945 0000:10:00.0: PCI INT A disabled
iwl3945: probe of 0000:10:00.0 failed with error -2
[...]
While trying to unload iwl3945-module...
$ ps axu | grep modprobe
root 2143 0.0 0.0 1836 556 ? D< 11:27 0:00
/sbin/modprobe -b
pci:v0000104Cd00008039sv0000103Csd000030ACbc06sc07i00
root 2149 0.0 0.0 1812 532 ? D< 11:27 0:00
/sbin/modprobe -b
pci:v0000104Cd0000803Bsv0000103Csd000030ACbc01sc80i00
root 7186 0.0 0.0 1804 544 ? DN 11:38 0:00
modprobe -r -v iwl3945
I could *not* kill the modprobe process and my system hang while halting.
In addition, I had troubles with the ACPI-battery [2] and max3100
serial-driver [3] and applied the according patches.
Last but not least, I disabled CONFIG_VIDEO_GO7007 (is broken).
For more Details see below investigations section.
With the 3 patches a "normal" booting was possible (w/o ACPI-battery
patch the system hangs for a while) and WIFI works, again.
The only thing I was wondering is the reduced signal-quality from
75/80 down to 50/60 % (location of the notebook didn't change).
Hope these informations help.
Kind Regards,
Sedat
[1] http://marc.info/?l=linux-wireless&m=123916648402847&w=2
[2] http://marc.info/?l=linux-acpi&m=123918789630534&w=2
[3] http://patchwork.kernel.org/patch/17034/
------ BEGIN INVESTIGATIONS -----
>From the same dmesg output [ACPI-battery]:
[...]
Call Trace:
[<c01500f6>] ? async_thread+0xf4/0x1f6
[<c0130de0>] ? default_wake_function+0x0/0x30
[<c0150002>] ? async_thread+0x0/0x1f6
[<c014956c>] ? kthread+0x4a/0x82
[<c0149522>] ? kthread+0x0/0x82
[<c01047a7>] ? kernel_thread_helper+0x7/0x10
Code: 00 00 00 00 00 00 00 00 01 00 03 00 01 00 00 00 00 00 00 00 00
00 00 00 18 1b 00 00 00 00 00 00 34 00 00 00 00 00 28 00 19 00 16 <00>
04 00 00 00 14 00 00 00 03 00 00 00 47 4e 55 00 3a 35 91 0c
EIP: [<f807e033>] 0xf807e033 SS:ESP 0068:f650ff98
CR2: 0000000000000000
---[ end trace 426c85e9e66d48c6 ]---
[...]
>From the build-log [max3100 serial-driver]:
[...]
make[4]: *** No rule to make target `drivers/serial/max3100.c', needed
by `drivers/serial/max3100.o'. Stop.
[...]
>From the build-log [go7007-driver] :
[...]
drivers/staging/go7007/go7007-driver.c:284: error: 'TUNER_SET_TYPE'
undeclared (first use in this function)
drivers/staging/go7007/go7007-driver.c:284: error: (Each undeclared
identifier is reported only once
drivers/staging/go7007/go7007-driver.c:284: error: for each function
it appears in.)
make[5]: *** [drivers/staging/go7007/go7007-driver.o] Error 1
make[4]: *** [drivers/staging/go7007] Error 2
make[3]: *** [drivers/staging] Error 2
[...]
------ END INVESTIGATIONS -----
On Wed, Apr 8, 2009 at 9:01 AM, Rusty Russell <[email protected]> wrote:
> On Wednesday 08 April 2009 14:41:06 Arjan van de Ven wrote:
>> Larry Finger wrote:
>> > The most recent pulls of the Linux-2.6 git tree has broken wireless. The problem
>> > was bisected with commit acae05156551fd7528fbb616271e672789388e3c, entitled
>> > "module: create a request_module_nowait()", indicated as the faulty change. This
>> > is seen with driver b43 on my system, and 2 reports for driver iwlagn:
>> > http://marc.info/?l=linux-wireless&m=123916157630571&w=2 and
>> > http://marc.info/?l=linux-wireless&m=123913015021457&w=2.
>> >
>> > For b43, the logged error messages are:
>>
>> rusty... I still suspect your "int to bool" conversion stuff ;-)
>
> One way to find out. Here's the reversion:
>
> diff --git a/include/linux/kmod.h b/include/linux/kmod.h
> --- a/include/linux/kmod.h
> +++ b/include/linux/kmod.h
> @@ -29,12 +29,10 @@
> #ifdef CONFIG_MODULES
> /* modprobe exit status on success, -ve on error. Return value
> * usually useless though. */
> -extern int __request_module(bool wait, const char *name, ...) \
> - __attribute__((format(printf, 2, 3)));
> -#define request_module(mod...) __request_module(true, mod)
> -#define request_module_nowait(mod...) __request_module(false, mod)
> -#define try_then_request_module(x, mod...) \
> - ((x) ?: (__request_module(false, mod), (x)))
> +extern int __request_module(int wait, const char *name, ...) __attribute__ ((format (printf, 2, 3)));
> +#define request_module(mod...) __request_module(1, mod)
> +#define request_module_nowait(mod...) __request_module(0, mod)
> +#define try_then_request_module(x, mod...) ((x) ?: (__request_module(0, mod), (x)))
> #else
> static inline int request_module(const char *name, ...) { return -ENOSYS; }
> static inline int request_module_nowait(const char *name, ...) { return -ENOSYS; }
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -64,7 +64,8 @@ char modprobe_path[KMOD_PATH_LEN] = "/sb
> * If module auto-loading support is disabled then this function
> * becomes a no-operation.
> */
> -int __request_module(bool wait, const char *fmt, ...)
> +
> +int __request_module(int wait, const char *fmt, ...)
> {
> va_list args;
> char module_name[MODULE_NAME_LEN];
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Rusty Russell wrote:
> On Wednesday 08 April 2009 14:41:06 Arjan van de Ven wrote:
>> Larry Finger wrote:
>>> The most recent pulls of the Linux-2.6 git tree has broken wireless. The problem
>>> was bisected with commit acae05156551fd7528fbb616271e672789388e3c, entitled
>>> "module: create a request_module_nowait()", indicated as the faulty change. This
>>> is seen with driver b43 on my system, and 2 reports for driver iwlagn:
>>> http://marc.info/?l=linux-wireless&m=123916157630571&w=2 and
>>> http://marc.info/?l=linux-wireless&m=123913015021457&w=2.
>>>
>>> For b43, the logged error messages are:
>> rusty... I still suspect your "int to bool" conversion stuff ;-)
>
> One way to find out. Here's the reversion:
>
> diff --git a/include/linux/kmod.h b/include/linux/kmod.h
> --- a/include/linux/kmod.h
> +++ b/include/linux/kmod.h
> @@ -29,12 +29,10 @@
> #ifdef CONFIG_MODULES
> /* modprobe exit status on success, -ve on error. Return value
> * usually useless though. */
> -extern int __request_module(bool wait, const char *name, ...) \
The patch did not fix the problem. The symptoms are the same.
Larry
On 4/8/09, Larry Finger <[email protected]> wrote:
> Rusty Russell wrote:
>> On Wednesday 08 April 2009 14:41:06 Arjan van de Ven wrote:
>>> Larry Finger wrote:
>>>> The most recent pulls of the Linux-2.6 git tree has broken wireless. The
>>>> problem
>>>> was bisected with commit acae05156551fd7528fbb616271e672789388e3c,
>>>> entitled
>>>> "module: create a request_module_nowait()", indicated as the faulty
>>>> change. This
>>>> is seen with driver b43 on my system, and 2 reports for driver iwlagn:
>>>> http://marc.info/?l=linux-wireless&m=123916157630571&w=2 and
>>>> http://marc.info/?l=linux-wireless&m=123913015021457&w=2.
>>>>
>>>> For b43, the logged error messages are:
>>> rusty... I still suspect your "int to bool" conversion stuff ;-)
>>
>> One way to find out. Here's the reversion:
>>
>> diff --git a/include/linux/kmod.h b/include/linux/kmod.h
>> --- a/include/linux/kmod.h
>> +++ b/include/linux/kmod.h
>> @@ -29,12 +29,10 @@
>> #ifdef CONFIG_MODULES
>> /* modprobe exit status on success, -ve on error. Return value
>> * usually useless though. */
>> -extern int __request_module(bool wait, const char *name, ...) \
>
> The patch did not fix the problem. The symptoms are the same.
>
> Larry
Hi, I can confirm this bug on ath5k.
Something is very wrong with request_module(), this is just the most
obvious symptom. It also seems to affect libusual (loading
usb-storage) and FAT (loading NLS modules).
If I hotplug my wireless device, it then loads correctly. So I'm
guessing wireless modules e.g. encryption modules get loaded too
asynchronously. I.e. on boot, the sub-modules are loaded too late.
But when I hotplug the device, the modules are already loaded.
Same with FAT - it fails on first attempt to mount because of missing
NLS module, then works on second mount,
I agree that commit looks like it should be a no-op though :-).
I will try to confirm the OP's bisection by reverting the commit, acae0515.
Alan
Alan Jenkins wrote:
> On 4/8/09, Larry Finger <[email protected]> wrote:
>
> Something is very wrong with request_module(), this is just the most
> obvious symptom. It also seems to affect libusual (loading
> usb-storage) and FAT (loading NLS modules).
>
> If I hotplug my wireless device, it then loads correctly. So I'm
> guessing wireless modules e.g. encryption modules get loaded too
> asynchronously. I.e. on boot, the sub-modules are loaded too late.
> But when I hotplug the device, the modules are already loaded.
>
> Same with FAT - it fails on first attempt to mount because of missing
> NLS module, then works on second mount,
>
> I agree that commit looks like it should be a no-op though :-).
> I will try to confirm the OP's bisection by reverting the commit, acae0515.
I added printk's to the entry and exit from __request_module and obtained the
following:
module: __request_module entered for module snd-hda-codec-id:14f15051
module: loading module snd-hda-codec-id:14f15051 - call_usermodehelper returned 0
module: __request_module entered for module ecb(arc4)
module: loading module ecb(arc4) - call_usermodehelper returned 256
module: __request_module entered for module ecb
module: loading module ecb - call_usermodehelper returned 0
module: __request_module entered for module char-major-4-68
module: loading module char-major-4-68 - call_usermodehelper returned 256
module: __request_module entered for module char-major-4
module: loading module char-major-4 - call_usermodehelper returned 256
module: __request_module entered for module char-major-4-69
module: loading module char-major-4-69 - call_usermodehelper returned 256
module: __request_module entered for module char-major-4
module: loading module char-major-4 - call_usermodehelper returned 256
module: __request_module entered for module char-major-4-70
module: loading module char-major-4-70 - call_usermodehelper returned 256
module: __request_module entered for module char-major-4
module: loading module char-major-4 - call_usermodehelper returned 256
module: __request_module entered for module char-major-4-71
module: loading module char-major-4-71 - call_usermodehelper returned 256
module: __request_module entered for module char-major-4
module: loading module char-major-4 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
module: __request_module entered for module net-pf-10
module: loading module net-pf-10 - call_usermodehelper returned 256
According to the description of the routine, it should return 0 on success and a
negative number for an error. Where do the values of "256" mean?
Larry
Alan Jenkins <sourcejedi.lkml-gM/[email protected]>
writes:
> I agree that commit looks like it should be a no-op though :-).
But it isn't.
Andreas.
---
Fix try_then_request_module to use waiting __request_module again.
Signed-off-by: Andreas Schwab <[email protected]>
---
include/linux/kmod.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.30-rc1/include/linux/kmod.h
===================================================================
--- linux-2.6.30-rc1.orig/include/linux/kmod.h 2009-04-08 12:47:54.000000000 +0200
+++ linux-2.6.30-rc1/include/linux/kmod.h 2009-04-08 17:39:35.000000000 +0200
@@ -34,7 +34,7 @@ extern int __request_module(bool wait, c
#define request_module(mod...) __request_module(true, mod)
#define request_module_nowait(mod...) __request_module(false, mod)
#define try_then_request_module(x, mod...) \
- ((x) ?: (__request_module(false, mod), (x)))
+ ((x) ?: (__request_module(true, mod), (x)))
#else
static inline int request_module(const char *name, ...) { return -ENOSYS; }
static inline int request_module_nowait(const char *name, ...) { return -ENOSYS; }
--
Andreas Schwab, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab wrote:
>
>
> Alan Jenkins <sourcejedi.lkml-gM/[email protected]>
> writes:
>
>> I agree that commit looks like it should be a no-op though :-).
>
> But it isn't.
>
> Andreas.
>
> ---
> Fix try_then_request_module to use waiting __request_module again.
>
> Signed-off-by: Andreas Schwab <[email protected]>
> ---
> include/linux/kmod.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.30-rc1/include/linux/kmod.h
> ===================================================================
> --- linux-2.6.30-rc1.orig/include/linux/kmod.h 2009-04-08 12:47:54.000000000 +0200
> +++ linux-2.6.30-rc1/include/linux/kmod.h 2009-04-08 17:39:35.000000000 +0200
> @@ -34,7 +34,7 @@ extern int __request_module(bool wait, c
> #define request_module(mod...) __request_module(true, mod)
> #define request_module_nowait(mod...) __request_module(false, mod)
> #define try_then_request_module(x, mod...) \
> - ((x) ?: (__request_module(false, mod), (x)))
> + ((x) ?: (__request_module(true, mod), (x)))
> #else
> static inline int request_module(const char *name, ...) { return -ENOSYS; }
> static inline int request_module_nowait(const char *name, ...) { return -ENOSYS; }
>
Bingo. The above patch fixes my system. Andreas, you have a much sharper eye
than I do.
Feel free to add a Tested-by: Larry Finger <[email protected]> if you wish.
Larry
Larry Finger wrote:
> Alan Jenkins wrote:
>> On 4/8/09, Larry Finger <[email protected]> wrote:
>>
>> Something is very wrong with request_module(), this is just the most
>> obvious symptom. It also seems to affect libusual (loading
>> usb-storage) and FAT (loading NLS modules).
>>
>> If I hotplug my wireless device, it then loads correctly. So I'm
>> guessing wireless modules e.g. encryption modules get loaded too
>> asynchronously. I.e. on boot, the sub-modules are loaded too late.
>> But when I hotplug the device, the modules are already loaded.
>>
>> Same with FAT - it fails on first attempt to mount because of missing
>> NLS module, then works on second mount,
>>
>> I agree that commit looks like it should be a no-op though :-).
>> I will try to confirm the OP's bisection by reverting the commit, acae0515.
>
> I added printk's to the entry and exit from __request_module and obtained the
> following:
>
> module: __request_module entered for module snd-hda-codec-id:14f15051
> module: loading module snd-hda-codec-id:14f15051 - call_usermodehelper returned 0
> module: __request_module entered for module ecb(arc4)
> module: loading module ecb(arc4) - call_usermodehelper returned 256
> module: __request_module entered for module ecb
> module: loading module ecb - call_usermodehelper returned 0
> module: __request_module entered for module char-major-4-68
> module: loading module char-major-4-68 - call_usermodehelper returned 256
> module: __request_module entered for module char-major-4
> module: loading module char-major-4 - call_usermodehelper returned 256
> module: __request_module entered for module char-major-4-69
> module: loading module char-major-4-69 - call_usermodehelper returned 256
> module: __request_module entered for module char-major-4
> module: loading module char-major-4 - call_usermodehelper returned 256
> module: __request_module entered for module char-major-4-70
> module: loading module char-major-4-70 - call_usermodehelper returned 256
> module: __request_module entered for module char-major-4
> module: loading module char-major-4 - call_usermodehelper returned 256
> module: __request_module entered for module char-major-4-71
> module: loading module char-major-4-71 - call_usermodehelper returned 256
> module: __request_module entered for module char-major-4
> module: loading module char-major-4 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
> module: __request_module entered for module net-pf-10
> module: loading module net-pf-10 - call_usermodehelper returned 256
>
> According to the description of the routine, it should return 0 on success and a
> negative number for an error. Where do the values of "256" mean?
Here's a quick explanation (Linus explained this to me 6-8 years ago;
I bet his was better than mine, but I can't find his).
256 = 0x0100
Inside the kernel, a program's exit code/status is split into 2 8-bit fields,
so this exit status is (0x01, 0x00). The low 8 bits (0x00 in this example)
store an internal code for why the program is exiting (or did exit). E.g.:
0xlow_7_bits = 0 => exited, exit status is in "high" 8 bits
else 0x80 bit set => core dumped, else killed, with exit status in low 7 bits
So it looks like /sbin/modprobe exited with an exit status of 1...
whatever that means (fatal error or usage() printed or module not found).
See kernel/[signal.c & exit.c] for uses of 0x80...
HTH.
--
~Randy
Randy Dunlap wrote:
>
> Here's a quick explanation (Linus explained this to me 6-8 years ago;
> I bet his was better than mine, but I can't find his).
>
> 256 = 0x0100
>
> Inside the kernel, a program's exit code/status is split into 2 8-bit fields,
> so this exit status is (0x01, 0x00). The low 8 bits (0x00 in this example)
> store an internal code for why the program is exiting (or did exit). E.g.:
>
> 0xlow_7_bits = 0 => exited, exit status is in "high" 8 bits
> else 0x80 bit set => core dumped, else killed, with exit status in low 7 bits
>
>
> So it looks like /sbin/modprobe exited with an exit status of 1...
> whatever that means (fatal error or usage() printed or module not found).
>
>
> See kernel/[signal.c & exit.c] for uses of 0x80...
Thanks for the explanation. In all the cases where the returned value was
0x0100, the corresponding module does not exist. The comment is still wrong, but
at least non-zero is an error.
Larry
On Thursday 09 April 2009 05:35:21 Andreas Schwab wrote:
>
> Alan Jenkins <sourcejedi.lkml-gM/[email protected]>
> writes:
>
> > I agree that commit looks like it should be a no-op though :-).
>
> But it isn't.
How embarrassing.
Applied,
Rusty.