Skip to contentSkip to conversation

Add CONFIG for -mregparm=3

PATCH In review Andi Kleen 10 participants 23 messages Jan 14, 2004 – Jan 19, 2004

lore
Share & tools
lore

Andi Kleen

author
#0 lore raw

PATCH 1/1 Add CONFIG for -mregparm=3

Using -mregparm=3 shrinks the kernel further:

(compiled with gcc 3.4, without -funit-at-a-time, using the later and together with -Os shrinks .text even more, making over 700KB difference)

4129346  708629  207240 5045215  4cfbdf vmlinux
3892905  708629  207240 4808774  496046 vmlinux-regparm

This one helps even more, >236KB .text difference. Clearly worth the effort.

This patch adds an option to use -mregparm=3 while compiling the kernel. I did an LTP run and it showed no additional failures over an non regparm kernel.

According to some gcc developers it should be safe to use in all gccs that are still supports (2.95 and up)

I didn't make it the default because it will break all binary only modules (although they can be fixed by adding a wrapper that calls them with "asmlinkage"). Actually it may be a good idea to make this default with 2.7.1 or somesuch.

arch/i386/Kconfig renamed from arch/i386/Kconfig-o +8 -0
diff -u linux-34/arch/i386/Kconfig-o linux-34/arch/i386/Kconfig
@@ -820,6 +820,14 @@
 	depends on (((X86_SUMMIT || X86_GENERICARCH) && NUMA) || (X86 && EFI))
 	default y
 
+config REGPARM
+	bool "Use register arguments (EXPERIMENTAL)"
+	default n
+	help
+	Compile the kernel with -mregparm=3. This uses an different ABI
+	and passes the first three arguments of a function call in registers.
+	This will probably break binary only modules.	
+	
 endmenu
arch/i386/Makefile renamed from arch/i386/Makefile-o +2 -0
diff -u linux-34/arch/i386/Makefile-o linux-34/arch/i386/Makefile
@@ -47,6 +47,8 @@
 cflags-$(CONFIG_MCYRIXIII)	+= $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
 cflags-$(CONFIG_MVIAC3_2)	+= $(call check_gcc,-march=c3-2,-march=i686)
 
+cflags-$(CONFIG_REGPARM) 	+= -mregparm=3
+
 CFLAGS += $(cflags-y)
 
 # Default subarch .c files
#1 lore raw
Quoted 1 line · Andi Kleen

Using -mregparm=3 shrinks the kernel further:

Note that there is a dependence on this patch - as highlighted by Arjan, CardServices() breaks when built on x86 with -mregparm.

Therefore, the CardServices() patches need to be merged into any tree prior to this patch.

Signature · 4 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core
#2 lore raw
Quoted 8 lines · Russell King
Quoted 1 line · Andi Kleen

Using -mregparm=3 shrinks the kernel further:

Note that there is a dependence on this patch - as highlighted by Arjan, CardServices() breaks when built on x86 with -mregparm.

Therefore, the CardServices() patches need to be merged into any tree prior to this patch.

Ah, because of the broken prototypes again?

You could just mark them all asmlinkage to force stack arguments.

Or just fix the prototypes.

-Andi

#3 lore raw
In reply to Andi Kleen
Quoted 5 lines · Andi Kleen

I didn't make it the default because it will break all binary only modules (although they can be fixed by adding a wrapper that calls them with "asmlinkage"). Actually it may be a good idea to make this default with 2.7.1 or somesuch.

yes, that is a hassle. But for these sorts of gains, it's worth pursuing it a bit further.

How _much_ of a hassle it will be I can not say - I'd be looking to vendors to advise before merging this into mainline.

I changed your patch to make it dependent on CONFIG_EXPERIMENTAL.

#4 lore raw
Quoted 11 lines · Andrew Morton
Quoted 5 lines · Andi Kleen

I didn't make it the default because it will break all binary only modules (although they can be fixed by adding a wrapper that calls them with "asmlinkage"). Actually it may be a good idea to make this default with 2.7.1 or somesuch.

yes, that is a hassle. But for these sorts of gains, it's worth pursuing it a bit further.

How _much_ of a hassle it will be I can not say - I'd be looking to vendors

I think the popular modules like nvidia or ATI could be fixed relatively easily. They usually consist of a glue layer with source and a binary blob that is only called from the glue layer. Basically all you have to do is the mark the prototypes for the binary blob in the glue layer as "asmlinkage". In addition this can be done without any ifdefs because asmlinkage does the right thing on a non regparm kernel.

