2.6.23-rc4: known regressions

Hi all,

Here is a list of some known regressions in 2.6.23-rc4.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

Name Regressions fixed since 21-Jun-2007

Adrian Bunk                            9
Andi Kleen                             5
Linus Torvalds                         5
Andrew Morton                          4
Hugh Dickins                           4
Al Viro                                3
Alan Stern                             3
Cornelia Huck                          3
Jens Axboe                             3
Tejun Heo                              3

Unclassified

Subject : cpu hotplug support broken in 2.6.23-rc3
References : http://lkml.org/lkml/2007/8/27/58
Last known good : ?
Submitter : Pavel Machek <[email protected]>

Caused-By       : ?
Handled-By      : ?
Status          : problem is being debugged

Subject : 2.6.23-rc3-git1 crash/stuck on VIA CN700 system
References : http://lkml.org/lkml/2007/8/20/174
Last known good : ?
Submitter : Stefan Becker <[email protected]>

Caused-By       : ?
Handled-By      : ?
Status          : unknown

Subject : 2.6.23-rc2 cross compile regressions (alpha,xtensa)
References : http://lkml.org/lkml/2007/8/6/43
Last known good : alpha: 2.6.22-git8

                  xtensa: 2.6.22-git6
Submitter       : Jan Dittmer <[email protected]>
Caused-By       : ?
Handled-By      : xtensa: Christian Zankel <[email protected]>
Status          : unknown

Subject : console is messed up after resume from s2ram or switching to console from X
References : http://lkml.org/lkml/2007/8/4/6
Last known good : ?
Submitter : Jeff Chua <[email protected]>

Antonino A. Daplas <[email protected]>
Workaround : "s2ram --force --acpi_sleep 1 --vbe_mode"
Status : problem is being debugged

Subject : konqueror suddenly vanishing, "konqueror: Fatal IO error: client killed"
References : http://lkml.org/lkml/2007/7/22/86
Last known good : ?
Submitter : Markus <[email protected]>

Caused-By       : ?
Handled-By      : Ingo Molnar <[email protected]>
Status          : problem is being debugged

Regards,
Michal

LOG
http://www.stardust.webpages.pl/log/

Status: Unfixed

alpha: http://l4x.org/k/?d=33700

  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1

arch/alpha/kernel/built-in.o(.text+0xaaa8): In function `pdev_save_srm_config':
include/linux/slub_def.h:154: undefined reference to __kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0xaaac):include/linux/slub_def.h:154: undefined reference to __kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0xd0a8): In function `module_frob_arch_sections':
include/linux/slub_def.h:154: undefined reference to __kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0xd0ac):include/linux/slub_def.h:154: undefined reference to __kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0x19388): In function `srmcons_get_private_struct':
include/linux/slub_def.h:154: undefined reference to __kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0x1938c):include/linux/slub_def.h:154: more undefined references to __kmalloc_size_too_large' follow make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [_all] Error 2

xtensa: http://l4x.org/k/?d=33728
CC arch/xtensa/kernel/process.o
arch/xtensa/kernel/process.c:50: error: INR_OPEN' undeclared here (not in a function) arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim[7].rlim_cur') arch/xtensa/kernel/process.c:50: error: INR_OPEN' undeclared here (not in a function) arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim[7].rlim_max') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim[7]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim[8]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim[9]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim[10]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim[11]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim[12]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim[13]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim[14]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.rlim') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for init_signals.<anonymous>') arch/xtensa/kernel/process.c: In function `xtensa_execve':
arch/xtensa/kernel/process.c:449: error: implicit declaration of function getname' arch/xtensa/kernel/process.c:449: warning: assignment makes pointer from integer without a cast arch/xtensa/kernel/process.c:460: error: implicit declaration of function putname' make[2]: *** [arch/xtensa/kernel/process.o] Error 1
make[1]: *** [arch/xtensa/kernel] Error 2
make: *** [_all] Error 2

Jan

Patch below.

cu
Adrian

<-- snip -->

Another fallout from the removal of #include <linux/fs.h> from mm.h

---
6a0031b0f3f40238fc604bba264981776a155dbf

index ce758ba..dd498f1 100644
@@ -30,6 +30,7 @@
 #include <linux/init_task.h>
 #include <linux/module.h>
 #include <linux/mqueue.h>
+#include <linux/fs.h>
 
 #include <asm/pgtable.h>
 #include <asm/uaccess.h>

Christoph, is your fix in -mm suitable for 2.6.23, or how else should this regression be fixed for 2.6.23?

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

Could you give me an asm dump via objdump of one of these functions? I wonder what is going on there? Seeing the code generated may give us a hint what is going on.

Likely an old compiler that has troubles performing constant folding <sigh>. One solution would be to use a newer compiler?

And yes, the page allocator pass through patch in mm would fix this.

Or define CONFIG_BROKEN_CONSTANT_FOLDING for alpha and then use this patch:

---
 include/linux/slub_def.h |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6/include/linux/slub_def.h
