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]>
Caused-By : ?
Handled-By : H. Peter Anvin <[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/
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 <[email protected]>
> Caused-By : ?
> Handled-By : xtensa: Christian Zankel <[email protected]>
> 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
On 8/29/07, Michal Piotrowski <[email protected]> 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 <[email protected]>
> Caused-By : ?
> Handled-By : H. Peter Anvin <[email protected]>
> Antonino A. Daplas <[email protected]>
> 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.
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 <[email protected]>
> > Caused-By : ?
> > Handled-By : xtensa: Christian Zankel <[email protected]>
> > Status : unknown
>
> Status: Unfixed
>...
> 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')
>...
Patch below.
> Jan
cu
Adrian
<-- snip -->
Another fallout from the removal of #include <linux/fs.h> from mm.h
Signed-off-by: Adrian Bunk <[email protected]>
---
6a0031b0f3f40238fc604bba264981776a155dbf
diff --git a/arch/xtensa/kernel/process.c b/arch/xtensa/kernel/process.c
index ce758ba..dd498f1 100644
--- a/arch/xtensa/kernel/process.c
+++ b/arch/xtensa/kernel/process.c
@@ -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>
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 <[email protected]>
> > Caused-By : ?
> > Handled-By : xtensa: Christian Zankel <[email protected]>
> > 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
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
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.
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
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.
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
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.
Signed-off-by: Christoph Lameter <[email protected]>
Acked-by: Jan Dittmer <[email protected]>
---
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);
On Fri, Aug 31, 2007 at 12:48:45AM -0700, Christoph Lameter wrote:
> 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.
>...
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