Of course true binary only modules without glue layer would be more difficult, but for those the vendors just have to recompile. Conceivable it would be possible to write a glue layer even for them.

Quoted 1 line

to advise before merging this into mainline.

I'm not sure why vendors should care as long as it's only a CONFIG_*.

The option is clearly more aimed at "kernel self compiler operators" for now.

-Andi

#5 lore raw
Quoted 8 lines · Andi Kleen

...
I think the popular modules like nvidia or ATI could be fixed relatively easily. They usually consist of a glue layer with source and a binary blob that is only called from the glue layer. Basically all you have to do is the mark the prototypes for the binary blob in the glue layer as "asmlinkage". In addition this can be done without any ifdefs because asmlinkage does the right thing on a non regparm kernel.

Quoted 4 lines

Of course true binary only modules without glue layer would be more difficult, but for those the vendors just have to recompile. Conceivable it would be possible to write a glue layer even for them.
...

Did I miss Linus announcing a stable ABI between kernel versions?

If some binary module vendor tries to support more than one kernel version it's his problem - this is nothing that is officially supported by the Linux kernel.

Quoted 1 line

-Andi

cu
Adrian

Signature · 4 lines
       "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
#6 lore raw
Quoted 14 lines · Adrian Bunk
Quoted 8 lines · Andi Kleen

...
I think the popular modules like nvidia or ATI could be fixed relatively easily. They usually consist of a glue layer with source and a binary blob that is only called from the glue layer. Basically all you have to do is the mark the prototypes for the binary blob in the glue layer as "asmlinkage". In addition this can be done without any ifdefs because asmlinkage does the right thing on a non regparm kernel.

Quoted 4 lines

Of course true binary only modules without glue layer would be more difficult, but for those the vendors just have to recompile. Conceivable it would be possible to write a glue layer even for them.
...

Quoted 5 lines

Did I miss Linus announcing a stable ABI between kernel versions?

If some binary module vendor tries to support more than one kernel version it's his problem - this is nothing that is officially supported by the Linux kernel.

agreed.

this is the sort of stuff that shouldn't be a config option, it exercises new paths in gcc as well, _all_ the userbase has to use it, or it's not worth the risk/pain IMHO.

#7 lore raw
In reply to Andrew Morton
Quoted 2 lines · Andrew Morton

How _much_ of a hassle it will be I can not say - I'd be looking to vendors to advise before merging this into mainline.

I am compiling my kernel rpms with this already and have the full intention to keep doing that into production.

#8 lore raw
In reply to Andi Kleen
Quoted 3 lines · Andi Kleen

According to some gcc developers it should be safe to use in all gccs that are still supports (2.95 and up)

it is not safe for the kernel until the cardbus CardServices patches get merged (is in -mm), for the same reason CardServices() is broken on amd64.

#9 lore raw
Quoted 9 lines · Arjan van de Ven
Quoted 3 lines · Andi Kleen

According to some gcc developers it should be safe to use in all gccs that are still supports (2.95 and up)

it is not safe for the kernel until the cardbus CardServices patches get merged (is in -mm), for the same reason CardServices() is broken on amd64.

Just mark them asmlinkage then.

I would be a shame to leave that much space saving on the table just for an single misdesigned API than can be easily fixed.

-Andi

#10 lore raw
Quoted 7 lines · Andi Kleen
Quoted 6 lines · Arjan van de Ven
Quoted 3 lines · Andi Kleen

According to some gcc developers it should be safe to use in all gccs that are still supports (2.95 and up)

Quoted 8 lines
Quoted 3 lines

it is not safe for the kernel until the cardbus CardServices patches get merged (is in -mm), for the same reason CardServices() is broken on amd64.

Just mark them asmlinkage then.

I would be a shame to leave that much space saving on the table just for an single misdesigned API than can be easily fixed.

Oh I rather just fix the API period... :)
Patches exist and work excellent for me.

#11 lore raw
In reply to Arjan van de Ven
Quoted 10 lines · Arjan van de Ven
Quoted 3 lines · Andi Kleen

According to some gcc developers it should be safe to use in all gccs that are still supports (2.95 and up)

it is not safe for the kernel until the cardbus CardServices patches get merged (is in -mm), for the same reason CardServices() is broken on amd64.

The CardServices API migration work is complete. It'll probaby appear in 2.6.2.

