[1/4] 2.6.23-rc4: known regressions

[1/4] 2.6.23-rc4: known regressions

[Michal Piotrowski]

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 <pavel@ucw.cz>
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 <Stefan.Becker@nokia.com>
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 <jdi@l4x.org>
Caused-By       : ?
Handled-By      : xtensa: Christian Zankel <chris@zankel.net>
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 <jeff.chua.linux@gmail.com>
Caused-By       : ?
Handled-By      : H. Peter Anvin <hpa@zytor.com>
                  Antonino A. Daplas <adaplas@gmail.com>
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 <lists4me@web.de>
Caused-By       : ?
Handled-By      : Ingo Molnar <mingo@elte.hu>
Status          : problem is being debugged

Regards,
Michal

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

Re: [1/4] 2.6.23-rc4: known regressions

[Jan Dittmer]

Michal Piotrowski wrote:
> 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 <jdi@l4x.org>
> Caused-By       : ?
> Handled-By      : xtensa: Christian Zankel <chris@zankel.net>
> Status          : unknown

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

Re: [1/4] 2.6.23-rc4: known regressions

[Adrian Bunk]

On Wed, Aug 29, 2007 at 08:04:52PM +0200, Jan Dittmer wrote:
> Michal Piotrowski wrote:
> > 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 <jdi@l4x.org>
> > Caused-By       : ?
> > Handled-By      : xtensa: Christian Zankel <chris@zankel.net>
> > Status          : unknown
> 
> 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
>...

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

> Jan

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

Re: [1/4] 2.6.23-rc4: known regressions

[Christoph Lameter]

On Thu, 30 Aug 2007, Adrian Bunk wrote:

> >   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
> >...
> 
> Christoph, is your fix in -mm suitable for 2.6.23, or how else should 
> this regression be fixed for 2.6.23?

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
===================================================================
--- linux-2.6.orig/include/linux/slub_def.h	2007-08-29 17:03:48.000000000 -0700
+++ linux-2.6/include/linux/slub_def.h	2007-08-29 17:09:55.000000000 -0700
@@ -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

Re: [1/4] 2.6.23-rc4: known regressions

[Christoph Lameter]

On Thu, 30 Aug 2007, Adrian Bunk wrote:

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

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.

Re: [1/4] 2.6.23-rc4: known regressions

[Jan Dittmer]

Christoph Lameter wrote:
> On Thu, 30 Aug 2007, Adrian Bunk wrote:
> 
>> Christoph, is your fix in -mm suitable for 2.6.23, or how else should 
>> this regression be fixed for 2.6.23?
> 
> Looks like this is just alpha and a certain particular compiler version? 

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

Re: [1/4] 2.6.23-rc4: known regressions

[Christoph Lameter]

On Thu, 30 Aug 2007, Jan Dittmer wrote:

> Christoph Lameter wrote:
> > On Thu, 30 Aug 2007, Adrian Bunk wrote:
> > 
> > > Christoph, is your fix in -mm suitable for 2.6.23, or how else should this
> > > regression be fixed for 2.6.23?
> > 
> > Looks like this is just alpha and a certain particular compiler version? 
> 
> 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?

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

Re: [1/4] 2.6.23-rc4: known regressions

[Jan Dittmer]

Christoph Lameter wrote:
> On Thu, 30 Aug 2007, Jan Dittmer wrote:
> 
>> Christoph Lameter wrote:
>>> On Thu, 30 Aug 2007, Adrian Bunk wrote:
>>>
>>>> Christoph, is your fix in -mm suitable for 2.6.23, or how else should this
>>>> regression be fixed for 2.6.23?
>>> Looks like this is just alpha and a certain particular compiler version? 
>> 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?
> 
> 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

Re: [1/4] 2.6.23-rc4: known regressions

[Christoph Lameter]

Here is the fix for alpha:



From clameter@sgi.com 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.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Acked-by: Jan Dittmer <jdi@l4x.org>

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

Index: linux-2.6/include/linux/slub_def.h
===================================================================
--- linux-2.6.orig/include/linux/slub_def.h	2007-08-30 14:12:25.000000000 -0700
+++ linux-2.6/include/linux/slub_def.h	2007-08-30 14:13:07.000000000 -0700
@@ -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);

Re: [1/4] 2.6.23-rc4: known regressions

[Adrian Bunk]

On Fri, Aug 31, 2007 at 12:48:45AM -0700, Christoph Lameter wrote:
> Here is the fix for alpha:
> 
> >From clameter@sgi.com 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.
>...

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

Re: [1/4] 2.6.23-rc4: known regressions

[Jeff Chua]

On 8/29/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:

> 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 <jeff.chua.linux@gmail.com>
> Caused-By       : ?
> Handled-By      : H. Peter Anvin <hpa@zytor.com>
>                   Antonino A. Daplas <adaplas@gmail.com>
> Workaround      : "s2ram --force --acpi_sleep 1 --vbe_mode"
> Status          : problem is being debugged

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.