From: Randy Dunlap <randy.dunlap@oracle.com>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: alan-jenkins@tuffmail.co.uk,
Rusty Russell <rusty@rustcorp.com.au>,
Arjan van de Ven <arjan@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
wireless <linux-wireless@vger.kernel.org>
Subject: Re: Regression in 2.6.30-rc1 since commit acae0515 - wireless broken
Date: Wed, 08 Apr 2009 16:49:31 -0700 [thread overview]
Message-ID: <49DD380B.5080101@oracle.com> (raw)
In-Reply-To: <49DCDF9E.8000605@lwfinger.net>
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
next prev parent reply other threads:[~2009-04-08 23:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 4:54 Regression in 2.6.30-rc1 since commit acae0515 - wireless broken Larry Finger
2009-04-08 5:11 ` Arjan van de Ven
2009-04-08 7:01 ` Rusty Russell
2009-04-08 13:46 ` Sedat Dilek
2009-04-08 14:49 ` Larry Finger
2009-04-08 17:06 ` Alan Jenkins
2009-04-08 17:32 ` Larry Finger
2009-04-08 23:49 ` Randy Dunlap [this message]
2009-04-09 0:02 ` Larry Finger
2009-04-08 20:05 ` Andreas Schwab
2009-04-08 21:13 ` Larry Finger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49DD380B.5080101@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=Larry.Finger@lwfinger.net \
--cc=alan-jenkins@tuffmail.co.uk \
--cc=arjan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).