Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Larry Finger]

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

Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Arjan van de Ven]

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

Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Rusty Russell]

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];

Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Sedat Dilek]

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.

=46rom 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 channel=
s
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 haltin=
g.

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).
=46or 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=3Dlinux-wireless&m=3D123916648402847&w=3D2
[2] http://marc.info/?l=3Dlinux-acpi&m=3D123918789630534&w=3D2
[3] http://patchwork.kernel.org/patch/17034/

------ BEGIN INVESTIGATIONS -----

=46rom 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 ]---
[...]

=46rom the build-log [max3100 serial-driver]:
[...]
make[4]: *** No rule to make target `drivers/serial/max3100.c', needed
by `drivers/serial/max3100.o'.  Stop.
[...]

=46rom 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 <rusty@rustcorp.com.au> w=
rote:
> 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 wireles=
s. The problem
>> > was bisected with commit acae05156551fd7528fbb616271e672789388e3c,=
 entitled
>> > "module: create a request_module_nowait()", indicated as the fault=
y change. This
>> > is seen with driver b43 on my system, and 2 reports for driver iwl=
agn:
>> > http://marc.info/?l=3Dlinux-wireless&m=3D123916157630571&w=3D2 and
>> > http://marc.info/?l=3Dlinux-wireless&m=3D123913015021457&w=3D2.
>> >
>> > For b43, the logged error messages are:
>>
>> rusty... I still suspect your "int to bool" conversion stuff ;-)
>
> One way to find out. =C2=A0Here'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 @@
> =C2=A0#ifdef CONFIG_MODULES
> =C2=A0/* modprobe exit status on success, -ve on error. =C2=A0Return =
value
> =C2=A0* usually useless though. */
> -extern int __request_module(bool wait, const char *name, ...) \
> - =C2=A0 =C2=A0 =C2=A0 __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...) \
> - =C2=A0 =C2=A0 =C2=A0 ((x) ?: (__request_module(false, mod), (x)))
> +extern int __request_module(int wait, const char *name, ...) __attri=
bute__ ((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)))
> =C2=A0#else
> =C2=A0static inline int request_module(const char *name, ...) { retur=
n -ENOSYS; }
> =C2=A0static 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] =3D "/sb
> =C2=A0* If module auto-loading support is disabled then this function
> =C2=A0* becomes a no-operation.
> =C2=A0*/
> -int __request_module(bool wait, const char *fmt, ...)
> +
> +int __request_module(int wait, const char *fmt, ...)
> =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 =C2=A0va_list args;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0char module_name[MODULE_NAME_LEN];
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wirel=
ess" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.ht=
ml
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Larry Finger]

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

Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Alan Jenkins]

On 4/8/09, Larry Finger <Larry.Finger@lwfinger.net> 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

Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Larry Finger]

Alan Jenkins wrote:
> On 4/8/09, Larry Finger <Larry.Finger@lwfinger.net> 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

Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Randy Dunlap]

Larry Finger wrote:
> Alan Jenkins wrote:
>> On 4/8/09, Larry Finger <Larry.Finger@lwfinger.net> 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

Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Larry Finger]

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

Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Andreas Schwab]

Alan Jenkins <sourcejedi.lkml-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
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 <schwab@linux-m68k.org>
---
 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, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

[Larry Finger]

Andreas Schwab wrote:
> 
> 
> Alan Jenkins <sourcejedi.lkml-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> 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 <schwab@linux-m68k.org>
> ---
>  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 <Larry.Finger@lwfinger.net> if you wish.

Larry