#12 lore raw
In reply to Andi Kleen
Quoted 4 lines · On Wed, 14 Jan 2004 10:06:03 +0100 Andi Kleen <[email protected]> wrote:

I didn't make it the default because it will break all binary only modules (although they can be fixed by adding a wrapper that calls them with "asmlinkage"). Actually it may be a good idea to make this default with 2.7.1 or somesuch.

Who cares. Anyway, if kept as a config option, this should probably be added to MODULE_ARCH_VERMAGIC in include/asm-i386/module.h.

Thanks,
Rusty.

Signature · 2 lines
   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy
#13 lore raw
Quoted 9 lines · Rusty Russell
Quoted 4 lines · On Wed, 14 Jan 2004 10:06:03 +0100 Andi Kleen <[email protected]> wrote:

I didn't make it the default because it will break all binary only modules (although they can be fixed by adding a wrapper that calls them with "asmlinkage"). Actually it may be a good idea to make this default with 2.7.1 or somesuch.

Who cares. Anyway, if kept as a config option, this should probably be added to MODULE_ARCH_VERMAGIC in include/asm-i386/module.h.

Ok. Good point.

On second thought I'm actually not opposed to make it the default, but Linus/Andrew have to decide if they want this. It certainly would be a good strategy longer term (even though it would eliminate some of the advantages x86-64 currently enjoys over i386 ;-)

New patch appended.

-Andi

----------------------------------------

Add CONFIG_REGPARM option to enable compilation with -mregparm=3. This shrinks the kernel .text considerably.

This could be made default later when it has been more tested.

arch/i386/Kconfig renamed from arch/i386/Kconfig-o +8 -0
diff -u linux-34/arch/i386/Kconfig-o linux-34/arch/i386/Kconfig
@@ -820,6 +820,14 @@
 	depends on (((X86_SUMMIT || X86_GENERICARCH) && NUMA) || (X86 && EFI))
 	default y
 
+config REGPARM
+	bool "Use register arguments (EXPERIMENTAL)"
+	default n
+	help
+	Compile the kernel with -mregparm=3. This uses an different ABI
+	and passes the first three arguments of a function call in registers.
+	This will probably break binary only modules.	
+	
 endmenu
arch/i386/Makefile renamed from arch/i386/Makefile-o +2 -0
diff -u linux-34/arch/i386/Makefile-o linux-34/arch/i386/Makefile
@@ -47,6 +47,8 @@
 cflags-$(CONFIG_MCYRIXIII)	+= $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
 cflags-$(CONFIG_MVIAC3_2)	+= $(call check_gcc,-march=c3-2,-march=i686)
 
+cflags-$(CONFIG_REGPARM) 	+= -mregparm=3
+
 CFLAGS += $(cflags-y)
 
 # Default subarch .c files
include/asm-i386/module.h renamed from include/asm-i386/module.h-o +7 -1
diff -u linux-34/include/asm-i386/module.h-o linux-34/include/asm-i386/module.h
@@ -52,6 +52,12 @@
 #error unknown processor family
 #endif
 
-#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY
+#ifdef CONFIG_REGPARM
+#define MODULE_REGPARM "REGPARM "
+#else
+#define MODULE_REGPARM "" 
+#endif
+
+#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM
 
 #endif /* _ASM_I386_MODULE_H */
#14 lore raw

several oopses during boot (was: Re: [PATCH] Add CONFIG for -mregparm=3)

In reply to Andi Kleen

Hi Andi and Andrew,

Andi Kleen wrote (ao):

Quoted 1 line

Using -mregparm=3 shrinks the kernel further:

...

Quoted 11 lines

This patch adds an option to use -mregparm=3 while compiling the kernel. I did an LTP run and it showed no additional failures over an non regparm kernel.

According to some gcc developers it should be safe to use in all gccs that are still supports (2.95 and up)

I didn't make it the default because it will break all binary only modules (although they can be fixed by adding a wrapper that calls them with "asmlinkage"). Actually it may be a good idea to make this default with 2.7.1 or somesuch.

...

arch/i386/Kconfig line 829

Quoted 7 lines
arch/i386/Kconfig renamed from arch/i386/Kconfig-o +7 -0
+config REGPARM
+	bool "Use register arguments (EXPERIMENTAL)"
+	default n
+	help
+	Compile the kernel with -mregparm=3. This uses an different ABI
+	and passes the first three arguments of a function call in registers.
+	This will probably break binary only modules.