===================================================================
@@ -168,6 +168,7 @@ void *__kmalloc(size_t size, gfp_t flags
 
 static inline void *kmalloc(size_t size, gfp_t flags)
 {
+#ifndef CONFIG_BROKEN_CONSTANT_FOLDING
 	if (__builtin_constant_p(size) && !(flags & SLUB_DMA)) {
 		struct kmem_cache *s = kmalloc_slab(size);
 

@@ -176,6 +177,7 @@ static inline void *kmalloc(size_t size,
 
 		return kmem_cache_alloc(s, flags);
 	} else
+#endif
 		return __kmalloc(size, flags);
 }
 

@@ -185,6 +187,7 @@ void *kmem_cache_alloc_node(struct kmem_
 
 static inline void *kmalloc_node(size_t size, gfp_t flags, int node)
 {
+#ifndef CONFIG_BROKEN_CONSTANT_FOLDING
 	if (__builtin_constant_p(size) && !(flags & SLUB_DMA)) {
 		struct kmem_cache *s = kmalloc_slab(size);
 

@@ -193,6 +196,7 @@ static inline void *kmalloc_node(size_t 
 
 		return kmem_cache_alloc_node(s, flags, node);
 	} else
+#endif
 		return __kmalloc_node(size, flags, node);
 }
 #endif

Looks like this is just alpha and a certain particular compiler version? You may get away with adding

void __kmalloc_size_too_large(void)

{
	BUG();
}

somewhere if you use the particular compiler version causing trouble. The compiler will then generate some useless code wasting processor cycles due to not folding constants but it should(tm) work.

binutils 2.15.95, gcc 3.3.6 and I could update to 4.0.4 or something more recent I guess. And yes, it's only alpha.

Of which file do you want the objdump?

Jan

The one where the link fails. Dump the code around the unresolved symbol.

Here is one of them:

   19380:       10 00 1f 20     lda     v0,16
   19384:       e6 ff ff c3     br      19320 <srmcons_get_private_struct+0x90>
                 * Generate a link failure. Would be great if we could
                 * do something to stop the compile here.
                 */
                extern void __kmalloc_size_too_large(void);
                __kmalloc_size_too_large();
   19388:       00 00 7d a7     ldq     t12,0(gp)
   1938c:       00 40 5b 6b     jsr     ra,(t12),19390 <srmcons_get_private_struct+0x100>
   19390:       00 00 ba 27     ldah    gp,0(ra)
   19394:       00 00 bd 23     lda     gp,0(gp)
   19398:       d6 ff ff c3     br      192f4 <srmcons_get_private_struct+0x64>
   1939c:       00 00 fe 2f     unop

Jan

Here is the fix for alpha:

From [email protected] Thu Aug 30 14:13:57 2007
Subject: SLUB: Force inlining for functions in slub_def.h

Some compilers (especially older gcc releases) may skip inlining sometimes which will lead to link failures. Force the inlining of keyfunctions in slub_def.h to avoid these issues.

---
 include/linux/slub_def.h |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6/include/linux/slub_def.h
===================================================================
@@ -78,7 +78,7 @@ extern struct kmem_cache kmalloc_caches[
  * Sorry that the following has to be that ugly but some versions of GCC
  * have trouble with constant propagation and loops.
  */
-static inline int kmalloc_index(size_t size)
+static __always_inline int kmalloc_index(size_t size)
 {
 	if (!size)
 		return 0;

@@ -133,7 +133,7 @@ static inline int kmalloc_index(size_t s
  * This ought to end up with a global pointer to the right cache
  * in kmalloc_caches.
  */
-static inline struct kmem_cache *kmalloc_slab(size_t size)
+static __always_inline struct kmem_cache *kmalloc_slab(size_t size)
 {
 	int index = kmalloc_index(size);
 

@@ -166,7 +166,7 @@ static inline struct kmem_cache *kmalloc
 void *kmem_cache_alloc(struct kmem_cache *, gfp_t);
 void *__kmalloc(size_t size, gfp_t flags);
 
-static inline void *kmalloc(size_t size, gfp_t flags)
+static __always_inline void *kmalloc(size_t size, gfp_t flags)
 {
 	if (__builtin_constant_p(size) && !(flags & SLUB_DMA)) {
 		struct kmem_cache *s = kmalloc_slab(size);

@@ -183,7 +183,7 @@ static inline void *kmalloc(size_t size,
 void *__kmalloc_node(size_t size, gfp_t flags, int node);
 void *kmem_cache_alloc_node(struct kmem_cache *, gfp_t flags, int node);
 
-static inline void *kmalloc_node(size_t size, gfp_t flags, int node)
+static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node)
 {
 	if (__builtin_constant_p(size) && !(flags & SLUB_DMA)) {
 		struct kmem_cache *s = kmalloc_slab(size);

This also explains why it's an Alpha-only problem - the Alpha port pretty much diverges from the rest of the kernel regarding "inline" semantics and usage...

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

I'm satisfied with the workaround using "s2ram --force --acpi_sleep 1 --vbe_mode", and so is H. Peter Anvin, and he uncovered a different bug while debugging this.

Please close the case.

Thanks,
Jeff.