Skip to contentSkip to conversation

Regression in 2.6.30-rc1 since commit acae0515 - wireless broken

DISCUSSION Applied Larry Finger 7 participants 12 messages Apr 8, 2009 – Apr 9, 2009 Module support

lore
Share & tools
lore

Larry Finger

author
#0 lore raw

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

#1 lore raw
Quoted 8 lines · 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:

rusty... I still suspect your "int to bool" conversion stuff ;-) the rest is pretty close to syntactic noop

#2 lore raw
Quoted 11 lines · On Wednesday 08 April 2009 14:41:06 Arjan van de Ven wrote:
Quoted 8 lines · 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:

rusty... I still suspect your "int to bool" conversion stuff ;-)

One way to find out. Here's the reversion:

include/linux/kmod.h +4 -6
@@ -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; }
kernel/kmod.c +2 -1
@@ -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];
#3 lore raw

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 <[email protected]> w= rote:

Quoted 3 lines · On Wednesday 08 April 2009 14:41:06 Arjan van de Ven wrote:
Quoted 2 lines
Quoted 1 line · Larry Finger

The most recent pulls of the Linux-2.6 git tree has broken wireles=

s. The problem

Quoted 1 line
Quoted 1 line
Quoted 1 line

was bisected with commit acae05156551fd7528fbb616271e672789388e3c,=

entitled

Quoted 1 line
Quoted 1 line
Quoted 1 line

"module: create a request_module_nowait()", indicated as the fault=

y change. This

Quoted 1 line
Quoted 1 line
Quoted 1 line

is seen with driver b43 on my system, and 2 reports for driver iwl=

agn:

Quoted 13 lines
Quoted 6 lines
Quoted 4 lines

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:

include/linux/kmod.h +0 -0
@@ -29,12 +29,10 @@
Quoted 2 lines

=C2=A0#ifdef CONFIG_MODULES
=C2=A0/* modprobe exit status on success, -ve on error. =C2=A0Return =

value

include/linux/kmod.h

Quoted 8 lines

=C2=A0* usually useless though. */

include/linux/kmod.h +1 -6
-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)));

include/linux/kmod.h

Quoted 3 lines
include/linux/kmod.h +3 -0
+#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)))

Quoted 2 lines

=C2=A0#else
=C2=A0static inline int request_module(const char *name, ...) { retur=

n -ENOSYS; }

Quoted 1 line

=C2=A0static inline int request_module_nowait(const char *name, ...) =

{ return -ENOSYS; }

Quoted 10 lines
kernel/kmod.c +0 -0
@@ -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*/

kernel/kmod.c +2 -1
-int __request_module(bool wait, const char *fmt, ...)
+
+int __request_module(int wait, const char *fmt, ...)
Quoted 5 lines

=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

Quoted 2 lines

the body of a message to [email protected]
More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.ht=

ml

Quoted 1 line

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#4 lore raw
In reply to Rusty Russell
Quoted 18 lines · Rusty Russell
Quoted 10 lines · On Wednesday 08 April 2009 14:41:06 Arjan van de Ven wrote:
Quoted 8 lines · 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:

rusty... I still suspect your "int to bool" conversion stuff ;-)

One way to find out. Here's the reversion:

include/linux/kmod.h line 32

Quoted 4 lines
include/linux/kmod.h +0 -1
@@ -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

#5 lore raw
Quoted 29 lines · Larry Finger
Quoted 21 lines · Rusty Russell
Quoted 11 lines · On Wednesday 08 April 2009 14:41:06 Arjan van de Ven wrote:
Quoted 10 lines · 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.

Quoted 2 lines
Quoted 1 line

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:

include/linux/kmod.h line 32

Quoted 4 lines
include/linux/kmod.h +0 -1
@@ -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.

Quoted 1 line

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

author
#6 lore raw
Quoted 11 lines · Alan Jenkins

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.

Quoted 5 lines

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

#7 lore raw
Quoted 86 lines · Larry Finger
Quoted 11 lines · Alan Jenkins

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.

Quoted 5 lines

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

Quoted 2 lines

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.

Signature · 1 line
~Randy
author
#8 lore raw
Quoted 14 lines · Randy Dunlap

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

Quoted 5 lines

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

#9 lore raw
In reply to Alan Jenkins

Alan Jenkins <sourcejedi.lkml-gM/[email protected]>

Quoted 1 line · 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(-)
include/linux/kmod.h +1 -1
Index: linux-2.6.30-rc1/include/linux/kmod.h
===================================================================
@@ -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; }
Signature · 3 lines
Andreas Schwab, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
author
#10 lore raw
Quoted 25 lines · Andreas Schwab

Alan Jenkins <sourcejedi.lkml-gM/[email protected]>

Quoted 1 line · 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
===================================================================

include/linux/kmod.h extern int __request_module(bool wait, c · line 40

Quoted 8 lines
include/linux/kmod.h +1 -1
@@ -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

Applied
#11 lore raw
In reply to Andreas Schwab
Quoted 7 lines · On Thursday 09 April 2009 05:35:21 Andreas Schwab wrote:

Alan Jenkins <sourcejedi.lkml-gM/[email protected]>

Quoted 1 line · writes:

I agree that commit looks like it should be a no-op though :-).

But it isn't.

How embarrassing.

Applied,
Rusty.