This gives several oopses on my system during boot, after which is seems dead.

2.6.1-mm4
VIA C3 Ezra

It mounts its root filesystem over nfs and has netconsole compiled in.

Without the REGPARM option the system boots and runs fine.

Should I post the oopses, the result of ksymoops, a dmesg and kernel config or is this an already known issue?

Kind regards, Sander

Signature · 2 lines
Humilis IT Services and Solutions
http://www.humilis.net
#15 lore raw

Re: several oopses during boot (was: Re: [PATCH] Add CONFIG for -mregparm=3)

Quoted 1 line

2.6.1-mm4

Note that this kernel is broken on gcc 3.4 and on 3.3-hammer. If you're using that disable the -funit-at-a-time setting in the main Makefile.

Quoted 8 lines

VIA C3 Ezra

It mounts its root filesystem over nfs and has netconsole compiled in.

Without the REGPARM option the system boots and runs fine.

Should I post the oopses, the result of ksymoops, a dmesg and kernel config or is this an already known issue?

Not known. Please post the decoded oopses. Also give your compiler version.

-Andi

#16 lore raw

Re: several oopses during boot (was: Re: [PATCH] Add CONFIG for -mregparm=3)

Andi Kleen wrote (ao):

Quoted 11 lines
Quoted 1 line

2.6.1-mm4

Note that this kernel is broken on gcc 3.4 and on 3.3-hammer. If you're using that disable the -funit-at-a-time setting in the main Makefile.

Quoted 5 lines

VIA C3 Ezra

It mounts its root filesystem over nfs and has netconsole compiled in.

Quoted 7 lines
Quoted 4 lines

Without the REGPARM option the system boots and runs fine.

Should I post the oopses, the result of ksymoops, a dmesg and kernel config or is this an already known issue?

Not known. Please post the decoded oopses. Also give your compiler version.

Hope this helps. The system runs fine with the option disabled.

gcc (GCC) 3.3.3 20040110 (prerelease) (Debian)

I ran ksymoops on another system, but used the vmlinux and System.map from the mentioned oopsing system.

The full output is very long (3657 lines), so I only post the fist 100 or so lines. Do you need them all?

ksymoops 2.4.9 on i686 2.6.0-test11. Options used
-v /tmp/vmlinux (specified)
-K (specified)
-L (specified)
-O (specified)
-m /tmp/System.map (specified)

Unable to handle kernel paging request at virtual address 249579f8
c012c19d
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI

Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: c1557940 ebx: c1554000 ecx: c1557a4c edx: c1557990
esi: 0000000d edi: bffffaa0 ebp: c1554000 esp: c1555fb8
ds: 007b es: 007b ss: 0068

Stack: bffffba0 bffffb20 c02a01d7 bffffba0 00002323 23232323 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000202 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb
Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8

Warning (Oops_code): trailing garbage ignored on Code: line
Text: 'Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8'
Garbage: 'Unable to handle kernel paging request at virtual address 249579f8'
Error (Oops_code_values): invalid value 0x1 in Code line, must be 2, 4, 8 or 16 digits, value ignored

Quoted 8 lines
Quoted 8 lines

EIP; c012c19d <sys_setsid+7d/a0> <=====

eax; c1557940 <_end+119d158/3fc42818>
ebx; c1554000 <_end+1199818/3fc42818>
ecx; c1557a4c <_end+119d264/3fc42818>
edx; c1557990 <_end+119d1a8/3fc42818>
ebp; c1554000 <_end+1199818/3fc42818>
esp; c1555fb8 <_end+119b7d0/3fc42818>

Trace; c02a01d7 <syscall_call+7/b>

This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt.

Code; c012c18a <sys_setsid+6a/a0>
00000000 <_EIP>:
Code; c012c18a <sys_setsid+6a/a0>
0: 00 00 add %al,(%eax)
Code; c012c18c <sys_setsid+6c/a0>
2: 52 push %edx
Code; c012c18d <sys_setsid+6d/a0>
3: 8b 80 88 00 00 00 mov 0x88(%eax),%eax
Code; c012c193 <sys_setsid+73/a0>
9: 50 push %eax
Code; c012c194 <sys_setsid+74/a0>
a: e8 0f 49 ff ff call ffff491e <_EIP+0xffff491e>
Code; c012c199 <sys_setsid+79/a0>
f: 5e pop %esi
Code; c012c19a <sys_setsid+7a/a0>
10: 58 pop %eax
Code; c012c19b <sys_setsid+7b/a0>
11: 8b 03 mov (%ebx),%eax

