LinuxLists.cc - linux-next: Tree for June 3

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3

On Thu, 3 Jun 2010 05:30:09 pm Dave Young wrote:
> Seems for some module drop reference of 0 in following code of init_module:
>
> /* Drop initial reference. */
> module_put(mod);

Thanks Dave, good bug report.

It was "module: refactor load_module part 4" where I initialized
the per-cpu pointer before allocating it:

static int module_unload_init(struct module *mod)
{
...
/* Hold reference count during initialization. */
__this_cpu_write(mod->refptr->incs, 1);
...
mod->refptr = alloc_percpu(struct module_ref);
...

This also explains Stephen's crash during module load (which was more
expected since refptr is NULL, though percpu ptrs don't work that way).

I've fixed it (by reversing the order of those lines) for tomorrow's
linux-next.

Thanks!
Rusty.

2010-06-03 15:47:04

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3 (qlcnic)

On Thu, 3 Jun 2010 13:47:53 +1000 Stephen Rothwell wrote:

> Hi all,
>
> Changes since 20100602:

when CONFIG_INET=n:

ERROR: "qlcnicvf_set_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_config_bridged_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_config_led" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_clear_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
ERROR: "qlcnicvf_start_firmware" [drivers/net/qlcnic/qlcnic.ko] undefined!

full config is attached.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Attachments:

config-r2527 (60.78 kB)

2010-06-03 15:55:41

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3 (iwlwifi)

On Thu, 3 Jun 2010 13:47:53 +1000 Stephen Rothwell wrote:

> Hi all,
>
> Changes since 20100602:

when CONFIG_IWLAGN=n:

drivers/net/wireless/iwlwifi/iwl-rx.c:254: error: 'struct iwl_priv' has no member named '_agn'
drivers/net/wireless/iwlwifi/iwl-rx.c:303: error: 'struct iwl_priv' has no member named '_agn'
drivers/net/wireless/iwlwifi/iwl-rx.c:304: error: 'struct iwl_priv' has no member named '_agn'
drivers/net/wireless/iwlwifi/iwl-rx.c:305: error: 'struct iwl_priv' has no member named '_agn'
drivers/net/wireless/iwlwifi/iwl-rx.c:306: error: 'struct iwl_priv' has no member named '_agn'

and many more.

Haven't we seen this movie before?

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

2010-06-03 16:40:48

[permalink] [raw]

Subject: [PATCH -next] classmate-laptop: fix for RFKILL=m, CMPC=y

From: Randy Dunlap <[email protected]>

Fix build error when CONFIG_RFKILL=m and CONFIG_ACPI_CMPC=y:
classmate-laptop should depend on RFKILL or RFKILL=n.

classmate-laptop.c:(.text+0x1351fc): undefined reference to `rfkill_unregister'
classmate-laptop.c:(.text+0x135204): undefined reference to `rfkill_destroy'
classmate-laptop.c:(.text+0x135237): undefined reference to `rfkill_set_sw_state'
classmate-laptop.c:(.text+0x1352b9): undefined reference to `rfkill_alloc'
classmate-laptop.c:(.text+0x1352ca): undefined reference to `rfkill_register'
classmate-laptop.c:(.text+0x1352d6): undefined reference to `rfkill_destroy'

Signed-off-by: Randy Dunlap <[email protected]>
---
drivers/platform/x86/Kconfig | 1 +
1 file changed, 1 insertion(+)

--- linux-next-20100603.orig/drivers/platform/x86/Kconfig
+++ linux-next-20100603/drivers/platform/x86/Kconfig
@@ -520,6 +520,7 @@ config TOSHIBA_BT_RFKILL
config ACPI_CMPC
tristate "CMPC Laptop Extras"
depends on X86 && ACPI
+ depends on RFKILL || RFKILL=n
select INPUT
select BACKLIGHT_CLASS_DEVICE
default n

2010-06-03 17:30:14

by John W. Linville

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3 (iwlwifi)

On Thu, Jun 03, 2010 at 08:55:01AM -0700, Randy Dunlap wrote:
> On Thu, 3 Jun 2010 13:47:53 +1000 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since 20100602:
>
>
> when CONFIG_IWLAGN=n:
>
> drivers/net/wireless/iwlwifi/iwl-rx.c:254: error: 'struct iwl_priv' has no member named '_agn'
> drivers/net/wireless/iwlwifi/iwl-rx.c:303: error: 'struct iwl_priv' has no member named '_agn'
> drivers/net/wireless/iwlwifi/iwl-rx.c:304: error: 'struct iwl_priv' has no member named '_agn'
> drivers/net/wireless/iwlwifi/iwl-rx.c:305: error: 'struct iwl_priv' has no member named '_agn'
> drivers/net/wireless/iwlwifi/iwl-rx.c:306: error: 'struct iwl_priv' has no member named '_agn'
>
> and many more.
>
> Haven't we seen this movie before?

Ugh...caused be this:

commit a2064b7a4a22d118087898e4308670da7ac07911
Author: Wey-Yi Guy <[email protected]>
Date: Fri Apr 30 14:21:48 2010 -0700

iwlwifi: move _agn statistics related structure

agn and 3945 has different statistics_notif data structure; since 3945
has it statistics_notif data structure inside the _3945 portion of
iwl_priv, it make sense to move the agn statistics_notif into _agn portion.

Signed-off-by: Wey-Yi Guy <[email protected]>
Signed-off-by: Reinette Chatre <[email protected]>

Since iwl-rx.o is part of iwlcore.ko, this change seems wrong.
Reinette, any reason why I shouldn't just revert it?

John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.

2010-06-03 17:31:47

by Anirban Chakraborty

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3 (qlcnic)

On Jun 3, 2010, at 8:46 AM, Randy Dunlap wrote:

> On Thu, 3 Jun 2010 13:47:53 +1000 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20100602:
>
>
> when CONFIG_INET=n:
>
> ERROR: "qlcnicvf_set_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_config_bridged_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_config_led" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_clear_ilb_mode" [drivers/net/qlcnic/qlcnic.ko] undefined!
> ERROR: "qlcnicvf_start_firmware" [drivers/net/qlcnic/qlcnic.ko] undefined!
>
> full config is attached.
>

Sorry about that. I will send fix right away.

thanks,
Anirban

2010-06-03 17:42:51

by Wey-Yi Guy

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3 (iwlwifi)

Hi John,

On Thu, 2010-06-03 at 10:21 -0700, John W. Linville wrote:
> On Thu, Jun 03, 2010 at 08:55:01AM -0700, Randy Dunlap wrote:
> > On Thu, 3 Jun 2010 13:47:53 +1000 Stephen Rothwell wrote:
> >
> > > Hi all,
> > >
> > > Changes since 20100602:
> >
> >
> > when CONFIG_IWLAGN=n:
> >
> > drivers/net/wireless/iwlwifi/iwl-rx.c:254: error: 'struct iwl_priv' has no member named '_agn'
> > drivers/net/wireless/iwlwifi/iwl-rx.c:303: error: 'struct iwl_priv' has no member named '_agn'
> > drivers/net/wireless/iwlwifi/iwl-rx.c:304: error: 'struct iwl_priv' has no member named '_agn'
> > drivers/net/wireless/iwlwifi/iwl-rx.c:305: error: 'struct iwl_priv' has no member named '_agn'
> > drivers/net/wireless/iwlwifi/iwl-rx.c:306: error: 'struct iwl_priv' has no member named '_agn'
> >
> > and many more.
> >
> > Haven't we seen this movie before?
>
> Ugh...caused be this:
>
> commit a2064b7a4a22d118087898e4308670da7ac07911
> Author: Wey-Yi Guy <[email protected]>
> Date: Fri Apr 30 14:21:48 2010 -0700
>
> iwlwifi: move _agn statistics related structure
>
> agn and 3945 has different statistics_notif data structure; since 3945
> has it statistics_notif data structure inside the _3945 portion of
> iwl_priv, it make sense to move the agn statistics_notif into _agn portion.
>
> Signed-off-by: Wey-Yi Guy <[email protected]>
> Signed-off-by: Reinette Chatre <[email protected]>
>
> Since iwl-rx.o is part of iwlcore.ko, this change seems wrong.
> Reinette, any reason why I shouldn't just revert it?
>
Sorry for the mistake, please revert it and I will fix the issue and
re-submit.

Thanks
Wey

2010-06-03 18:44:23

by Reinette Chatre

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3 (iwlwifi)

Hi John,

On Thu, 2010-06-03 at 10:21 -0700, John W. Linville wrote:
> On Thu, Jun 03, 2010 at 08:55:01AM -0700, Randy Dunlap wrote:
> > On Thu, 3 Jun 2010 13:47:53 +1000 Stephen Rothwell wrote:
> >
> > > Hi all,
> > >
> > > Changes since 20100602:
> >
> >
> > when CONFIG_IWLAGN=n:
> >
> > drivers/net/wireless/iwlwifi/iwl-rx.c:254: error: 'struct iwl_priv' has no member named '_agn'
> > drivers/net/wireless/iwlwifi/iwl-rx.c:303: error: 'struct iwl_priv' has no member named '_agn'
> > drivers/net/wireless/iwlwifi/iwl-rx.c:304: error: 'struct iwl_priv' has no member named '_agn'
> > drivers/net/wireless/iwlwifi/iwl-rx.c:305: error: 'struct iwl_priv' has no member named '_agn'
> > drivers/net/wireless/iwlwifi/iwl-rx.c:306: error: 'struct iwl_priv' has no member named '_agn'
> >
> > and many more.
> >
> > Haven't we seen this movie before?
>
> Ugh...caused be this:
>
> commit a2064b7a4a22d118087898e4308670da7ac07911
> Author: Wey-Yi Guy <[email protected]>
> Date: Fri Apr 30 14:21:48 2010 -0700
>
> iwlwifi: move _agn statistics related structure
>
> agn and 3945 has different statistics_notif data structure; since 3945
> has it statistics_notif data structure inside the _3945 portion of
> iwl_priv, it make sense to move the agn statistics_notif into _agn portion.
>
> Signed-off-by: Wey-Yi Guy <[email protected]>
> Signed-off-by: Reinette Chatre <[email protected]>
>
> Since iwl-rx.o is part of iwlcore.ko, this change seems wrong.

Indeed. Sorry about this.

> Reinette, any reason why I shouldn't just revert it?

No - please do revert it. I am getting an unfamiliar error when I tried
to revert it from linux-2.6 as well as wireless-testing, but perhaps it
is something your are familiar with. Please let me know if you need a
patch that will take care of the revert.

Reinette

2010-06-04 19:47:05

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3

> I've fixed it (by reversing the order of those lines) for tomorrow's
> linux-next.

Somewhere between next-20100602 and next-20100604
something was changed that results in ia64 taking deref
NULL oops in sys_init_module() ...

Freeing unused kernel memory: 1984kB freed
modprobe[1851]: NaT consumption 2216203124768 [1]
Modules linked in:

Pid: 1851, CPU 2, comm: modprobe
psr : 0000121008526030 ifs : 8000000000000794 ip :
[<a0000001000f0f31>] Not tainted
(2.6.35-rc1-generic-smp-next-20100604)
ip is at sys_init_module+0x131/0x420

At the point of dereference it looks like we were trying
to load a 4-byte data object from offset 552 into the
"struct module *" that wa returned by load_module().

-Tony

2010-06-04 20:09:35

by Linus Torvalds

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3

On Fri, 4 Jun 2010, Tony Luck wrote:
>
> At the point of dereference it looks like we were trying
> to load a 4-byte data object from offset 552 into the
> "struct module *" that wa returned by load_module().

Sounds like 'mod->num_ctors' loaded by do_mod_ctors(). It's a 4-byte field
in roughly that area.

What does a NaT consumption fault mean, and does it give the invalid
address it was loaded off? In the successful path of "load_module()", we
will have dereferenced the "mod" pointer we return just before, so I
wonder if there's some error case that incorrectly returns a positive
errno instead of a negative one, and causes us to miss the "IS_ERR()"
check or something.

There's a couple of checking routines in module.c that do not return a
negative error, but instead return 0/1. The one I looked at was converted
into a negative error, but there are several cases of

if (err)
return ERR_PTR(err)

and if something does that on a 0/1 value, it will return a bogus pointer.

Linus

2010-06-04 20:46:58

[permalink] [raw]

Subject: RE: linux-next: Tree for June 3

> What does a NaT consumption fault mean, and does it give the invalid
> address it was loaded off?

This almost always means that we dereferenced a NULL pointer ... though
any access into the bottom PAGE_SIZE of kernel virtual address space
will result in this trap. This happens on ia64 because we have a "NaT"
page mapped at 0x0 so that speculative loads that chase NULL pointers
at the end of lists behave more rationally.

Sadly I don't have the actual address. The register that was used
for the dereference isn't included in the OOPS output.

-Tony

2010-06-04 22:10:05

by Linus Torvalds

[permalink] [raw]

Subject: RE: linux-next: Tree for June 3

On Fri, 4 Jun 2010, Luck, Tony wrote:
>
> This almost always means that we dereferenced a NULL pointer ... though
> any access into the bottom PAGE_SIZE of kernel virtual address space
> will result in this trap. This happens on ia64 because we have a "NaT"
> page mapped at 0x0 so that speculative loads that chase NULL pointers
> at the end of lists behave more rationally.
>
> Sadly I don't have the actual address. The register that was used
> for the dereference isn't included in the OOPS output.

Ok, so it confirms just that load_module() has returned a pointer that is
either NULL or at least within PAGE_SIZE-552.

It could be a negative error pointer (and the offset of 552 turns it into
the NULL page), but that's what the whole IS_ERR() thing checks for, so
that's not the case.

So the

if (err)
return ERR_PTR(err);

case does seem pretty likely (most of them with a "goto <error-case>", but
some directly. Many of them have the stricter form of "if (err < 0)", but
there's a number that do not.

And in fact, I think I see the bad one:

/* Figure out module layout, and allocate all the memory. */
mod = layout_and_allocate(&info);
if (IS_ERR(mod))
goto free_copy;

which looks fine, but "free_copy:" expects the error number in "err",
which is what the other error cases do.

I think this was introduced by Rusty's commit 5d3f5be82944 ("module:
layout_and_allocate"), and here's a suggested fix.. The easiest fix is to
actually change the "free_copy" target to return "mod" as the above goto
expects, and then just do a conversion before the fall-through from the
other error cases (that have it in 'err').

Does this fix it? I stopped looking for other possible causes when I found
this one.

Linus

---
kernel/module.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 69a3f12..9a0b275 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2653,9 +2653,10 @@ static struct module *load_module(void __user *umod,
module_unload_free(mod);
free_module:
module_deallocate(mod, &info);
+ mod = ERR_PTR(err);
free_copy:
free_copy(&info);
- return ERR_PTR(err);
+ return mod;
}

/* Call module constructors. */

2010-06-04 22:50:46

[permalink] [raw]

Subject: RE: linux-next: Tree for June 3

> Does this fix it? I stopped looking for other possible causes when I found
> this one.

It gets rid of the oops. So that's good. Something is still
hokey in linux-next land though because no modules get loaded.
So no ehci/uhci available :-(

No obvious looking error messages on the console.

-Tony
---
kernel/module.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 69a3f12..9a0b275 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2653,9 +2653,10 @@ static struct module *load_module(void __user *umod,
module_unload_free(mod);
free_module:
module_deallocate(mod, &info);
+ mod = ERR_PTR(err);
free_copy:
free_copy(&info);
- return ERR_PTR(err);
+ return mod;
}

/* Call module constructors. */

2010-06-04 23:02:13

by Linus Torvalds

[permalink] [raw]

Subject: RE: linux-next: Tree for June 3

On Fri, 4 Jun 2010, Luck, Tony wrote:
>
> It gets rid of the oops. So that's good. Something is still
> hokey in linux-next land though because no modules get loaded.
> So no ehci/uhci available :-(

So maybe the error (the one that caused us to exit and caused the oops due
to the wrong return value) is the one that now causes it to not load.

I note that ia64 has a pretty big/complex module_frob_arch_sections().
Many architectures (like x86) has a trivial one ("return 0;"), and there
might be some ordering differences in the setup that only matter with
architectures that do odd things there..

Linus

2010-06-05 02:39:59

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3

On Sat, 5 Jun 2010 08:27:13 am Linus Torvalds wrote:
>
> On Fri, 4 Jun 2010, Luck, Tony wrote:
> >
> > It gets rid of the oops. So that's good. Something is still
> > hokey in linux-next land though because no modules get loaded.
> > So no ehci/uhci available :-(
>
> So maybe the error (the one that caused us to exit and caused the oops due
> to the wrong return value) is the one that now causes it to not load.
>
> I note that ia64 has a pretty big/complex module_frob_arch_sections().
> Many architectures (like x86) has a trivial one ("return 0;"), and there
> might be some ordering differences in the setup that only matter with
> architectures that do odd things there..

Hmm, but at a glance nothing else in layout_and_allocate() can fail silently,
and ia64's module_arch_frob_sections() has a printk on fail.

But, the June 3 tree (beware dateline: we are talking next-20100603?)
had the "deref per-cpu ptr before allocating it" issue which was fixed
the following day.

There have been three bugfixes since then, too:
1) I have also thrown out the "clean up percpu" commit, which would fail
on any relocations in the percpu section.
2) Linus' error path fix (I did it slightly different for consistency)
3) SYSFS=n compile issue.

Since it's a weekend here already, we're not going to get another linux-next
until Monday.

Here's a tree with all current fixes: still no module load?

The following changes since commit ad8456361fa19068cf49b50a4f98e41b73c08e76:
Linus Torvalds (1):
Merge branch 'upstream-linus' of git://git.kernel.org/.../jgarzik/libata-dev

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6 module

Eric Dumazet (1):
module: module_unload_init() cleanup

Linus Torvalds (6):
module: Make the 'usage' lists be two-way
module: move find_module check to end
module: refactor load_module
module: refactor load_module part 2
module: reduce stack usage for each_symbol()
module: fix bne2 "gave up waiting for init of module libcrc32c"

Rusty Russell (18):
module: fix kdb's illicit use of struct module_use.
module: move sysfs exposure to end of load_module
module: Make module sysfs functions private.
module: make locking more fine-grained.
module: verify_export_symbols under the lock
module: fix bne2 "gave up waiting for init of module libcrc32c"
module: refactor load_module part 3
module: refactor load_module part 4
module: refactor load_module part 5
module: refactor out section header rewriting
module: kallsyms functions take struct load_info
module: layout_and_allocate
module: sysfs cleanup
module: fix sysfs cleanup for !CONFIG_SYSFS
module: pass load_info into other functions
module: move module args strndup_user to just before use
module: group post-relocation functions into post_relocation()
module: cleanup comments, remove noinline

include/linux/module.h | 44 +--
kernel/debug/kdb/kdb_main.c | 12 +-
kernel/module.c | 1362 ++++++++++++++++++++++++-------------------
3 files changed, 779 insertions(+), 639 deletions(-)

2010-06-05 02:51:46

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3

On Sat, 5 Jun 2010 12:09:51 pm Rusty Russell wrote:
> Here's a tree with all current fixes: still no module load?

Erk, terminally broken tree. Will re-xmit once fixed...

Rusty.

2010-06-05 04:01:34

[permalink] [raw]

Subject: Re: linux-next: Tree for June 3

On Sat, 5 Jun 2010 12:21:37 pm Rusty Russell wrote:
> On Sat, 5 Jun 2010 12:09:51 pm Rusty Russell wrote:
> > Here's a tree with all current fixes: still no module load?
>
> Erk, terminally broken tree. Will re-xmit once fixed...

I'd introduced a bug with MODVERSIONS=y in "module: refactor out section
header rewriting". Not doing too well on this...

Fixed that, too (see below for fix if curious).

This time for sure!
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6.git module

Subject: module: refactor out section header rewriting: FIX modversions

We can't do the find_sec after removing the SHF_ALLOC flags; it won't
find the sections.

Signed-off-by: Rusty Russell <[email protected]>
---
kernel/module.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2217,11 +2217,13 @@ static int rewrite_section_headers(struc
if (strstarts(info->secstrings+shdr->sh_name, ".exit"))
shdr->sh_flags &= ~(unsigned long)SHF_ALLOC;
#endif
- /* Don't keep modinfo and version sections. */
- if (!strcmp(info->secstrings+shdr->sh_name, "__versions")
- || !strcmp(info->secstrings+shdr->sh_name, ".modinfo"))
- shdr->sh_flags &= ~(unsigned long)SHF_ALLOC;
}
+
+ /* Track but don't keep modinfo and version sections. */
+ info->index.vers = find_sec(info->hdr, info->sechdrs, info->secstrings, "__versions");
+ info->index.info = find_sec(info->hdr, info->sechdrs, info->secstrings, ".modinfo");
+ info->sechdrs[info->index.info].sh_flags &= ~(unsigned long)SHF_ALLOC;
+ info->sechdrs[info->index.vers].sh_flags &= ~(unsigned long)SHF_ALLOC;
return 0;
}

@@ -2274,8 +2276,6 @@ static struct module *setup_load_info(st
return ERR_PTR(-ENOEXEC);
}

- info->index.vers = find_sec(info->hdr, info->sechdrs, info->secstrings, "__versions");
- info->index.info = find_sec(info->hdr, info->sechdrs, info->secstrings, ".modinfo");
info->index.pcpu = find_pcpusec(info->hdr, info->sechdrs, info->secstrings);

/* Check module struct version now, before we try to use module. */

2010-06-07 18:16:43

by Thadeu Lima de Souza Cascardo

[permalink] [raw]

Subject: RE: linux-next: Tree for June 3

> This time for sure!

Something very like that patch showed up in next-20100607 ... so
I took that for a spin. Everything seems tickety-boo. Modules get
loaded with no OOPSen. All my devices are found and working.

Thanks

-Tony

2010-06-09 20:02:25

[permalink] [raw]

Subject: Re: [PATCH -next] classmate-laptop: fix for RFKILL=m, CMPC=y

On Thu, Jun 03, 2010 at 09:39:03AM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> Fix build error when CONFIG_RFKILL=m and CONFIG_ACPI_CMPC=y:
> classmate-laptop should depend on RFKILL or RFKILL=n.
>
> classmate-laptop.c:(.text+0x1351fc): undefined reference to `rfkill_unregister'
> classmate-laptop.c:(.text+0x135204): undefined reference to `rfkill_destroy'
> classmate-laptop.c:(.text+0x135237): undefined reference to `rfkill_set_sw_state'
> classmate-laptop.c:(.text+0x1352b9): undefined reference to `rfkill_alloc'
> classmate-laptop.c:(.text+0x1352ca): undefined reference to `rfkill_register'
> classmate-laptop.c:(.text+0x1352d6): undefined reference to `rfkill_destroy'
>
> Signed-off-by: Randy Dunlap <[email protected]>
> ---

Randy,

Since this implies a build failure, shouldn't it be sent for rc too?

Best Regards,
Cascardo.

> drivers/platform/x86/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20100603.orig/drivers/platform/x86/Kconfig
> +++ linux-next-20100603/drivers/platform/x86/Kconfig
> @@ -520,6 +520,7 @@ config TOSHIBA_BT_RFKILL
> config ACPI_CMPC
> tristate "CMPC Laptop Extras"
> depends on X86 && ACPI
> + depends on RFKILL || RFKILL=n
> select INPUT
> select BACKLIGHT_CLASS_DEVICE
> default n

Attachments:

(No filename) (1.27 kB)
signature.asc (836.00 B)
Digital signature Download all attachments

2010-06-09 20:06:36