* modutils url for: Re: Linux v2.5.48
2002-11-18 4:41 Linux v2.5.48 Linus Torvalds
@ 2002-11-18 6:32 ` bert hubert
2002-11-18 6:57 ` William Lee Irwin III
` (5 subsequent siblings)
6 siblings, 0 replies; 15+ messages in thread
From: bert hubert @ 2002-11-18 6:32 UTC (permalink / raw)
To: Kernel Mailing List
On Sun, Nov 17, 2002 at 08:41:05PM -0800, Linus Torvalds wrote:
> Hmm.. All over the place, best you see the changelog. Lots of small
> cleanups (remove unnecessary header files etc), but a few more fundamental
> changes too. Times in nsecs in stat64(), for example, and the
> oft-discussed kernel module loader changes..
To get this to load modules, you need:
http://www.kernel.org/pub/linux/kernel/people/rusty/module-init-tools-0.7.tar.gz
Just to save you the searching.
Shameless plug: to play with the ipsec, see
http://lartc.org/howto/lartc.ipsec.html - should now work without further
patches!
Regards,
bert
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Linux v2.5.48
2002-11-18 4:41 Linux v2.5.48 Linus Torvalds
2002-11-18 6:32 ` modutils url for: " bert hubert
@ 2002-11-18 6:57 ` William Lee Irwin III
2002-11-18 7:19 ` William Lee Irwin III
2002-11-18 7:47 ` Martin J. Bligh
2002-11-18 9:08 ` Gabor Z. Papp
` (4 subsequent siblings)
6 siblings, 2 replies; 15+ messages in thread
From: William Lee Irwin III @ 2002-11-18 6:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
On Sun, Nov 17, 2002 at 08:41:05PM -0800, Linus Torvalds wrote:
> Hmm.. All over the place, best you see the changelog. Lots of small
> cleanups (remove unnecessary header files etc), but a few more fundamental
> changes too. Times in nsecs in stat64(), for example, and the
> oft-discussed kernel module loader changes..
This oopses on NUMA-Q sometime prior to TSC synch and then hangs in TSC
synch because not all cpus are responding where 2.5.47-mm3 (which
included some intermediate bk stuff) did not. This is because AP's are
taking timer interrupts before they are prepared to do so. Please apply
the following patch from Martin Bligh which resolves this issue:
Thanks,
Bill
diff -purN -X /home/mbligh/.diff.exclude virgin/arch/i386/kernel/smpboot.c noearlyirq/arch/i386/kernel/smpboot.c
--- virgin/arch/i386/kernel/smpboot.c Mon Nov 4 14:30:27 2002
+++ noearlyirq/arch/i386/kernel/smpboot.c Wed Nov 6 15:22:12 2002
@@ -419,6 +419,7 @@ void __init smp_callin(void)
smp_store_cpu_info(cpuid);
disable_APIC_timer();
+ local_irq_disable();
/*
* Allow the master to continue.
*/
@@ -1186,6 +1187,7 @@ int __devinit __cpu_up(unsigned int cpu)
if (!test_bit(cpu, &cpu_callin_map))
return -EIO;
+ local_irq_enable();
/* Unleash the CPU! */
set_bit(cpu, &smp_commenced_mask);
while (!test_bit(cpu, &cpu_online_map))
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Linux v2.5.48
2002-11-18 6:57 ` William Lee Irwin III
@ 2002-11-18 7:19 ` William Lee Irwin III
2002-11-18 7:47 ` Martin J. Bligh
1 sibling, 0 replies; 15+ messages in thread
From: William Lee Irwin III @ 2002-11-18 7:19 UTC (permalink / raw)
To: Linus Torvalds, Kernel Mailing List
On Sun, Nov 17, 2002 at 10:57:05PM -0800, William Lee Irwin III wrote:
> This oopses on NUMA-Q sometime prior to TSC synch and then hangs in TSC
> synch because not all cpus are responding where 2.5.47-mm3 (which
> included some intermediate bk stuff) did not. This is because AP's are
> taking timer interrupts before they are prepared to do so. Please apply
> the following patch from Martin Bligh which resolves this issue:
Actually, please apply this one instead. The prior patch did not
re-enable interrupts appropriately in its return paths (pointed out
by Andrew Morton):
diff -urpN linux-2.5.48/arch/i386/kernel/smpboot.c numaq-2.5.48/arch/i386/kernel/smpboot.c
--- linux-2.5.48/arch/i386/kernel/smpboot.c 2002-11-17 20:29:45.000000000 -0800
+++ numaq-2.5.48/arch/i386/kernel/smpboot.c 2002-11-17 22:35:05.000000000 -0800
@@ -419,6 +419,7 @@ void __init smp_callin(void)
smp_store_cpu_info(cpuid);
disable_APIC_timer();
+ local_irq_disable();
/*
* Allow the master to continue.
*/
@@ -1179,13 +1180,18 @@ void __init smp_prepare_cpus(unsigned in
int __devinit __cpu_up(unsigned int cpu)
{
/* This only works at boot for x86. See "rewrite" above. */
- if (test_bit(cpu, &smp_commenced_mask))
+ if (test_bit(cpu, &smp_commenced_mask)) {
+ local_irq_enable();
return -ENOSYS;
+ }
/* In case one didn't come up */
- if (!test_bit(cpu, &cpu_callin_map))
+ if (!test_bit(cpu, &cpu_callin_map)) {
+ local_irq_enable();
return -EIO;
+ }
+ local_irq_enable();
/* Unleash the CPU! */
set_bit(cpu, &smp_commenced_mask);
while (!test_bit(cpu, &cpu_online_map))
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Linux v2.5.48
2002-11-18 6:57 ` William Lee Irwin III
2002-11-18 7:19 ` William Lee Irwin III
@ 2002-11-18 7:47 ` Martin J. Bligh
2002-11-18 7:55 ` William Lee Irwin III
1 sibling, 1 reply; 15+ messages in thread
From: Martin J. Bligh @ 2002-11-18 7:47 UTC (permalink / raw)
To: William Lee Irwin III, Linus Torvalds; +Cc: Kernel Mailing List
> This oopses on NUMA-Q sometime prior to TSC synch and then hangs in TSC
> synch because not all cpus are responding where 2.5.47-mm3 (which
> included some intermediate bk stuff) did not. This is because AP's are
> taking timer interrupts before they are prepared to do so. Please apply
> the following patch from Martin Bligh which resolves this issue:
It seems to come and go randomly (timing issue), it's not new with 48.
Has been happening since 44-mm3 or so. Just as a point of interest,
doesn't seem to be the timer int itself that kill her, it's the
softirq processing that happens in irq_exit on the way back.
M.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Linux v2.5.48
2002-11-18 7:47 ` Martin J. Bligh
@ 2002-11-18 7:55 ` William Lee Irwin III
0 siblings, 0 replies; 15+ messages in thread
From: William Lee Irwin III @ 2002-11-18 7:55 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Linus Torvalds, Kernel Mailing List
At some point in the past, my attribution was stripped from this comment:
>> This oopses on NUMA-Q sometime prior to TSC synch and then hangs in TSC
>> synch because not all cpus are responding where 2.5.47-mm3 (which
>> included some intermediate bk stuff) did not. This is because AP's are
>> taking timer interrupts before they are prepared to do so. Please apply
>> the following patch from Martin Bligh which resolves this issue:
On Sun, Nov 17, 2002 at 11:47:12PM -0800, Martin J. Bligh wrote:
> It seems to come and go randomly (timing issue), it's not new with 48.
> Has been happening since 44-mm3 or so. Just as a point of interest,
> doesn't seem to be the timer int itself that kill her, it's the
> softirq processing that happens in irq_exit on the way back.
This is all the more ammunition for the patch's inclusion. Linus, this
problem is even more severe and more persistent than I originally reported.
Please apply.
Thanks,
Bill
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Linux v2.5.48
2002-11-18 4:41 Linux v2.5.48 Linus Torvalds
2002-11-18 6:32 ` modutils url for: " bert hubert
2002-11-18 6:57 ` William Lee Irwin III
@ 2002-11-18 9:08 ` Gabor Z. Papp
2002-11-18 12:37 ` Adrian Bunk
` (3 subsequent siblings)
6 siblings, 0 replies; 15+ messages in thread
From: Gabor Z. Papp @ 2002-11-18 9:08 UTC (permalink / raw)
To: linux-kernel
gcc 2.95.4
GNU ld version 2.12.90.0.15 20020717
make -f scripts/Makefile.build obj=fs/devfs
gcc -Wp,-MD,fs/devfs/.base.o.d -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -Iarch/i386/mach-generic -nostdinc -iwithprefix include -DKBUILD_BASENAME=base -DKBUILD_MODNAME=devfs -DEXPORT_SYMTAB -c -o fs/devfs/base.o fs/devfs/base.c
fs/devfs/base.c: In function `devfs_symlink':
fs/devfs/base.c:3032: incompatible types in assignment
fs/devfs/base.c:3033: incompatible types in assignment
fs/devfs/base.c:3034: incompatible types in assignment
fs/devfs/base.c: In function `devfs_mkdir':
fs/devfs/base.c:3063: incompatible types in assignment
fs/devfs/base.c:3064: incompatible types in assignment
fs/devfs/base.c:3065: incompatible types in assignment
fs/devfs/base.c: In function `devfs_mknod':
fs/devfs/base.c:3132: incompatible types in assignment
fs/devfs/base.c:3133: incompatible types in assignment
fs/devfs/base.c:3134: incompatible types in assignment
make[3]: *** [fs/devfs/base.o] Error 1
make[2]: *** [fs/devfs] Error 2
make[1]: *** [fs] Error 2
make: *** [vmlinux] Error 2
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Linux v2.5.48
2002-11-18 4:41 Linux v2.5.48 Linus Torvalds
` (2 preceding siblings ...)
2002-11-18 9:08 ` Gabor Z. Papp
@ 2002-11-18 12:37 ` Adrian Bunk
2002-11-18 18:33 ` Udo A. Steinberg
` (2 subsequent siblings)
6 siblings, 0 replies; 15+ messages in thread
From: Adrian Bunk @ 2002-11-18 12:37 UTC (permalink / raw)
To: Linus Torvalds, Alexander Viro; +Cc: Kernel Mailing List, bcollins
On Sun, Nov 17, 2002 at 08:41:05PM -0800, Linus Torvalds wrote:
>...
> Summary of changes from v2.5.47 to v2.5.48
> ============================================
>...
> Alexander Viro <viro@math.psu.edu>:
>...
> o dv1394 devfs use
>...
This patch broke the compilation of dv1394:
<-- snip -->
...
gcc -Wp,-MD,drivers/ieee1394/.dv1394.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=k6 -Iarch/i386/mach-generic -nostdinc -iwithprefix include
-DKBUILD_BASENAME=dv1394 -DKBUILD_MODNAME=dv1394 -c -o
drivers/ieee1394/dv1394.o drivers/ieee1394/dv1394.c
drivers/ieee1394/dv1394.c:2586: parse error before `return'
make[2]: *** [drivers/ieee1394/dv1394.o] Error 1
<-- snip -->
The fix is trivial:
--- linux-2.5.48/drivers/ieee1394/dv1394.c.old 2002-11-18 13:32:02.000000000 +0100
+++ linux-2.5.48/drivers/ieee1394/dv1394.c 2002-11-18 13:35:55.000000000 +0100
@@ -2579,7 +2579,7 @@
static int dv1394_devfs_add_dir(char *name)
{
- if (!devfs_mk_dir(NULL, name, NULL))
+ if (!devfs_mk_dir(NULL, name, NULL)) {
printk(KERN_ERR "dv1394: unable to create /dev/%s\n", name);
return -ENOMEM;
}
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Linux v2.5.48
2002-11-18 4:41 Linux v2.5.48 Linus Torvalds
` (3 preceding siblings ...)
2002-11-18 12:37 ` Adrian Bunk
@ 2002-11-18 18:33 ` Udo A. Steinberg
2002-11-19 5:13 ` Linus Torvalds
2002-11-19 11:20 ` modutils url for: " Allan Duncan
2002-11-26 23:15 ` Adrian Bunk
6 siblings, 1 reply; 15+ messages in thread
From: Udo A. Steinberg @ 2002-11-18 18:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
On Sun, 17 Nov 2002 20:41:05 -0800 (PST) Linus Torvalds (LT) wrote:
Hi Linus,
2.5.48 broke completely monolithic kernels.
ld -m elf_i386 -e stext -T arch/i386/vmlinux.lds.s arch/i386/kernel/head.o
arch/i386/kernel/init_task.o init/built-in.o --start-group usr/built-in.o
arch/i386/kernel/built-in.o arch/i386/mm/built-in.o arch/i386/mach-generic/built-in.o
kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o
crypto/built-in.o lib/lib.a arch/i386/lib/lib.a drivers/built-in.o sound/built-in.o
arch/i386/pci/built-in.o net/built-in.o --end-group -o vmlinux
init/built-in.o(.init.text+0x684): In function `start_kernel':
: undefined reference to `extable_init'
make: *** [vmlinux] Error 1
#
# Loadable module support
#
# CONFIG_MODULES is not set
If module support is enabled, the thing links beautifully.
Regards,
-Udo.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Linux v2.5.48
2002-11-18 18:33 ` Udo A. Steinberg
@ 2002-11-19 5:13 ` Linus Torvalds
0 siblings, 0 replies; 15+ messages in thread
From: Linus Torvalds @ 2002-11-19 5:13 UTC (permalink / raw)
To: Udo A. Steinberg; +Cc: linux-kernel
On Mon, 18 Nov 2002, Udo A. Steinberg wrote:
>
> 2.5.48 broke completely monolithic kernels.
Ok, this should be fixed in current -bk (snapshots will be built at 4AM
PST as usual, so they should show up reasonably soon).
I also merged/updated the old kallsyms fixups from Rusty, so together with
the updated module loader we should be back to "working order" both
without and with modules and not missing any features.
Please test,
Linus
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: modutils url for: Re: Linux v2.5.48
2002-11-18 4:41 Linux v2.5.48 Linus Torvalds
` (4 preceding siblings ...)
2002-11-18 18:33 ` Udo A. Steinberg
@ 2002-11-19 11:20 ` Allan Duncan
2002-11-26 23:15 ` Adrian Bunk
6 siblings, 0 replies; 15+ messages in thread
From: Allan Duncan @ 2002-11-19 11:20 UTC (permalink / raw)
To: linux-kernel
bert hubert wrote:
> On Sun, Nov 17, 2002 at 08:41:05PM -0800, Linus Torvalds wrote:
>
>
> >Hmm.. All over the place, best you see the changelog. Lots of small
> >cleanups (remove unnecessary header files etc), but a few more fundamental
> >changes too. Times in nsecs in stat64(), for example, and the
> >oft-discussed kernel module loader changes..
>
>
> To get this to load modules, you need:
> http://www.kernel.org/pub/linux/kernel/people/rusty/module-init-tools-0.7.tar.gz
Does this then make depmod happy?
Without it I get heaps of (eg)
depmod: *** Unresolved symbols in /lib/modules/2.5.48/kernel/zlib_deflate.o
I tried applying Adam Richter's module device ID tables patch without success.
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_KMOD=y
Turning off KMOD, or turning on UNLOAD makes no difference.
depmod version 2.4.18 I tried the latest 2.4.21 as well.
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Linux v2.5.48
2002-11-18 4:41 Linux v2.5.48 Linus Torvalds
` (5 preceding siblings ...)
2002-11-19 11:20 ` modutils url for: " Allan Duncan
@ 2002-11-26 23:15 ` Adrian Bunk
2002-11-26 23:49 ` Randy.Dunlap
6 siblings, 1 reply; 15+ messages in thread
From: Adrian Bunk @ 2002-11-26 23:15 UTC (permalink / raw)
To: Linus Torvalds, Alexey Kuznetsov; +Cc: Kernel Mailing List
On Sun, Nov 17, 2002 at 08:41:05PM -0800, Linus Torvalds wrote:
>...
> Summary of changes from v2.5.47 to v2.5.48
> ============================================
>...
> Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>:
> o [IPSEC]: More fixes and corrections
>...
The following part of this patch looks bogus:
<-- snip -->
--- 1.6/net/key/af_key.c Fri Nov 8 00:34:37 2002
+++ 1.7/net/key/af_key.c Mon Nov 11 01:03:55 2002
...
@@ -2179,7 +2223,7 @@
if (skb)
kfree_skb(skb);
- return err;
+ return err ? : len;
}
static int pfkey_recvmsg(struct kiocb *kiocb,
<-- snip -->
Is the following correct to fix it?
--- linux/net/key/af_key.c.old 2002-11-27 00:12:28.000000000 +0100
+++ linux/net/key/af_key.c 2002-11-27 00:12:40.000000000 +0100
@@ -2242,7 +2242,7 @@
if (skb)
kfree_skb(skb);
- return err ? : len;
+ return err ? err : len;
}
static int pfkey_recvmsg(struct kiocb *kiocb,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Linux v2.5.48
2002-11-26 23:15 ` Adrian Bunk
@ 2002-11-26 23:49 ` Randy.Dunlap
2002-11-27 0:42 ` kuznet
2002-11-27 0:53 ` Adrian Bunk
0 siblings, 2 replies; 15+ messages in thread
From: Randy.Dunlap @ 2002-11-26 23:49 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Linus Torvalds, Alexey Kuznetsov, Kernel Mailing List
On Wed, 27 Nov 2002, Adrian Bunk wrote:
| On Sun, Nov 17, 2002 at 08:41:05PM -0800, Linus Torvalds wrote:
|
| >...
| > Summary of changes from v2.5.47 to v2.5.48
| > ============================================
| >...
| > Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>:
| > o [IPSEC]: More fixes and corrections
| >...
|
| The following part of this patch looks bogus:
|
| <-- snip -->
|
| --- 1.6/net/key/af_key.c Fri Nov 8 00:34:37 2002
| +++ 1.7/net/key/af_key.c Mon Nov 11 01:03:55 2002
| ...
| @@ -2179,7 +2223,7 @@
| if (skb)
| kfree_skb(skb);
|
| - return err;
| + return err ? : len;
| }
|
| static int pfkey_recvmsg(struct kiocb *kiocb,
|
| <-- snip -->
|
|
| Is the following correct to fix it?
|
|
| --- linux/net/key/af_key.c.old 2002-11-27 00:12:28.000000000 +0100
| +++ linux/net/key/af_key.c 2002-11-27 00:12:40.000000000 +0100
| @@ -2242,7 +2242,7 @@
| if (skb)
| kfree_skb(skb);
|
| - return err ? : len;
| + return err ? err : len;
| }
|
| static int pfkey_recvmsg(struct kiocb *kiocb,
Hi Adrian,
That's a gcc extension that means the same as your patch. See
http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Conditionals.html#Conditionals
It would be OK with me not to accept such extensions. :)
--
~Randy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Linux v2.5.48
2002-11-26 23:49 ` Randy.Dunlap
@ 2002-11-27 0:42 ` kuznet
2002-11-27 0:53 ` Adrian Bunk
1 sibling, 0 replies; 15+ messages in thread
From: kuznet @ 2002-11-27 0:42 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: bunk, torvalds, linux-kernel
Hello!
> It would be OK with me not to accept such extensions. :)
One of a few of extensions which does not cause any reaction
but "it's strange that it was not in KR, apparently it was lost
due to a buglet in the first parser" :-)
Alexey
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Linux v2.5.48
2002-11-26 23:49 ` Randy.Dunlap
2002-11-27 0:42 ` kuznet
@ 2002-11-27 0:53 ` Adrian Bunk
1 sibling, 0 replies; 15+ messages in thread
From: Adrian Bunk @ 2002-11-27 0:53 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Linus Torvalds, Alexey Kuznetsov, Kernel Mailing List
On Tue, Nov 26, 2002 at 03:49:11PM -0800, Randy.Dunlap wrote:
> On Wed, 27 Nov 2002, Adrian Bunk wrote:
>...
> | - return err;
> | + return err ? : len;
>...
> Hi Adrian,
>
> That's a gcc extension that means the same as your patch. See
> http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Conditionals.html#Conditionals
>...
Ah, thanks for the correction. I didn't know that there is such a gcc
extension.
> ~Randy
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 15+ messages in thread