This decode from eip onwards should be reliable

Code; c012c19d <sys_setsid+7d/a0>
00000000 <_EIP>:

c012c19d
*pde = 00000000

Oops: 0000 [#2]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI
EFLAGS: 00010046
eax: c1557940   ebx: c1554000   ecx: c1557a4c   edx: c1557990
esi: 0000000e   edi: bffffaa0   ebp: c1554000   esp: c1555fb8
ds: 007b   es: 007b   ss: 0068
Stack: bffffba0 bffffb20 c02a01d7 bffffba0 61630053 32323232 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000246 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb
Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8

Warning (Oops_code): trailing garbage ignored on Code: line
Text: 'Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8'
Garbage: 'Unable to handle kernel paging request at virtual address 249579f8'
Error (Oops_code_values): invalid value 0x1 in Code line, must be 2, 4, 8 or 16 digits, value ignored

Quoted 8 lines
Quoted 8 lines

EIP; c012c19d <sys_setsid+7d/a0> <=====

eax; c1557940 <_end+119d158/3fc42818>
ebx; c1554000 <_end+1199818/3fc42818>
ecx; c1557a4c <_end+119d264/3fc42818>
edx; c1557990 <_end+119d1a8/3fc42818>
ebp; c1554000 <_end+1199818/3fc42818>
esp; c1555fb8 <_end+119b7d0/3fc42818>

Trace; c02a01d7 <syscall_call+7/b>

This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt.

Code; c012c18a <sys_setsid+6a/a0>
00000000 <_EIP>:
Code; c012c18a <sys_setsid+6a/a0>
0: 00 00 add %al,(%eax)
Code; c012c18c <sys_setsid+6c/a0>
2: 52 push %edx
Code; c012c18d <sys_setsid+6d/a0>
3: 8b 80 88 00 00 00 mov 0x88(%eax),%eax
Code; c012c193 <sys_setsid+73/a0>
9: 50 push %eax
Code; c012c194 <sys_setsid+74/a0>
a: e8 0f 49 ff ff call ffff491e <_EIP+0xffff491e>
Code; c012c199 <sys_setsid+79/a0>
f: 5e pop %esi
Code; c012c19a <sys_setsid+7a/a0>
10: 58 pop %eax
Code; c012c19b <sys_setsid+7b/a0>
11: 8b 03 mov (%ebx),%eax

This decode from eip onwards should be reliable

Code; c012c19d <sys_setsid+7d/a0>
00000000 <_EIP>:

c012c19d
*pde = 00000000

Oops: 0000 [#3]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI
EFLAGS: 00010046
eax: c1557940   ebx: c1554000   ecx: c1557a4c   edx: c1557990
esi: 0000000f   edi: bffffaa0   ebp: c1554000   esp: c1555fb8
ds: 007b   es: 007b   ss: 0068
Stack: bffffba0 bffffb20 c02a01d7 bffffba0 61630053 32323232 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000246 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb
Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8

Warning (Oops_code): trailing garbage ignored on Code: line
Text: 'Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8'
Garbage: 'Unable to handle kernel paging request at virtual address 249579f8'
Error (Oops_code_values): invalid value 0x1 in Code line, must be 2, 4, 8 or 16 digits, value ignored

Quoted 8 lines
Quoted 8 lines

EIP; c012c19d <sys_setsid+7d/a0> <=====

eax; c1557940 <_end+119d158/3fc42818>
ebx; c1554000 <_end+1199818/3fc42818>
ecx; c1557a4c <_end+119d264/3fc42818>
edx; c1557990 <_end+119d1a8/3fc42818>
ebp; c1554000 <_end+1199818/3fc42818>
esp; c1555fb8 <_end+119b7d0/3fc42818>

Trace; c02a01d7 <syscall_call+7/b>

This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt.

Code; c012c18a <sys_setsid+6a/a0>
00000000 <_EIP>:
Code; c012c18a <sys_setsid+6a/a0>
0: 00 00 add %al,(%eax)
Code; c012c18c <sys_setsid+6c/a0>
2: 52 push %edx
Code; c012c18d <sys_setsid+6d/a0>
3: 8b 80 88 00 00 00 mov 0x88(%eax),%eax
Code; c012c193 <sys_setsid+73/a0>
9: 50 push %eax
Code; c012c194 <sys_setsid+74/a0>
a: e8 0f 49 ff ff call ffff491e <_EIP+0xffff491e>
Code; c012c199 <sys_setsid+79/a0>
f: 5e pop %esi
Code; c012c19a <sys_setsid+7a/a0>
10: 58 pop %eax
Code; c012c19b <sys_setsid+7b/a0>
11: 8b 03 mov (%ebx),%eax

Signature · 2 lines
Humilis IT Services and Solutions
http://www.humilis.net
#17 lore raw

Re: several oopses during boot (was: Re: [PATCH] Add CONFIG for -mregparm=3)

Quoted 14 lines · Sander

Andi Kleen wrote (ao):

Quoted 13 lines
Quoted 1 line

2.6.1-mm4

Note that this kernel is broken on gcc 3.4 and on 3.3-hammer. If you're using that disable the -funit-at-a-time setting in the main Makefile.

Quoted 7 lines

VIA C3 Ezra

It mounts its root filesystem over nfs and has netconsole compiled in.

Without the REGPARM option the system boots and runs fine.

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Should I post the oopses, the result of ksymoops, a dmesg and kernel config or is this an already known issue?

Not known. Please post the decoded oopses. Also give your compiler version.

Hope this helps. The system runs fine with the option disabled.

Can you perhaps save your .config, do a make distclean and try to compile the kernel from scratch again? Maybe you had some stale object files around.

-Andi

#18 lore raw

Re: several oopses during boot (was: Re: [PATCH] Add CONFIG for -mregparm=3)

Quoted 18 lines · Andi Kleen
Quoted 17 lines · Sander

Andi Kleen wrote (ao):

Quoted 16 lines
Quoted 1 line

2.6.1-mm4

Note that this kernel is broken on gcc 3.4 and on 3.3-hammer. If you're using that disable the -funit-at-a-time setting in the main Makefile.

Quoted 9 lines

VIA C3 Ezra

It mounts its root filesystem over nfs and has netconsole compiled in.

Without the REGPARM option the system boots and runs fine.

Should I post the oopses, the result of ksymoops, a dmesg and kernel config or is this an already known issue?

Quoted 8 lines
Quoted 4 lines
Quoted 2 lines

Not known. Please post the decoded oopses. Also give your compiler version.

Hope this helps. The system runs fine with the option disabled.

Can you perhaps save your .config, do a make distclean and try to compile the kernel from scratch again? Maybe you had some stale object files around.

Also, turn on kksymoops so that you'll get symbols in your oops reports, and no need for ksymoops in userspace.

#19 lore raw

Re: several oopses during boot (was: Re: [PATCH] Add CONFIG for -mregparm=3)

In reply to Andi Kleen

Andi Kleen wrote (ao):

Quoted 6 lines · Sander
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

Without the REGPARM option the system boots and runs fine.

Should I post the oopses, the result of ksymoops, a dmesg and kernel config or is this an already known issue?

Quoted 8 lines
Quoted 4 lines
Quoted 2 lines

Not known. Please post the decoded oopses. Also give your compiler version.

Hope this helps. The system runs fine with the option disabled.

Can you perhaps save your .config, do a make distclean and try to compile the kernel from scratch again? Maybe you had some stale object files around.

I'm terrible sorry to say that I can't reproduce the oopses anymore .. :-( Maybe something went wrong during the tftp of the kernel, or I made a mistake ..

Sorry for wasting your time ..

sander

Signature · 2 lines
Humilis IT Services and Solutions
http://www.humilis.net
#20 lore raw

Re: several oopses during boot (was: Re: [PATCH] Add CONFIG for -mregparm=3)

Sander wrote (ao):

Quoted 16 lines

Andi Kleen wrote (ao):

Quoted 6 lines · Sander
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

Without the REGPARM option the system boots and runs fine.

Should I post the oopses, the result of ksymoops, a dmesg and kernel config or is this an already known issue?

Quoted 8 lines
Quoted 4 lines
Quoted 2 lines

Not known. Please post the decoded oopses. Also give your compiler version.

Hope this helps. The system runs fine with the option disabled.

Can you perhaps save your .config, do a make distclean and try to compile the kernel from scratch again? Maybe you had some stale object files around.

Quoted 5 lines

I'm terrible sorry to say that I can't reproduce the oopses anymore .. :-( Maybe something went wrong during the tftp of the kernel, or I made a mistake ..

Sorry for wasting your time ..

I got another oops now, and discovered that I had kksymoops (KALLSYMS) already enabled as Mike requested.

kernel 2.6.1-mm4, C3 cpu (via mini-itx mobo)
gcc (GCC) 3.3.3 20040110 (prerelease) (Debian)

I have no idea if it is hardware or software related, and if it has got anything to do with the REGPARM option, but I entered this thread because the kernel oopsed the first time I booted it and the first time I enabled this option.

Btw, I always do rm -rf linux-2.6.1 ; tar jxf linux-2.6.1.tar.bz2 etc before a compile.

I'll provide the .config if needed, but thought this message is long enough already. Is this report of any use?

This is the oops I got now when doing an apt-get install. It was idle for some hours after an afternoon of stress testing:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c029fa14
*pde = 00000000
Oops: 0002 [#1]
CPU:    0
EIP:    0060:[<c029fa14>]    Not tainted VLI
EFLAGS: 00010282

EIP is at proc_dodebug+0xa74/0x10c0
eax: fffffed0 ebx: 00000000 ecx: 00000003 edx: db098d20
esi: db098d3a edi: cc380010 ebp: 000004f8 esp: c0357ce4
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c0356000 task=c02eba60)

Stack: 000000d0 000005c8 000000d0 c0248c60 db098d2a cc380000 000000d0 00000000 
       00000000 00000000 00000001 00000000 c0357da0 c0126bba 00000000 00000001 
       000000d0 00001000 00000b90 00001088 c0248dec dacd1be0 000004f8 cc380000 skb_copy_and_csum_bits+0x50/0x2a0
 [<c0126bba>] update_process_times+0x2a/0x30
 [<c0248dec>] skb_copy_and_csum_bits+0x1dc/0x2a0
 [<c0291828>] skb_read_and_csum_bits+0x28/0x60
 [<c029b025>] xdr_partial_copy_from_skb+0x105/0x150
 [<c02918b4>] csum_partial_copy_to_xdr+0x54/0x100
 [<c0291800>] skb_read_and_csum_bits+0x0/0x60
 [<c0291a75>] udp_data_ready+0x115/0x1f0
 [<c027db48>]

(ends here)

And this are the first few oopses from yesterdays report during startup:

Unable to handle kernel paging request at virtual address 249579f8
 printing eip:
c012c19d
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI
EFLAGS: 00010046

EIP is at sys_setsid+0x7d/0xa0
eax: c1557940 ebx: c1554000 ecx: c1557a4c edx: c1557990
esi: 0000000d edi: bffffaa0 ebp: c1554000 esp: c1555fb8
ds: 007b es: 007b ss: 0068
Process init (pid: 13, threadinfo=c1554000 task=c1557940)

Stack: bffffba0 bffffb20 c02a01d7 bffffba0 00002323 23232323 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000202 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb

Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8
 printing eip:
c012c19d
*pde = 00000000
Oops: 0000 [#2]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI
EFLAGS: 00010046

EIP is at sys_setsid+0x7d/0xa0
eax: c1557940 ebx: c1554000 ecx: c1557a4c edx: c1557990
esi: 0000000e edi: bffffaa0 ebp: c1554000 esp: c1555fb8
ds: 007b es: 007b ss: 0068
Process init (pid: 14, threadinfo=c1554000 task=c1557940)

Stack: bffffba0 bffffb20 c02a01d7 bffffba0 61630053 32323232 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000246 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb

Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8
 printing eip:
c012c19d
*pde = 00000000
Oops: 0000 [#3]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI
EFLAGS: 00010046

EIP is at sys_setsid+0x7d/0xa0
eax: c1557940 ebx: c1554000 ecx: c1557a4c edx: c1557990
esi: 0000000f edi: bffffaa0 ebp: c1554000 esp: c1555fb8
ds: 007b es: 007b ss: 0068
Process init (pid: 15, threadinfo=c1554000 task=c1557940)

Stack: bffffba0 bffffb20 c02a01d7 bffffba0 61630053 32323232 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000246 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb

Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8
 printing eip:
c012c19d
*pde = 00000000
Oops: 0000 [#4]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI
EFLAGS: 00010046

EIP is at sys_setsid+0x7d/0xa0
eax: c1557940 ebx: c1554000 ecx: c1557a4c edx: c1557990
esi: 00000010 edi: bffffaa0 ebp: c1554000 esp: c1555fb8
ds: 007b es: 007b ss: 0068
Process init (pid: 16, threadinfo=c1554000 task=c1557940)

Stack: bffffba0 bffffb20 c02a01d7 bffffba0 61630053 32323232 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000246 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb

Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8
 printing eip:
c012c19d
*pde = 00000000
Oops: 0000 [#5]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI
EFLAGS: 00010046

EIP is at sys_setsid+0x7d/0xa0
eax: c1557940 ebx: c1554000 ecx: c1557a4c edx: c1557990
esi: 00000011 edi: bffffaa0 ebp: c1554000 esp: c1555fb8
ds: 007b es: 007b ss: 0068
Process init (pid: 17, threadinfo=c1554000 task=c1557940)

Stack: bffffba0 bffffb20 c02a01d7 bffffba0 61630053 32323232 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000246 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb

Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8
 printing eip:
c012c19d
*pde = 00000000
Oops: 0000 [#6]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI
EFLAGS: 00010046

EIP is at sys_setsid+0x7d/0xa0
eax: c1557940 ebx: c1554000 ecx: c1557a4c edx: c1557990
esi: 00000012 edi: bffffaa0 ebp: c1554000 esp: c1555fb8
ds: 007b es: 007b ss: 0068
Process init (pid: 18, threadinfo=c1554000 task=c1557940)

Stack: bffffba0 bffffb20 c02a01d7 bffffba0 61630053 32323232 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000246 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb

Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8
 printing eip:
c012c19d
*pde = 00000000
Oops: 0000 [#7]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI
EFLAGS: 00010046

EIP is at sys_setsid+0x7d/0xa0
eax: c1557940 ebx: c1554000 ecx: c1557a4c edx: c1557990
esi: 00000013 edi: bffffaa0 ebp: c1554000 esp: c1555fb8
ds: 007b es: 007b ss: 0068
Process init (pid: 19, threadinfo=c1554000 task=c1557940)

Stack: bffffba0 bffffb20 c02a01d7 bffffba0 61630053 32323232 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000246 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb

Code: 00 00 52 8b 80 88 00 00 00 50 e8 0f 49 ff ff 5e 58 8b 03 <1>Unable to handle kernel paging request at virtual address 249579f8
 printing eip:
c012c19d
*pde = 00000000
Oops: 0000 [#8]
CPU:    0
EIP:    0060:[<c012c19d>]    Not tainted VLI
EFLAGS: 00010046

EIP is at sys_setsid+0x7d/0xa0
eax: c1557940 ebx: c1554000 ecx: c1557a4c edx: c1557990
esi: 00000014 edi: bffffaa0 ebp: c1554000 esp: c1555fb8
ds: 007b es: 007b ss: 0068
Process init (pid: 20, threadinfo=c1554000 task=c1557940)

Stack: bffffba0 bffffb20 c02a01d7 bffffba0 61630053 32323232 bffffb20 bffffaa0 
       bffffcc8 00000042 0000007b 0000007b 00000042 400c8b17 00000073 00000246 
       bffff9fc 0000007b 
Call Trace:
 [<c02a01d7>] syscall_call+0x7/0xb
Signature · 2 lines
Humilis IT Services and Solutions
http://www.humilis.net
#21 lore raw

Re: several oopses during boot (was: Re: [PATCH] Add CONFIG for -mregparm=3)

Quoted 4 lines

I have no idea if it is hardware or software related, and if it has got anything to do with the REGPARM option, but I entered this thread because the kernel oopsed the first time I booted it and the first time I enabled this option.

Do the oopses go away when you disable the option? And do they come back when you reenable it again?

You could run memtest86 to make sure your RAM is ok.

-Andi

#22 lore raw

Re: several oopses during boot (was: Re: [PATCH] Add CONFIG for -mregparm=3)

Andi Kleen wrote (ao):

Quoted 7 lines
Quoted 4 lines

I have no idea if it is hardware or software related, and if it has got anything to do with the REGPARM option, but I entered this thread because the kernel oopsed the first time I booted it and the first time I enabled this option.

Do the oopses go away when you disable the option? And do they come back when you reenable it again?

I have to try that, but have no reliable way to get the oopses yet which makes that a bit hard.

Quoted 1 line

You could run memtest86 to make sure your RAM is ok.

I'll do that.

Signature · 2 lines
Humilis IT Services and Solutions
http://www.humilis.net