to: [email protected]
cc: [email protected]
2006/12/04/18:00 CST
Building modules, stage 2.
Kernel: arch/x86_64/boot/bzImage is ready (#2)
MODPOST 1256 modules
WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
xboom
[email protected] wrote:
> 2006/12/04/18:00 CST
>
> Building modules, stage 2.
> Kernel: arch/x86_64/boot/bzImage is ready (#2)
> MODPOST 1256 modules
> WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
Also i686, sparc64. At drivers/net/phy/phy.c:590 is the lone reference to
current_is_keventd in that directory. Still present as of ff51a9...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
On Mon, 4 Dec 2006, Horst H. von Brand wrote:
> [email protected] wrote:
> > 2006/12/04/18:00 CST
> >
> > Building modules, stage 2.
> > Kernel: arch/x86_64/boot/bzImage is ready (#2)
> > MODPOST 1256 modules
> > WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined!
> > make[1]: *** [__modpost] Error 1
> > make: *** [modules] Error 2
>
> Also i686, sparc64. At drivers/net/phy/phy.c:590 is the lone reference to
> current_is_keventd in that directory. Still present as of ff51a9...
Yeah, I'm waiting for this whole mess to be either explained or reverted.
There are apparently bigegr issues with it than just the butt-ugly
"current_is_keventd()" crud.
Linus
[email protected] wrote:
> to: [email protected]
> cc: [email protected]
>
> 2006/12/04/18:00 CST
>
> Building modules, stage 2.
> Kernel: arch/x86_64/boot/bzImage is ready (#2)
> MODPOST 1256 modules
> WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> xboom
Here's a patch with the easy fix, but I'm not certain it's a permanent fix.
Frank
This patch fixes a compile error when CONFIG_PHYLIB is a module.
Signed-off-by: Frank Sorenson <[email protected]>
---
kernel/workqueue.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.19-fs1/kernel/workqueue.c
===================================================================
--- linux-2.6.19-fs1.orig/kernel/workqueue.c 2006-12-04
22:21:06.000000000 -0600
+++ linux-2.6.19-fs1/kernel/workqueue.c 2006-12-04 22:59:55.000000000 -0600
@@ -608,6 +608,7 @@
return ret;
}
+EXPORT_SYMBOL_GPL(current_is_keventd);
#ifdef CONFIG_HOTPLUG_CPU
/* Take the work from this (downed) CPU. */
On Mon, 4 Dec 2006, Linus Torvalds wrote:
> > Also i686, sparc64. At drivers/net/phy/phy.c:590 is the lone reference to
> > current_is_keventd in that directory. Still present as of ff51a9...
>
> Yeah, I'm waiting for this whole mess to be either explained or reverted.
> There are apparently bigegr issues with it than just the butt-ugly
> "current_is_keventd()" crud.
I am very surprised indeed "the mess" has been applied at all in the
first place. The conclusion of the discussion a while ago was to sort out
the issue within libphy. The change should be reverted.
Maciej
>> > Also i686, sparc64. At drivers/net/phy/phy.c:590 is the lone reference to
>> > current_is_keventd in that directory. Still present as of ff51a9...
>>
>> Yeah, I'm waiting for this whole mess to be either explained or reverted.
>> There are apparently bigegr issues with it than just the butt-ugly
>> "current_is_keventd()" crud.
>
> I am very surprised indeed "the mess" has been applied at all in the
>first place. The conclusion of the discussion a while ago was to sort out
>the issue within libphy. The change should be reverted.
I am more surprised about that "the mess" has not been discovered so
far. Does no one go test compile an allyesconfig/allmodconfig before
actually releasing a kernel to the ftp?
-`J'
--