linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).