* Re: 2.6.21-rc7-mm2
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
@ 2007-04-26 11:47 ` Gabriel C
2007-04-26 20:37 ` 2.6.21-rc7-mm2 Andrew Morton
2007-04-26 12:16 ` 2.6.21-rc7-mm2 -- x86_64 VDSO compile error Andy Whitcroft
` (14 subsequent siblings)
15 siblings, 1 reply; 135+ messages in thread
From: Gabriel C @ 2007-04-26 11:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
>
>
> - this has everything which is in 2.6.21. Plus more!
>
> - a number of nasty bugs were fixed. This should be (a lot) more stable
> than 2.6.21-rc7-mm1.
>
>
I get this warning here :
drivers/net/Kconfig:2327:warning: 'select' used by config symbol
'UCC_GETH' refer to undefined symbol 'UCC_FAST'
Regards,
Gabriel
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2
2007-04-26 11:47 ` 2.6.21-rc7-mm2 Gabriel C
@ 2007-04-26 20:37 ` Andrew Morton
2007-04-26 20:46 ` 2.6.21-rc7-mm2 Randy Dunlap
2007-04-26 20:57 ` 2.6.21-rc7-mm2 Timur Tabi
0 siblings, 2 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-26 20:37 UTC (permalink / raw)
To: Gabriel C; +Cc: linux-kernel, Timur Tabi, Kumar Gala, Paul Mackerras
On Thu, 26 Apr 2007 13:47:14 +0200 Gabriel C <nix.or.die@googlemail.com> wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
> >
> >
> > - this has everything which is in 2.6.21. Plus more!
> >
> > - a number of nasty bugs were fixed. This should be (a lot) more stable
> > than 2.6.21-rc7-mm1.
> >
> >
>
> I get this warning here :
>
>
> drivers/net/Kconfig:2327:warning: 'select' used by config symbol
> 'UCC_GETH' refer to undefined symbol 'UCC_FAST'
Yes, we get so many of those that I tend to ignore them, assuming that
someone will pick it up and fix it.
This one was added by git-powerpc, presumably
7d776cb596994219584257eb5956b87628e5deaf "QE: automatically select QE
options"
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2
2007-04-26 20:37 ` 2.6.21-rc7-mm2 Andrew Morton
@ 2007-04-26 20:46 ` Randy Dunlap
2007-04-29 8:05 ` 2.6.21-rc7-mm2 Geert Uytterhoeven
2007-04-26 20:57 ` 2.6.21-rc7-mm2 Timur Tabi
1 sibling, 1 reply; 135+ messages in thread
From: Randy Dunlap @ 2007-04-26 20:46 UTC (permalink / raw)
To: Andrew Morton
Cc: Gabriel C, linux-kernel, Timur Tabi, Kumar Gala, Paul Mackerras
On Thu, 26 Apr 2007 13:37:20 -0700 Andrew Morton wrote:
> On Thu, 26 Apr 2007 13:47:14 +0200 Gabriel C <nix.or.die@googlemail.com> wrote:
>
> > Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
> > >
> > >
> > > - this has everything which is in 2.6.21. Plus more!
> > >
> > > - a number of nasty bugs were fixed. This should be (a lot) more stable
> > > than 2.6.21-rc7-mm1.
> > >
> > >
> >
> > I get this warning here :
> >
> >
> > drivers/net/Kconfig:2327:warning: 'select' used by config symbol
> > 'UCC_GETH' refer to undefined symbol 'UCC_FAST'
>
> Yes, we get so many of those that I tend to ignore them, assuming that
> someone will pick it up and fix it.
>
> This one was added by git-powerpc, presumably
> 7d776cb596994219584257eb5956b87628e5deaf "QE: automatically select QE
> options"
There was a similar problem with PS3_xyz (don't recall exactly
which PS3_option it was) that was "solved" by introducing an
intermediate config symbol IIRC. Maybe that trick^W fix can be
done here also...
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2
2007-04-26 20:46 ` 2.6.21-rc7-mm2 Randy Dunlap
@ 2007-04-29 8:05 ` Geert Uytterhoeven
0 siblings, 0 replies; 135+ messages in thread
From: Geert Uytterhoeven @ 2007-04-29 8:05 UTC (permalink / raw)
To: Randy Dunlap
Cc: Andrew Morton, Gabriel C, Linux Kernel Development, Timur Tabi,
Kumar Gala, Paul Mackerras
On Thu, 26 Apr 2007, Randy Dunlap wrote:
> On Thu, 26 Apr 2007 13:37:20 -0700 Andrew Morton wrote:
> > On Thu, 26 Apr 2007 13:47:14 +0200 Gabriel C <nix.or.die@googlemail.com> wrote:
> > > Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
> > > >
> > > >
> > > > - this has everything which is in 2.6.21. Plus more!
> > > >
> > > > - a number of nasty bugs were fixed. This should be (a lot) more stable
> > > > than 2.6.21-rc7-mm1.
> > > >
> > > >
> > >
> > > I get this warning here :
> > >
> > >
> > > drivers/net/Kconfig:2327:warning: 'select' used by config symbol
> > > 'UCC_GETH' refer to undefined symbol 'UCC_FAST'
> >
> > Yes, we get so many of those that I tend to ignore them, assuming that
> > someone will pick it up and fix it.
> >
> > This one was added by git-powerpc, presumably
> > 7d776cb596994219584257eb5956b87628e5deaf "QE: automatically select QE
> > options"
>
> There was a similar problem with PS3_xyz (don't recall exactly
> which PS3_option it was) that was "solved" by introducing an
> intermediate config symbol IIRC. Maybe that trick^W fix can be
> done here also...
CONFIG_PS3_ADVANCED, commit 3f555c700b6c90f9ac24bc81a4f509583d906278
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-2908453 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2
2007-04-26 20:37 ` 2.6.21-rc7-mm2 Andrew Morton
2007-04-26 20:46 ` 2.6.21-rc7-mm2 Randy Dunlap
@ 2007-04-26 20:57 ` Timur Tabi
2007-04-26 21:13 ` 2.6.21-rc7-mm2 Gabriel C
2007-04-26 21:33 ` 2.6.21-rc7-mm2 Andrew Morton
1 sibling, 2 replies; 135+ messages in thread
From: Timur Tabi @ 2007-04-26 20:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: Gabriel C, linux-kernel, Kumar Gala, Paul Mackerras
Andrew Morton wrote:
>> drivers/net/Kconfig:2327:warning: 'select' used by config symbol
>> 'UCC_GETH' refer to undefined symbol 'UCC_FAST'
>
> Yes, we get so many of those that I tend to ignore them, assuming that
> someone will pick it up and fix it.
Is this being compiled on a non-ppc/powerpc platform? That might explain it. UCC_GETH is
defined in drivers/net/Kconfig, but UCC_FAST is defined in
arch/powerpc/sysdev/qe_lib/Kconfig. So I supposed if you don't compile for ARCH=powerpc,
then arch/powerpc/sysdev/qe_lib/Kconfig is never loaded?
If that's the case, then we're always going to have this problem with platform-dependent
drivers in the /drivers/ directory. The ucc_geth driver depends on the "QE library",
which is present only on some PowerPC processors, so we put the config options for the QE
in arch/powerpc. But since ucc_geth is a standard Ethernet driver, it exists in drivers/net.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2
2007-04-26 20:57 ` 2.6.21-rc7-mm2 Timur Tabi
@ 2007-04-26 21:13 ` Gabriel C
2007-04-26 21:33 ` 2.6.21-rc7-mm2 Andrew Morton
1 sibling, 0 replies; 135+ messages in thread
From: Gabriel C @ 2007-04-26 21:13 UTC (permalink / raw)
To: Timur Tabi; +Cc: Andrew Morton, linux-kernel, Kumar Gala, Paul Mackerras
Timur Tabi wrote:
> Andrew Morton wrote:
>
>
>>> drivers/net/Kconfig:2327:warning: 'select' used by config symbol
>>> 'UCC_GETH' refer to undefined symbol 'UCC_FAST'
>>>
>> Yes, we get so many of those that I tend to ignore them, assuming that
>> someone will pick it up and fix it.
>>
>
> Is this being compiled on a non-ppc/powerpc platform?
Yes , on i386 with this config :
http://crazy.dev.frugalware.org/2.6.21-rc7-mm2/config
> That might explain it. UCC_GETH is
> defined in drivers/net/Kconfig, but UCC_FAST is defined in
> arch/powerpc/sysdev/qe_lib/Kconfig. So I supposed if you don't compile for ARCH=powerpc,
> then arch/powerpc/sysdev/qe_lib/Kconfig is never loaded?
>
> If that's the case, then we're always going to have this problem with platform-dependent
> drivers in the /drivers/ directory. The ucc_geth driver depends on the "QE library",
> which is present only on some PowerPC processors, so we put the config options for the QE
> in arch/powerpc. But since ucc_geth is a standard Ethernet driver, it exists in drivers/net.
>
>
Gabriel
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2
2007-04-26 20:57 ` 2.6.21-rc7-mm2 Timur Tabi
2007-04-26 21:13 ` 2.6.21-rc7-mm2 Gabriel C
@ 2007-04-26 21:33 ` Andrew Morton
1 sibling, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-26 21:33 UTC (permalink / raw)
To: Timur Tabi; +Cc: Gabriel C, linux-kernel, Kumar Gala, Paul Mackerras
On Thu, 26 Apr 2007 15:57:21 -0500 Timur Tabi <timur@freescale.com> wrote:
> Andrew Morton wrote:
>
> >> drivers/net/Kconfig:2327:warning: 'select' used by config symbol
> >> 'UCC_GETH' refer to undefined symbol 'UCC_FAST'
> >
> > Yes, we get so many of those that I tend to ignore them, assuming that
> > someone will pick it up and fix it.
>
> Is this being compiled on a non-ppc/powerpc platform?
yup, sorry I forgot to mention that: i386 `make allmodconfig'.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
2007-04-26 11:47 ` 2.6.21-rc7-mm2 Gabriel C
@ 2007-04-26 12:16 ` Andy Whitcroft
2007-04-26 13:27 ` Mel Gorman
2007-04-26 12:30 ` 2.6.21-rc7-mm2 -- x86_64 blade hard hangs Andy Whitcroft
` (13 subsequent siblings)
15 siblings, 1 reply; 135+ messages in thread
From: Andy Whitcroft @ 2007-04-26 12:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Steve Fox
Getting the following on an x86_64 numa box:
CC arch/x86_64/vdso/vclock_gettime.o
arch/x86_64/vdso/vclock_gettime.c:1: error: code model `small' not
supported in the 32 bit mode
make[1]: *** [arch/x86_64/vdso/vclock_gettime.o] Error 1
make: *** [arch/x86_64/vdso] Error 2
Kernel config here: http://test.kernel.org/abat/85358/build/dotconfig
-apw
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error
2007-04-26 12:16 ` 2.6.21-rc7-mm2 -- x86_64 VDSO compile error Andy Whitcroft
@ 2007-04-26 13:27 ` Mel Gorman
2007-04-26 14:11 ` Andi Kleen
2007-04-26 14:13 ` 2.6.21-rc7-mm2 -- x86_64 VDSO compile error II Andi Kleen
0 siblings, 2 replies; 135+ messages in thread
From: Mel Gorman @ 2007-04-26 13:27 UTC (permalink / raw)
To: ak; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
On (26/04/07 13:16), Andy Whitcroft didst pronounce:
> Getting the following on an x86_64 numa box:
>
> CC arch/x86_64/vdso/vclock_gettime.o
> arch/x86_64/vdso/vclock_gettime.c:1: error: code model `small' not
> supported in the 32 bit mode
> make[1]: *** [arch/x86_64/vdso/vclock_gettime.o] Error 1
> make: *** [arch/x86_64/vdso] Error 2
>
> Kernel config here: http://test.kernel.org/abat/85358/build/dotconfig
>
Hi Andi,
Backing out x86_64-mm-vdso.patch allowed this kernel to build and boot
successful on the machine in question (elm3b6). The backout caused one reject
in Documentation/kernel-parameters but otherwise backed out easily. It's
not super-clear why it fails to build. If you want me to try another patch,
make sure I'm cc'd and I'll give it a spin.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error
2007-04-26 13:27 ` Mel Gorman
@ 2007-04-26 14:11 ` Andi Kleen
2007-04-26 14:31 ` Mel Gorman
2007-04-26 14:13 ` 2.6.21-rc7-mm2 -- x86_64 VDSO compile error II Andi Kleen
1 sibling, 1 reply; 135+ messages in thread
From: Andi Kleen @ 2007-04-26 14:11 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
On Thursday 26 April 2007 15:27:36 Mel Gorman wrote:
> On (26/04/07 13:16), Andy Whitcroft didst pronounce:
> > Getting the following on an x86_64 numa box:
> >
> > CC arch/x86_64/vdso/vclock_gettime.o
> > arch/x86_64/vdso/vclock_gettime.c:1: error: code model `small' not
> > supported in the 32 bit mode
32bit mode? Something must be confused.
What gcc/binutils is that?
Can you post V=1 output for that line please?
It works for me with gcc 4.1 and 3.3
-Andi
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error
2007-04-26 14:11 ` Andi Kleen
@ 2007-04-26 14:31 ` Mel Gorman
0 siblings, 0 replies; 135+ messages in thread
From: Mel Gorman @ 2007-04-26 14:31 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
On (26/04/07 16:11), Andi Kleen didst pronounce:
> On Thursday 26 April 2007 15:27:36 Mel Gorman wrote:
> > On (26/04/07 13:16), Andy Whitcroft didst pronounce:
> > > Getting the following on an x86_64 numa box:
> > >
> > > CC arch/x86_64/vdso/vclock_gettime.o
> > > arch/x86_64/vdso/vclock_gettime.c:1: error: code model `small' not
> > > supported in the 32 bit mode
>
> 32bit mode? Something must be confused.
>
> What gcc/binutils is that?
gcc -v
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13sarge1)
ld -v
GNU ld version 2.15
>
> Can you post V=1 output for that line please?
make -f scripts/Makefile.build obj=arch/x86_64/vdso
gcc -Wp,-MD,arch/x86_64/vdso/.vclock_gettime.o.d -nostdinc -isystem
/usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vclock_gettime)" -D"KBUILD_MODNAME=KBUILD_STR(vclock_gettime)" -c -o arch/x86_64/vdso/vclock_gettime.o arch/x86_64/vdso/vclock_gettime.c
arch/x86_64/vdso/vclock_gettime.c:1: error: code model `small' not
supported in the 32 bit mode
make[1]: *** [arch/x86_64/vdso/vclock_gettime.o] Error 1
make: *** [arch/x86_64/vdso] Error 2
>
> It works for me with gcc 4.1 and 3.3
>
Will try the patch.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error II
2007-04-26 13:27 ` Mel Gorman
2007-04-26 14:11 ` Andi Kleen
@ 2007-04-26 14:13 ` Andi Kleen
2007-04-26 14:39 ` Mel Gorman
1 sibling, 1 reply; 135+ messages in thread
From: Andi Kleen @ 2007-04-26 14:13 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
On Thursday 26 April 2007 15:27:36 Mel Gorman wrote:
> On (26/04/07 13:16), Andy Whitcroft didst pronounce:
> > Getting the following on an x86_64 numa box:
> >
> > CC arch/x86_64/vdso/vclock_gettime.o
> > arch/x86_64/vdso/vclock_gettime.c:1: error: code model `small' not
> > supported in the 32 bit mode
> > make[1]: *** [arch/x86_64/vdso/vclock_gettime.o] Error 1
> > make: *** [arch/x86_64/vdso] Error 2
> >
> > Kernel config here: http://test.kernel.org/abat/85358/build/dotconfig
> >
>
> Hi Andi,
>
> Backing out x86_64-mm-vdso.patch allowed this kernel to build and boot
> successful on the machine in question (elm3b6). The backout caused one reject
> in Documentation/kernel-parameters but otherwise backed out easily. It's
> not super-clear why it fails to build. If you want me to try another patch,
> make sure I'm cc'd and I'll give it a spin.
Or please try this simple patch.
-Andi
Index: linux/arch/x86_64/vdso/Makefile
===================================================================
--- linux.orig/arch/x86_64/vdso/Makefile
+++ linux/arch/x86_64/vdso/Makefile
@@ -32,7 +32,7 @@ $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso
$(obj)/vdso.so: $(src)/vdso.lds $(vobjs) FORCE
$(call if_changed,syscall)
-CF := $(PROFILING) -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables
+CF := $(PROFILING) -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables -m64
$(obj)/vclock_gettime.o: CFLAGS = $(CF)
$(obj)/vgetcpu.o: CFLAGS = $(CF)
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error II
2007-04-26 14:13 ` 2.6.21-rc7-mm2 -- x86_64 VDSO compile error II Andi Kleen
@ 2007-04-26 14:39 ` Mel Gorman
2007-04-26 15:20 ` Mel Gorman
0 siblings, 1 reply; 135+ messages in thread
From: Mel Gorman @ 2007-04-26 14:39 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
On (26/04/07 16:13), Andi Kleen didst pronounce:
> On Thursday 26 April 2007 15:27:36 Mel Gorman wrote:
> > On (26/04/07 13:16), Andy Whitcroft didst pronounce:
> > > Getting the following on an x86_64 numa box:
> > >
> > > CC arch/x86_64/vdso/vclock_gettime.o
> > > arch/x86_64/vdso/vclock_gettime.c:1: error: code model `small' not
> > > supported in the 32 bit mode
> > > make[1]: *** [arch/x86_64/vdso/vclock_gettime.o] Error 1
> > > make: *** [arch/x86_64/vdso] Error 2
> > >
> > > Kernel config here: http://test.kernel.org/abat/85358/build/dotconfig
> > >
> >
> > Hi Andi,
> >
> > Backing out x86_64-mm-vdso.patch allowed this kernel to build and boot
> > successful on the machine in question (elm3b6). The backout caused one reject
> > in Documentation/kernel-parameters but otherwise backed out easily. It's
> > not super-clear why it fails to build. If you want me to try another patch,
> > make sure I'm cc'd and I'll give it a spin.
>
>
> Or please try this simple patch.
>
> -Andi
>
> Index: linux/arch/x86_64/vdso/Makefile
> ===================================================================
> --- linux.orig/arch/x86_64/vdso/Makefile
> +++ linux/arch/x86_64/vdso/Makefile
> @@ -32,7 +32,7 @@ $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso
> $(obj)/vdso.so: $(src)/vdso.lds $(vobjs) FORCE
> $(call if_changed,syscall)
>
> -CF := $(PROFILING) -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables
> +CF := $(PROFILING) -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables -m64
>
> $(obj)/vclock_gettime.o: CFLAGS = $(CF)
> $(obj)/vgetcpu.o: CFLAGS = $(CF)
make -f scripts/Makefile.build obj=arch/x86_64/vdso
gcc -Wp,-MD,arch/x86_64/vdso/.vma.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vma)" -D"KBUILD_MODNAME=KBUILD_STR(vma)" -c -o arch/x86_64/vdso/vma.o arch/x86_64/vdso/vma.c
gcc -Wp,-MD,arch/x86_64/vdso/.vdso-start.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -D__ASSEMBLY__ -DCONFIG_AS_CFI=1 -m64 -c -o arch/x86_64/vdso/vdso-start.o arch/x86_64/vdso/vdso-start.S
gcc -Wp,-MD,arch/x86_64/vdso/.vdso-note.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -D__ASSEMBLY__ -DCONFIG_AS_CFI=1 -m64 -c -o arch/x86_64/vdso/vdso-note.o arch/x86_64/vdso/vdso-note.S
gcc -Wp,-MD,arch/x86_64/vdso/.vclock_gettime.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables -m64 -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vclock_gettime)" -D"KBUILD_MODNAME=KBUILD_STR(vclock_gettime)" -c -o arch/x86_64/vdso/vclock_gettime.o arch/x86_64/vdso/vclock_gettime.c
gcc -Wp,-MD,arch/x86_64/vdso/.vgetcpu.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables -m64 -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vgetcpu)" -D"KBUILD_MODNAME=KBUILD_STR(vgetcpu)" -c -o arch/x86_64/vdso/vgetcpu.o arch/x86_64/vdso/vgetcpu.c
gcc -Wp,-MD,arch/x86_64/vdso/.vvar.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vvar)" -D"KBUILD_MODNAME=KBUILD_STR(vvar)" -c -o arch/x86_64/vdso/vvar.o arch/x86_64/vdso/vvar.c
gcc -m elf_x86_64 -nostdlib -fPIC -shared -Wl,-soname=linux-vdso.so.1 -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 -Wl,-T,arch/x86_64/vdso/vdso.lds arch/x86_64/vdso/vdso-start.o arch/x86_64/vdso/vdso-note.o arch/x86_64/vdso/vclock_gettime.o arch/x86_64/vdso/vgetcpu.o arch/x86_64/vdso/vvar.o -o arch/x86_64/vdso/vdso.so
/usr/bin/ld: section .text [ffffffffff700400 -> ffffffffff700687] overlaps section .dynsym [ffffffffff7001d0 -> ffffffffff700427]
collect2: ld returned 1 exit status
make[1]: *** [arch/x86_64/vdso/vdso.so] Error 1
make: *** [arch/x86_64/vdso] Error 2
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error II
2007-04-26 14:39 ` Mel Gorman
@ 2007-04-26 15:20 ` Mel Gorman
2007-04-26 15:24 ` Andi Kleen
0 siblings, 1 reply; 135+ messages in thread
From: Mel Gorman @ 2007-04-26 15:20 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
On (26/04/07 15:39), Mel Gorman didst pronounce:
> On (26/04/07 16:13), Andi Kleen didst pronounce:
> > On Thursday 26 April 2007 15:27:36 Mel Gorman wrote:
> > > On (26/04/07 13:16), Andy Whitcroft didst pronounce:
> > > > Getting the following on an x86_64 numa box:
> > > >
> > > > CC arch/x86_64/vdso/vclock_gettime.o
> > > > arch/x86_64/vdso/vclock_gettime.c:1: error: code model `small' not
> > > > supported in the 32 bit mode
> > > > make[1]: *** [arch/x86_64/vdso/vclock_gettime.o] Error 1
> > > > make: *** [arch/x86_64/vdso] Error 2
> > > >
> > > > Kernel config here: http://test.kernel.org/abat/85358/build/dotconfig
> > > >
> > >
> > > Hi Andi,
> > >
> > > Backing out x86_64-mm-vdso.patch allowed this kernel to build and boot
> > > successful on the machine in question (elm3b6). The backout caused one reject
> > > in Documentation/kernel-parameters but otherwise backed out easily. It's
> > > not super-clear why it fails to build. If you want me to try another patch,
> > > make sure I'm cc'd and I'll give it a spin.
> >
> >
> > Or please try this simple patch.
> >
> > -Andi
> >
> > Index: linux/arch/x86_64/vdso/Makefile
> > ===================================================================
> > --- linux.orig/arch/x86_64/vdso/Makefile
> > +++ linux/arch/x86_64/vdso/Makefile
> > @@ -32,7 +32,7 @@ $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso
> > $(obj)/vdso.so: $(src)/vdso.lds $(vobjs) FORCE
> > $(call if_changed,syscall)
> >
> > -CF := $(PROFILING) -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables
> > +CF := $(PROFILING) -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables -m64
> >
> > $(obj)/vclock_gettime.o: CFLAGS = $(CF)
> > $(obj)/vgetcpu.o: CFLAGS = $(CF)
>
> make -f scripts/Makefile.build obj=arch/x86_64/vdso
> gcc -Wp,-MD,arch/x86_64/vdso/.vma.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vma)" -D"KBUILD_MODNAME=KBUILD_STR(vma)" -c -o arch/x86_64/vdso/vma.o arch/x86_64/vdso/vma.c
> gcc -Wp,-MD,arch/x86_64/vdso/.vdso-start.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -D__ASSEMBLY__ -DCONFIG_AS_CFI=1 -m64 -c -o arch/x86_64/vdso/vdso-start.o arch/x86_64/vdso/vdso-start.S
> gcc -Wp,-MD,arch/x86_64/vdso/.vdso-note.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -D__ASSEMBLY__ -DCONFIG_AS_CFI=1 -m64 -c -o arch/x86_64/vdso/vdso-note.o arch/x86_64/vdso/vdso-note.S
> gcc -Wp,-MD,arch/x86_64/vdso/.vclock_gettime.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables -m64 -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vclock_gettime)" -D"KBUILD_MODNAME=KBUILD_STR(vclock_gettime)" -c -o arch/x86_64/vdso/vclock_gettime.o arch/x86_64/vdso/vclock_gettime.c
> gcc -Wp,-MD,arch/x86_64/vdso/.vgetcpu.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables -m64 -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vgetcpu)" -D"KBUILD_MODNAME=KBUILD_STR(vgetcpu)" -c -o arch/x86_64/vdso/vgetcpu.o arch/x86_64/vdso/vgetcpu.c
> gcc -Wp,-MD,arch/x86_64/vdso/.vvar.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux/3.4.4/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vvar)" -D"KBUILD_MODNAME=KBUILD_STR(vvar)" -c -o arch/x86_64/vdso/vvar.o arch/x86_64/vdso/vvar.c
> gcc -m elf_x86_64 -nostdlib -fPIC -shared -Wl,-soname=linux-vdso.so.1 -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 -Wl,-T,arch/x86_64/vdso/vdso.lds arch/x86_64/vdso/vdso-start.o arch/x86_64/vdso/vdso-note.o arch/x86_64/vdso/vclock_gettime.o arch/x86_64/vdso/vgetcpu.o arch/x86_64/vdso/vvar.o -o arch/x86_64/vdso/vdso.so
> /usr/bin/ld: section .text [ffffffffff700400 -> ffffffffff700687] overlaps section .dynsym [ffffffffff7001d0 -> ffffffffff700427]
> collect2: ld returned 1 exit status
> make[1]: *** [arch/x86_64/vdso/vdso.so] Error 1
> make: *** [arch/x86_64/vdso] Error 2
>
If I add the following patch on top of yours, it builds and boots. It's
your call on whether it's a valid fix or not but it might point out the
Right Way to fix this
--- build/arch/x86_64/vdso/vdso.lds-orig 2007-04-26 08:18:19.000000000 -0700
+++ build/arch/x86_64/vdso/vdso.lds 2007-04-26 08:18:23.000000000 -0700
@@ -33,7 +33,7 @@
For the layouts to match, we need to skip more than enough
space for the dynamic symbol table et al. If this amount
is insufficient, ld -shared will barf. Just increase it here. */
- . = 0xffffffffff700000 + 0x500;
+ . = 0xffffffffff700000 + 0x400;
.text : { *(.text) } :text
.text.ptr : { *(.text.ptr) } :text
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error II
2007-04-26 15:20 ` Mel Gorman
@ 2007-04-26 15:24 ` Andi Kleen
2007-04-26 15:45 ` Mel Gorman
0 siblings, 1 reply; 135+ messages in thread
From: Andi Kleen @ 2007-04-26 15:24 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
> --- build/arch/x86_64/vdso/vdso.lds-orig 2007-04-26 08:18:19.000000000 -0700
> +++ build/arch/x86_64/vdso/vdso.lds 2007-04-26 08:18:23.000000000 -0700
> @@ -33,7 +33,7 @@
> For the layouts to match, we need to skip more than enough
> space for the dynamic symbol table et al. If this amount
> is insufficient, ld -shared will barf. Just increase it here. */
> - . = 0xffffffffff700000 + 0x500;
> + . = 0xffffffffff700000 + 0x400;
Hmm, you must have an old version of the patch. in my copy it looks like
. = VDSO_PRELINK + VDSO_TEXT_OFFSET;
and
#define VDSO_TEXT_OFFSET 0x400
Can you try the latest patch from ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/vdso
?
(doesn't include the -m64 change yet so you will still need to apply that)
-Andi
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error II
2007-04-26 15:24 ` Andi Kleen
@ 2007-04-26 15:45 ` Mel Gorman
2007-04-27 0:39 ` Andi Kleen
0 siblings, 1 reply; 135+ messages in thread
From: Mel Gorman @ 2007-04-26 15:45 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
On (26/04/07 17:24), Andi Kleen didst pronounce:
>
> > --- build/arch/x86_64/vdso/vdso.lds-orig 2007-04-26 08:18:19.000000000 -0700
> > +++ build/arch/x86_64/vdso/vdso.lds 2007-04-26 08:18:23.000000000 -0700
> > @@ -33,7 +33,7 @@
> > For the layouts to match, we need to skip more than enough
> > space for the dynamic symbol table et al. If this amount
> > is insufficient, ld -shared will barf. Just increase it here. */
> > - . = 0xffffffffff700000 + 0x500;
> > + . = 0xffffffffff700000 + 0x400;
>
> Hmm, you must have an old version of the patch. in my copy it looks like
>
> . = VDSO_PRELINK + VDSO_TEXT_OFFSET;
>
That's vdso.lds.S, not vdso.lds. The VDSO_TEXT_OFFSET is still 0x400.
This is what I should have posted the last time
--- build/arch/x86_64/vdso/voffset.h.orig 2007-04-26 08:43:31.523739878 -0700
+++ build/arch/x86_64/vdso/voffset.h 2007-04-26 08:43:38.839579356 -0700
@@ -1 +1 @@
-#define VDSO_TEXT_OFFSET 0x500
+#define VDSO_TEXT_OFFSET 0x400
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error II
2007-04-26 15:45 ` Mel Gorman
@ 2007-04-27 0:39 ` Andi Kleen
2007-04-27 8:59 ` Mel Gorman
0 siblings, 1 reply; 135+ messages in thread
From: Andi Kleen @ 2007-04-27 0:39 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
> That's vdso.lds.S, not vdso.lds. The VDSO_TEXT_OFFSET is still 0x400.
> This is what I should have posted the last time
>
> --- build/arch/x86_64/vdso/voffset.h.orig 2007-04-26 08:43:31.523739878 -0700
> +++ build/arch/x86_64/vdso/voffset.h 2007-04-26 08:43:38.839579356 -0700
> @@ -1 +1 @@
> -#define VDSO_TEXT_OFFSET 0x500
> +#define VDSO_TEXT_OFFSET 0x400
It's definitely 0x400 here. Is your patch reversed and you want 0x500?
-Andi
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 VDSO compile error II
2007-04-27 0:39 ` Andi Kleen
@ 2007-04-27 8:59 ` Mel Gorman
2007-04-27 15:50 ` [PATCH] Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu fix Mel Gorman
0 siblings, 1 reply; 135+ messages in thread
From: Mel Gorman @ 2007-04-27 8:59 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
On (27/04/07 02:39), Andi Kleen didst pronounce:
>
>
> > That's vdso.lds.S, not vdso.lds. The VDSO_TEXT_OFFSET is still 0x400.
> > This is what I should have posted the last time
> >
> > --- build/arch/x86_64/vdso/voffset.h.orig 2007-04-26 08:43:31.523739878 -0700
> > +++ build/arch/x86_64/vdso/voffset.h 2007-04-26 08:43:38.839579356 -0700
> > @@ -1 +1 @@
> > -#define VDSO_TEXT_OFFSET 0x500
> > +#define VDSO_TEXT_OFFSET 0x400
>
> It's definitely 0x400 here. Is your patch reversed and you want 0x500?
>
Sorry, that patch is reversed. It's 0x500 it needs to be to work here.
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH] Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu fix
2007-04-27 8:59 ` Mel Gorman
@ 2007-04-27 15:50 ` Mel Gorman
2007-04-27 16:34 ` Andi Kleen
0 siblings, 1 reply; 135+ messages in thread
From: Mel Gorman @ 2007-04-27 15:50 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
On (27/04/07 09:59), Mel Gorman didst pronounce:
> On (27/04/07 02:39), Andi Kleen didst pronounce:
> >
> >
> > > That's vdso.lds.S, not vdso.lds. The VDSO_TEXT_OFFSET is still 0x400.
> > > This is what I should have posted the last time
> > >
> > > --- build/arch/x86_64/vdso/voffset.h.orig 2007-04-26 08:43:31.523739878 -0700
> > > +++ build/arch/x86_64/vdso/voffset.h 2007-04-26 08:43:38.839579356 -0700
> > > @@ -1 +1 @@
> > > -#define VDSO_TEXT_OFFSET 0x500
> > > +#define VDSO_TEXT_OFFSET 0x400
> >
> > It's definitely 0x400 here. Is your patch reversed and you want 0x500?
> >
>
> Sorry, that patch is reversed. It's 0x500 it needs to be to work here.
>
What I should have done in the first place..... Sorry for the noise.
=======
The machine elm3b6 on test.kernel.org had problems with the patch
x86_64-mm-vdso.patch. The fix is two-fold. The first patch fixes a compile
problem by adding -m64. This patch updates VDSO_TEXT_OFFSET so that the
linker does not complain.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
voffset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21-rc7-mm2-quilt/arch/x86_64/vdso/voffset.h
===================================================================
--- linux-2.6.21-rc7-mm2-quilt.orig/arch/x86_64/vdso/voffset.h 2007-04-27 10:35:09.000000000 +0100
+++ linux-2.6.21-rc7-mm2-quilt/arch/x86_64/vdso/voffset.h 2007-04-27 10:35:12.000000000 +0100
@@ -1 +1 @@
-#define VDSO_TEXT_OFFSET 0x400
+#define VDSO_TEXT_OFFSET 0x500
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu fix
2007-04-27 15:50 ` [PATCH] Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu fix Mel Gorman
@ 2007-04-27 16:34 ` Andi Kleen
2007-04-27 16:49 ` Mel Gorman
0 siblings, 1 reply; 135+ messages in thread
From: Andi Kleen @ 2007-04-27 16:34 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft
On Friday 27 April 2007 17:50:06 Mel Gorman wrote:
> On (27/04/07 09:59), Mel Gorman didst pronounce:
> > On (27/04/07 02:39), Andi Kleen didst pronounce:
> > >
> > >
> > > > That's vdso.lds.S, not vdso.lds. The VDSO_TEXT_OFFSET is still 0x400.
> > > > This is what I should have posted the last time
> > > >
> > > > --- build/arch/x86_64/vdso/voffset.h.orig 2007-04-26 08:43:31.523739878 -0700
> > > > +++ build/arch/x86_64/vdso/voffset.h 2007-04-26 08:43:38.839579356 -0700
> > > > @@ -1 +1 @@
> > > > -#define VDSO_TEXT_OFFSET 0x500
> > > > +#define VDSO_TEXT_OFFSET 0x400
> > >
> > > It's definitely 0x400 here. Is your patch reversed and you want 0x500?
> > >
> >
> > Sorry, that patch is reversed. It's 0x500 it needs to be to work here.
> >
>
> What I should have done in the first place..... Sorry for the noise.
I had already fixed it up.
But now can you test Suresh's latest patch too please?
-Andi
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu fix
2007-04-27 16:34 ` Andi Kleen
@ 2007-04-27 16:49 ` Mel Gorman
0 siblings, 0 replies; 135+ messages in thread
From: Mel Gorman @ 2007-04-27 16:49 UTC (permalink / raw)
To: Andi Kleen
Cc: Andrew Morton, linux-kernel, Steve Fox, Andy Whitcroft, suresh.b.siddha
On (27/04/07 18:34), Andi Kleen didst pronounce:
> On Friday 27 April 2007 17:50:06 Mel Gorman wrote:
> > On (27/04/07 09:59), Mel Gorman didst pronounce:
> > > On (27/04/07 02:39), Andi Kleen didst pronounce:
> > > >
> > > >
> > > > > That's vdso.lds.S, not vdso.lds. The VDSO_TEXT_OFFSET is still 0x400.
> > > > > This is what I should have posted the last time
> > > > >
> > > > > --- build/arch/x86_64/vdso/voffset.h.orig 2007-04-26 08:43:31.523739878 -0700
> > > > > +++ build/arch/x86_64/vdso/voffset.h 2007-04-26 08:43:38.839579356 -0700
> > > > > @@ -1 +1 @@
> > > > > -#define VDSO_TEXT_OFFSET 0x500
> > > > > +#define VDSO_TEXT_OFFSET 0x400
> > > >
> > > > It's definitely 0x400 here. Is your patch reversed and you want 0x500?
> > > >
> > >
> > > Sorry, that patch is reversed. It's 0x500 it needs to be to work here.
> > >
> >
> > What I should have done in the first place..... Sorry for the noise.
>
> I had already fixed it up.
>
Cool
> But now can you test Suresh's latest patch too please?
I did earlier and it had merge problems. I had responded to the and I see
it in my sent-mail and Andy says he received it but it hasn't shown up on
lkml so somehow I screwed up. Here is the response again.
===== Rend earlier response =====
On (26/04/07 16:40), Siddha, Suresh B didst pronounce:
> On Thu, Apr 26, 2007 at 06:40:36PM +0100, Mel Gorman wrote:
> > NODE_DATA(0) was returning NULL because of
> > x86_64-set-node_possible_map-at-runtime.patch. This patch appears to
> > break acpi_scan_nodes() so that setup_node_bootmem() never gets called and
> > node_data[] remains full of zeros. Later on, reserve_bootmem_generic() is
> > called but with NODE_DATA(0) == NULL, it all goes pear shaped. Author of
> > patch cc'd.
>
> oops. Appended patch should fix this. Can you please check this and Ack it?
>
This patch does not apply cleanly to 2.6.21-rc7-mm2. Nor does
x86_64-set-node_possible_map-at-runtime.patch backout cleanly and when rejects
are fixed up, this patch still not apply cleanly . After fixing rejects
I ended up with the patch below that applies on top of 2.6.21-rc7-mm2. It
booted but it's not clear if the end result is what you intended. Could you
send a patch that applies cleanly on top of 2.6.21-rc7-mm2 and I'll give it
a test please? Thanks
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.21-rc7-mm2-clean/arch/x86_64/mm/numa.c linux-2.6.21-rc7-mm2-scratch/arch/x86_64/mm/numa.c
--- linux-2.6.21-rc7-mm2-clean/arch/x86_64/mm/numa.c 2007-04-27 10:24:47.000000000 +0100
+++ linux-2.6.21-rc7-mm2-scratch/arch/x86_64/mm/numa.c 2007-04-27 11:00:40.000000000 +0100
@@ -298,7 +298,7 @@ static int __init setup_node_range(int n
ret = -1;
}
nodes[nid].end = *addr;
- node_set(nid, node_possible_map);
+ node_set_online(nid);
printk(KERN_INFO "Faking node %d at %016Lx-%016Lx (%LuMB)\n", nid,
nodes[nid].start, nodes[nid].end,
(nodes[nid].end - nodes[nid].start) >> 20);
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.21-rc7-mm2-clean/arch/x86_64/mm/srat.c linux-2.6.21-rc7-mm2-scratch/arch/x86_64/mm/srat.c
--- linux-2.6.21-rc7-mm2-clean/arch/x86_64/mm/srat.c 2007-04-27 10:24:47.000000000 +0100
+++ linux-2.6.21-rc7-mm2-scratch/arch/x86_64/mm/srat.c 2007-04-27 10:58:33.000000000 +0100
@@ -25,6 +25,7 @@ int acpi_numa __initdata;
static struct acpi_table_slit *acpi_slit;
+static nodemask_t nodes_parsed __initdata;
static struct bootnode nodes[MAX_NUMNODES] __initdata;
static struct bootnode nodes_add[MAX_NUMNODES];
static int found_add_area __initdata;
@@ -42,7 +43,7 @@ static __init int setup_node(int pxm)
static __init int conflicting_nodes(unsigned long start, unsigned long end)
{
int i;
- for_each_node_mask(i, node_possible_map) {
+ for_each_node_mask(i, nodes_parsed) {
struct bootnode *nd = &nodes[i];
if (nd->start == nd->end)
continue;
@@ -320,7 +321,7 @@ acpi_numa_memory_affinity_init(struct ac
}
nd = &nodes[node];
oldnode = *nd;
- if (!node_test_and_set(node, node_possible_map)) {
+ if (!node_test_and_set(node, nodes_parsed)) {
nd->start = start;
nd->end = end;
} else {
@@ -343,7 +344,7 @@ acpi_numa_memory_affinity_init(struct ac
printk(KERN_NOTICE "SRAT: Hotplug region ignored\n");
*nd = oldnode;
if ((nd->start | nd->end) == 0)
- node_clear(node, node_possible_map);
+ node_clear(node, nodes_parsed);
}
}
@@ -355,7 +356,7 @@ static int nodes_cover_memory(void)
unsigned long pxmram, e820ram;
pxmram = 0;
- for_each_node_mask(i, node_possible_map) {
+ for_each_node_mask(i, nodes_parsed) {
unsigned long s = nodes[i].start >> PAGE_SHIFT;
unsigned long e = nodes[i].end >> PAGE_SHIFT;
pxmram += e - s;
@@ -379,7 +380,7 @@ static int nodes_cover_memory(void)
static void unparse_node(int node)
{
int i;
- node_clear(node, node_possible_map);
+ node_clear(node, nodes_parsed);
for (i = 0; i < MAX_LOCAL_APIC; i++) {
if (apicid_to_node[i] == node)
apicid_to_node[i] = NUMA_NO_NODE;
@@ -418,6 +419,8 @@ int __init acpi_scan_nodes(unsigned long
return -1;
}
+ node_possible_map = nodes_parsed;
+
/* Finally register nodes */
for_each_node_mask(i, node_possible_map)
setup_node_bootmem(i, nodes[i].start, nodes[i].end);
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 blade hard hangs
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
2007-04-26 11:47 ` 2.6.21-rc7-mm2 Gabriel C
2007-04-26 12:16 ` 2.6.21-rc7-mm2 -- x86_64 VDSO compile error Andy Whitcroft
@ 2007-04-26 12:30 ` Andy Whitcroft
2007-04-26 13:51 ` Andi Kleen
2007-04-26 13:17 ` 2.6.21-rc7-mm2 Andy Whitcroft
` (12 subsequent siblings)
15 siblings, 1 reply; 135+ messages in thread
From: Andy Whitcroft @ 2007-04-26 12:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Getting hard boot failures before any kernel output on an x86_64 blade:
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-autobench ro root=/dev/VolGroup00/LogVol00 rhgb
console=tty0 console=ttyS1,19200 selinux=no autobench_args:
root=30726124 ABAT:1177507960 profile=2
[Linux-bzImage, setup=0x1e00, size=0x21fe48]
initrd /initrd-autobench.img
[Linux-initrd @ 0x37e5f000, 0x190984 bytes]
[silence]
Kernel config is here:
http://test.kernel.org/abat/85082/build/dotconfig
-apw
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 -- x86_64 blade hard hangs
2007-04-26 12:30 ` 2.6.21-rc7-mm2 -- x86_64 blade hard hangs Andy Whitcroft
@ 2007-04-26 13:51 ` Andi Kleen
2007-04-26 13:33 ` Mel Gorman
0 siblings, 1 reply; 135+ messages in thread
From: Andi Kleen @ 2007-04-26 13:51 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linux-kernel
Andy Whitcroft <apw@shadowen.org> writes:
> Getting hard boot failures before any kernel output on an x86_64 blade:
>
> root (hd0,0)
> Filesystem type is ext2fs, partition type 0x83
> kernel /vmlinuz-autobench ro root=/dev/VolGroup00/LogVol00 rhgb
> console=tty0 console=ttyS1,19200 selinux=no autobench_args:
> root=30726124 ABAT:1177507960 profile=2
> [Linux-bzImage, setup=0x1e00, size=0x21fe48]
> initrd /initrd-autobench.img
> [Linux-initrd @ 0x37e5f000, 0x190984 bytes]
> [silence]
>
> Kernel config is here:
>
> http://test.kernel.org/abat/85082/build/dotconfig
You should boot with earlyprintk=serial,ttyS1,19200
-Andi
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 blade hard hangs
2007-04-26 13:51 ` Andi Kleen
@ 2007-04-26 13:33 ` Mel Gorman
2007-04-26 14:46 ` Mel Gorman
0 siblings, 1 reply; 135+ messages in thread
From: Mel Gorman @ 2007-04-26 13:33 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andy Whitcroft, Andrew Morton, linux-kernel
On (26/04/07 15:51), Andi Kleen didst pronounce:
> Andy Whitcroft <apw@shadowen.org> writes:
>
> > Getting hard boot failures before any kernel output on an x86_64 blade:
> >
> > root (hd0,0)
> > Filesystem type is ext2fs, partition type 0x83
> > kernel /vmlinuz-autobench ro root=/dev/VolGroup00/LogVol00 rhgb
> > console=tty0 console=ttyS1,19200 selinux=no autobench_args:
> > root=30726124 ABAT:1177507960 profile=2
> > [Linux-bzImage, setup=0x1e00, size=0x21fe48]
> > initrd /initrd-autobench.img
> > [Linux-initrd @ 0x37e5f000, 0x190984 bytes]
> > [silence]
> >
> > Kernel config is here:
> >
> > http://test.kernel.org/abat/85082/build/dotconfig
>
> You should boot with earlyprintk=serial,ttyS1,19200
>
Here is the console log. Haven't taken a closer look yet in case it's
blindingly obvious to you.
kernel /vmlinuz-autobench ro root=/dev/VolGroup00/LogVol00 rhgb
console=tty0 co
nsole=ttyS1,19200 selinux=no autobench_args: root=30726124
ABAT:1177594149 logl
evel=8 earlyprintk=serial,ttyS1,19200
[Linux-bzImage, setup=0x1e00, size=0x220da8]
initrd /initrd-autobench.img
[Linux-initrd @ 0x37e5f000, 0x190982 bytes]
Linux version 2.6.21-rc7-mm2-autokern1 (root@bl6-13.ltc.austin.ibm.com)
(gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Thu Apr 26
08:16:37 CDT 2007
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb console=tty0
console=ttyS1,19200 selinux=no autobench_args: root=30726124
ABAT:1177594149 loglevel=8 earlyprintk=serial,ttyS1,19200
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003ffcddc0 (usable)
BIOS-e820: 000000003ffcddc0 - 000000003ffd0000 (ACPI data)
BIOS-e820: 000000003ffd0000 - 0000000040000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
end_pfn_map = 1048576
kernel direct mapping tables up to 100000000 @ 8000-d000
DMI 2.3 present.
ACPI: RSDP 000FDFC0, 0014 (r0 IBM )
ACPI: RSDT 3FFCFF80, 0034 (r1 IBM SERBLADE 1000 IBM 45444F43)
ACPI: FACP 3FFCFEC0, 0084 (r2 IBM SERBLADE 1000 IBM 45444F43)
ACPI: DSDT 3FFCDDC0, 1EA6 (r1 IBM SERBLADE 1000 INTL 2002025)
ACPI: FACS 3FFCFCC0, 0040
ACPI: APIC 3FFCFE00, 009C (r1 IBM SERBLADE 1000 IBM 45444F43)
ACPI: SRAT 3FFCFD40, 0098 (r1 IBM SERBLADE 1000 IBM 45444F43)
ACPI: HPET 3FFCFD00, 0038 (r1 IBM SERBLADE 1000 IBM 45444F43)
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: PXM 1 -> APIC 2 -> Node 1
SRAT: PXM 1 -> APIC 3 -> Node 1
SRAT: Node 0 PXM 0 0-40000000
PANIC: early exception rip ffffffff808a7e83 error 0 cr2 5cf0
Call Trace:
[<ffffffff808a7e83>] reserve_bootmem_node+0x0/0xc
[<ffffffff808a3a8c>] reserve_bootmem_generic+0x6d/0x99
[<ffffffff8089cc00>] setup_arch+0x2f7/0x469
[<ffffffff80896510>] start_kernel+0x64/0x2aa
[<ffffffff80896148>] _sinittext+0x148/0x14c
RIP reserve_bootmem_node+0x0/0xc
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 blade hard hangs
2007-04-26 13:33 ` Mel Gorman
@ 2007-04-26 14:46 ` Mel Gorman
2007-04-26 17:40 ` Mel Gorman
0 siblings, 1 reply; 135+ messages in thread
From: Mel Gorman @ 2007-04-26 14:46 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andy Whitcroft, Andrew Morton, linux-kernel
On (26/04/07 14:33), Mel Gorman didst pronounce:
> On (26/04/07 15:51), Andi Kleen didst pronounce:
> > Andy Whitcroft <apw@shadowen.org> writes:
> >
> > > Getting hard boot failures before any kernel output on an x86_64 blade:
> > >
> > > root (hd0,0)
> > > Filesystem type is ext2fs, partition type 0x83
> > > kernel /vmlinuz-autobench ro root=/dev/VolGroup00/LogVol00 rhgb
> > > console=tty0 console=ttyS1,19200 selinux=no autobench_args:
> > > root=30726124 ABAT:1177507960 profile=2
> > > [Linux-bzImage, setup=0x1e00, size=0x21fe48]
> > > initrd /initrd-autobench.img
> > > [Linux-initrd @ 0x37e5f000, 0x190984 bytes]
> > > [silence]
> > >
> > > Kernel config is here:
> > >
> > > http://test.kernel.org/abat/85082/build/dotconfig
> >
> > You should boot with earlyprintk=serial,ttyS1,19200
> >
>
> Here is the console log. Haven't taken a closer look yet in case it's
> blindingly obvious to you.
>
> kernel /vmlinuz-autobench ro root=/dev/VolGroup00/LogVol00 rhgb
> console=tty0 co
> nsole=ttyS1,19200 selinux=no autobench_args: root=30726124
> ABAT:1177594149 logl
> evel=8 earlyprintk=serial,ttyS1,19200
> [Linux-bzImage, setup=0x1e00, size=0x220da8]
> initrd /initrd-autobench.img
> [Linux-initrd @ 0x37e5f000, 0x190982 bytes]
> Linux version 2.6.21-rc7-mm2-autokern1 (root@bl6-13.ltc.austin.ibm.com)
> (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Thu Apr 26
> 08:16:37 CDT 2007
> Command line: ro root=/dev/VolGroup00/LogVol00 rhgb console=tty0
> console=ttyS1,19200 selinux=no autobench_args: root=30726124
> ABAT:1177594149 loglevel=8 earlyprintk=serial,ttyS1,19200
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
> BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000003ffcddc0 (usable)
> BIOS-e820: 000000003ffcddc0 - 000000003ffd0000 (ACPI data)
> BIOS-e820: 000000003ffd0000 - 0000000040000000 (reserved)
> BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
> end_pfn_map = 1048576
> kernel direct mapping tables up to 100000000 @ 8000-d000
> DMI 2.3 present.
> ACPI: RSDP 000FDFC0, 0014 (r0 IBM )
> ACPI: RSDT 3FFCFF80, 0034 (r1 IBM SERBLADE 1000 IBM 45444F43)
> ACPI: FACP 3FFCFEC0, 0084 (r2 IBM SERBLADE 1000 IBM 45444F43)
> ACPI: DSDT 3FFCDDC0, 1EA6 (r1 IBM SERBLADE 1000 INTL 2002025)
> ACPI: FACS 3FFCFCC0, 0040
> ACPI: APIC 3FFCFE00, 009C (r1 IBM SERBLADE 1000 IBM 45444F43)
> ACPI: SRAT 3FFCFD40, 0098 (r1 IBM SERBLADE 1000 IBM 45444F43)
> ACPI: HPET 3FFCFD00, 0038 (r1 IBM SERBLADE 1000 IBM 45444F43)
> SRAT: PXM 0 -> APIC 0 -> Node 0
> SRAT: PXM 0 -> APIC 1 -> Node 0
> SRAT: PXM 1 -> APIC 2 -> Node 1
> SRAT: PXM 1 -> APIC 3 -> Node 1
> SRAT: Node 0 PXM 0 0-40000000
> PANIC: early exception rip ffffffff808a7e83 error 0 cr2 5cf0
> Call Trace:
> [<ffffffff808a7e83>] reserve_bootmem_node+0x0/0xc
> [<ffffffff808a3a8c>] reserve_bootmem_generic+0x6d/0x99
> [<ffffffff8089cc00>] setup_arch+0x2f7/0x469
> [<ffffffff80896510>] start_kernel+0x64/0x2aa
> [<ffffffff80896148>] _sinittext+0x148/0x14c
> RIP reserve_bootmem_node+0x0/0xc
>
When I looked closer, nothing seemed to make sense so here is another
log with stack unwinder, frame pointer etc etc
PANIC: early exception rip ffffffff8095a873 error 0 cr2 5cf0
Call Trace:
[<ffffffff8020b174>] dump_trace+0xb6/0x3d8
[<ffffffff8020b4d2>] show_trace+0x3c/0x52
[<ffffffff8020b4fd>] dump_stack+0x15/0x17
[<ffffffff802001e7>]
DWARF2 unwinder stuck at 0xffffffff802001e7
Leftover inexact backtrace:
[<ffffffff8095a873>] reserve_bootmem_node+0x1/0x12
[<ffffffff8096114f>] acpi_table_parse+0x4f/0x69
[<ffffffff80955f91>] reserve_bootmem_generic+0x73/0x9e
[<ffffffff8094edd3>] setup_arch+0x301/0x49c
[<ffffffff8094855f>] start_kernel+0x6c/0x30b
[<ffffffff80948144>] _sinittext+0x144/0x14b
RIP reserve_bootmem_node+0x1/0x12
Will keep kicking.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- x86_64 blade hard hangs
2007-04-26 14:46 ` Mel Gorman
@ 2007-04-26 17:40 ` Mel Gorman
[not found] ` <20070426234002.GH5475@linux-os.sc.intel.com>
0 siblings, 1 reply; 135+ messages in thread
From: Mel Gorman @ 2007-04-26 17:40 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andy Whitcroft, Andrew Morton, linux-kernel, suresh.b.siddha
On (26/04/07 15:46), Mel Gorman didst pronounce:
> On (26/04/07 14:33), Mel Gorman didst pronounce:
> > On (26/04/07 15:51), Andi Kleen didst pronounce:
> > > Andy Whitcroft <apw@shadowen.org> writes:
> > >
> > > > Getting hard boot failures before any kernel output on an x86_64 blade:
> > > >
> > > > root (hd0,0)
> > > > Filesystem type is ext2fs, partition type 0x83
> > > > kernel /vmlinuz-autobench ro root=/dev/VolGroup00/LogVol00 rhgb
> > > > console=tty0 console=ttyS1,19200 selinux=no autobench_args:
> > > > root=30726124 ABAT:1177507960 profile=2
> > > > [Linux-bzImage, setup=0x1e00, size=0x21fe48]
> > > > initrd /initrd-autobench.img
> > > > [Linux-initrd @ 0x37e5f000, 0x190984 bytes]
> > > > [silence]
> > > >
> > > > Kernel config is here:
> > > >
> > > > http://test.kernel.org/abat/85082/build/dotconfig
> > >
> > > You should boot with earlyprintk=serial,ttyS1,19200
> > >
> >
> > Here is the console log. Haven't taken a closer look yet in case it's
> > blindingly obvious to you.
> >
> > kernel /vmlinuz-autobench ro root=/dev/VolGroup00/LogVol00 rhgb
> > console=tty0 co
> > nsole=ttyS1,19200 selinux=no autobench_args: root=30726124
> > ABAT:1177594149 logl
> > evel=8 earlyprintk=serial,ttyS1,19200
> > [Linux-bzImage, setup=0x1e00, size=0x220da8]
> > initrd /initrd-autobench.img
> > [Linux-initrd @ 0x37e5f000, 0x190982 bytes]
> > Linux version 2.6.21-rc7-mm2-autokern1 (root@bl6-13.ltc.austin.ibm.com)
> > (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Thu Apr 26
> > 08:16:37 CDT 2007
> > Command line: ro root=/dev/VolGroup00/LogVol00 rhgb console=tty0
> > console=ttyS1,19200 selinux=no autobench_args: root=30726124
> > ABAT:1177594149 loglevel=8 earlyprintk=serial,ttyS1,19200
> > BIOS-provided physical RAM map:
> > BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
> > BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
> > BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> > BIOS-e820: 0000000000100000 - 000000003ffcddc0 (usable)
> > BIOS-e820: 000000003ffcddc0 - 000000003ffd0000 (ACPI data)
> > BIOS-e820: 000000003ffd0000 - 0000000040000000 (reserved)
> > BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
> > end_pfn_map = 1048576
> > kernel direct mapping tables up to 100000000 @ 8000-d000
> > DMI 2.3 present.
> > ACPI: RSDP 000FDFC0, 0014 (r0 IBM )
> > ACPI: RSDT 3FFCFF80, 0034 (r1 IBM SERBLADE 1000 IBM 45444F43)
> > ACPI: FACP 3FFCFEC0, 0084 (r2 IBM SERBLADE 1000 IBM 45444F43)
> > ACPI: DSDT 3FFCDDC0, 1EA6 (r1 IBM SERBLADE 1000 INTL 2002025)
> > ACPI: FACS 3FFCFCC0, 0040
> > ACPI: APIC 3FFCFE00, 009C (r1 IBM SERBLADE 1000 IBM 45444F43)
> > ACPI: SRAT 3FFCFD40, 0098 (r1 IBM SERBLADE 1000 IBM 45444F43)
> > ACPI: HPET 3FFCFD00, 0038 (r1 IBM SERBLADE 1000 IBM 45444F43)
> > SRAT: PXM 0 -> APIC 0 -> Node 0
> > SRAT: PXM 0 -> APIC 1 -> Node 0
> > SRAT: PXM 1 -> APIC 2 -> Node 1
> > SRAT: PXM 1 -> APIC 3 -> Node 1
> > SRAT: Node 0 PXM 0 0-40000000
> > PANIC: early exception rip ffffffff808a7e83 error 0 cr2 5cf0
> > Call Trace:
> > [<ffffffff808a7e83>] reserve_bootmem_node+0x0/0xc
> > [<ffffffff808a3a8c>] reserve_bootmem_generic+0x6d/0x99
> > [<ffffffff8089cc00>] setup_arch+0x2f7/0x469
> > [<ffffffff80896510>] start_kernel+0x64/0x2aa
> > [<ffffffff80896148>] _sinittext+0x148/0x14c
> > RIP reserve_bootmem_node+0x0/0xc
> >
>
> When I looked closer, nothing seemed to make sense so here is another
> log with stack unwinder, frame pointer etc etc
>
> PANIC: early exception rip ffffffff8095a873 error 0 cr2 5cf0
>
> Call Trace:
> [<ffffffff8020b174>] dump_trace+0xb6/0x3d8
> [<ffffffff8020b4d2>] show_trace+0x3c/0x52
> [<ffffffff8020b4fd>] dump_stack+0x15/0x17
> [<ffffffff802001e7>]
> DWARF2 unwinder stuck at 0xffffffff802001e7
> Leftover inexact backtrace:
> [<ffffffff8095a873>] reserve_bootmem_node+0x1/0x12
> [<ffffffff8096114f>] acpi_table_parse+0x4f/0x69
> [<ffffffff80955f91>] reserve_bootmem_generic+0x73/0x9e
> [<ffffffff8094edd3>] setup_arch+0x301/0x49c
> [<ffffffff8094855f>] start_kernel+0x6c/0x30b
> [<ffffffff80948144>] _sinittext+0x144/0x14b
>
> RIP reserve_bootmem_node+0x1/0x12
>
> Will keep kicking.
>
NODE_DATA(0) was returning NULL because of
x86_64-set-node_possible_map-at-runtime.patch. This patch appears to
break acpi_scan_nodes() so that setup_node_bootmem() never gets called and
node_data[] remains full of zeros. Later on, reserve_bootmem_generic() is
called but with NODE_DATA(0) == NULL, it all goes pear shaped. Author of
patch cc'd.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (2 preceding siblings ...)
2007-04-26 12:30 ` 2.6.21-rc7-mm2 -- x86_64 blade hard hangs Andy Whitcroft
@ 2007-04-26 13:17 ` Andy Whitcroft
2007-04-26 13:41 ` 2.6.21-rc7-mm2 -- PPC link failure Andy Whitcroft
2007-04-26 18:25 ` [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2 Borislav Petkov
` (11 subsequent siblings)
15 siblings, 1 reply; 135+ messages in thread
From: Andy Whitcroft @ 2007-04-26 13:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Getting a link failure on a ppc64 system:
LD .tmp_vmlinux1
init/built-in.o(.init.text+0x32e4): In function `.rd_load_image':
: undefined reference to `.__kmalloc_size_too_large'
fs/built-in.o(.text+0xa6fe0): In function `.ext3_fill_super':
: undefined reference to `.__kmalloc_size_too_large'
fs/built-in.o(.text+0xc1fe0): In function `.ext2_fill_super':
: undefined reference to `.__kmalloc_size_too_large'
fs/built-in.o(.text+0xf6a1c): In function `.nfs4_proc_lookup':
: undefined reference to `.__kmalloc_size_too_large'
fs/built-in.o(.text+0x104104): In function `.nfs_idmap_new':
: undefined reference to `.__kmalloc_size_too_large'
fs/built-in.o(.text+0x105520): more undefined references to
`.__kmalloc_size_too_large' follow
make: *** [.tmp_vmlinux1] Error 1
Kernel config:
http://test.kernel.org/abat/85342/build/dotconfig
-apw
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 -- PPC link failure
2007-04-26 13:17 ` 2.6.21-rc7-mm2 Andy Whitcroft
@ 2007-04-26 13:41 ` Andy Whitcroft
2007-04-26 18:14 ` Andy Whitcroft
0 siblings, 1 reply; 135+ messages in thread
From: Andy Whitcroft @ 2007-04-26 13:41 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linux-kernel, Christoph Lameter
Andy Whitcroft wrote:
> Getting a link failure on a ppc64 system:
>
> LD .tmp_vmlinux1
> init/built-in.o(.init.text+0x32e4): In function `.rd_load_image':
> : undefined reference to `.__kmalloc_size_too_large'
> fs/built-in.o(.text+0xa6fe0): In function `.ext3_fill_super':
> : undefined reference to `.__kmalloc_size_too_large'
> fs/built-in.o(.text+0xc1fe0): In function `.ext2_fill_super':
> : undefined reference to `.__kmalloc_size_too_large'
> fs/built-in.o(.text+0xf6a1c): In function `.nfs4_proc_lookup':
> : undefined reference to `.__kmalloc_size_too_large'
> fs/built-in.o(.text+0x104104): In function `.nfs_idmap_new':
> : undefined reference to `.__kmalloc_size_too_large'
> fs/built-in.o(.text+0x105520): more undefined references to
> `.__kmalloc_size_too_large' follow
> make: *** [.tmp_vmlinux1] Error 1
Ok, this is a SLUB related link failure. Am investigating if PPC simply
needs larger allocs and needs CONFIG_LARGE_ALLOCS, of if this is an
inlining issue.
-apw
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- PPC link failure
2007-04-26 13:41 ` 2.6.21-rc7-mm2 -- PPC link failure Andy Whitcroft
@ 2007-04-26 18:14 ` Andy Whitcroft
2007-04-26 18:27 ` Christoph Lameter
0 siblings, 1 reply; 135+ messages in thread
From: Andy Whitcroft @ 2007-04-26 18:14 UTC (permalink / raw)
To: Andrew Morton, Christoph Lameter; +Cc: Andy Whitcroft, linux-kernel
Andy Whitcroft wrote:
> Andy Whitcroft wrote:
>> Getting a link failure on a ppc64 system:
>>
>> LD .tmp_vmlinux1
>> init/built-in.o(.init.text+0x32e4): In function `.rd_load_image':
>> : undefined reference to `.__kmalloc_size_too_large'
>> fs/built-in.o(.text+0xa6fe0): In function `.ext3_fill_super':
>> : undefined reference to `.__kmalloc_size_too_large'
>> fs/built-in.o(.text+0xc1fe0): In function `.ext2_fill_super':
>> : undefined reference to `.__kmalloc_size_too_large'
>> fs/built-in.o(.text+0xf6a1c): In function `.nfs4_proc_lookup':
>> : undefined reference to `.__kmalloc_size_too_large'
>> fs/built-in.o(.text+0x104104): In function `.nfs_idmap_new':
>> : undefined reference to `.__kmalloc_size_too_large'
>> fs/built-in.o(.text+0x105520): more undefined references to
>> `.__kmalloc_size_too_large' follow
>> make: *** [.tmp_vmlinux1] Error 1
>
> Ok, this is a SLUB related link failure. Am investigating if PPC simply
> needs larger allocs and needs CONFIG_LARGE_ALLOCS, of if this is an
> inlining issue.
Ok this is confirmed as an inlining issue. With the compiler below on
ppc64 we get the above link failure:
gcc version 3.3.3 (SuSE Linux)
What seems to happen is that although the optimiser is capable of
collapsing the kmalloc_index() call it then fails to collapse
kmalloc_slab(). This leads to the never used reference to
__kmalloc_size_too_large() and the link failure. From my testing this
seems to occur at sizes >= 32k. At 16k all of the code collapses
correctly, at 32k it does not. I am not entirely sure what to think at
this point, it is cirtainly not at all clear why the 32k version fails
and the 16k succeeds they are almost identical.
Either way it seems to me that assuming the optimiser will remove the
code is perhaps over optimistic. Perhaps it would make more sense to
put a BUG() in here. Though that points out the anomaly that the
kmalloc() for constants has different semantics to that for variable values?
Comments?
-apw
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- PPC link failure
2007-04-26 18:14 ` Andy Whitcroft
@ 2007-04-26 18:27 ` Christoph Lameter
2007-04-26 18:40 ` Andy Whitcroft
0 siblings, 1 reply; 135+ messages in thread
From: Christoph Lameter @ 2007-04-26 18:27 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linux-kernel
On Thu, 26 Apr 2007, Andy Whitcroft wrote:
> > Ok, this is a SLUB related link failure. Am investigating if PPC simply
> > needs larger allocs and needs CONFIG_LARGE_ALLOCS, of if this is an
> > inlining issue.
>
> Ok this is confirmed as an inlining issue. With the compiler below on
> ppc64 we get the above link failure:
>
> gcc version 3.3.3 (SuSE Linux)
>
> What seems to happen is that although the optimiser is capable of
> collapsing the kmalloc_index() call it then fails to collapse
> kmalloc_slab(). This leads to the never used reference to
> __kmalloc_size_too_large() and the link failure. From my testing this
> seems to occur at sizes >= 32k. At 16k all of the code collapses
Interesting. Why would that boundary be of relevance to the compiler? Some
offset heuristics?
> correctly, at 32k it does not. I am not entirely sure what to think at
> this point, it is cirtainly not at all clear why the 32k version fails
> and the 16k succeeds they are almost identical.
Likely a backend optimization issue.
> Either way it seems to me that assuming the optimiser will remove the
> code is perhaps over optimistic. Perhaps it would make more sense to
> put a BUG() in here. Though that points out the anomaly that the
> kmalloc() for constants has different semantics to that for variable values?
Yes but that has always been the case. We want to reduce kmalloc for
constants at compile time to use the appropriate kmalloc cache. If kmalloc
does not use a constant then we will do run time determination of the
kmalloc cache.
The code in SLAB is easier to fold since it does not use a subroutine call.
We could simply #ifdef out the __kmalloc_sizes_too_large for ppc and let
it fall back to __kmalloc? That would mean only that kmallocs >32k
would require an additional determination of the kmalloc cache at run
time.
But then how important is gcc 3.3 support?
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- PPC link failure
2007-04-26 18:27 ` Christoph Lameter
@ 2007-04-26 18:40 ` Andy Whitcroft
2007-04-26 18:49 ` Christoph Lameter
2007-04-26 19:12 ` Christoph Lameter
0 siblings, 2 replies; 135+ messages in thread
From: Andy Whitcroft @ 2007-04-26 18:40 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
Christoph Lameter wrote:
> On Thu, 26 Apr 2007, Andy Whitcroft wrote:
>
>>> Ok, this is a SLUB related link failure. Am investigating if PPC simply
>>> needs larger allocs and needs CONFIG_LARGE_ALLOCS, of if this is an
>>> inlining issue.
>> Ok this is confirmed as an inlining issue. With the compiler below on
>> ppc64 we get the above link failure:
>>
>> gcc version 3.3.3 (SuSE Linux)
>>
>> What seems to happen is that although the optimiser is capable of
>> collapsing the kmalloc_index() call it then fails to collapse
>> kmalloc_slab(). This leads to the never used reference to
>> __kmalloc_size_too_large() and the link failure. From my testing this
>> seems to occur at sizes >= 32k. At 16k all of the code collapses
>
> Interesting. Why would that boundary be of relevance to the compiler? Some
> offset heuristics?
>
>> correctly, at 32k it does not. I am not entirely sure what to think at
>> this point, it is cirtainly not at all clear why the 32k version fails
>> and the 16k succeeds they are almost identical.
>
> Likely a backend optimization issue.
>
>> Either way it seems to me that assuming the optimiser will remove the
>> code is perhaps over optimistic. Perhaps it would make more sense to
>> put a BUG() in here. Though that points out the anomaly that the
>> kmalloc() for constants has different semantics to that for variable values?
>
> Yes but that has always been the case. We want to reduce kmalloc for
> constants at compile time to use the appropriate kmalloc cache. If kmalloc
> does not use a constant then we will do run time determination of the
> kmalloc cache.
>
> The code in SLAB is easier to fold since it does not use a subroutine call.
>
> We could simply #ifdef out the __kmalloc_sizes_too_large for ppc and let
> it fall back to __kmalloc? That would mean only that kmallocs >32k
> would require an additional determination of the kmalloc cache at run
> time.
>
> But then how important is gcc 3.3 support?
Well we say 3.2 is the minimum. If we simply return(NULL) or BUG() in
that branch the generated code actually works and is mostly optimised
away. We end up with the assembly equivalent of:
index = 15;
if (index == 0)
return NULL;
if (index < 0)
__kmalloc_sizes_too_large();
return &kmalloc_caches[index];
The code is functionally correct, just stupid as clearly the if's can
never trigger. We do not need to lose the constant optimisation, its
just that the clever attempt to get a link error fails on this compiler.
I am inclined to suggest we change it for BUG:
BUG(index < 0);
Perhaps only on older compilers.
-apw
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- PPC link failure
2007-04-26 18:40 ` Andy Whitcroft
@ 2007-04-26 18:49 ` Christoph Lameter
2007-04-26 19:12 ` Christoph Lameter
1 sibling, 0 replies; 135+ messages in thread
From: Christoph Lameter @ 2007-04-26 18:49 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linux-kernel
On Thu, 26 Apr 2007, Andy Whitcroft wrote:
> I am inclined to suggest we change it for BUG:
>
> BUG(index < 0);
>
> Perhaps only on older compilers.
I'd be fine with that solution.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- PPC link failure
2007-04-26 18:40 ` Andy Whitcroft
2007-04-26 18:49 ` Christoph Lameter
@ 2007-04-26 19:12 ` Christoph Lameter
2007-04-26 19:48 ` Andy Whitcroft
1 sibling, 1 reply; 135+ messages in thread
From: Christoph Lameter @ 2007-04-26 19:12 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linux-kernel
On Thu, 26 Apr 2007, Andy Whitcroft wrote:
> > But then how important is gcc 3.3 support?
>
> Well we say 3.2 is the minimum. If we simply return(NULL) or BUG() in
Oh before I forget
Gcc 3.3 works just fine on other platforms like i386. This is more likely
a platform issue. If we disable it then only for <= gcc 3.3 on ppc. If
problems crop up with other platforms then we can expand on it.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- PPC link failure
2007-04-26 19:12 ` Christoph Lameter
@ 2007-04-26 19:48 ` Andy Whitcroft
2007-04-26 20:23 ` Christoph Lameter
0 siblings, 1 reply; 135+ messages in thread
From: Andy Whitcroft @ 2007-04-26 19:48 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
Christoph Lameter wrote:
> On Thu, 26 Apr 2007, Andy Whitcroft wrote:
>
>>> But then how important is gcc 3.3 support?
>> Well we say 3.2 is the minimum. If we simply return(NULL) or BUG() in
>
> Oh before I forget
>
> Gcc 3.3 works just fine on other platforms like i386. This is more likely
> a platform issue. If we disable it then only for <= gcc 3.3 on ppc. If
> problems crop up with other platforms then we can expand on it.
I was thinking that it would be nasty to have a set of platform
specific, compiler specific ifdefs in here. I was more thinking of just
making this a BUG for all platforms. This does result in slightly later
detection but this is a constant mode only, so any bad use of kmalloc()
would be picked up on first boot in testing always.
I think that would be sufficient and safe even against the worst
optimiser (none). Plus much less horrible to look at?
-apw
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- PPC link failure
2007-04-26 19:48 ` Andy Whitcroft
@ 2007-04-26 20:23 ` Christoph Lameter
2007-04-27 16:55 ` Andy Whitcroft
0 siblings, 1 reply; 135+ messages in thread
From: Christoph Lameter @ 2007-04-26 20:23 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linux-kernel
On Thu, 26 Apr 2007, Andy Whitcroft wrote:
> > Gcc 3.3 works just fine on other platforms like i386. This is more likely
> > a platform issue. If we disable it then only for <= gcc 3.3 on ppc. If
> > problems crop up with other platforms then we can expand on it.
>
> I was thinking that it would be nasty to have a set of platform
> specific, compiler specific ifdefs in here. I was more thinking of just
> making this a BUG for all platforms. This does result in slightly later
> detection but this is a constant mode only, so any bad use of kmalloc()
> would be picked up on first boot in testing always.
>
> I think that would be sufficient and safe even against the worst
> optimiser (none). Plus much less horrible to look at?
The build time detection is quite important for NUMA since structures keep
growing. I'd like to keep that. In fact I would really like a build time
detection. If a too large kmalloc occurs then the compile should stop at
that point and the kernel should not link at all.
See my patch @ http://marc.info/?l=linux-kernel&m=117752927203466&w=2
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- PPC link failure
2007-04-26 20:23 ` Christoph Lameter
@ 2007-04-27 16:55 ` Andy Whitcroft
2007-04-27 16:58 ` Christoph Lameter
0 siblings, 1 reply; 135+ messages in thread
From: Andy Whitcroft @ 2007-04-27 16:55 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
Christoph Lameter wrote:
> On Thu, 26 Apr 2007, Andy Whitcroft wrote:
>
>>> Gcc 3.3 works just fine on other platforms like i386. This is more likely
>>> a platform issue. If we disable it then only for <= gcc 3.3 on ppc. If
>>> problems crop up with other platforms then we can expand on it.
>> I was thinking that it would be nasty to have a set of platform
>> specific, compiler specific ifdefs in here. I was more thinking of just
>> making this a BUG for all platforms. This does result in slightly later
>> detection but this is a constant mode only, so any bad use of kmalloc()
>> would be picked up on first boot in testing always.
>>
>> I think that would be sufficient and safe even against the worst
>> optimiser (none). Plus much less horrible to look at?
>
> The build time detection is quite important for NUMA since structures keep
> growing. I'd like to keep that. In fact I would really like a build time
> detection. If a too large kmalloc occurs then the compile should stop at
> that point and the kernel should not link at all.
>
> See my patch @ http://marc.info/?l=linux-kernel&m=117752927203466&w=2
Yeah I played with that for a bit last night to no good effect.
BUILD_BUG_ON simply becomes a noop if the optimiser doesn't really
really know that the thing its talking about is a real constant.
I assume that if it cannot be sure that it should constant fold the
number, it leaves it for runtime. Then the optimiser sees that the
thing is void and therefore removable and removes it. So no error.
Perhaps we need to enlist someone from gcc-land to tell us how to figure
out what its doing and massage it into working.
-apw
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 -- PPC link failure
2007-04-27 16:55 ` Andy Whitcroft
@ 2007-04-27 16:58 ` Christoph Lameter
0 siblings, 0 replies; 135+ messages in thread
From: Christoph Lameter @ 2007-04-27 16:58 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linux-kernel
On Fri, 27 Apr 2007, Andy Whitcroft wrote:
> > See my patch @ http://marc.info/?l=linux-kernel&m=117752927203466&w=2
>
> Yeah I played with that for a bit last night to no good effect.
> BUILD_BUG_ON simply becomes a noop if the optimiser doesn't really
> really know that the thing its talking about is a real constant.
Too bad. Sigh.
> I assume that if it cannot be sure that it should constant fold the
> number, it leaves it for runtime. Then the optimiser sees that the
> thing is void and therefore removable and removes it. So no error.
>
> Perhaps we need to enlist someone from gcc-land to tell us how to figure
> out what its doing and massage it into working.
In the meantime how about moving that generation of the link err out of
SLUB and SLAB into kernel.h and make some BUILD_BUG() or so out of it? We
are talking about some generically useful functionality I guess.
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (3 preceding siblings ...)
2007-04-26 13:17 ` 2.6.21-rc7-mm2 Andy Whitcroft
@ 2007-04-26 18:25 ` Borislav Petkov
2007-04-28 0:22 ` Andrew Morton
2007-04-26 23:47 ` [-mm patch] make drivers/hwmon/applesmc.c:backlight_work static Adrian Bunk
` (10 subsequent siblings)
15 siblings, 1 reply; 135+ messages in thread
From: Borislav Petkov @ 2007-04-26 18:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Remove build warning mm/memory.c:1491: warning: 'ptl' may be used uninitialized in this function.
The spinlock pointer is assigned to null since it gets overwritten right away in
pte_alloc_map_lock().
Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
---
Index: linux-mm/mm/memory.c
===================================================================
--- linux-mm.orig/mm/memory.c 2007-04-26 19:57:14.000000000 +0200
+++ linux-mm/mm/memory.c 2007-04-26 20:00:30.000000000 +0200
@@ -1488,7 +1488,7 @@
pte_t *pte;
int err;
struct page *pmd_page;
- spinlock_t *ptl;
+ spinlock_t *ptl = NULL;
pte = (mm == &init_mm) ?
pte_alloc_kernel(pmd, addr) :
--
Regards/Gruß,
Boris.
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-26 18:25 ` [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2 Borislav Petkov
@ 2007-04-28 0:22 ` Andrew Morton
2007-04-28 0:27 ` Jeremy Fitzhardinge
` (2 more replies)
0 siblings, 3 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-28 0:22 UTC (permalink / raw)
To: bbpetkov; +Cc: linux-kernel, Jeremy Fitzhardinge
On Thu, 26 Apr 2007 20:25:19 +0200
Borislav Petkov <bbpetkov@yahoo.de> wrote:
>
> Remove build warning mm/memory.c:1491: warning: 'ptl' may be used uninitialized in this function.
> The spinlock pointer is assigned to null since it gets overwritten right away in
> pte_alloc_map_lock().
>
> Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
> ---
>
> Index: linux-mm/mm/memory.c
> ===================================================================
> --- linux-mm.orig/mm/memory.c 2007-04-26 19:57:14.000000000 +0200
> +++ linux-mm/mm/memory.c 2007-04-26 20:00:30.000000000 +0200
> @@ -1488,7 +1488,7 @@
> pte_t *pte;
> int err;
> struct page *pmd_page;
> - spinlock_t *ptl;
> + spinlock_t *ptl = NULL;
>
> pte = (mm == &init_mm) ?
> pte_alloc_kernel(pmd, addr) :
>
yes, I've been staring unhappily at this for some time.
Your change adds seven bytes of text to this function for no runtime
benefit, just to fix a build-time warning. It's a general problem.
Often we just leave the warning in place and curse gcc each time it flies
past. Sometimes the code can be restructured in a sensible fashion to
avoid the warning; often it cannot.
But I don't think I want to put up with a warning coming out of core MM all
the time so let's go with the following silliness which adds no additional
runtime cost.
--- a/mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix
+++ a/mm/memory.c
@@ -1455,7 +1455,7 @@ static int apply_to_pte_range(struct mm_
pte_t *pte;
int err;
struct page *pmd_page;
- spinlock_t *ptl;
+ spinlock_t *ptl = ptl; /* Suppress gcc warning */
pte = (mm == &init_mm) ?
pte_alloc_kernel(pmd, addr) :
_
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-28 0:22 ` Andrew Morton
@ 2007-04-28 0:27 ` Jeremy Fitzhardinge
2007-04-28 5:57 ` Borislav Petkov
2007-04-28 23:48 ` Andy Whitcroft
2 siblings, 0 replies; 135+ messages in thread
From: Jeremy Fitzhardinge @ 2007-04-28 0:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: bbpetkov, linux-kernel, Jeremy Fitzhardinge
Andrew Morton wrote:
> --- a/mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix
> +++ a/mm/memory.c
> @@ -1455,7 +1455,7 @@ static int apply_to_pte_range(struct mm_
> pte_t *pte;
> int err;
> struct page *pmd_page;
> - spinlock_t *ptl;
> + spinlock_t *ptl = ptl; /* Suppress gcc warning */
>
Sigh. I guess so.
J
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-28 0:22 ` Andrew Morton
2007-04-28 0:27 ` Jeremy Fitzhardinge
@ 2007-04-28 5:57 ` Borislav Petkov
2007-04-28 6:25 ` Borislav Petkov
2007-04-28 23:48 ` Andy Whitcroft
2 siblings, 1 reply; 135+ messages in thread
From: Borislav Petkov @ 2007-04-28 5:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Jeremy Fitzhardinge
On Fri, Apr 27, 2007 at 05:22:30PM -0700, Andrew Morton wrote:
> On Thu, 26 Apr 2007 20:25:19 +0200
> Borislav Petkov <bbpetkov@yahoo.de> wrote:
>
> >
> > Remove build warning mm/memory.c:1491: warning: 'ptl' may be used uninitialized in this function.
> > The spinlock pointer is assigned to null since it gets overwritten right away in
> > pte_alloc_map_lock().
> >
> > Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
> > ---
> >
> > Index: linux-mm/mm/memory.c
> > ===================================================================
> > --- linux-mm.orig/mm/memory.c 2007-04-26 19:57:14.000000000 +0200
> > +++ linux-mm/mm/memory.c 2007-04-26 20:00:30.000000000 +0200
> > @@ -1488,7 +1488,7 @@
> > pte_t *pte;
> > int err;
> > struct page *pmd_page;
> > - spinlock_t *ptl;
> > + spinlock_t *ptl = NULL;
> >
> > pte = (mm == &init_mm) ?
> > pte_alloc_kernel(pmd, addr) :
> >
>
> yes, I've been staring unhappily at this for some time.
>
> Your change adds seven bytes of text to this function for no runtime
> benefit, just to fix a build-time warning. It's a general problem.
>
>
> Often we just leave the warning in place and curse gcc each time it flies
> past. Sometimes the code can be restructured in a sensible fashion to
> avoid the warning; often it cannot.
>
> But I don't think I want to put up with a warning coming out of core MM all
> the time so let's go with the following silliness which adds no additional
> runtime cost.
>
> --- a/mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix
> +++ a/mm/memory.c
> @@ -1455,7 +1455,7 @@ static int apply_to_pte_range(struct mm_
> pte_t *pte;
> int err;
> struct page *pmd_page;
> - spinlock_t *ptl;
> + spinlock_t *ptl = ptl; /* Suppress gcc warning */
>
> pte = (mm == &init_mm) ?
> pte_alloc_kernel(pmd, addr) :
> _
Yeah,
I saw in other places that usually a NULL/0 is assigned to such a type of pointer.
However, writing code which looks pretty silly just to shut up gcc is pretty
senseless, IMHO. Isn't there such a tweak in gcc to say that this pointer is
going to be assigned to later on, so don't issue a warning. Something like
__attribute__ __address_will_be_overwritten_so_don't_bother_warning_me__?
/me going to read gcc docs...
--
Regards/Gruß,
Boris.
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-28 5:57 ` Borislav Petkov
@ 2007-04-28 6:25 ` Borislav Petkov
2007-04-28 6:54 ` Andrew Morton
2007-04-28 7:03 ` Jeremy Fitzhardinge
0 siblings, 2 replies; 135+ messages in thread
From: Borislav Petkov @ 2007-04-28 6:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Jeremy Fitzhardinge
On Sat, Apr 28, 2007 at 07:57:40AM +0200, Borislav Petkov wrote:
> On Fri, Apr 27, 2007 at 05:22:30PM -0700, Andrew Morton wrote:
> > On Thu, 26 Apr 2007 20:25:19 +0200
> > Borislav Petkov <bbpetkov@yahoo.de> wrote:
> >
> > >
> > > Remove build warning mm/memory.c:1491: warning: 'ptl' may be used uninitialized in this function.
> > > The spinlock pointer is assigned to null since it gets overwritten right away in
> > > pte_alloc_map_lock().
> > >
> > > Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
> > > ---
> > >
> > > Index: linux-mm/mm/memory.c
> > > ===================================================================
> > > --- linux-mm.orig/mm/memory.c 2007-04-26 19:57:14.000000000 +0200
> > > +++ linux-mm/mm/memory.c 2007-04-26 20:00:30.000000000 +0200
> > > @@ -1488,7 +1488,7 @@
> > > pte_t *pte;
> > > int err;
> > > struct page *pmd_page;
> > > - spinlock_t *ptl;
> > > + spinlock_t *ptl = NULL;
> > >
> > > pte = (mm == &init_mm) ?
> > > pte_alloc_kernel(pmd, addr) :
> > >
> >
> > yes, I've been staring unhappily at this for some time.
> >
> > Your change adds seven bytes of text to this function for no runtime
> > benefit, just to fix a build-time warning. It's a general problem.
> >
> >
> > Often we just leave the warning in place and curse gcc each time it flies
> > past. Sometimes the code can be restructured in a sensible fashion to
> > avoid the warning; often it cannot.
> >
> > But I don't think I want to put up with a warning coming out of core MM all
> > the time so let's go with the following silliness which adds no additional
> > runtime cost.
> >
> > --- a/mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix
> > +++ a/mm/memory.c
> > @@ -1455,7 +1455,7 @@ static int apply_to_pte_range(struct mm_
> > pte_t *pte;
> > int err;
> > struct page *pmd_page;
> > - spinlock_t *ptl;
> > + spinlock_t *ptl = ptl; /* Suppress gcc warning */
> >
> > pte = (mm == &init_mm) ?
> > pte_alloc_kernel(pmd, addr) :
> > _
>
> Yeah,
> I saw in other places that usually a NULL/0 is assigned to such a type of pointer.
> However, writing code which looks pretty silly just to shut up gcc is pretty
> senseless, IMHO. Isn't there such a tweak in gcc to say that this pointer is
> going to be assigned to later on, so don't issue a warning. Something like
>
> __attribute__ __address_will_be_overwritten_so_don't_bother_warning_me__?
>
> /me going to read gcc docs...
Sorry, no such thing in the docs to do
spinlock_t __attribute__((__uninitialized__)) *ptl;
in order to suppress warnings. But if function size is our concern here, even
shorter would be:
Index: linux-mm/mm/memory.c
===================================================================
--- linux-mm.orig/mm/memory.c 2007-04-26 19:57:14.000000000 +0200
+++ linux-mm/mm/memory.c 2007-04-26 20:00:30.000000000 +0200
@@ -1488,7 +1488,7 @@
pte_t *pte;
int err;
struct page *pmd_page;
- spinlock_t *ptl;
+ spinlock_t *ptl = 0;
pte = (mm == &init_mm) ?
pte_alloc_kernel(pmd, addr) :
--
Regards/Gruß,
Boris.
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-28 6:25 ` Borislav Petkov
@ 2007-04-28 6:54 ` Andrew Morton
2007-04-28 7:03 ` Jeremy Fitzhardinge
1 sibling, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-28 6:54 UTC (permalink / raw)
To: bbpetkov; +Cc: linux-kernel, Jeremy Fitzhardinge
On Sat, 28 Apr 2007 08:25:17 +0200 Borislav Petkov <bbpetkov@yahoo.de> wrote:
> > __attribute__ __address_will_be_overwritten_so_don't_bother_warning_me__?
> >
> > /me going to read gcc docs...
>
> Sorry, no such thing in the docs to do
>
> spinlock_t __attribute__((__uninitialized__)) *ptl;
>
> in order to suppress warnings.
Bummer. Thanks for checking.
> But if function size is our concern here, even
> shorter would be:
>
> Index: linux-mm/mm/memory.c
> ===================================================================
> --- linux-mm.orig/mm/memory.c 2007-04-26 19:57:14.000000000 +0200
> +++ linux-mm/mm/memory.c 2007-04-26 20:00:30.000000000 +0200
> @@ -1488,7 +1488,7 @@
> pte_t *pte;
> int err;
> struct page *pmd_page;
> - spinlock_t *ptl;
> + spinlock_t *ptl = 0;
>
> pte = (mm == &init_mm) ?
> pte_alloc_kernel(pmd, addr) :
hm, that'll have the same seven-byte cost as `= NULL;', won't it?
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-28 6:25 ` Borislav Petkov
2007-04-28 6:54 ` Andrew Morton
@ 2007-04-28 7:03 ` Jeremy Fitzhardinge
1 sibling, 0 replies; 135+ messages in thread
From: Jeremy Fitzhardinge @ 2007-04-28 7:03 UTC (permalink / raw)
To: bbpetkov; +Cc: Andrew Morton, linux-kernel, Jeremy Fitzhardinge
Borislav Petkov wrote:
> Sorry, no such thing in the docs to do
>
> spinlock_t __attribute__((__uninitialized__)) *ptl;
>
> in order to suppress warnings. But if function size is our concern here, even
> shorter would be:
>
asm("" : "=rm" (ptl)) would do the job, I think, but it's pretty ugly
syntactically.
J
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-28 0:22 ` Andrew Morton
2007-04-28 0:27 ` Jeremy Fitzhardinge
2007-04-28 5:57 ` Borislav Petkov
@ 2007-04-28 23:48 ` Andy Whitcroft
2007-04-29 3:25 ` Andrew Morton
2007-04-29 6:50 ` Borislav Petkov
2 siblings, 2 replies; 135+ messages in thread
From: Andy Whitcroft @ 2007-04-28 23:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: bbpetkov, linux-kernel, Jeremy Fitzhardinge
Andrew Morton wrote:
> On Thu, 26 Apr 2007 20:25:19 +0200
> Borislav Petkov <bbpetkov@yahoo.de> wrote:
>
>> Remove build warning mm/memory.c:1491: warning: 'ptl' may be used uninitialized in this function.
>> The spinlock pointer is assigned to null since it gets overwritten right away in
>> pte_alloc_map_lock().
>>
>> Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
>> ---
>>
>> Index: linux-mm/mm/memory.c
>> ===================================================================
>> --- linux-mm.orig/mm/memory.c 2007-04-26 19:57:14.000000000 +0200
>> +++ linux-mm/mm/memory.c 2007-04-26 20:00:30.000000000 +0200
>> @@ -1488,7 +1488,7 @@
>> pte_t *pte;
>> int err;
>> struct page *pmd_page;
>> - spinlock_t *ptl;
>> + spinlock_t *ptl = NULL;
>>
>> pte = (mm == &init_mm) ?
>> pte_alloc_kernel(pmd, addr) :
>>
>
> yes, I've been staring unhappily at this for some time.
>
> Your change adds seven bytes of text to this function for no runtime
> benefit, just to fix a build-time warning. It's a general problem.
>
>
> Often we just leave the warning in place and curse gcc each time it flies
> past. Sometimes the code can be restructured in a sensible fashion to
> avoid the warning; often it cannot.
>
> But I don't think I want to put up with a warning coming out of core MM all
> the time so let's go with the following silliness which adds no additional
> runtime cost.
>
> --- a/mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix
> +++ a/mm/memory.c
> @@ -1455,7 +1455,7 @@ static int apply_to_pte_range(struct mm_
> pte_t *pte;
> int err;
> struct page *pmd_page;
> - spinlock_t *ptl;
> + spinlock_t *ptl = ptl; /* Suppress gcc warning */
>
> pte = (mm == &init_mm) ?
> pte_alloc_kernel(pmd, addr) :
> _
>
Perhaps we should have some kind definition helper.
#define suppress_unused(x) x = x
spinlock_t *suppress_unused(ptl);
Perhaps?
-apw
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-28 23:48 ` Andy Whitcroft
@ 2007-04-29 3:25 ` Andrew Morton
2007-04-29 6:50 ` Borislav Petkov
1 sibling, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-29 3:25 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: bbpetkov, linux-kernel, Jeremy Fitzhardinge
On Sun, 29 Apr 2007 00:48:37 +0100 Andy Whitcroft <apw@shadowen.org> wrote:
> > +++ a/mm/memory.c
> > @@ -1455,7 +1455,7 @@ static int apply_to_pte_range(struct mm_
> > pte_t *pte;
> > int err;
> > struct page *pmd_page;
> > - spinlock_t *ptl;
> > + spinlock_t *ptl = ptl; /* Suppress gcc warning */
> >
> > pte = (mm == &init_mm) ?
> > pte_alloc_kernel(pmd, addr) :
> > _
> >
>
> Perhaps we should have some kind definition helper.
>
> #define suppress_unused(x) x = x
>
> spinlock_t *suppress_unused(ptl);
>
> Perhaps?
I think so. It makes it clear what's happening and it allows us to change
the implementation later on if the present trick stops working in later
gcc. It also allows people to suppress the suppression (some have
expressed concern that it can hide real bugs).
But I lost (or didn't pursue) the bunfight^Wdiscussion last time this came
around.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-28 23:48 ` Andy Whitcroft
2007-04-29 3:25 ` Andrew Morton
@ 2007-04-29 6:50 ` Borislav Petkov
2007-04-29 8:19 ` Andrew Morton
2007-04-29 9:24 ` Andrew Morton
1 sibling, 2 replies; 135+ messages in thread
From: Borislav Petkov @ 2007-04-29 6:50 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linux-kernel, Jeremy Fitzhardinge
On Sun, Apr 29, 2007 at 12:48:37AM +0100, Andy Whitcroft wrote:
> Andrew Morton wrote:
> > On Thu, 26 Apr 2007 20:25:19 +0200
> > Borislav Petkov <bbpetkov@yahoo.de> wrote:
> >
> >> Remove build warning mm/memory.c:1491: warning: 'ptl' may be used uninitialized in this function.
> >> The spinlock pointer is assigned to null since it gets overwritten right away in
> >> pte_alloc_map_lock().
> >>
> >> Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
> >> ---
> >>
> >> Index: linux-mm/mm/memory.c
> >> ===================================================================
> >> --- linux-mm.orig/mm/memory.c 2007-04-26 19:57:14.000000000 +0200
> >> +++ linux-mm/mm/memory.c 2007-04-26 20:00:30.000000000 +0200
> >> @@ -1488,7 +1488,7 @@
> >> pte_t *pte;
> >> int err;
> >> struct page *pmd_page;
> >> - spinlock_t *ptl;
> >> + spinlock_t *ptl = NULL;
> >>
> >> pte = (mm == &init_mm) ?
> >> pte_alloc_kernel(pmd, addr) :
> >>
> >
> > yes, I've been staring unhappily at this for some time.
> >
> > Your change adds seven bytes of text to this function for no runtime
> > benefit, just to fix a build-time warning. It's a general problem.
> >
> >
> > Often we just leave the warning in place and curse gcc each time it flies
> > past. Sometimes the code can be restructured in a sensible fashion to
> > avoid the warning; often it cannot.
> >
> > But I don't think I want to put up with a warning coming out of core MM all
> > the time so let's go with the following silliness which adds no additional
> > runtime cost.
> >
> > --- a/mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix
> > +++ a/mm/memory.c
> > @@ -1455,7 +1455,7 @@ static int apply_to_pte_range(struct mm_
> > pte_t *pte;
> > int err;
> > struct page *pmd_page;
> > - spinlock_t *ptl;
> > + spinlock_t *ptl = ptl; /* Suppress gcc warning */
> >
> > pte = (mm == &init_mm) ?
> > pte_alloc_kernel(pmd, addr) :
> > _
> >
>
> Perhaps we should have some kind definition helper.
>
> #define suppress_unused(x) x = x
>
> spinlock_t *suppress_unused(ptl);
I like that idea, let's do that. However, Andrew's concern remains still valid
about suppressing the suppression and thereby hiding real bugs. But hey, the use
of such a macro is pretty straightforward and if we choose a suitable name for
it stating the unitialized state of the variable, messing up stuff then and
producing a faulty code out of it is pretty careless to begin with, IMVHO.
Here's a patch:
-----
From: Borislav Petkov <bbpetkov@yahoo.de>
Introduce a macro for suppressing gcc from generating a warning about a probable
unitialized state of a variable.
Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
---
Index: linux-mm/include/linux/compiler.h
===================================================================
--- linux-mm.orig/include/linux/compiler.h
+++ linux-mm/include/linux/compiler.h
@@ -109,6 +109,10 @@ extern int do_check_likely(struct likeli
(typeof(ptr)) (__ptr + (off)); })
#endif
+#ifndef unitialized_var
+# define unitialized_var(x) x = x
+#endif
+
#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */
Index: linux-mm/mm/memory.c
===================================================================
--- linux-mm.orig/mm/memory.c
+++ linux-mm/mm/memory.c
@@ -1488,7 +1488,7 @@ static int apply_to_pte_range(struct mm_
pte_t *pte;
int err;
struct page *pmd_page;
- spinlock_t *ptl;
+ spinlock_t *unitialized_var(ptl);
pte = (mm == &init_mm) ?
pte_alloc_kernel(pmd, addr) :
--
Regards/Gruß,
Boris.
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-29 6:50 ` Borislav Petkov
@ 2007-04-29 8:19 ` Andrew Morton
2007-04-29 9:24 ` Andrew Morton
1 sibling, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-29 8:19 UTC (permalink / raw)
To: bbpetkov; +Cc: Andy Whitcroft, linux-kernel, Jeremy Fitzhardinge
On Sun, 29 Apr 2007 08:50:49 +0200 Borislav Petkov <bbpetkov@yahoo.de> wrote:
>
> Introduce a macro for suppressing gcc from generating a warning about a probable
> unitialized state of a variable.
>
> Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
>
> ---
>
> Index: linux-mm/include/linux/compiler.h
> ===================================================================
> --- linux-mm.orig/include/linux/compiler.h
> +++ linux-mm/include/linux/compiler.h
> @@ -109,6 +109,10 @@ extern int do_check_likely(struct likeli
> (typeof(ptr)) (__ptr + (off)); })
> #endif
>
> +#ifndef unitialized_var
> +# define unitialized_var(x) x = x
> +#endif
> +
> #endif /* __KERNEL__ */
>
> #endif /* __ASSEMBLY__ */
> Index: linux-mm/mm/memory.c
> ===================================================================
> --- linux-mm.orig/mm/memory.c
> +++ linux-mm/mm/memory.c
> @@ -1488,7 +1488,7 @@ static int apply_to_pte_range(struct mm_
> pte_t *pte;
> int err;
> struct page *pmd_page;
> - spinlock_t *ptl;
> + spinlock_t *unitialized_var(ptl);
>
> pte = (mm == &init_mm) ?
> pte_alloc_kernel(pmd, addr) :
Ho hum. I guess I'll slide this over to Linus if there's not too much
howling, and unless someone can come up with anything better.
I will, however, fix the spelling to "uninitialized" ;)
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-29 6:50 ` Borislav Petkov
2007-04-29 8:19 ` Andrew Morton
@ 2007-04-29 9:24 ` Andrew Morton
2007-04-29 21:36 ` Dave Jones
2007-11-07 19:20 ` Steven Rostedt
1 sibling, 2 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-29 9:24 UTC (permalink / raw)
To: bbpetkov; +Cc: Andy Whitcroft, linux-kernel, Jeremy Fitzhardinge
On Sun, 29 Apr 2007 08:50:49 +0200 Borislav Petkov <bbpetkov@yahoo.de> wrote:
> Introduce a macro for suppressing gcc from generating a warning about a probable
> unitialized state of a variable.
I ended up doing the below.
It's better to make this a per-compiler-version thing: later versions of
gcc might need different tricks, or might provide __attribute__((stfu)) or
whatever.
Plus I don't know if the x=x trick is needed on the intel compiler, nor if
it even works, so I left ICC alone.
From: Borislav Petkov <bbpetkov@yahoo.de>
Introduce a macro for suppressing gcc from generating a warning about a
probable uninitialized state of a variable.
Example:
- spinlock_t *ptl;
+ spinlock_t *uninitialized_var(ptl);
Not a happy solution, but those warnings are obnoxious.
- Using the usual pointlessly-set-it-to-zero approach wastes several
bytes of text.
- Using a macro means we can (hopefully) do something else if gcc changes
cause the `x = x' hack to stop working
- Using a macro means that people who are worried about hiding true bugs
can easily turn it off.
Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/compiler-gcc3.h | 6 ++++++
include/linux/compiler-gcc4.h | 6 ++++++
include/linux/compiler-intel.h | 2 ++
3 files changed, 14 insertions(+)
diff -puN include/linux/compiler-gcc3.h~add-unitialized_var-macro-for-suppressing-gcc-warnings include/linux/compiler-gcc3.h
--- a/include/linux/compiler-gcc3.h~add-unitialized_var-macro-for-suppressing-gcc-warnings
+++ a/include/linux/compiler-gcc3.h
@@ -13,4 +13,10 @@
#define __must_check __attribute__((warn_unused_result))
#endif
+/*
+ * A trick to suppress uninitialized variable warning without generating any
+ * code
+ */
+#define uninitialized_var(x) x = x
+
#define __always_inline inline __attribute__((always_inline))
diff -puN include/linux/compiler-gcc4.h~add-unitialized_var-macro-for-suppressing-gcc-warnings include/linux/compiler-gcc4.h
--- a/include/linux/compiler-gcc4.h~add-unitialized_var-macro-for-suppressing-gcc-warnings
+++ a/include/linux/compiler-gcc4.h
@@ -16,3 +16,9 @@
#define __must_check __attribute__((warn_unused_result))
#define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
#define __always_inline inline __attribute__((always_inline))
+
+/*
+ * A trick to suppress uninitialized variable warning without generating any
+ * code
+ */
+#define uninitialized_var(x) x = x
diff -puN include/linux/compiler-intel.h~add-unitialized_var-macro-for-suppressing-gcc-warnings include/linux/compiler-intel.h
--- a/include/linux/compiler-intel.h~add-unitialized_var-macro-for-suppressing-gcc-warnings
+++ a/include/linux/compiler-intel.h
@@ -22,3 +22,5 @@
(typeof(ptr)) (__ptr + (off)); })
#endif
+
+#define uninitialized_var(x) x
_
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-29 9:24 ` Andrew Morton
@ 2007-04-29 21:36 ` Dave Jones
2007-04-29 21:45 ` Andrew Morton
2007-11-07 19:20 ` Steven Rostedt
1 sibling, 1 reply; 135+ messages in thread
From: Dave Jones @ 2007-04-29 21:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: bbpetkov, Andy Whitcroft, linux-kernel, Jeremy Fitzhardinge
On Sun, Apr 29, 2007 at 02:24:40AM -0700, Andrew Morton wrote:
> On Sun, 29 Apr 2007 08:50:49 +0200 Borislav Petkov <bbpetkov@yahoo.de> wrote:
>
> > Introduce a macro for suppressing gcc from generating a warning about a probable
> > unitialized state of a variable.
>
> I ended up doing the below.
>
> It's better to make this a per-compiler-version thing: later versions of
> gcc might need different tricks, or might provide __attribute__((stfu)) or
> whatever.
__attribute__((unused)) ?
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-29 21:36 ` Dave Jones
@ 2007-04-29 21:45 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-29 21:45 UTC (permalink / raw)
To: Dave Jones; +Cc: bbpetkov, Andy Whitcroft, linux-kernel, Jeremy Fitzhardinge
On Sun, 29 Apr 2007 17:36:01 -0400 Dave Jones <davej@redhat.com> wrote:
> On Sun, Apr 29, 2007 at 02:24:40AM -0700, Andrew Morton wrote:
> > On Sun, 29 Apr 2007 08:50:49 +0200 Borislav Petkov <bbpetkov@yahoo.de> wrote:
> >
> > > Introduce a macro for suppressing gcc from generating a warning about a probable
> > > unitialized state of a variable.
> >
> > I ended up doing the below.
> >
> > It's better to make this a per-compiler-version thing: later versions of
> > gcc might need different tricks, or might provide __attribute__((stfu)) or
> > whatever.
>
> __attribute__((unused)) ?
That'll prevent unused-variable warnings, but there doesn't appear to be
an attribute to prevent might-be-used-uninitialized warnings.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-04-29 9:24 ` Andrew Morton
2007-04-29 21:36 ` Dave Jones
@ 2007-11-07 19:20 ` Steven Rostedt
2007-11-08 5:15 ` Borislav Petkov
1 sibling, 1 reply; 135+ messages in thread
From: Steven Rostedt @ 2007-11-07 19:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: bbpetkov, Andy Whitcroft, linux-kernel, Jeremy Fitzhardinge
>
> Introduce a macro for suppressing gcc from generating a warning about a
> probable uninitialized state of a variable.
>
> Example:
>
> - spinlock_t *ptl;
> + spinlock_t *uninitialized_var(ptl);
>
> Not a happy solution, but those warnings are obnoxious.
>
> - Using the usual pointlessly-set-it-to-zero approach wastes several
> bytes of text.
>
> - Using a macro means we can (hopefully) do something else if gcc changes
> cause the `x = x' hack to stop working
>
> - Using a macro means that people who are worried about hiding true bugs
> can easily turn it off.
>
> Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
I just stumbled across this being in the kernel. Well, I'm finally glad
it made it in, even though it was suggested one year earlier ;-)
http://lkml.org/lkml/2006/5/11/50
-- Steve
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2
2007-11-07 19:20 ` Steven Rostedt
@ 2007-11-08 5:15 ` Borislav Petkov
0 siblings, 0 replies; 135+ messages in thread
From: Borislav Petkov @ 2007-11-08 5:15 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, Andy Whitcroft, linux-kernel, Jeremy Fitzhardinge
On Wed, Nov 07, 2007 at 02:20:03PM -0500, Steven Rostedt wrote:
> >
> > Introduce a macro for suppressing gcc from generating a warning about a
> > probable uninitialized state of a variable.
> >
> > Example:
> >
> > - spinlock_t *ptl;
> > + spinlock_t *uninitialized_var(ptl);
> >
> > Not a happy solution, but those warnings are obnoxious.
> >
> > - Using the usual pointlessly-set-it-to-zero approach wastes several
> > bytes of text.
> >
> > - Using a macro means we can (hopefully) do something else if gcc changes
> > cause the `x = x' hack to stop working
> >
> > - Using a macro means that people who are worried about hiding true bugs
> > can easily turn it off.
> >
> > Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> I just stumbled across this being in the kernel. Well, I'm finally glad
> it made it in, even though it was suggested one year earlier ;-)
>
> http://lkml.org/lkml/2006/5/11/50
yeah, this was Andrew's idea. The version in the kernel, in
contrast to yours, doesn't have a config option so you still
have to make really sure you're not aiding any bugs with it.
--
Regards/Gruß,
Boris.
^ permalink raw reply [flat|nested] 135+ messages in thread
* [-mm patch] make drivers/hwmon/applesmc.c:backlight_work static
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (4 preceding siblings ...)
2007-04-26 18:25 ` [PATCH] mm/memory.c: remove warning from an uninitialized spinlock. was: Re: 2.6.21-rc7-mm2 Borislav Petkov
@ 2007-04-26 23:47 ` Adrian Bunk
2007-04-26 23:47 ` [-mm patch] unexport highlevel_host_reset Adrian Bunk
` (9 subsequent siblings)
15 siblings, 0 replies; 135+ messages in thread
From: Adrian Bunk @ 2007-04-26 23:47 UTC (permalink / raw)
To: Andrew Morton, Nicolas Boichat, Jean Delvare; +Cc: linux-kernel
This patch makes the needlessly global "backlight_work" static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.21-rc7-mm2/drivers/hwmon/applesmc.c.old 2007-04-27 00:34:45.000000000 +0200
+++ linux-2.6.21-rc7-mm2/drivers/hwmon/applesmc.c 2007-04-27 00:34:57.000000000 +0200
@@ -742,7 +742,7 @@
applesmc_write_key(BACKLIGHT_KEY, buffer, 2);
mutex_unlock(&applesmc_lock);
}
-DECLARE_WORK(backlight_work, &applesmc_backlight_set);
+static DECLARE_WORK(backlight_work, &applesmc_backlight_set);
static void applesmc_brightness_set(struct led_classdev *led_cdev,
enum led_brightness value)
^ permalink raw reply [flat|nested] 135+ messages in thread* [-mm patch] unexport highlevel_host_reset
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (5 preceding siblings ...)
2007-04-26 23:47 ` [-mm patch] make drivers/hwmon/applesmc.c:backlight_work static Adrian Bunk
@ 2007-04-26 23:47 ` Adrian Bunk
2007-04-27 0:16 ` Stefan Richter
2007-04-27 2:31 ` 2.6.21-rc7-mm2 breaks 'lvm vgscan' Valdis.Kletnieks
` (8 subsequent siblings)
15 siblings, 1 reply; 135+ messages in thread
From: Adrian Bunk @ 2007-04-26 23:47 UTC (permalink / raw)
To: Andrew Morton, ben.collins, stefanr; +Cc: linux-kernel, linux1394-devel
On Wed, Apr 25, 2007 at 10:57:16PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc7-mm1:
>...
> git-ieee1394.patch
>...
> git trees
>...
highlevel_host_reset no longer has any modular users.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.21-rc7-mm2/drivers/ieee1394/ieee1394_core.c.old 2007-04-27 00:48:12.000000000 +0200
+++ linux-2.6.21-rc7-mm2/drivers/ieee1394/ieee1394_core.c 2007-04-27 00:48:19.000000000 +0200
@@ -1338,7 +1338,6 @@
EXPORT_SYMBOL(hpsb_set_hostinfo_key);
EXPORT_SYMBOL(hpsb_get_hostinfo_bykey);
EXPORT_SYMBOL(hpsb_set_hostinfo);
-EXPORT_SYMBOL(highlevel_host_reset);
/** nodemgr.c **/
EXPORT_SYMBOL(hpsb_node_fill_packet);
^ permalink raw reply [flat|nested] 135+ messages in thread* 2.6.21-rc7-mm2 breaks 'lvm vgscan'.
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (6 preceding siblings ...)
2007-04-26 23:47 ` [-mm patch] unexport highlevel_host_reset Adrian Bunk
@ 2007-04-27 2:31 ` Valdis.Kletnieks
2007-04-27 2:55 ` Andrew Morton
2007-05-05 18:04 ` Valdis.Kletnieks
2007-04-28 17:56 ` 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1) Tilman Schmidt
` (7 subsequent siblings)
15 siblings, 2 replies; 135+ messages in thread
From: Valdis.Kletnieks @ 2007-04-27 2:31 UTC (permalink / raw)
To: Andrew Morton, Tejun Heo; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]
On Wed, 25 Apr 2007 22:57:16 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
This addition in -rc7-mm1 breaks my laptop (Dell Latitude D820, x86_64 kernel)
gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch
The initrd on my system does an 'lvm vgscan' to get the root filesystem
accessible. Under -rc5-mm2, this works fine. For -rc7-mm[12], it finds the disk:
ata_piix 0000:00:1f.2: version 2.11
ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1f.2 to 64
scsi0 : ata_piix
scsi1 : ata_piix
ata1: SATA max UDMA/133 cmd 0x00000000000101f0 ctl 0x00000000000103f6 bmdma 0x000000000001bfa0 irq 14
ata2: PATA max UDMA/100 cmd 0x0000000000010170 ctl 0x0000000000010376 bmdma 0x000000000001bfa8 irq 15
ata1.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488
ata1.00: ATA-7: ST980825AS, 8.04, max UDMA/133
ata1.00: 156301488 sectors, multi 8: LBA48 NCQ (depth 0/32)
ata1.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488
ata1.00: configured for UDMA/133
ata2.00: ATAPI, max UDMA/33
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA ST980825AS 8.04 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
sda1 is an ext3 /boot, sda2 is an LVM space covering the rest of the disk, so
we're doing well so far.
The 'lvm vgscan' fails and says 'No volume groups found, with no useful kernel
messages issued. Then we get the infamous "Kernel panic - not syncing:
Attempted to kill init!" when it can't find the root file system and we fall
off the end of the initrd.
Any ideas?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 breaks 'lvm vgscan'.
2007-04-27 2:31 ` 2.6.21-rc7-mm2 breaks 'lvm vgscan' Valdis.Kletnieks
@ 2007-04-27 2:55 ` Andrew Morton
2007-05-05 18:04 ` Valdis.Kletnieks
1 sibling, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-27 2:55 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Tejun Heo, linux-kernel
On Thu, 26 Apr 2007 22:31:15 -0400 Valdis.Kletnieks@vt.edu wrote:
> On Wed, 25 Apr 2007 22:57:16 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
>
> This addition in -rc7-mm1 breaks my laptop (Dell Latitude D820, x86_64 kernel)
>
> gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch
Thanks for doing the bisection. It is boring, but helps so much.
> Any ideas?
You cc'ed the right guy ;)
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 breaks 'lvm vgscan'.
2007-04-27 2:31 ` 2.6.21-rc7-mm2 breaks 'lvm vgscan' Valdis.Kletnieks
2007-04-27 2:55 ` Andrew Morton
@ 2007-05-05 18:04 ` Valdis.Kletnieks
1 sibling, 0 replies; 135+ messages in thread
From: Valdis.Kletnieks @ 2007-05-05 18:04 UTC (permalink / raw)
To: Andrew Morton, Tejun Heo; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Thu, 26 Apr 2007 22:31:15 EDT, Valdis.Kletnieks@vt.edu said:
> On Wed, 25 Apr 2007 22:57:16 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
>
> This addition in -rc7-mm1 breaks my laptop (Dell Latitude D820, x86_64 kernel)
>
> gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch
>
> The initrd on my system does an 'lvm vgscan' to get the root filesystem
> accessible.
This is confirmed fixed in 2.6.21-mm1.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (7 preceding siblings ...)
2007-04-27 2:31 ` 2.6.21-rc7-mm2 breaks 'lvm vgscan' Valdis.Kletnieks
@ 2007-04-28 17:56 ` Tilman Schmidt
2007-04-28 21:10 ` Andrew Morton
2007-04-28 19:19 ` [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static Adrian Bunk
` (6 subsequent siblings)
15 siblings, 1 reply; 135+ messages in thread
From: Tilman Schmidt @ 2007-04-28 17:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 6111 bytes --]
With kernel 2.6.21-rc7-mm2, my Dell Optiplex GX110 (P3/933) regularly
crashes during the SuSE 10.1 startup sequence. When booting to RL5,
it panicblinks shortly after the graphical login screen appears.
Booting to RL3, it hangs after the startup message:
Starting Firewall Initialization (phase 2 of 2)
(the last message before "runlevel 3 has been reached") logging this:
[ 57.138955] Eeek! page_mapcount(page) went negative! (-1)
[ 57.139040] page pfn = 0
[ 57.139053] page->flags = 400
[ 57.139066] page->count = 1
[ 57.139079] page->mapping = 00000000
[ 57.139111] vma->vm_ops = generic_file_vm_ops+0x0/0x18
[ 57.139147] vma->vm_ops->nopage = 0x0
[ 57.139181] vma->vm_file->f_op->mmap = reiserfs_file_mmap+0x0/0x47
[ 57.139220] ------------[ cut here ]------------
[ 57.139236] kernel BUG at mm/rmap.c:648!
[ 57.139251] invalid opcode: 0000 [#1]
[ 57.139264] PREEMPT
[ 57.139278] Modules linked in: usbserial snd_rtctimer snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device thermal processor fan button battery ac af_packet usb_gigaset ser_gigaset bas_gigaset gigaset isdn slhc crc_ccitt ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables ehci_hcd snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 uhci_hcd parport_pc lp parport ipv6 nls_iso8859_1 nls_cp437 vfat fat nls_utf8 ntfs dm_mod
[ 57.139447] CPU: 0
[ 57.139450] EIP: 0060:[<c015dfc0>] Not tainted VLI
[ 57.139453] EFLAGS: 00010282 (2.6.21-rc7-mm2-noinitrd #1)
[ 57.139506] EIP is at page_remove_rmap+0xd7/0x106
[ 57.139522] eax: 0000004b ebx: c1000000 ecx: 00000001 edx: 00000002
[ 57.139541] esi: c309fde0 edi: b7f24000 ebp: c373ec90 esp: c373ec78
[ 57.139559] ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068
[ 57.139577] Process getcfg-interfac (pid: 4343, ti=c373e000 task=c18734d0 task.ti=c373e000)
[ 57.139586] Stack: c042abb5 00000000 c373ec90 c13f91c0 c1000000 c373dc90 c373ecf0 c0158df4
[ 57.139618] c04f2ac4 00000001 00000000 c309fde0 c373ed10 00005ff1 00000000 00000001
[ 57.139647] b7f62000 c374cb7c c374cb7c c374cb7c c373b344 fffffffe 00000000 c0569c2c
[ 57.139677] Call Trace:
[ 57.139721] [<c0158df4>] unmap_vmas+0x2d7/0x4c9
[ 57.139748] [<c015b7dd>] exit_mmap+0x68/0xeb
[ 57.139772] [<c01191b0>] mmput+0x52/0xcb
[ 57.139805] [<c011c368>] exit_mm+0xbb/0xc3
[ 57.139832] [<c011d188>] do_exit+0x1ea/0x73e
[ 57.139857] [<c011d74d>] sys_exit_group+0x0/0x13
[ 57.139880] [<c012524e>] get_signal_to_deliver+0x6cd/0x6f8
[ 57.139917] [<c01036cf>] do_notify_resume+0x91/0x692
[ 57.139944] [<c0103f15>] work_notifysig+0x13/0x1a
[ 57.139970] [<b7f6b7a8>] 0xb7f6b7a8
[ 57.139988] =======================
[ 57.140002] INFO: lockdep is turned off.
[ 57.140015] Code: c0 74 0d 8b 50 0c b8 e5 ab 42 c0 e8 d7 fa fd ff 8b 46 48 85 c0 74 14 8b 40 10 85 c0 74 0d 8b 50 2c b8 04 ac 42 c0 e8 bc fa fd ff <0f> 0b eb fe 8b 53 10 8b 03 83 e2 01 f7 da c1 e8 1e 83 c2 04 69
[ 57.140133] EIP: [<c015dfc0>] page_remove_rmap+0xd7/0x106 SS:ESP 0068:c373ec78
[ 57.140191] Fixing recursive fault but reboot is needed!
[ 57.140209] BUG: scheduling while atomic: getcfg-interfac/0x00000002/4343
[ 57.140225] INFO: lockdep is turned off.
[ 57.140247] [<c0104e80>] dump_trace+0x61/0x1e4
[ 57.140275] [<c010501d>] show_trace_log_lvl+0x1a/0x30
[ 57.140298] [<c0105fe9>] show_trace+0x12/0x14
[ 57.140322] [<c0106000>] dump_stack+0x15/0x17
[ 57.140344] [<c0380849>] schedule+0x6e/0x52c
[ 57.140383] [<c011d08f>] do_exit+0xf1/0x73e
[ 57.140407] [<c010569b>] die+0x1b7/0x1bf
[ 57.140429] [<c0105a66>] do_trap+0x8d/0xa7
[ 57.140451] [<c0105dd2>] do_invalid_op+0x88/0x92
[ 57.140474] [<c03833ba>] error_code+0x6a/0x70
[ 57.140500] [<c015dfc0>] page_remove_rmap+0xd7/0x106
[ 57.140525] [<c0158df4>] unmap_vmas+0x2d7/0x4c9
[ 57.140548] [<c015b7dd>] exit_mmap+0x68/0xeb
[ 57.140571] [<c01191b0>] mmput+0x52/0xcb
[ 57.140593] [<c011c368>] exit_mm+0xbb/0xc3
[ 57.140615] [<c011d188>] do_exit+0x1ea/0x73e
[ 57.140638] [<c011d74d>] sys_exit_group+0x0/0x13
[ 57.140661] [<c012524e>] get_signal_to_deliver+0x6cd/0x6f8
[ 57.140686] [<c01036cf>] do_notify_resume+0x91/0x692
[ 57.140708] [<c0103f15>] work_notifysig+0x13/0x1a
[ 57.140731] [<b7f6b7a8>] 0xb7f6b7a8
[ 57.140749] =======================
followed by a couple of these:
[ 87.264940] BUG: sleeping function called from invalid context at mm/slab.c:3054
[ 87.265023] in_atomic():1, irqs_disabled():0
[ 87.265038] INFO: lockdep is turned off.
[ 87.265079] [<c0104e80>] dump_trace+0x61/0x1e4
[ 87.265119] [<c010501d>] show_trace_log_lvl+0x1a/0x30
[ 87.265161] [<c0105fe9>] show_trace+0x12/0x14
[ 87.265187] [<c0106000>] dump_stack+0x15/0x17
[ 87.265210] [<c01177b3>] __might_sleep+0xc7/0xcd
[ 87.265241] [<c0168548>] __kmalloc_track_caller+0x67/0xe9
[ 87.265281] [<c0156e0b>] __kzalloc+0x13/0x3d
[ 87.265312] [<c0226a6c>] kobject_get_path+0x3b/0x94
[ 87.265342] [<c02b4004>] dev_uevent+0x2d0/0x36a
[ 87.265375] [<c02b36ac>] show_uevent+0x94/0xe4
[ 87.265400] [<c02b34fd>] dev_attr_show+0x1b/0x1f
[ 87.265424] [<c01a7ac0>] sysfs_read_file+0x17f/0x1b0
[ 87.265454] [<c016bbf8>] vfs_read+0xaf/0x138
[ 87.265479] [<c016c476>] sys_read+0x3d/0x61
[ 87.265503] [<c0103dc2>] sysenter_past_esp+0x5f/0x99
[ 87.265531] [<b7fd7410>] 0xb7fd7410
[ 87.265568] =======================
separated by 20 or 40 second pauses, before rebooting spontaneously.
2.6.21-rc7-mm1 crashed too. 2.6.21 runs fine.
Please let me know if you need more information or want me to test
anything.
HTH
T.
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
- In theory, there is no difference between theory and practice.
In practice, there is.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-04-28 17:56 ` 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1) Tilman Schmidt
@ 2007-04-28 21:10 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-28 21:10 UTC (permalink / raw)
To: Tilman Schmidt; +Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins
On Sat, 28 Apr 2007 19:56:59 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
> With kernel 2.6.21-rc7-mm2, my Dell Optiplex GX110 (P3/933) regularly
> crashes during the SuSE 10.1 startup sequence. When booting to RL5,
> it panicblinks shortly after the graphical login screen appears.
> Booting to RL3, it hangs after the startup message:
>
> Starting Firewall Initialization (phase 2 of 2)
>
> (the last message before "runlevel 3 has been reached") logging this:
>
> [ 57.138955] Eeek! page_mapcount(page) went negative! (-1)
> [ 57.139040] page pfn = 0
> [ 57.139053] page->flags = 400
> [ 57.139066] page->count = 1
> [ 57.139079] page->mapping = 00000000
> [ 57.139111] vma->vm_ops = generic_file_vm_ops+0x0/0x18
> [ 57.139147] vma->vm_ops->nopage = 0x0
> [ 57.139181] vma->vm_file->f_op->mmap = reiserfs_file_mmap+0x0/0x47
> [ 57.139220] ------------[ cut here ]------------
> [ 57.139236] kernel BUG at mm/rmap.c:648!
> [ 57.139251] invalid opcode: 0000 [#1]
> [ 57.139264] PREEMPT
> [ 57.139278] Modules linked in: usbserial snd_rtctimer snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device thermal processor fan button battery ac af_packet usb_gigaset ser_gigaset bas_gigaset gigaset isdn slhc crc_ccitt ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables ehci_hcd snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 uhci_hcd parport_pc lp parport ipv6 nls_iso8859_1 nls_cp437 vfat fat nls_utf8 ntfs dm_mod
> [ 57.139447] CPU: 0
> [ 57.139450] EIP: 0060:[<c015dfc0>] Not tainted VLI
> [ 57.139453] EFLAGS: 00010282 (2.6.21-rc7-mm2-noinitrd #1)
> [ 57.139506] EIP is at page_remove_rmap+0xd7/0x106
> [ 57.139522] eax: 0000004b ebx: c1000000 ecx: 00000001 edx: 00000002
> [ 57.139541] esi: c309fde0 edi: b7f24000 ebp: c373ec90 esp: c373ec78
> [ 57.139559] ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068
> [ 57.139577] Process getcfg-interfac (pid: 4343, ti=c373e000 task=c18734d0 task.ti=c373e000)
> [ 57.139586] Stack: c042abb5 00000000 c373ec90 c13f91c0 c1000000 c373dc90 c373ecf0 c0158df4
> [ 57.139618] c04f2ac4 00000001 00000000 c309fde0 c373ed10 00005ff1 00000000 00000001
> [ 57.139647] b7f62000 c374cb7c c374cb7c c374cb7c c373b344 fffffffe 00000000 c0569c2c
> [ 57.139677] Call Trace:
> [ 57.139721] [<c0158df4>] unmap_vmas+0x2d7/0x4c9
> [ 57.139748] [<c015b7dd>] exit_mmap+0x68/0xeb
> [ 57.139772] [<c01191b0>] mmput+0x52/0xcb
> [ 57.139805] [<c011c368>] exit_mm+0xbb/0xc3
> [ 57.139832] [<c011d188>] do_exit+0x1ea/0x73e
> [ 57.139857] [<c011d74d>] sys_exit_group+0x0/0x13
> [ 57.139880] [<c012524e>] get_signal_to_deliver+0x6cd/0x6f8
> [ 57.139917] [<c01036cf>] do_notify_resume+0x91/0x692
> [ 57.139944] [<c0103f15>] work_notifysig+0x13/0x1a
> [ 57.139970] [<b7f6b7a8>] 0xb7f6b7a8
> [ 57.139988] =======================
> [ 57.140002] INFO: lockdep is turned off.
> [ 57.140015] Code: c0 74 0d 8b 50 0c b8 e5 ab 42 c0 e8 d7 fa fd ff 8b 46 48 85 c0 74 14 8b 40 10 85 c0 74 0d 8b 50 2c b8 04 ac 42 c0 e8 bc fa fd ff <0f> 0b eb fe 8b 53 10 8b 03 83 e2 01 f7 da c1 e8 1e 83 c2 04 69
I don't know which patch might have caused that. Is it always
getcfg-interface which dies? Seems to be a suse-only thing, and I
unfortunately don't have any test boxes which have it.
It seems wildly screwed up that we have a PageReserved() page with a pfn of
zero (!) which claims to be in a reiserfs mapping, only it isn't attached to a
reiserfs file. How the heck did that happen?
Nick, I think that printk needs updating for changed vm_operations methods,
btw (->fault?)
This puts a dark cloud over about 200 patches at present. It would be
great if you could perform a bisection search as per
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt.
I'd start out at fix-slab-corruption-running-ip6sic.patch then try
mm-fix-handling-of-panic_on_oom-when-cpusets-are-in-use.patch. It should
take six or seven hops.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-04-28 21:10 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-28 21:10 UTC (permalink / raw)
To: Tilman Schmidt; +Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins
On Sat, 28 Apr 2007 19:56:59 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
> With kernel 2.6.21-rc7-mm2, my Dell Optiplex GX110 (P3/933) regularly
> crashes during the SuSE 10.1 startup sequence. When booting to RL5,
> it panicblinks shortly after the graphical login screen appears.
> Booting to RL3, it hangs after the startup message:
>
> Starting Firewall Initialization (phase 2 of 2)
>
> (the last message before "runlevel 3 has been reached") logging this:
>
> [ 57.138955] Eeek! page_mapcount(page) went negative! (-1)
> [ 57.139040] page pfn = 0
> [ 57.139053] page->flags = 400
> [ 57.139066] page->count = 1
> [ 57.139079] page->mapping = 00000000
> [ 57.139111] vma->vm_ops = generic_file_vm_ops+0x0/0x18
> [ 57.139147] vma->vm_ops->nopage = 0x0
> [ 57.139181] vma->vm_file->f_op->mmap = reiserfs_file_mmap+0x0/0x47
> [ 57.139220] ------------[ cut here ]------------
> [ 57.139236] kernel BUG at mm/rmap.c:648!
> [ 57.139251] invalid opcode: 0000 [#1]
> [ 57.139264] PREEMPT
> [ 57.139278] Modules linked in: usbserial snd_rtctimer snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device thermal processor fan button battery ac af_packet usb_gigaset ser_gigaset bas_gigaset gigaset isdn slhc crc_ccitt ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables ehci_hcd snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 uhci_hcd parport_pc lp parport ipv6 nls_iso8859_1 nls_cp437 vfat fat nls_utf8 ntfs dm_mod
> [ 57.139447] CPU: 0
> [ 57.139450] EIP: 0060:[<c015dfc0>] Not tainted VLI
> [ 57.139453] EFLAGS: 00010282 (2.6.21-rc7-mm2-noinitrd #1)
> [ 57.139506] EIP is at page_remove_rmap+0xd7/0x106
> [ 57.139522] eax: 0000004b ebx: c1000000 ecx: 00000001 edx: 00000002
> [ 57.139541] esi: c309fde0 edi: b7f24000 ebp: c373ec90 esp: c373ec78
> [ 57.139559] ds: 007b es: 007b fs: 0000 gs: 0000 ss: 0068
> [ 57.139577] Process getcfg-interfac (pid: 4343, ti=c373e000 task=c18734d0 task.ti=c373e000)
> [ 57.139586] Stack: c042abb5 00000000 c373ec90 c13f91c0 c1000000 c373dc90 c373ecf0 c0158df4
> [ 57.139618] c04f2ac4 00000001 00000000 c309fde0 c373ed10 00005ff1 00000000 00000001
> [ 57.139647] b7f62000 c374cb7c c374cb7c c374cb7c c373b344 fffffffe 00000000 c0569c2c
> [ 57.139677] Call Trace:
> [ 57.139721] [<c0158df4>] unmap_vmas+0x2d7/0x4c9
> [ 57.139748] [<c015b7dd>] exit_mmap+0x68/0xeb
> [ 57.139772] [<c01191b0>] mmput+0x52/0xcb
> [ 57.139805] [<c011c368>] exit_mm+0xbb/0xc3
> [ 57.139832] [<c011d188>] do_exit+0x1ea/0x73e
> [ 57.139857] [<c011d74d>] sys_exit_group+0x0/0x13
> [ 57.139880] [<c012524e>] get_signal_to_deliver+0x6cd/0x6f8
> [ 57.139917] [<c01036cf>] do_notify_resume+0x91/0x692
> [ 57.139944] [<c0103f15>] work_notifysig+0x13/0x1a
> [ 57.139970] [<b7f6b7a8>] 0xb7f6b7a8
> [ 57.139988] =======================
> [ 57.140002] INFO: lockdep is turned off.
> [ 57.140015] Code: c0 74 0d 8b 50 0c b8 e5 ab 42 c0 e8 d7 fa fd ff 8b 46 48 85 c0 74 14 8b 40 10 85 c0 74 0d 8b 50 2c b8 04 ac 42 c0 e8 bc fa fd ff <0f> 0b eb fe 8b 53 10 8b 03 83 e2 01 f7 da c1 e8 1e 83 c2 04 69
I don't know which patch might have caused that. Is it always
getcfg-interface which dies? Seems to be a suse-only thing, and I
unfortunately don't have any test boxes which have it.
It seems wildly screwed up that we have a PageReserved() page with a pfn of
zero (!) which claims to be in a reiserfs mapping, only it isn't attached to a
reiserfs file. How the heck did that happen?
Nick, I think that printk needs updating for changed vm_operations methods,
btw (->fault?)
This puts a dark cloud over about 200 patches at present. It would be
great if you could perform a bisection search as per
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt.
I'd start out at fix-slab-corruption-running-ip6sic.patch then try
mm-fix-handling-of-panic_on_oom-when-cpusets-are-in-use.patch. It should
take six or seven hops.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-04-28 21:10 ` Andrew Morton
@ 2007-04-28 22:06 ` Hugh Dickins
-1 siblings, 0 replies; 135+ messages in thread
From: Hugh Dickins @ 2007-04-28 22:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tilman Schmidt, linux-kernel, linux-mm, Nick Piggin
On Sat, 28 Apr 2007, Andrew Morton wrote:
>
> It seems wildly screwed up that we have a PageReserved() page with a pfn of
> zero (!) which claims to be in a reiserfs mapping, only it isn't attached
> to a reiserfs file. How the heck did that happen?
It's "simply" that it somehow got a spurious page table entry 00000001.
Great that it's so reproducible, I take that to mean this one is not
bad RAM. Your request for a bisection is just what we want, thanks.
Hugh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-04-28 22:06 ` Hugh Dickins
0 siblings, 0 replies; 135+ messages in thread
From: Hugh Dickins @ 2007-04-28 22:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tilman Schmidt, linux-kernel, linux-mm, Nick Piggin
On Sat, 28 Apr 2007, Andrew Morton wrote:
>
> It seems wildly screwed up that we have a PageReserved() page with a pfn of
> zero (!) which claims to be in a reiserfs mapping, only it isn't attached
> to a reiserfs file. How the heck did that happen?
It's "simply" that it somehow got a spurious page table entry 00000001.
Great that it's so reproducible, I take that to mean this one is not
bad RAM. Your request for a bisection is just what we want, thanks.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-04-28 21:10 ` Andrew Morton
(?)
(?)
@ 2007-04-30 17:17 ` Tilman Schmidt
2007-04-30 18:21 ` Andrew Morton
-1 siblings, 1 reply; 135+ messages in thread
From: Tilman Schmidt @ 2007-04-30 17:17 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]
>> With kernel 2.6.21-rc7-mm2, my Dell Optiplex GX110 (P3/933) regularly
>> crashes during the SuSE 10.1 startup sequence. When booting to RL5,
>> it panicblinks shortly after the graphical login screen appears.
>> Booting to RL3, it hangs after the startup message:
I have now bisected this down to the section in the series file between
#GREGKH-DRIVER-START and #GREGKH-DRIVER-END, and therefore added GregKH
to the CC list. I'll try bisecting further inside that section (unless
you tell me not to), but it may take some time.
The exact point during the startup sequence when the crash occurred and
the amount of BUG messages produced varied somewhat during these tests.
The common denominator, and my criterion for the good/bad decisions
during the bisect, was the crash (panic blink) just before completion
of the system startup.
Sometimes there weren't any BUG messages in the log (or perhaps they
just didn't make it to the disk.) Sometimes I just had a couple of the
"sleeping function called from invalid context at mm/slab.c:3054"
ones but no "Eeek! page_mapcount(page) went negative!" one before them.
However, whenever the "Eeek!" did appear it announced "getcfg-interfac"
as the current process and was followed by a few of the "mm/slab.c:3054"
ones.
HTH
Tilman
--
In the long run, we'll all be dead.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-04-30 17:17 ` Tilman Schmidt
@ 2007-04-30 18:21 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-30 18:21 UTC (permalink / raw)
To: Tilman Schmidt
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
On Mon, 30 Apr 2007 19:17:02 +0200
Tilman Schmidt <tilman@imap.cc> wrote:
> >> With kernel 2.6.21-rc7-mm2, my Dell Optiplex GX110 (P3/933) regularly
> >> crashes during the SuSE 10.1 startup sequence. When booting to RL5,
> >> it panicblinks shortly after the graphical login screen appears.
> >> Booting to RL3, it hangs after the startup message:
>
> I have now bisected this down to the section in the series file between
> #GREGKH-DRIVER-START and #GREGKH-DRIVER-END, and therefore added GregKH
> to the CC list.
This is rather good news. I was staring at about 200-300 MM patches
wondering which one was buggy. Thanks heaps for doing the bisect. Now the
main worry is Randy's dead box.
A lot of Greg's driver tree has gone upstream, so please check current
mainline. If that's OK then we need to pick through the difference between
2.6.21-rc7-mm2's driver tree and the patches which went into mainline. And
that's a pretty small set.
> I'll try bisecting further inside that section (unless
> you tell me not to), but it may take some time.
>
> The exact point during the startup sequence when the crash occurred and
> the amount of BUG messages produced varied somewhat during these tests.
> The common denominator, and my criterion for the good/bad decisions
> during the bisect, was the crash (panic blink) just before completion
> of the system startup.
> Sometimes there weren't any BUG messages in the log (or perhaps they
> just didn't make it to the disk.) Sometimes I just had a couple of the
> "sleeping function called from invalid context at mm/slab.c:3054"
> ones but no "Eeek! page_mapcount(page) went negative!" one before them.
> However, whenever the "Eeek!" did appear it announced "getcfg-interfac"
> as the current process and was followed by a few of the "mm/slab.c:3054"
> ones.
hm, big mess. Could be it was some glitch from Tejun's sysfs changes which
are all being extensively redone, so perhaps we'll never hear from it
again. Or perhaps we just merged it into mainline.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-04-30 18:21 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-30 18:21 UTC (permalink / raw)
To: Tilman Schmidt
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
On Mon, 30 Apr 2007 19:17:02 +0200
Tilman Schmidt <tilman@imap.cc> wrote:
> >> With kernel 2.6.21-rc7-mm2, my Dell Optiplex GX110 (P3/933) regularly
> >> crashes during the SuSE 10.1 startup sequence. When booting to RL5,
> >> it panicblinks shortly after the graphical login screen appears.
> >> Booting to RL3, it hangs after the startup message:
>
> I have now bisected this down to the section in the series file between
> #GREGKH-DRIVER-START and #GREGKH-DRIVER-END, and therefore added GregKH
> to the CC list.
This is rather good news. I was staring at about 200-300 MM patches
wondering which one was buggy. Thanks heaps for doing the bisect. Now the
main worry is Randy's dead box.
A lot of Greg's driver tree has gone upstream, so please check current
mainline. If that's OK then we need to pick through the difference between
2.6.21-rc7-mm2's driver tree and the patches which went into mainline. And
that's a pretty small set.
> I'll try bisecting further inside that section (unless
> you tell me not to), but it may take some time.
>
> The exact point during the startup sequence when the crash occurred and
> the amount of BUG messages produced varied somewhat during these tests.
> The common denominator, and my criterion for the good/bad decisions
> during the bisect, was the crash (panic blink) just before completion
> of the system startup.
> Sometimes there weren't any BUG messages in the log (or perhaps they
> just didn't make it to the disk.) Sometimes I just had a couple of the
> "sleeping function called from invalid context at mm/slab.c:3054"
> ones but no "Eeek! page_mapcount(page) went negative!" one before them.
> However, whenever the "Eeek!" did appear it announced "getcfg-interfac"
> as the current process and was followed by a few of the "mm/slab.c:3054"
> ones.
hm, big mess. Could be it was some glitch from Tejun's sysfs changes which
are all being extensively redone, so perhaps we'll never hear from it
again. Or perhaps we just merged it into mainline.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-04-30 18:21 ` Andrew Morton
(?)
@ 2007-04-30 19:28 ` Tilman Schmidt
2007-04-30 19:46 ` Andrew Morton
-1 siblings, 1 reply; 135+ messages in thread
From: Tilman Schmidt @ 2007-04-30 19:28 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
Am 30.04.2007 20:21 schrieb Andrew Morton:
> A lot of Greg's driver tree has gone upstream, so please check current
> mainline.
2.6.21-final is fine.
> If that's OK then we need to pick through the difference between
> 2.6.21-rc7-mm2's driver tree and the patches which went into mainline. And
> that's a pretty small set.
I'm not quite sure how to determine that difference. Can you just provide
me with a list of patches you'd like me to test?
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Wehrhausweg 66 Fax: +49 228 4299019
53227 Bonn
Germany
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-04-30 19:28 ` Tilman Schmidt
@ 2007-04-30 19:46 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-30 19:46 UTC (permalink / raw)
To: Tilman Schmidt
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
On Mon, 30 Apr 2007 21:28:06 +0200
Tilman Schmidt <tilman@imap.cc> wrote:
> Am 30.04.2007 20:21 schrieb Andrew Morton:
> > A lot of Greg's driver tree has gone upstream, so please check current
> > mainline.
>
> 2.6.21-final is fine.
Sure, but what about 2.6.21-git3 (or, better, current -git)?
> > If that's OK then we need to pick through the difference between
> > 2.6.21-rc7-mm2's driver tree and the patches which went into mainline. And
> > that's a pretty small set.
>
> I'm not quite sure how to determine that difference. Can you just provide
> me with a list of patches you'd like me to test?
Not really - everything's tangled up. A bisection search on the
2.6.21-rc7-mm2 driver tree would be the best bet.
See, 2.6.21-rc7-mm2 had:
gregkh-driver-driver-core-fix-device_add-error-path.patch
gregkh-driver-driver-core-fix-namespace-issue-with-devices-assigned-to-classes.patch
gregkh-driver-dev_printk-and-new-style-class-devices.patch
gregkh-driver-driver-core-udev-triggered-device-driver-binding.patch
gregkh-driver-driver-core-use-attribute-groups-in-struct-device_type.patch
gregkh-driver-named-device_type.patch
gregkh-driver-kobject-kobject_shadow_add-cleanup.patch
gregkh-driver-driver-core-per-subsystem-multithreaded-probing.patch
gregkh-driver-powerpc-make-it-compile-for-multithread-change.patch
gregkh-driver-driver-core-don-t-fail-attaching-the-device-if-it-cannot-be-bound.patch
gregkh-driver-driver-no-more-wait.patch
gregkh-driver-kref-fix-cpu-ordering-with-respect-to-krefs.patch
gregkh-driver-driver-core-notify-userspace-of-network-device-renames.patch
gregkh-driver-driver-core-suppress-uevents-via-filter.patch
gregkh-driver-driver-core-switch-firmware_class-to-uevent_suppress.patch
gregkh-driver-uevent-use-add_uevent_var-instead-of-open-coding-it.patch
gregkh-driver-driver-core-add-suspend-and-resume-to-struct-device_type.patch
gregkh-driver-kobject-kobject_ueventc-collapse-unnecessary-loop-nesting.patch
gregkh-driver-kobject-kobject_add-reference-leak.patch
gregkh-driver-devices_subsys-rwsem-removal.patch
gregkh-driver-scsi-hosts-rwsem-removal.patch
gregkh-driver-usb-bus-mutex.patch
gregkh-driver-pnp-remove-rwsem-usage.patch
gregkh-driver-input-serio-do-not-touch-bus-s-rwsem.patch
gregkh-driver-input-gameport-do-not-touch-bus-s-rwsem.patch
gregkh-driver-ide-proc-remove-rwsem.patch
gregkh-driver-ieee1394-rwsem-removal.patch
gregkh-driver-phy-rwsem-removal.patch
gregkh-driver-qeth-remove-usage-of-subsys_rwsem.patch
gregkh-driver-subsys-rwsem-removal.patch
gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch
gregkh-driver-sysfs-fix-error-handling-in-binattr-write.patch
gregkh-driver-sysfs-move-release_sysfs_dirent-to-dirc.patch
gregkh-driver-sysfs-flatten-cleanup-paths-in-sysfs_add_link-and-create_dir.patch
gregkh-driver-sysfs-consolidate-sysfs_dirent-creation-functions.patch
gregkh-driver-sysfs-add-sysfs_dirent-s_parent.patch
gregkh-driver-sysfs-add-sysfs_dirent-s_name.patch
gregkh-driver-sysfs-make-sysfs_dirent-s_element-a-union.patch
gregkh-driver-sysfs-implement-kobj_sysfs_assoc_lock.patch
gregkh-driver-sysfs-reimplement-symlink-using-sysfs_dirent-tree.patch
gregkh-driver-sysfs-implement-bin_buffer.patch
gregkh-driver-sysfs-implement-sysfs_dirent-active-reference-and-immediate-disconnect.patch
gregkh-driver-sysfs-kill-attribute-file-orphaning.patch
gregkh-driver-sysfs-kill-unnecessary-attribute-owner.patch
gregkh-driver-sysfs-make-lockdep-ignore-s_active.patch
gregkh-driver-sysfs-make-sysfs_put-ignore-null-sd.patch
gregkh-driver-sysfs-rename-object_depth-to-sysfs_path_depth-and-make-it-global.patch
gregkh-driver-sysfs-reimplement-sysfs_drop_dentry.patch
gregkh-driver-sysfs-kill-sysfs_dirent-s_dentry.patch
gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
gregkh-driver-driver-core-warn-for-odd-store-uevent-usage.patch
gregkh-driver-kobject-comment-and-warning-fixes-to-kobjectc.patch
gregkh-driver-the-overdue-removal-of-the-mount-umount-uevents.patch
gregkh-driver-debugfs-add-debugfs_create_u64.patch
gregkh-driver-bus_add_driver-return-error-for-no-bus.patch
gregkh-driver-uio.patch
gregkh-driver-uio-documentation.patch
gregkh-driver-uio-dummy.patch
gregkh-driver-uio-hilscher-cif-card-driver.patch
gregkh-driver-remove-struct-subsystem-as-it-is-no-longer-needed.patch
gregkh-driver-put_device-might_sleep.patch
gregkh-driver-kobject-warn.patch
gregkh-driver-warn-when-statically-allocated-kobjects-are-used.patch
gregkh-driver-nozomi.patch
and Greg's driver tree (as of yesterday, I think) had
gregkh-driver-uio.patch
gregkh-driver-uio-documentation.patch
gregkh-driver-uio-dummy.patch
gregkh-driver-uio-hilscher-cif-card-driver.patch
gregkh-driver-remove-struct-subsystem-as-it-is-no-longer-needed.patch
gregkh-driver-put_device-might_sleep.patch
gregkh-driver-kobject-warn.patch
gregkh-driver-warn-when-statically-allocated-kobjects-are-used.patch
gregkh-driver-nozomi.patch
So what has happened (approximately) is that
- the above nine patches have been held back, or are new
- Tejun's sysfs changes have been dropped
- Everything else from 2.6.21-rc7-mm2 has gone into mainline
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-04-30 19:46 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-30 19:46 UTC (permalink / raw)
To: Tilman Schmidt
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
On Mon, 30 Apr 2007 21:28:06 +0200
Tilman Schmidt <tilman@imap.cc> wrote:
> Am 30.04.2007 20:21 schrieb Andrew Morton:
> > A lot of Greg's driver tree has gone upstream, so please check current
> > mainline.
>
> 2.6.21-final is fine.
Sure, but what about 2.6.21-git3 (or, better, current -git)?
> > If that's OK then we need to pick through the difference between
> > 2.6.21-rc7-mm2's driver tree and the patches which went into mainline. And
> > that's a pretty small set.
>
> I'm not quite sure how to determine that difference. Can you just provide
> me with a list of patches you'd like me to test?
Not really - everything's tangled up. A bisection search on the
2.6.21-rc7-mm2 driver tree would be the best bet.
See, 2.6.21-rc7-mm2 had:
gregkh-driver-driver-core-fix-device_add-error-path.patch
gregkh-driver-driver-core-fix-namespace-issue-with-devices-assigned-to-classes.patch
gregkh-driver-dev_printk-and-new-style-class-devices.patch
gregkh-driver-driver-core-udev-triggered-device-driver-binding.patch
gregkh-driver-driver-core-use-attribute-groups-in-struct-device_type.patch
gregkh-driver-named-device_type.patch
gregkh-driver-kobject-kobject_shadow_add-cleanup.patch
gregkh-driver-driver-core-per-subsystem-multithreaded-probing.patch
gregkh-driver-powerpc-make-it-compile-for-multithread-change.patch
gregkh-driver-driver-core-don-t-fail-attaching-the-device-if-it-cannot-be-bound.patch
gregkh-driver-driver-no-more-wait.patch
gregkh-driver-kref-fix-cpu-ordering-with-respect-to-krefs.patch
gregkh-driver-driver-core-notify-userspace-of-network-device-renames.patch
gregkh-driver-driver-core-suppress-uevents-via-filter.patch
gregkh-driver-driver-core-switch-firmware_class-to-uevent_suppress.patch
gregkh-driver-uevent-use-add_uevent_var-instead-of-open-coding-it.patch
gregkh-driver-driver-core-add-suspend-and-resume-to-struct-device_type.patch
gregkh-driver-kobject-kobject_ueventc-collapse-unnecessary-loop-nesting.patch
gregkh-driver-kobject-kobject_add-reference-leak.patch
gregkh-driver-devices_subsys-rwsem-removal.patch
gregkh-driver-scsi-hosts-rwsem-removal.patch
gregkh-driver-usb-bus-mutex.patch
gregkh-driver-pnp-remove-rwsem-usage.patch
gregkh-driver-input-serio-do-not-touch-bus-s-rwsem.patch
gregkh-driver-input-gameport-do-not-touch-bus-s-rwsem.patch
gregkh-driver-ide-proc-remove-rwsem.patch
gregkh-driver-ieee1394-rwsem-removal.patch
gregkh-driver-phy-rwsem-removal.patch
gregkh-driver-qeth-remove-usage-of-subsys_rwsem.patch
gregkh-driver-subsys-rwsem-removal.patch
gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch
gregkh-driver-sysfs-fix-error-handling-in-binattr-write.patch
gregkh-driver-sysfs-move-release_sysfs_dirent-to-dirc.patch
gregkh-driver-sysfs-flatten-cleanup-paths-in-sysfs_add_link-and-create_dir.patch
gregkh-driver-sysfs-consolidate-sysfs_dirent-creation-functions.patch
gregkh-driver-sysfs-add-sysfs_dirent-s_parent.patch
gregkh-driver-sysfs-add-sysfs_dirent-s_name.patch
gregkh-driver-sysfs-make-sysfs_dirent-s_element-a-union.patch
gregkh-driver-sysfs-implement-kobj_sysfs_assoc_lock.patch
gregkh-driver-sysfs-reimplement-symlink-using-sysfs_dirent-tree.patch
gregkh-driver-sysfs-implement-bin_buffer.patch
gregkh-driver-sysfs-implement-sysfs_dirent-active-reference-and-immediate-disconnect.patch
gregkh-driver-sysfs-kill-attribute-file-orphaning.patch
gregkh-driver-sysfs-kill-unnecessary-attribute-owner.patch
gregkh-driver-sysfs-make-lockdep-ignore-s_active.patch
gregkh-driver-sysfs-make-sysfs_put-ignore-null-sd.patch
gregkh-driver-sysfs-rename-object_depth-to-sysfs_path_depth-and-make-it-global.patch
gregkh-driver-sysfs-reimplement-sysfs_drop_dentry.patch
gregkh-driver-sysfs-kill-sysfs_dirent-s_dentry.patch
gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
gregkh-driver-driver-core-warn-for-odd-store-uevent-usage.patch
gregkh-driver-kobject-comment-and-warning-fixes-to-kobjectc.patch
gregkh-driver-the-overdue-removal-of-the-mount-umount-uevents.patch
gregkh-driver-debugfs-add-debugfs_create_u64.patch
gregkh-driver-bus_add_driver-return-error-for-no-bus.patch
gregkh-driver-uio.patch
gregkh-driver-uio-documentation.patch
gregkh-driver-uio-dummy.patch
gregkh-driver-uio-hilscher-cif-card-driver.patch
gregkh-driver-remove-struct-subsystem-as-it-is-no-longer-needed.patch
gregkh-driver-put_device-might_sleep.patch
gregkh-driver-kobject-warn.patch
gregkh-driver-warn-when-statically-allocated-kobjects-are-used.patch
gregkh-driver-nozomi.patch
and Greg's driver tree (as of yesterday, I think) had
gregkh-driver-uio.patch
gregkh-driver-uio-documentation.patch
gregkh-driver-uio-dummy.patch
gregkh-driver-uio-hilscher-cif-card-driver.patch
gregkh-driver-remove-struct-subsystem-as-it-is-no-longer-needed.patch
gregkh-driver-put_device-might_sleep.patch
gregkh-driver-kobject-warn.patch
gregkh-driver-warn-when-statically-allocated-kobjects-are-used.patch
gregkh-driver-nozomi.patch
So what has happened (approximately) is that
- the above nine patches have been held back, or are new
- Tejun's sysfs changes have been dropped
- Everything else from 2.6.21-rc7-mm2 has gone into mainline
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-04-30 19:46 ` Andrew Morton
(?)
@ 2007-04-30 21:32 ` Tilman Schmidt
-1 siblings, 0 replies; 135+ messages in thread
From: Tilman Schmidt @ 2007-04-30 21:32 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 906 bytes --]
Am 30.04.2007 21:46 schrieb Andrew Morton:
>> 2.6.21-final is fine.
>
> Sure, but what about 2.6.21-git3 (or, better, current -git)?
OIC. Sorry for being dense. Will check.
>>> If that's OK then we need to pick through the difference between
>>> 2.6.21-rc7-mm2's driver tree and the patches which went into mainline. And
>>> that's a pretty small set.
>> I'm not quite sure how to determine that difference. Can you just provide
>> me with a list of patches you'd like me to test?
>
> Not really - everything's tangled up. A bisection search on the
> 2.6.21-rc7-mm2 driver tree would be the best bet.
Ok. No prob. It'll just take a bit of time. (Compiling a kernel on
that machine takes about 4 hours.)
I'll be back. :-)
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-04-30 19:46 ` Andrew Morton
(?)
(?)
@ 2007-05-01 11:26 ` Tilman Schmidt
2007-05-02 3:10 ` Greg KH
-1 siblings, 1 reply; 135+ messages in thread
From: Tilman Schmidt @ 2007-05-01 11:26 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
Am 30.04.2007 21:46 schrieb Andrew Morton:
> Sure, but what about 2.6.21-git3 (or, better, current -git)?
2.6.21-git3 crashed with panic blink at "scanning usb: .."
(Nothing in the log this time.)
Will continue bisecting -rc7-mm2.
HTH
T.
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-01 11:26 ` Tilman Schmidt
@ 2007-05-02 3:10 ` Greg KH
0 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 3:10 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Andrew Morton, linux-kernel, linux-mm, Nick Piggin, Hugh Dickins
On Tue, May 01, 2007 at 01:26:44PM +0200, Tilman Schmidt wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
> > Sure, but what about 2.6.21-git3 (or, better, current -git)?
>
> 2.6.21-git3 crashed with panic blink at "scanning usb: .."
> (Nothing in the log this time.)
Eeek, that's not good.
Can you keep bisecting Linus's tree? 'git bisect' makes this very easy
to do. We need to track this down as soon as possible if we can.
> Will continue bisecting -rc7-mm2.
Can you focus on Linus's tree now, as we know that it is the part
causing problems?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 3:10 ` Greg KH
0 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 3:10 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Andrew Morton, linux-kernel, linux-mm, Nick Piggin, Hugh Dickins
On Tue, May 01, 2007 at 01:26:44PM +0200, Tilman Schmidt wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
> > Sure, but what about 2.6.21-git3 (or, better, current -git)?
>
> 2.6.21-git3 crashed with panic blink at "scanning usb: .."
> (Nothing in the log this time.)
Eeek, that's not good.
Can you keep bisecting Linus's tree? 'git bisect' makes this very easy
to do. We need to track this down as soon as possible if we can.
> Will continue bisecting -rc7-mm2.
Can you focus on Linus's tree now, as we know that it is the part
causing problems?
thanks,
greg k-h
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-04-30 19:46 ` Andrew Morton
` (2 preceding siblings ...)
(?)
@ 2007-05-02 7:01 ` Tilman Schmidt
2007-05-02 7:02 ` Greg KH
` (2 more replies)
-1 siblings, 3 replies; 135+ messages in thread
From: Tilman Schmidt @ 2007-05-02 7:01 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
Am 30.04.2007 21:46 schrieb Andrew Morton:
> Not really - everything's tangled up. A bisection search on the
> 2.6.21-rc7-mm2 driver tree would be the best bet.
And the winner is:
gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
again.
I'll try building 2.6.21-git3 minus that one next, but I'll have
to revert it manually, because my naive attempt to "patch -R" it
failed 1 out of 2 hunks.
HTH
T.
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 7:01 ` Tilman Schmidt
@ 2007-05-02 7:02 ` Greg KH
2007-05-02 7:10 ` Andrew Morton
2007-05-02 7:10 ` Nick Piggin
2 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 7:02 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Andrew Morton, linux-kernel, linux-mm, Nick Piggin, Hugh Dickins,
kay.sievers
On Wed, May 02, 2007 at 09:01:22AM +0200, Tilman Schmidt wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
> > Not really - everything's tangled up. A bisection search on the
> > 2.6.21-rc7-mm2 driver tree would be the best bet.
>
> And the winner is:
>
> gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
>
> Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> again.
>
> I'll try building 2.6.21-git3 minus that one next, but I'll have
> to revert it manually, because my naive attempt to "patch -R" it
> failed 1 out of 2 hunks.
Ok, that's just wierd, it only adds a new feature, it doesn't touch any
existing code to cause things to go wrong.
Can you try using 'git bisect' on Linus's tree instead? That should
show the real problem much easier.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 7:02 ` Greg KH
0 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 7:02 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Andrew Morton, linux-kernel, linux-mm, Nick Piggin, Hugh Dickins,
kay.sievers
On Wed, May 02, 2007 at 09:01:22AM +0200, Tilman Schmidt wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
> > Not really - everything's tangled up. A bisection search on the
> > 2.6.21-rc7-mm2 driver tree would be the best bet.
>
> And the winner is:
>
> gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
>
> Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> again.
>
> I'll try building 2.6.21-git3 minus that one next, but I'll have
> to revert it manually, because my naive attempt to "patch -R" it
> failed 1 out of 2 hunks.
Ok, that's just wierd, it only adds a new feature, it doesn't touch any
existing code to cause things to go wrong.
Can you try using 'git bisect' on Linus's tree instead? That should
show the real problem much easier.
thanks,
greg k-h
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 7:01 ` Tilman Schmidt
@ 2007-05-02 7:10 ` Andrew Morton
2007-05-02 7:10 ` Andrew Morton
2007-05-02 7:10 ` Nick Piggin
2 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-05-02 7:10 UTC (permalink / raw)
To: Tilman Schmidt, Kay Sievers
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
> > Not really - everything's tangled up. A bisection search on the
> > 2.6.21-rc7-mm2 driver tree would be the best bet.
>
> And the winner is:
>
> gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
>
> Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> again.
cripes.
+static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct kobject *top_kobj;
+ struct kset *kset;
+ char *envp[32];
+ char data[PAGE_SIZE];
That won't work too well with 4k stacks.
Who's reviewing this stuff? The patch headers indicate that no mailing list was
cc'ed?
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 7:10 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-05-02 7:10 UTC (permalink / raw)
To: Tilman Schmidt, Kay Sievers
Cc: linux-kernel, linux-mm, Nick Piggin, Hugh Dickins, Greg Kroah-Hartman
On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
> > Not really - everything's tangled up. A bisection search on the
> > 2.6.21-rc7-mm2 driver tree would be the best bet.
>
> And the winner is:
>
> gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
>
> Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> again.
cripes.
+static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct kobject *top_kobj;
+ struct kset *kset;
+ char *envp[32];
+ char data[PAGE_SIZE];
That won't work too well with 4k stacks.
Who's reviewing this stuff? The patch headers indicate that no mailing list was
cc'ed?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 7:10 ` Andrew Morton
@ 2007-05-02 7:28 ` Greg KH
-1 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 7:28 UTC (permalink / raw)
To: Andrew Morton
Cc: Tilman Schmidt, Kay Sievers, linux-kernel, linux-mm, Nick Piggin,
Hugh Dickins
On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
>
> > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > Not really - everything's tangled up. A bisection search on the
> > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> >
> > And the winner is:
> >
> > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> >
> > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > again.
>
> cripes.
>
> +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct kobject *top_kobj;
> + struct kset *kset;
> + char *envp[32];
> + char data[PAGE_SIZE];
>
> That won't work too well with 4k stacks.
Oh crap. Yeah, that's not nice.
> Who's reviewing this stuff? The patch headers indicate that no mailing list was
> cc'ed?
Kay and I did this, sorry, it should have been cc:ed to lkml.
I'll go fix it up now...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 7:28 ` Greg KH
0 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 7:28 UTC (permalink / raw)
To: Andrew Morton
Cc: Tilman Schmidt, Kay Sievers, linux-kernel, linux-mm, Nick Piggin,
Hugh Dickins
On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
>
> > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > Not really - everything's tangled up. A bisection search on the
> > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> >
> > And the winner is:
> >
> > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> >
> > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > again.
>
> cripes.
>
> +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct kobject *top_kobj;
> + struct kset *kset;
> + char *envp[32];
> + char data[PAGE_SIZE];
>
> That won't work too well with 4k stacks.
Oh crap. Yeah, that's not nice.
> Who's reviewing this stuff? The patch headers indicate that no mailing list was
> cc'ed?
Kay and I did this, sorry, it should have been cc:ed to lkml.
I'll go fix it up now...
thanks,
greg k-h
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 7:10 ` Andrew Morton
@ 2007-05-02 7:43 ` Greg KH
-1 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 7:43 UTC (permalink / raw)
To: Andrew Morton
Cc: Tilman Schmidt, Kay Sievers, linux-kernel, linux-mm, Nick Piggin,
Hugh Dickins
On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
>
> > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > Not really - everything's tangled up. A bisection search on the
> > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> >
> > And the winner is:
> >
> > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> >
> > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > again.
>
> cripes.
>
> +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct kobject *top_kobj;
> + struct kset *kset;
> + char *envp[32];
> + char data[PAGE_SIZE];
>
> That won't work too well with 4k stacks.
Wait, even though this isn't good, it shouldn't have been hit by anyone,
that file used to not be readable, so I doubt userspace would have been
trying to read it...
Tilman, what version of HAL and udev do you have on your machine?
Kay, did you get the 'read the uevent file' code already into udev
and/or HAL?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 7:43 ` Greg KH
0 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 7:43 UTC (permalink / raw)
To: Andrew Morton
Cc: Tilman Schmidt, Kay Sievers, linux-kernel, linux-mm, Nick Piggin,
Hugh Dickins
On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
>
> > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > Not really - everything's tangled up. A bisection search on the
> > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> >
> > And the winner is:
> >
> > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> >
> > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > again.
>
> cripes.
>
> +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct kobject *top_kobj;
> + struct kset *kset;
> + char *envp[32];
> + char data[PAGE_SIZE];
>
> That won't work too well with 4k stacks.
Wait, even though this isn't good, it shouldn't have been hit by anyone,
that file used to not be readable, so I doubt userspace would have been
trying to read it...
Tilman, what version of HAL and udev do you have on your machine?
Kay, did you get the 'read the uevent file' code already into udev
and/or HAL?
thanks,
greg k-h
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 7:43 ` Greg KH
@ 2007-05-02 9:41 ` Tilman Schmidt
-1 siblings, 0 replies; 135+ messages in thread
From: Tilman Schmidt @ 2007-05-02 9:41 UTC (permalink / raw)
To: Greg KH, Andrew Morton
Cc: Kay Sievers, linux-kernel, linux-mm, Nick Piggin, Hugh Dickins
On Wed, 2 May 2007 00:43:05 -0700, "Greg KH" <gregkh@suse.de> said:
> > > And the winner is:
> > >
> > > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> > >
> > > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > > again.
>
> Wait, even though this isn't good, it shouldn't have been hit by anyone,
> that file used to not be readable, so I doubt userspace would have been
> trying to read it...
>
> Tilman, what version of HAL and udev do you have on your machine?
The ones that came with SuSE 10.0:
hal-0.5.4-6.4
udev-068git20050831-9
HTH
Tilman
PS: I'll test your patch and git-bisect when I'm back at the machine.
--
Tilman Schmidt
tilman@imap.cc
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 9:41 ` Tilman Schmidt
0 siblings, 0 replies; 135+ messages in thread
From: Tilman Schmidt @ 2007-05-02 9:41 UTC (permalink / raw)
To: Greg KH, Andrew Morton
Cc: Kay Sievers, linux-kernel, linux-mm, Nick Piggin, Hugh Dickins
On Wed, 2 May 2007 00:43:05 -0700, "Greg KH" <gregkh@suse.de> said:
> > > And the winner is:
> > >
> > > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> > >
> > > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > > again.
>
> Wait, even though this isn't good, it shouldn't have been hit by anyone,
> that file used to not be readable, so I doubt userspace would have been
> trying to read it...
>
> Tilman, what version of HAL and udev do you have on your machine?
The ones that came with SuSE 10.0:
hal-0.5.4-6.4
udev-068git20050831-9
HTH
Tilman
PS: I'll test your patch and git-bisect when I'm back at the machine.
--
Tilman Schmidt
tilman@imap.cc
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 9:41 ` Tilman Schmidt
@ 2007-05-02 22:06 ` Greg KH
-1 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 22:06 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Andrew Morton, Kay Sievers, linux-kernel, linux-mm, Nick Piggin,
Hugh Dickins
On Wed, May 02, 2007 at 11:41:22AM +0200, Tilman Schmidt wrote:
> On Wed, 2 May 2007 00:43:05 -0700, "Greg KH" <gregkh@suse.de> said:
>
> > > > And the winner is:
> > > >
> > > > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> > > >
> > > > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > > > again.
> >
> > Wait, even though this isn't good, it shouldn't have been hit by anyone,
> > that file used to not be readable, so I doubt userspace would have been
> > trying to read it...
> >
> > Tilman, what version of HAL and udev do you have on your machine?
>
> The ones that came with SuSE 10.0:
>
> hal-0.5.4-6.4
> udev-068git20050831-9
Ah, ok, that explains it, the really old libsysfs walks and opens all
files in sysfs for some odd, strange, and broken reason. This has been
fixed in newer versions, and explains why you are seeing this happen.
I'll send my fix for this to Linus in a few hours.
thanks for testing and tracking this down, I really appreciate it.
greg k-h
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 22:06 ` Greg KH
0 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 22:06 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Andrew Morton, Kay Sievers, linux-kernel, linux-mm, Nick Piggin,
Hugh Dickins
On Wed, May 02, 2007 at 11:41:22AM +0200, Tilman Schmidt wrote:
> On Wed, 2 May 2007 00:43:05 -0700, "Greg KH" <gregkh@suse.de> said:
>
> > > > And the winner is:
> > > >
> > > > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> > > >
> > > > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > > > again.
> >
> > Wait, even though this isn't good, it shouldn't have been hit by anyone,
> > that file used to not be readable, so I doubt userspace would have been
> > trying to read it...
> >
> > Tilman, what version of HAL and udev do you have on your machine?
>
> The ones that came with SuSE 10.0:
>
> hal-0.5.4-6.4
> udev-068git20050831-9
Ah, ok, that explains it, the really old libsysfs walks and opens all
files in sysfs for some odd, strange, and broken reason. This has been
fixed in newer versions, and explains why you are seeing this happen.
I'll send my fix for this to Linus in a few hours.
thanks for testing and tracking this down, I really appreciate it.
greg k-h
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 7:43 ` Greg KH
@ 2007-05-02 12:14 ` Kay Sievers
-1 siblings, 0 replies; 135+ messages in thread
From: Kay Sievers @ 2007-05-02 12:14 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, Tilman Schmidt, linux-kernel, linux-mm,
Nick Piggin, Hugh Dickins
On 5/2/07, Greg KH <gregkh@suse.de> wrote:
> On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> > On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
> >
> > > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > > Not really - everything's tangled up. A bisection search on the
> > > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> > >
> > > And the winner is:
> > >
> > > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> > >
> > > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > > again.
> >
> > cripes.
> >
> > +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct kobject *top_kobj;
> > + struct kset *kset;
> > + char *envp[32];
> > + char data[PAGE_SIZE];
> >
> > That won't work too well with 4k stacks.
Yeah, sorry.
> Wait, even though this isn't good, it shouldn't have been hit by anyone,
> that file used to not be readable, so I doubt userspace would have been
> trying to read it...
>
> Tilman, what version of HAL and udev do you have on your machine?
>
> Kay, did you get the 'read the uevent file' code already into udev
> and/or HAL?
Only udevtest uses this at the moment, but that is only used for debugging.
It's probably the brain-dead libsysfs, which opens and reads every
file in /sys, even when nobody is interested in the data.
Thanks,
Kay
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 12:14 ` Kay Sievers
0 siblings, 0 replies; 135+ messages in thread
From: Kay Sievers @ 2007-05-02 12:14 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, Tilman Schmidt, linux-kernel, linux-mm,
Nick Piggin, Hugh Dickins
On 5/2/07, Greg KH <gregkh@suse.de> wrote:
> On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> > On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
> >
> > > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > > Not really - everything's tangled up. A bisection search on the
> > > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> > >
> > > And the winner is:
> > >
> > > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> > >
> > > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > > again.
> >
> > cripes.
> >
> > +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct kobject *top_kobj;
> > + struct kset *kset;
> > + char *envp[32];
> > + char data[PAGE_SIZE];
> >
> > That won't work too well with 4k stacks.
Yeah, sorry.
> Wait, even though this isn't good, it shouldn't have been hit by anyone,
> that file used to not be readable, so I doubt userspace would have been
> trying to read it...
>
> Tilman, what version of HAL and udev do you have on your machine?
>
> Kay, did you get the 'read the uevent file' code already into udev
> and/or HAL?
Only udevtest uses this at the moment, but that is only used for debugging.
It's probably the brain-dead libsysfs, which opens and reads every
file in /sys, even when nobody is interested in the data.
Thanks,
Kay
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 7:10 ` Andrew Morton
@ 2007-05-02 7:52 ` Greg KH
-1 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 7:52 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Kay Sievers, Andrew Morton, linux-kernel, linux-mm, Nick Piggin,
Hugh Dickins
On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
>
> > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > Not really - everything's tangled up. A bisection search on the
> > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> >
> > And the winner is:
> >
> > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> >
> > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > again.
>
> cripes.
>
> +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct kobject *top_kobj;
> + struct kset *kset;
> + char *envp[32];
> + char data[PAGE_SIZE];
>
> That won't work too well with 4k stacks.
Tilman, here's a patch, can you try this on top of your tree that dies?
thanks,
greg k-h
---
drivers/base/core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -252,7 +252,7 @@ static ssize_t show_uevent(struct device
struct kobject *top_kobj;
struct kset *kset;
char *envp[32];
- char data[PAGE_SIZE];
+ char *data = NULL;
char *pos;
int i;
size_t count = 0;
@@ -276,6 +276,10 @@ static ssize_t show_uevent(struct device
if (!kset->uevent_ops->filter(kset, &dev->kobj))
goto out;
+ data = (char *)get_zeroed_page(GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
/* let the kset specific function add its keys */
pos = data;
retval = kset->uevent_ops->uevent(kset, &dev->kobj,
@@ -290,6 +294,7 @@ static ssize_t show_uevent(struct device
count += sprintf(pos, "%s\n", envp[i]);
}
out:
+ free_page((unsigned long)data);
return count;
}
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 7:52 ` Greg KH
0 siblings, 0 replies; 135+ messages in thread
From: Greg KH @ 2007-05-02 7:52 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Kay Sievers, Andrew Morton, linux-kernel, linux-mm, Nick Piggin,
Hugh Dickins
On Wed, May 02, 2007 at 12:10:00AM -0700, Andrew Morton wrote:
> On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
>
> > Am 30.04.2007 21:46 schrieb Andrew Morton:
> > > Not really - everything's tangled up. A bisection search on the
> > > 2.6.21-rc7-mm2 driver tree would be the best bet.
> >
> > And the winner is:
> >
> > gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
> >
> > Reverting only that from 2.6.21-rc7-mm2 gives me a working kernel
> > again.
>
> cripes.
>
> +static ssize_t show_uevent(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct kobject *top_kobj;
> + struct kset *kset;
> + char *envp[32];
> + char data[PAGE_SIZE];
>
> That won't work too well with 4k stacks.
Tilman, here's a patch, can you try this on top of your tree that dies?
thanks,
greg k-h
---
drivers/base/core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -252,7 +252,7 @@ static ssize_t show_uevent(struct device
struct kobject *top_kobj;
struct kset *kset;
char *envp[32];
- char data[PAGE_SIZE];
+ char *data = NULL;
char *pos;
int i;
size_t count = 0;
@@ -276,6 +276,10 @@ static ssize_t show_uevent(struct device
if (!kset->uevent_ops->filter(kset, &dev->kobj))
goto out;
+ data = (char *)get_zeroed_page(GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
/* let the kset specific function add its keys */
pos = data;
retval = kset->uevent_ops->uevent(kset, &dev->kobj,
@@ -290,6 +294,7 @@ static ssize_t show_uevent(struct device
count += sprintf(pos, "%s\n", envp[i]);
}
out:
+ free_page((unsigned long)data);
return count;
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 7:52 ` Greg KH
(?)
@ 2007-05-02 17:36 ` Tilman Schmidt
2007-05-02 20:07 ` Andrew Morton
-1 siblings, 1 reply; 135+ messages in thread
From: Tilman Schmidt @ 2007-05-02 17:36 UTC (permalink / raw)
To: Greg KH
Cc: Kay Sievers, Andrew Morton, linux-kernel, linux-mm, Nick Piggin,
Hugh Dickins
[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]
Am 02.05.2007 09:52 schrieb Greg KH:
> Tilman, here's a patch, can you try this on top of your tree that dies?
2.6.21-git3 plus that patch comes up fine.
(Except for a UDP problem I seem to remember I already saw reported
on lkml and which I'll ignore for now in order not to blur the
picture.)
Started to git-bisect mainline now, but that will take some time.
It's more than 800 patches to check and I don't get more than 2-3
iterations per day out of that machine.
HTH
T.
> ---
> drivers/base/core.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -252,7 +252,7 @@ static ssize_t show_uevent(struct device
> struct kobject *top_kobj;
> struct kset *kset;
> char *envp[32];
> - char data[PAGE_SIZE];
> + char *data = NULL;
> char *pos;
> int i;
> size_t count = 0;
> @@ -276,6 +276,10 @@ static ssize_t show_uevent(struct device
> if (!kset->uevent_ops->filter(kset, &dev->kobj))
> goto out;
>
> + data = (char *)get_zeroed_page(GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> /* let the kset specific function add its keys */
> pos = data;
> retval = kset->uevent_ops->uevent(kset, &dev->kobj,
> @@ -290,6 +294,7 @@ static ssize_t show_uevent(struct device
> count += sprintf(pos, "%s\n", envp[i]);
> }
> out:
> + free_page((unsigned long)data);
> return count;
> }
>
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 17:36 ` Tilman Schmidt
@ 2007-05-02 20:07 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-05-02 20:07 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Greg KH, Kay Sievers, linux-kernel, linux-mm, Nick Piggin, Hugh Dickins
On Wed, 02 May 2007 19:36:03 +0200
Tilman Schmidt <tilman@imap.cc> wrote:
> Am 02.05.2007 09:52 schrieb Greg KH:
> > Tilman, here's a patch, can you try this on top of your tree that dies?
>
> 2.6.21-git3 plus that patch comes up fine.
>
> (Except for a UDP problem I seem to remember I already saw reported
> on lkml and which I'll ignore for now in order not to blur the
> picture.)
Thanks.
> Started to git-bisect mainline now, but that will take some time.
> It's more than 800 patches to check and I don't get more than 2-3
> iterations per day out of that machine.
I don't think there's much point in you doing that. We know what the bug is.
Switching to 8k stacks will probably fix things up too.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 20:07 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-05-02 20:07 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Greg KH, Kay Sievers, linux-kernel, linux-mm, Nick Piggin, Hugh Dickins
On Wed, 02 May 2007 19:36:03 +0200
Tilman Schmidt <tilman@imap.cc> wrote:
> Am 02.05.2007 09:52 schrieb Greg KH:
> > Tilman, here's a patch, can you try this on top of your tree that dies?
>
> 2.6.21-git3 plus that patch comes up fine.
>
> (Except for a UDP problem I seem to remember I already saw reported
> on lkml and which I'll ignore for now in order not to blur the
> picture.)
Thanks.
> Started to git-bisect mainline now, but that will take some time.
> It's more than 800 patches to check and I don't get more than 2-3
> iterations per day out of that machine.
I don't think there's much point in you doing that. We know what the bug is.
Switching to 8k stacks will probably fix things up too.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 20:07 ` Andrew Morton
(?)
@ 2007-05-02 21:22 ` Tilman Schmidt
-1 siblings, 0 replies; 135+ messages in thread
From: Tilman Schmidt @ 2007-05-02 21:22 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, Kay Sievers, linux-kernel, linux-mm, Nick Piggin, Hugh Dickins
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
Am 02.05.2007 22:07 schrieb Andrew Morton:
>> Started to git-bisect mainline now, but that will take some time.
[...]
> I don't think there's much point in you doing that. We know what the bug is.
Good. Saves me some work. :-)
If you'd like me to test anything, just let me know.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
2007-05-02 7:01 ` Tilman Schmidt
@ 2007-05-02 7:10 ` Nick Piggin
2007-05-02 7:10 ` Andrew Morton
2007-05-02 7:10 ` Nick Piggin
2 siblings, 0 replies; 135+ messages in thread
From: Nick Piggin @ 2007-05-02 7:10 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Andrew Morton, linux-kernel, linux-mm, Hugh Dickins, Greg Kroah-Hartman
Tilman Schmidt wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
>
>>Not really - everything's tangled up. A bisection search on the
>>2.6.21-rc7-mm2 driver tree would be the best bet.
>
>
> And the winner is:
>
> gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
+ struct kobject *top_kobj;
+ struct kset *kset;
+ char *envp[32];
+ char data[PAGE_SIZE];
+ char *pos;
+ int i;
+ size_t count = 0;
+ int retval;
... that seems like a lot of stack to be using.
--
SUSE Labs, Novell Inc.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1)
@ 2007-05-02 7:10 ` Nick Piggin
0 siblings, 0 replies; 135+ messages in thread
From: Nick Piggin @ 2007-05-02 7:10 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Andrew Morton, linux-kernel, linux-mm, Hugh Dickins, Greg Kroah-Hartman
Tilman Schmidt wrote:
> Am 30.04.2007 21:46 schrieb Andrew Morton:
>
>>Not really - everything's tangled up. A bisection search on the
>>2.6.21-rc7-mm2 driver tree would be the best bet.
>
>
> And the winner is:
>
> gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch
+ struct kobject *top_kobj;
+ struct kset *kset;
+ char *envp[32];
+ char data[PAGE_SIZE];
+ char *pos;
+ int i;
+ size_t count = 0;
+ int retval;
... that seems like a lot of stack to be using.
--
SUSE Labs, Novell Inc.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (8 preceding siblings ...)
2007-04-28 17:56 ` 2.6.21-rc7-mm2 crash: Eeek! page_mapcount(page) went negative! (-1) Tilman Schmidt
@ 2007-04-28 19:19 ` Adrian Bunk
2007-04-28 19:58 ` Henrique de Moraes Holschuh
2007-04-28 19:19 ` [-mm patch] MMC: make tifm_sd_set_dma_data() static Adrian Bunk
` (5 subsequent siblings)
15 siblings, 1 reply; 135+ messages in thread
From: Adrian Bunk @ 2007-04-28 19:19 UTC (permalink / raw)
To: Andrew Morton, Henrique de Moraes Holschuh, lenb; +Cc: linux-kernel, linux-acpi
On Wed, Apr 25, 2007 at 10:57:16PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc7-mm1:
>...
> git-acpi.patch
>...
> git trees
>...
This patch makes the needlessly global fan_mutex static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
BTW: Prototypes for static versions and static variables in a header
file are really wrong, but the mess is bigger than what I'm
willing to clean up...
--- linux-2.6.21-rc7-mm2/drivers/misc/thinkpad_acpi.h.old 2007-04-27 00:55:58.000000000 +0200
+++ linux-2.6.21-rc7-mm2/drivers/misc/thinkpad_acpi.h 2007-04-28 01:32:54.000000000 +0200
@@ -382,7 +382,7 @@
static u8 fan_control_desired_level;
static int fan_watchdog_maxinterval;
-struct mutex fan_mutex;
+static struct mutex fan_mutex;
static acpi_handle fans_handle, gfan_handle, sfan_handle;
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static
2007-04-28 19:19 ` [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static Adrian Bunk
@ 2007-04-28 19:58 ` Henrique de Moraes Holschuh
2007-04-29 1:53 ` Len Brown
2007-04-29 2:50 ` Adrian Bunk
0 siblings, 2 replies; 135+ messages in thread
From: Henrique de Moraes Holschuh @ 2007-04-28 19:58 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, lenb, linux-kernel, linux-acpi
On Sat, 28 Apr 2007, Adrian Bunk wrote:
> On Wed, Apr 25, 2007 at 10:57:16PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.21-rc7-mm1:
> >...
> > git-acpi.patch
> >...
> > git trees
> >...
>
>
> This patch makes the needlessly global fan_mutex static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Sorry about the oversight.
> ---
>
> BTW: Prototypes for static versions and static variables in a header
> file are really wrong, but the mess is bigger than what I'm
> willing to clean up...
It is a private header file, only one file uses it and it is not supposed to
be used by any other file ever, either. I can certainly do a cleaning up
and a lot can be removed (at least 70% of it), but the driver is not linear
(it is some infrastructure and various subdrivers) and there is a bunch of
stuff that will need forward declarations regardless.
Maybe I should just break the driver into multiple files in a subdirectory?
That would certainly make it *much* cleaner...
> --- linux-2.6.21-rc7-mm2/drivers/misc/thinkpad_acpi.h.old 2007-04-27 00:55:58.000000000 +0200
> +++ linux-2.6.21-rc7-mm2/drivers/misc/thinkpad_acpi.h 2007-04-28 01:32:54.000000000 +0200
> @@ -382,7 +382,7 @@
> static u8 fan_control_desired_level;
> static int fan_watchdog_maxinterval;
>
> -struct mutex fan_mutex;
> +static struct mutex fan_mutex;
>
> static acpi_handle fans_handle, gfan_handle, sfan_handle;
>
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static
2007-04-28 19:58 ` Henrique de Moraes Holschuh
@ 2007-04-29 1:53 ` Len Brown
2007-04-29 2:50 ` Adrian Bunk
1 sibling, 0 replies; 135+ messages in thread
From: Len Brown @ 2007-04-29 1:53 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Adrian Bunk, Andrew Morton, linux-kernel, linux-acpi
> > This patch makes the needlessly global fan_mutex static.
applied.
thanks,
-Len
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static
2007-04-28 19:58 ` Henrique de Moraes Holschuh
2007-04-29 1:53 ` Len Brown
@ 2007-04-29 2:50 ` Adrian Bunk
2007-04-29 4:09 ` Henrique de Moraes Holschuh
1 sibling, 1 reply; 135+ messages in thread
From: Adrian Bunk @ 2007-04-29 2:50 UTC (permalink / raw)
To: Henrique de Moraes Holschuh; +Cc: Andrew Morton, lenb, linux-kernel, linux-acpi
On Sat, Apr 28, 2007 at 04:58:21PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 28 Apr 2007, Adrian Bunk wrote:
>...
> > BTW: Prototypes for static versions and static variables in a header
> > file are really wrong, but the mess is bigger than what I'm
> > willing to clean up...
>
> It is a private header file, only one file uses it and it is not supposed to
> be used by any other file ever, either. I can certainly do a cleaning up
> and a lot can be removed (at least 70% of it), but the driver is not linear
> (it is some infrastructure and various subdrivers) and there is a bunch of
> stuff that will need forward declarations regardless.
Forward declarations of static functions (if required) and actual
variables (like fan_mutex) belong into the C file, not the header.
> Maybe I should just break the driver into multiple files in a subdirectory?
> That would certainly make it *much* cleaner...
But even more in this case, you will not want to have actual variables
or prototypes of static functions in the header file.
> > --- linux-2.6.21-rc7-mm2/drivers/misc/thinkpad_acpi.h.old 2007-04-27 00:55:58.000000000 +0200
> > +++ linux-2.6.21-rc7-mm2/drivers/misc/thinkpad_acpi.h 2007-04-28 01:32:54.000000000 +0200
> > @@ -382,7 +382,7 @@
> > static u8 fan_control_desired_level;
> > static int fan_watchdog_maxinterval;
> >
> > -struct mutex fan_mutex;
> > +static struct mutex fan_mutex;
> >
> > static acpi_handle fans_handle, gfan_handle, sfan_handle;
> >
> Henrique Holschuh
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] 135+ messages in thread* Re: [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static
2007-04-29 2:50 ` Adrian Bunk
@ 2007-04-29 4:09 ` Henrique de Moraes Holschuh
0 siblings, 0 replies; 135+ messages in thread
From: Henrique de Moraes Holschuh @ 2007-04-29 4:09 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, lenb, linux-kernel, linux-acpi
On Sun, 29 Apr 2007, Adrian Bunk wrote:
> Forward declarations of static functions (if required) and actual
> variables (like fan_mutex) belong into the C file, not the header.
Very well. I will fix the mess for 2.6.23, or, time permitting, 2.6.22.
> > Maybe I should just break the driver into multiple files in a subdirectory?
> > That would certainly make it *much* cleaner...
>
> But even more in this case, you will not want to have actual variables
> or prototypes of static functions in the header file.
I would not have to, in that case. The driver would be much easier to
write, and I will need to break it in two for an alsa module anyway, might
as well break it in one subdriver per file.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 135+ messages in thread
* [-mm patch] MMC: make tifm_sd_set_dma_data() static
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (9 preceding siblings ...)
2007-04-28 19:19 ` [-mm patch] make drivers/misc/thinkpad_acpi:fan_mutex static Adrian Bunk
@ 2007-04-28 19:19 ` Adrian Bunk
2007-05-01 14:14 ` Pierre Ossman
2007-04-28 19:20 ` [-mm patch] drivers/rtc/rtc-dev.c should #include "rtc-core.h" Adrian Bunk
` (4 subsequent siblings)
15 siblings, 1 reply; 135+ messages in thread
From: Adrian Bunk @ 2007-04-28 19:19 UTC (permalink / raw)
To: Andrew Morton, drzeus-mmc; +Cc: linux-kernel
On Wed, Apr 25, 2007 at 10:57:16PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc7-mm1:
>...
> git-mmc.patch
>...
> git trees
>...
This patch makes the needlessly global tifm_sd_set_dma_data() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.21-rc7-mm2/drivers/mmc/host/tifm_sd.c.old 2007-04-28 01:36:33.000000000 +0200
+++ linux-2.6.21-rc7-mm2/drivers/mmc/host/tifm_sd.c 2007-04-28 01:36:41.000000000 +0200
@@ -259,7 +259,7 @@
}
}
-int tifm_sd_set_dma_data(struct tifm_sd *host, struct mmc_data *r_data)
+static int tifm_sd_set_dma_data(struct tifm_sd *host, struct mmc_data *r_data)
{
struct tifm_dev *sock = host->dev;
unsigned int t_size = TIFM_DMA_TSIZE * r_data->blksz;
^ permalink raw reply [flat|nested] 135+ messages in thread* [-mm patch] drivers/rtc/rtc-dev.c should #include "rtc-core.h"
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (10 preceding siblings ...)
2007-04-28 19:19 ` [-mm patch] MMC: make tifm_sd_set_dma_data() static Adrian Bunk
@ 2007-04-28 19:20 ` Adrian Bunk
2007-04-28 19:20 ` [-mm patch] scsi/lpfc/lpfc_init.c: remove unused variable Adrian Bunk
` (3 subsequent siblings)
15 siblings, 0 replies; 135+ messages in thread
From: Adrian Bunk @ 2007-04-28 19:20 UTC (permalink / raw)
To: Andrew Morton, David Brownell, Alessandro Zummo; +Cc: linux-kernel, rtc-linux
Every file should include the headers containing the prototypes for
it's global functions.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.21-rc7-mm2/drivers/rtc/rtc-dev.c.old 2007-04-28 15:16:24.000000000 +0200
+++ linux-2.6.21-rc7-mm2/drivers/rtc/rtc-dev.c 2007-04-28 15:16:36.000000000 +0200
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/rtc.h>
+#include "rtc-core.h"
static dev_t rtc_devt;
^ permalink raw reply [flat|nested] 135+ messages in thread* [-mm patch] scsi/lpfc/lpfc_init.c: remove unused variable
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (11 preceding siblings ...)
2007-04-28 19:20 ` [-mm patch] drivers/rtc/rtc-dev.c should #include "rtc-core.h" Adrian Bunk
@ 2007-04-28 19:20 ` Adrian Bunk
2007-04-29 19:19 ` 2.6.21-rc7-mm2 Dan Kruchinin
` (2 subsequent siblings)
15 siblings, 0 replies; 135+ messages in thread
From: Adrian Bunk @ 2007-04-28 19:20 UTC (permalink / raw)
To: Andrew Morton, Randy Dunlap, James Smart, James Bottomley
Cc: linux-kernel, linux-scsi
This patch removes a no longer used variable:
<-- snip -->
...
CC drivers/scsi/lpfc/lpfc_init.o
/home/bunk/linux/kernel-2.6/linux-2.6.21-rc7-mm2/drivers/scsi/lpfc/lpfc_init.c: In function ‘lpfc_pci_probe_one’:
/home/bunk/linux/kernel-2.6/linux-2.6.21-rc7-mm2/drivers/scsi/lpfc/lpfc_init.c:1419: warning: unused variable ‘retval’
...
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.21-rc7-mm2/drivers/scsi/lpfc/lpfc_init.c.old 2007-04-28 15:20:42.000000000 +0200
+++ linux-2.6.21-rc7-mm2/drivers/scsi/lpfc/lpfc_init.c 2007-04-28 15:20:57.000000000 +0200
@@ -1416,7 +1416,7 @@
struct lpfc_sli *psli;
struct lpfc_iocbq *iocbq_entry = NULL, *iocbq_next = NULL;
unsigned long bar0map_len, bar2map_len;
- int error = -ENODEV, retval;
+ int error = -ENODEV;
int i;
uint16_t iotag;
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (12 preceding siblings ...)
2007-04-28 19:20 ` [-mm patch] scsi/lpfc/lpfc_init.c: remove unused variable Adrian Bunk
@ 2007-04-29 19:19 ` Dan Kruchinin
2007-04-29 19:48 ` 2.6.21-rc7-mm2 Andrew Morton
2007-04-30 5:01 ` 2.6.21-rc7-mm2 hangs in boot Randy Dunlap
2007-05-04 11:38 ` Andy Whitcroft
15 siblings, 1 reply; 135+ messages in thread
From: Dan Kruchinin @ 2007-04-29 19:19 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
Hi
On 4/26/07, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
>
>
> - this has everything which is in 2.6.21. Plus more!
>
> - a number of nasty bugs were fixed. This should be (a lot) more stable
> than 2.6.21-rc7-mm1.
>
> Some sysfs-related problems are still expected. Fiddling with the
> setting of CONFIG_SYSFS_DEPRECATED might help avoid them.
>
> - the 64-bit futex patches and (consequently) the private-futex patches were
> dropped. Because the 64-bit futex patches need to be reconstituted.
>
> - the unprivileged mounts code was dropped, pending an updated patch series
>
> - lots of minor fbdev bugs were fixed
>
>
> Boilerplate:
>
> - See the `hot-fixes' directory for any important updates to this patchset.
>
> - To fetch an -mm tree using git, use (for example)
>
> git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1
> git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1
>
> - -mm kernel commit activity can be reviewed by subscribing to the
> mm-commits mailing list.
>
> echo "subscribe mm-commits" | mail majordomo@vger.kernel.org
>
> - If you hit a bug in -mm and it is not obvious which patch caused it, it is
> most valuable if you can perform a bisection search to identify which patch
> introduced the bug. Instructions for this process are at
>
> http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
>
> But beware that this process takes some time (around ten rebuilds and
> reboots), so consider reporting the bug first and if we cannot immediately
> identify the faulty patch, then perform the bisection search.
>
> - When reporting bugs, please try to Cc: the relevant maintainer and mailing
> list on any email.
>
> - When reporting bugs in this kernel via email, please also rewrite the
> email Subject: in some manner to reflect the nature of the bug. Some
> developers filter by Subject: when looking for messages to read.
>
> - Occasional snapshots of the -mm lineup are uploaded to
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
> the mm-commits list.
>
>
>
> Changes since 2.6.21-rc7-mm1:
>
> origin.patch
> git-acpi.patch
> git-alsa.patch
> git-agpgart.patch
> git-arm.patch
> git-avr32.patch
> git-cifs.patch
> git-cpufreq.patch
> git-powerpc.patch
> git-drm.patch
> git-dvb.patch
> git-gfs2-nmw.patch
> git-hid.patch
> git-ia64.patch
> git-ieee1394.patch
> git-infiniband.patch
> git-input.patch
> git-jfs.patch
> git-kbuild.patch
> git-kvm.patch
> git-leds.patch
> git-libata-all.patch
> git-md-accel.patch
> git-mips.patch
> git-mmc.patch
> git-mtd.patch
> git-ubi.patch
> git-netdev-all.patch
> git-e1000.patch
> git-net.patch
> git-ioat.patch
> git-nfs-server-cluster-locking-api.patch
> git-ocfs2.patch
> git-parisc.patch
> git-r8169.patch
> git-selinux.patch
> git-pciseg.patch
> git-s390.patch
> git-s390-fixup.patch
> git-sh.patch
> git-scsi-misc.patch
> git-block.patch
> git-watchdog.patch
> git-ipwireless_cs.patch
> git-cryptodev.patch
> git-gccbug.patch
>
> git trees
>
> -fix-possible-null-pointer-access-in-8250-serial-driver.patch
> -fix-oom-killing-processes-wrongly-thought-mpol_bind.patch
> -char-mxser_new-fix-recursive-locking.patch
> -char-mxser_new-fix-tiocmiwait.patch
> -char-mxser-fix-tiocmiwait.patch
> -taskstats-fix-the-structure-members-alignment-issue.patch
> -maintainers-use-listslinux-foundationorg.patch
> -paride-drivers-initialize-spinlocks.patch
> -add-mbuesch-to-mailmap.patch
> -fix-spelling-in-drivers-video-kconfig.patch
> -page-migration-fix-nr_file_pages-accounting.patch
> -ieee1394-update-maintainers-database.patch
> -v9fs-dont-use-primary-fid-when-removing-file.patch
> -acpi-thermal-fix-mod_timer-interval.patch
> -allow-reading-tainted-flag-as-user.patch
> -do-not-truncate-irq-number-for-icom-adapter.patch
> -hwmon-w83627ehf-dont-redefine-region_offset.patch
> -reiserfs-fix-xattr-root-locking-refcount-bug.patch
> -char-icom-mark-__init-as-__devinit.patch
> -fault-injection-add-entry-to-maintainers.patch
> -8250-fix-possible-deadlock-between-serial8250_handle_port-and-serial8250_interrupt.patch
> -oom-kill-all-threads-that-share-mm-with-killed-task.patch
> -fix-x86-fix-potential-overflow-in-perfctr-reservation.patch
> -cleanup-cpufreq-kconfig-options.patch
> -ppc-pci_32-stop-using-old-hotplug-unsafe-apis.patch
> -jdelvare-i2c-i2c-delete-scx200_i2c.patch
> -jdelvare-i2c-i2c-obsolete-ixp2000-and-ixp4xx.patch
> -jdelvare-hwmon-hwmon-smsc47m1-use-dynamic-attributes.patch
> -ide-cmd64x-remove-broken-sw-mw-dma-support.patch
> -ide-cmd64x-interrupt-status-fixes-resend.patch
> -ide-cmd64x-add-fix-enablebits.patch
> -ide-cmd64x-procfs-code-fixes-cleanups.patch
> -ide-cmd64x-use-interrupt-status-from-mrdmode-register.patch
> -ide-cmd64x-add-back-mwdma-support.patch
> -git-netdev-all-baycom_ser_fdx-fix.patch
> -fix-sparse-errors-in-drivers-net-ibmvethc.patch
> -netdrv-perform-missing-csum_offset-conversions.patch
> -x86_64-mm-remove-noreplacement.patch
> -fix-x86_64-mm-fam10-mwait-idle.patch
> -more-fix-x86_64-mm-fam10-mwait-idle.patch
> -fix-x86_64-mm-sched-clock-share.patch
> -revert-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch
> -rename-the-parainstructions-symbols-to-be-consistent-with-the-others.patch
> -rename-the-parainstructions-symbols-to-be-consistent-with-the-others-fix.patch
> -i386-sysenter-arch-pages-fix.patch
> -i386-acpi-remove-earlyquirk-warning.patch
> -i386-mcheck-p4-grotesque-and-needless-warning-fix.patch
> -i386-pgd-clone-under-lock-fix.patch
> -vmi-supports-compat-vdso.patch
> -resurrect-the-vmi-lazy-mode-fixes-fix.patch
> -vmi-kmap_atomic_pte-fix.patch
> -vmi-timer-update.patch
> -i386-pte-drop-ptep_get_and_clear-paravirt-op.patch
> -mtrr-adds-mtrr_save_fixed_ranges-for-use-in-two-later-patches.patch
> -mtrr-save-the-mtrrs-of-the-bsp-before-booting-an-ap.patch
> -mtrr-save-and-restore-the-fixed-range-mtrrs-of-the-bsp-when-suspending.patch
> -mtrr-enable-support-for-fixed-range-iorrs-to-keep-rdmem-wrmem-in-sync.patch
> -i386-map-enough-initial-memory-to-create-lowmem-mappings.patch
> -mm-only-i386-for-debugging-make-the-initial-page-table-setup-less-forgiving.patch
> -depcac-fix-handling-of-platorm_device_add-failure.patch
> -clean-up-elf-note-generation.patch
> -deflate-stack-usage-in-lib-inflatec.patch
>
> Merged into mainline or a subsystem tree
>
> +make-sysrq-t-show-all-tasks-again.patch
> +ia64-race-flushing-icache-in-do_no_page-path.patch
>
> 2.6.21 queue (sigh)
>
> -acpi-asus_acpi-support-f2je-model.patch
>
> Dropped
>
> +git-agp-build-fix.patch
>
> Fix git-agpgart.patch
>
> +git-cpufreq-borkage-fix.patch
>
> Fix git-cpufreq.patch
>
> +gregkh-driver-uevent-use-add_uevent_var-instead-of-open-coding-it.patch
>
> Driver tree update
>
> +fix-gregkh-driver-uevent-use-add_uevent_var-instead-of-open-coding-it.patch
> +sysfs-oops-workaround.patch
>
> Fix things in driver tree
>
> +jdelvare-i2c-i2c-deprecate-specific-gpio-drivers.patch
> +jdelvare-i2c-i2c-tiny-usb-new-driver.patch
> +jdelvare-i2c-i2c-s3c2410-setup-time.patch
> +jdelvare-i2c-i2c-s3c2410-fix-bug-in-releasing-driver.patch
>
> i2c tree updates
>
> +jdelvare-hwmon-hwmon-smsc47m1-use-dynamic-attributes.patch
>
> hwmon tree update
>
> +gfs2-printk-warning-fixes.patch
>
> Fix git-gfs2-nmw.patch
>
> +ohci1394-fix-mistake-in-printk-message.patch
> +fw-device-printk-fix.patch
> +ieee1394-iso-needs-schedh.patch
>
> 1394 fixes
>
> -git-infiniband-make-it-build-hack.patch
>
> Unneeded
>
> +input-convert-from-class-devices-to-standard-devices.patch
> +input-evdev-implement-proper-locking.patch
> +mousedev-fix.patch
> +mousedev-fix-2.patch
>
> input stuff
>
> +ahci-crash-fix.patch
> +ata-printk-warning-fixes.patch
> +ata_timing-ensure-t-cycle-is-always-correct.patch
> +pata_ali-more-work.patch
>
> ata fixes
>
> +ide-cmd64x-fix-multiword-and-remove-single-word-dma-support.patch
> +ide-cmd64x-interrupt-status-fixes-take-2.patch
> +ide-cmd64x-add_fix-enablebits-take-2.patch
> +ide-cmd64x-procfs-code-fixes_cleanups-take-2.patch
> +ide-cmd64x-use-interrupt-status-from-mrdmode-register-take-2.patch
> +ide-aec62xx-fix-pio_dma-setup-issues.patch
>
> IDE tree updates
>
> +git-mtd-build-fix.patch
>
> Fix git-mtd.patch
>
> -git-netdev-all-fixup.patch
>
> Unneeded
>
> +git-netdev-all-export-ieee80211_debug_level.patch
>
> Fix git-netdev-all
>
> +netlink-dont-reinitialize-callback-mutex.patch
> +sctp_getsockopt_local_addrs-type-fix.patch
>
> net things
>
> -pcmcia-irq-probe-can-be-done-without-risking-an-irq-storm.patch
>
> Dropped
>
> +ide-cs-recognize-2gb-compactflash-from-transcend.patch
>
> ide-cs fix
>
> +s390-net-lcs-convert-to-the-kthread-api-fix.patch
>
> Fix s390-net-lcs-convert-to-the-kthread-api.patch
>
> +x86_64-mm-deflate-stack-usage-in-lib-inflate_c.patch
> +x86_64-mm-page-align-the-gdt.patch
> +x86_64-mm-convert-pda-into-the-percpu-section.patch
> +x86_64-mm-paravirt-non-gpl-export.patch
> +x86_64-mm-cleanups-to-help-using-per-cpu-variables-from-asm.patch
> +x86_64-mm-define-per_cpu_offset.patch
> +x86_64-mm-fix-up-gdt-bugs.patch
> +x86_64-mm-map-enough-initial-memory-to-create-lowmem-mappings.patch
> +x86_64-mm-incremental-update-for-i386-and-x86-64-check_bugs.patch
> +x86_64-mm-paravirt-flush-lazy-mmu-updates-on-kunmap_atomic.patch
> +x86_64-mm-paravirt-fix-paravirt-documentation.patch
> +x86_64-mm-in-compat-mode-the-return-value-here-was-uninitialized_.patch
> +x86_64-mm-kremove-a-warning-about-unused-variable-in-config_acpi-compilation_.patch
> +x86_64-mm-cleanup-arch-i386-kernel-cpu-mcheck-p4_c.patch
> +x86_64-mm-vmi-now-that-the-vdso-can-be-relocated-we-can-support-it-in-vmi-configurations.patch
> +x86_64-mm-vmi-kmap-atomic-pte.patch
> +x86_64-mm-vmi-convert-vmi-timer-to-use-clock-events.patch
> +x86_64-mm-paravirt-drop-unused-ptep_get_and_clear.patch
> +x86_64-mm-paravirt-rename-parainstructions.patch
> +x86_64-mm-clean-up-elf-note-generation.patch
> +x86_64-mm-mtrr-adds-mtrr_save_fixed_ranges-for-use-in-two-later-patches.patch
> +x86_64-mm-mtrr-save-the-mtrrs-of-the-bsp-before-booting-an-ap.patch
> +x86_64-mm-mtrr-save-and-restore-the-fixed-range-mtrrs-of-the-bsp-when-suspending.patch
> +x86_64-mm-mtrr-enable-support-for-fixed-range-iorrs-to-keep-rdmem-wrmem-in-sync.patch
> +x86_64-mm-nmi-hack-revert.patch
> +x86_64-mm-nmi-watchdog-ops.patch
> +x86_64-mm-nmi-wd-ops-64bit.patch
> +x86_64-mm-compat-siocgifcount.patch
> +x86_64-mm-apic-timer-calibration.patch
> +x86_64-mm-vdso.patch
>
> x86 tree updates
>
> +fix-x86_64-mm-nmi-watchdog-ops.patch
>
> Fix it
>
> +x86_64-unexport-cpu_llc_id.patch
> +i386-efi-fix-proc-iomem-type-for-kexec-tools.patch
>
> x86 updates
>
> +fix-slab-corruption-running-ip6sic.patch
>
> net fix
>
> +create-the-zone_movable-zone-align-zone_movable-to-a-max_order_nr_pages-boundary.patch
>
> Fix create-the-zone_movable-zone.patch
>
> +handle-kernelcore=-boot-parameter-in-common-code-to-avoid-boot-problem-on-ia64.patch
>
> Fix Mel's MM patches som emore
>
> +introduce-high_order-delineating-easily-reclaimable-orders-cleanups.patch
> +lumpy-increase-pressure-at-the-end-of-the-inactive-list-cleanups.patch
>
> clean up lumpy reclaim code
>
> +slub-core-update-cpu-after-new_slab.patch
>
> slub fix
>
> +quicklists-for-page-table-pages-avoid-useless-virt_to_page-conversion-fix.patch
>
> Fix crashes in the quiklist code
>
> +madv_free-lazytlb-fix.patch
>
> Fix madv_free code
>
> +mm-document-fault_data-and-flags.patch
> +mm-fix-handling-of-panic_on_oom-when-cpusets-are-in-use.patch
>
> MM udpates
>
> +return-eperm-not-echild-on-security_task_wait-failure-fix.patch
>
> Fix return-eperm-not-echild-on-security_task_wait-failure.patch
>
> +pm-introduce-suspend-notifiers-rev-2.patch
>
> swsusp update
>
> +enlarge-console-name.patch
>
> prefix for fixes-and-cleanups-for-earlyprintk-aka-boot-console.patch
>
> +ignore-stolen-time-in-the-softlockup-watchdog.patch
> +ignore-stolen-time-in-the-softlockup-watchdog-fix.patch
> +add-touch_all_softlockup_watchdogs.patch
>
> Bring these back
>
> -report-that-kernel-is-tainted-if-there-were-an-oops-before.patch
>
> Experimentally drop this - the oops output has been odd-looking.
>
> +copy-i_flags-to-ext2-inode-flags-on-write.patch
> +fix-chapter-reference-in-codingstyle.patch
> +sleep-during-spinlock-in-tpm-driver.patch
>
> Misc
>
> -fix-pf_nofreeze-and-freezeable-race.patch
> +fix-kthread_create-vs-freezer-theoretical-race-dont-be-obnoxious.patch
> +fix-pf_nofreeze-and-freezeable-race-2.patch
>
> Update thread-management patches in -mm
>
> +rtc-update-vr41xx-alarm-handling.patch
>
> rtc driver fixes
>
> -sys_futex64-allows-64bit-futexes.patch
> -sys_futex64-allows-64bit-futexes-fix.patch
> -sys_futex64-allows-64bit-futexes-workaround.patch
> -sys_futex64-allows-64bit-futexes-workaround-for-uml.patch
> -sys_futex64-allows-64bit-futexes-get_futex_key-must-check-proper-alignement-for-64bit-futexes.patch
> -futex-new-private-futexes.patch
>
> Dropped
>
> -lguest-the-host-code-vs-sys_futex64-allows-64bit-futexes-get_futex_key-must-check-proper-alignement-for-64bit-futexes.patch
> -lguest-the-host-code-vs-futex-new-private-futexes.patch
>
> Dropped as a result of futex droppage
>
> +lguest-build-hack.patch
> +lguest-build-hack-2.patch
>
> Make lguest build against x86 tree
>
> -unprivileged-mounts-add-user-mounts-to-the-kernel.patch
> -unprivileged-mounts-allow-unprivileged-umount.patch
> -unprivileged-mounts-account-user-mounts.patch
> -unprivileged-mounts-account-user-mounts-fix.patch
> -unprivileged-mounts-propagate-error-values-from-clone_mnt.patch
> -unprivileged-mounts-propagate-error-values-from-clone_mnt-fix.patch
> -unprivileged-mounts-allow-unprivileged-bind-mounts.patch
> -unprivileged-mounts-allow-unprivileged-bind-mounts-fix.patch
> -unprivileged-mounts-put-declaration-of-put_filesystem-in-fsh.patch
> -unprivileged-mounts-allow-unprivileged-mounts.patch
> -unprivileged-mounts-allow-unprivileged-fuse-mounts.patch
>
> Dropped
>
> +epson1355fbc-fix-error-handling-code.patch
> +nvidiafb-vga-state-save-and-restore.patch
> +savagefb-rework-i2c-bit-access.patch
> +savagefb-vga-state-save-and-restore.patch
> +fbdev-link-vgastateo-using-kconfig.patch
> +fbcon-delay-screen-update-when-setting-the-mode-of.patch
> +nvidiafb-fix-sparse-warning.patch
> +rivafb-fix-io-access.patch
> +fbdev-kill-sparse-warning-in-deferred-io.patch
> +fbdev-add-sparse-annotations-in-svgalibc.patch
> +arcfb-kill-sparse-warning.patch
> +s3fb-add-sparse-annotations.patch
> +hecubafb-kill-sparse-warnings.patch
> +i810fb-fix-incorrect-frequency-mask.patch
> +vt-add-documentation-for-new-boot-sysfs-options.patch
> +skeletonfb-documentation-error-fixes.patch
> +fbdev-add-drawing-functions-for-framebuffers-in-system.patch
> +arcfb-use-sys-instead-of-cfb-drawing-functions.patch
> +hecubafb-use-sys-instead-of-cfb-drawing-functions.patch
> +vfb-use-sys-instead-of-cfb-drawing-functions.patch
> +fbdev-pass-struct-fb_info-to-fb_read-and-fb_write.patch
> +fbdev-add-fb_read-fb_write-functions-for-framebuffers.patch
> +arcfb-us-fb_sys_read.patch
> +hecubafb-us-fb_sys_read.patch
> +vfb-us-fb_sys_read-and-fb_sys_write.patch
> +fbdev-consolidate-common-drawing-functions-into-a.patch
> +fbdev-advertise-limitation-of-drawing-engine.patch
> +fbcon-font-setting-should-check-limitation-of-driver.patch
> +vga16fb-restrict-to-blit-rectangles-with-widths-of.patch
> +s3fb-limit-8x16-rectangles-when-tileblitting-is-enabled.patch
> +fbdev-add-tile-operation-to-get-the-maximum-length.patch
> +s3fb-implement-fb_get_tilemax.patch
> +fbcon-check-if-the-character-count-can-be-handled.patch
> +fbdev-save-the-activate-field-before-calling-fb_check_var.patch
> +s3fb-driver-fixes.patch
> +vmlfb-framebuffer-driver-for-intel-vermilion-range.patch
> +nvidiafb-rivafb-switch-to-pci_get-refcounting.patch
> +pm2fb-3dlabs-permedia-2v-reference-board-added.patch
> +pm2fb-permedia-2v-memory-clock-setting.patch
> +pm2fb-pixclock-setting-restriction.patch
> +nvidiafb-prevent-triggering-of-softlockup.patch
>
> fbdev bugstomp
>
> -cfq-debugging-stuff.patch
>
> Dropped due to rejects
>
>
>
> All 1993 patches:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/patch-list
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I have troubles with rtc on my macbook with mm2:
----
....
[126588.386116] rtc: lost some interrupts at 1024Hz.
[126588.404842] rtc: lost some interrupts at 1024Hz.
[126588.423566] rtc: lost some interrupts at 1024Hz.
[126588.442292] rtc: lost some interrupts at 1024Hz.
[126588.461016] rtc: lost some interrupts at 1024Hz.
[126588.479741] rtc: lost some interrupts at 1024Hz.
[126588.498466] rtc: lost some interrupts at 1024Hz.
[126588.517198] rtc: lost some interrupts at 1024Hz.
[126588.535923] rtc: lost some interrupts at 1024Hz.
[126588.554643] rtc: lost some interrupts at 1024Hz.
....
----
cat /proc/sys/dev/rtc/max-user-freq
64
On 2.6.20 there wasn't such problem.
Thanks.
Dan Kruchinin.
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2
2007-04-29 19:19 ` 2.6.21-rc7-mm2 Dan Kruchinin
@ 2007-04-29 19:48 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-04-29 19:48 UTC (permalink / raw)
To: Dan Kruchinin; +Cc: linux-kernel
On Sun, 29 Apr 2007 23:19:49 +0400 "Dan Kruchinin" <dubalom@gmail.com> wrote:
> I have troubles with rtc on my macbook with mm2:
> ----
> ....
> [126588.386116] rtc: lost some interrupts at 1024Hz.
> [126588.404842] rtc: lost some interrupts at 1024Hz.
> [126588.423566] rtc: lost some interrupts at 1024Hz.
> [126588.442292] rtc: lost some interrupts at 1024Hz.
> [126588.461016] rtc: lost some interrupts at 1024Hz.
> [126588.479741] rtc: lost some interrupts at 1024Hz.
> [126588.498466] rtc: lost some interrupts at 1024Hz.
> [126588.517198] rtc: lost some interrupts at 1024Hz.
> [126588.535923] rtc: lost some interrupts at 1024Hz.
> [126588.554643] rtc: lost some interrupts at 1024Hz.
> ....
> ----
> cat /proc/sys/dev/rtc/max-user-freq
> 64
I don't think there are any rtc changes in -mm which could have caused
this. Possibly there's something in there which is holding interrupts off
for too long.
> On 2.6.20 there wasn't such problem.
Can you try 2.6.21 please?
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
` (13 preceding siblings ...)
2007-04-29 19:19 ` 2.6.21-rc7-mm2 Dan Kruchinin
@ 2007-04-30 5:01 ` Randy Dunlap
2007-04-30 5:23 ` Andrew Morton
2007-05-04 11:38 ` Andy Whitcroft
15 siblings, 1 reply; 135+ messages in thread
From: Randy Dunlap @ 2007-04-30 5:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]
On Wed, 25 Apr 2007 22:57:16 -0700 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
I'm getting a hang near the end of booting on x86_64 UP.
The last initcall_debug function varies. E.g.:
1/
[ 0.140257] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
[ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
[ 0.140275] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
[ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
[ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
[ 0.140302] initcall 0xffffffff806f2fe7 ran for 0 msecs: init_script_binfmt+0x0/0x12()
[ 0.140310] Calling initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12()
[ 0.140317] initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12() returned 0.
[ 0.140326] initcall 0xffffffff806f2ff9 ran for 0 msecs: init_elf_binfmt+0x0/0x12()
[ 0.140335] Calling initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a()
[ 0.140344] initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a() returned 0.
[ 0.140351] initcall 0xffffffff806f3de9 ran for 0 msecs: debugfs_init+0x0/0x4a()
2/
[ 0.140206] Calling initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29()
[ 0.140215] initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29() returned 0.
[ 0.140222] initcall 0xffffffff806efeb1 ran for 0 msecs: ksysfs_init+0x0/0x29()
[ 0.140230] Calling initcall 0xffffffff806f25be: filelock_init+0x0/0x31()
[ 0.140242] initcall 0xffffffff806f25be: filelock_init+0x0/0x31() returned 0.
[ 0.140249] initcall 0xffffffff806f25be ran for 0 msecs: filelock_init+0x0/0x31()
[ 0.140258] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
[ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
[ 0.140276] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
[ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
[ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
.config is attached.
Any ideas/suggestions?
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
[-- Attachment #2: config-2621-rc7mm2 --]
[-- Type: application/octet-stream, Size: 47044 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc7-mm2
# Sun Apr 29 20:24:47 2007
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_NR_QUICK=2
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_DMI=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
# CONFIG_SWAP_PREFETCH is not set
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
# CONFIG_UTS_NS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_CPUSETS=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
# CONFIG_ANON_INODES is not set
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_PROC_SMAPS is not set
# CONFIG_PROC_CLEAR_REFS is not set
# CONFIG_PROC_PAGEMAP is not set
# CONFIG_PROC_KPAGEMAP is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VSMP is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_L1_CACHE_BYTES=128
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_INTERNODE_CACHE_BYTES=128
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_X86_HT=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
# CONFIG_NUMA is not set
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
# CONFIG_ADAPTIVE_READAHEAD is not set
CONFIG_NR_CPUS=8
CONFIG_HOTPLUG_CPU=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_START=0x200000
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_REORDER is not set
CONFIG_K8_NB=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_ISA_DMA_API=y
CONFIG_GENERIC_PENDING_IRQ=y
#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""
CONFIG_SUSPEND_SMP=y
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_SLEEP_PROC_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_BAY=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
#
# CPUFreq processor drivers
#
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_ACPI_CPUFREQ=y
#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_SPEEDSTEP_LIB is not set
#
# CPU idle PM support
#
# CONFIG_CPU_IDLE is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCI_DOMAINS is not set
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_PCCARD=m
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=m
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_CARDBUS=y
#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
CONFIG_I82092=m
CONFIG_PCCARD_NONSTATIC=m
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m
#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
#
# Wireless
#
# CONFIG_CFG80211 is not set
CONFIG_WIRELESS_EXT=y
CONFIG_IEEE80211=y
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=y
CONFIG_IEEE80211_CRYPT_CCMP=y
# CONFIG_IEEE80211_CRYPT_TKIP is not set
CONFIG_IEEE80211_SOFTMAC=y
# CONFIG_IEEE80211_SOFTMAC_DEBUG is not set
# CONFIG_RFKILL is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_PNPACPI=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=64000
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_CDROM_PKTCDVD_WCACHE=y
# CONFIG_ATA_OVER_ETH is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
# CONFIG_SGI_IOC4 is not set
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_BLINK is not set
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=4
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDECS is not set
# CONFIG_BLK_DEV_DELKIN is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=y
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_PROC_FS is not set
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPNP=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=m
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=y
CONFIG_SCSI_SAS_ATTRS=y
CONFIG_SCSI_SAS_LIBSAS=y
CONFIG_SCSI_SAS_LIBSAS_DEBUG=y
#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=5000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
# CONFIG_SCSI_AIC7XXX_OLD is not set
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC94XX=m
CONFIG_AIC94XX_DEBUG=y
CONFIG_SCSI_ARCMSR=m
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
CONFIG_SCSI_DEBUG=m
# CONFIG_SCSI_SRP is not set
#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_PCMCIA_SYM53C500 is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
CONFIG_SATA_VIA=m
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
CONFIG_SATA_ACPI=y
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
CONFIG_PATA_PCMCIA=m
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
CONFIG_IEEE1394=m
#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
#
# Device Drivers
#
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_OHCI1394=m
#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_I2O is not set
#
# Macintosh device drivers
#
# CONFIG_MAC_EMUMOUSEBTN is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
CONFIG_B44=y
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
CONFIG_VIA_RHINE=y
CONFIG_VIA_RHINE_MMIO=y
CONFIG_VIA_RHINE_NAPI=y
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
# CONFIG_PCMCIA_FMVJ18X is not set
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_NMCLAN=m
# CONFIG_PCMCIA_SMC91C92 is not set
CONFIG_PCMCIA_XIRC2PS=m
# CONFIG_PCMCIA_AXNET is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_RX=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_PS2_ALPS is not set
# CONFIG_MOUSE_PS2_LOGIPS2PP is not set
# CONFIG_MOUSE_PS2_SYNAPTICS is not set
# CONFIG_MOUSE_PS2_LIFEBOOK is not set
# CONFIG_MOUSE_PS2_TRACKPOINT is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_ATLAS_BTNS is not set
CONFIG_INPUT_UINPUT=y
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=y
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=64
CONFIG_PRINTER=y
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=y
# CONFIG_TIPAR is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=y
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_I8XX_TCO is not set
# CONFIG_ITCO_WDT is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set
#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_INTEL is not set
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_GEODE is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS_CS is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
CONFIG_RAW_DRIVER=m
CONFIG_MAX_RAW_DEVS=4096
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=y
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_TINY_USB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
CONFIG_SPI_BITBANG=y
# CONFIG_SPI_BUTTERFLY is not set
#
# SPI Protocol Masters
#
# CONFIG_SPI_AT25 is not set
# CONFIG_SPI_SPIDEV is not set
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y
#
# Video Capture Adapters
#
#
# Video Capture Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
# CONFIG_VIDEO_VIVI is not set
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
CONFIG_VIDEO_CPIA=m
# CONFIG_VIDEO_CPIA_PP is not set
CONFIG_VIDEO_CPIA_USB=m
# CONFIG_VIDEO_CPIA2 is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_IVTV is not set
# CONFIG_VIDEO_CAFE_CCIC is not set
#
# V4L USB devices
#
# CONFIG_VIDEO_PVRUSB2 is not set
# CONFIG_VIDEO_EM28XX is not set
# CONFIG_VIDEO_USBVISION is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_QUICKCAM_MESSENGER is not set
# CONFIG_USB_ET61X251 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set
# CONFIG_USB_W9968CF is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_ZC0301 is not set
# CONFIG_USB_PWC is not set
# CONFIG_USB_ZR364XX is not set
#
# Radio Adapters
#
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_USB_DSBR is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set
#
# Graphics support
#
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_VGASTATE is not set
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
# CONFIG_FB_DDC is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_HECUBA is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
#
# Logo configuration
#
# CONFIG_LOGO is not set
#
# Sound
#
CONFIG_SOUND=m
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_SUPPORT_OLD_API=y
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_DUMMY is not set
CONFIG_SND_VIRMIDI=m
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
# CONFIG_SND_PORTMAN2X4 is not set
#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=m
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
CONFIG_SND_VIA82XX=m
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_AC97_POWER_SAVE is not set
#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set
#
# System on Chip audio support
#
# CONFIG_SND_SOC is not set
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m
#
# HID Devices
#
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
CONFIG_USB_LIBUSUAL=y
#
# USB Input Devices
#
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
# CONFIG_USB_GTCO is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET_MII is not set
# CONFIG_USB_USBNET is not set
CONFIG_USB_MON=y
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_AIRPRIME is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
CONFIG_USB_SERIAL_BELKIN=m
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
CONFIG_USB_SERIAL_DEBUG=m
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GOTEMP is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
#
# MMC/SD Card Drivers
#
CONFIG_MMC_BLOCK=m
#
# MMC/SD Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_WBSD=m
CONFIG_MMC_TIFM_SD=m
#
# LED devices
#
# CONFIG_NEW_LEDS is not set
#
# LED drivers
#
#
# LED Triggers
#
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set
#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set
#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set
#
# DMA Clients
#
# CONFIG_ASYNC_TX_DMA is not set
#
# DMA Devices
#
#
# Auxiliary Display support
#
# CONFIG_KS0108 is not set
#
# Virtualization
#
# CONFIG_KVM is not set
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# Firmware Drivers
#
CONFIG_EDD=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_EXT4DEV_FS=m
CONFIG_EXT4DEV_FS_XATTR=y
CONFIG_EXT4DEV_FS_POSIX_ACL=y
CONFIG_EXT4DEV_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=m
CONFIG_JBD2_DEBUG=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISER4_FS is not set
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_REISERFS_FS_XATTR is not set
CONFIG_JFS_FS=m
# CONFIG_JFS_POSIX_ACL is not set
# CONFIG_JFS_SECURITY is not set
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_SECURITY is not set
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_XFS_RT is not set
# CONFIG_GFS2_FS is not set
CONFIG_OCFS2_FS=m
CONFIG_OCFS2_DEBUG_MASKLOG=y
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_ROMFS_ON_BLOCK=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=y
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_UFS_DEBUG is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
#
# Distributed Lock Manager
#
# CONFIG_DLM is not set
#
# Instrumentation Support
#
CONFIG_PROFILING=y
# CONFIG_OPROFILE is not set
CONFIG_KPROBES=y
# CONFIG_MARKERS is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOG_BUF_SHIFT=18
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
CONFIG_DEBUG_LIST=y
CONFIG_FRAME_POINTER=y
# CONFIG_UNWIND_INFO is not set
# CONFIG_PROFILE_LIKELY is not set
CONFIG_FORCED_INLINING=y
# CONFIG_DEBUG_SYNCHRO_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_DEBUG_RODATA=y
CONFIG_IOMMU_DEBUG=y
# CONFIG_IOMMU_LEAK is not set
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_INTEGRITY is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_PCBC is not set
CONFIG_CRYPTO_LRW=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_TWOFISH_X86_64=y
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
# CONFIG_CRYPTO_HW is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 hangs in boot
2007-04-30 5:01 ` 2.6.21-rc7-mm2 hangs in boot Randy Dunlap
@ 2007-04-30 5:23 ` Andrew Morton
2007-04-30 15:16 ` Randy Dunlap
0 siblings, 1 reply; 135+ messages in thread
From: Andrew Morton @ 2007-04-30 5:23 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-kernel
On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On Wed, 25 Apr 2007 22:57:16 -0700 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
>
> I'm getting a hang near the end of booting on x86_64 UP.
> The last initcall_debug function varies. E.g.:
>
> 1/
> [ 0.140257] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
> [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
> [ 0.140275] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
> [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
> [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
> [ 0.140302] initcall 0xffffffff806f2fe7 ran for 0 msecs: init_script_binfmt+0x0/0x12()
> [ 0.140310] Calling initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12()
> [ 0.140317] initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12() returned 0.
> [ 0.140326] initcall 0xffffffff806f2ff9 ran for 0 msecs: init_elf_binfmt+0x0/0x12()
> [ 0.140335] Calling initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a()
> [ 0.140344] initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a() returned 0.
> [ 0.140351] initcall 0xffffffff806f3de9 ran for 0 msecs: debugfs_init+0x0/0x4a()
>
> 2/
> [ 0.140206] Calling initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29()
> [ 0.140215] initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29() returned 0.
> [ 0.140222] initcall 0xffffffff806efeb1 ran for 0 msecs: ksysfs_init+0x0/0x29()
> [ 0.140230] Calling initcall 0xffffffff806f25be: filelock_init+0x0/0x31()
> [ 0.140242] initcall 0xffffffff806f25be: filelock_init+0x0/0x31() returned 0.
> [ 0.140249] initcall 0xffffffff806f25be ran for 0 msecs: filelock_init+0x0/0x31()
> [ 0.140258] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
> [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
> [ 0.140276] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
> [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
> [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
>
So perhaps it locks during a timer interrupt.
> .config is attached.
>
> Any ideas/suggestions?
Just the usual: nothing from sysrq or NMI watchdog?
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot
2007-04-30 5:23 ` Andrew Morton
@ 2007-04-30 15:16 ` Randy Dunlap
2007-04-30 23:51 ` 2.6.21-rc7-mm2 hangs in boot (netconsole) Randy Dunlap
0 siblings, 1 reply; 135+ messages in thread
From: Randy Dunlap @ 2007-04-30 15:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sun, 29 Apr 2007 22:23:54 -0700 Andrew Morton wrote:
> On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> > On Wed, 25 Apr 2007 22:57:16 -0700 Andrew Morton wrote:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
> >
> > I'm getting a hang near the end of booting on x86_64 UP.
> > The last initcall_debug function varies. E.g.:
> >
> > 1/
> > [ 0.140257] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
> > [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
> > [ 0.140275] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
> > [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
> > [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
> > [ 0.140302] initcall 0xffffffff806f2fe7 ran for 0 msecs: init_script_binfmt+0x0/0x12()
> > [ 0.140310] Calling initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12()
> > [ 0.140317] initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12() returned 0.
> > [ 0.140326] initcall 0xffffffff806f2ff9 ran for 0 msecs: init_elf_binfmt+0x0/0x12()
> > [ 0.140335] Calling initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a()
> > [ 0.140344] initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a() returned 0.
> > [ 0.140351] initcall 0xffffffff806f3de9 ran for 0 msecs: debugfs_init+0x0/0x4a()
> >
> > 2/
> > [ 0.140206] Calling initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29()
> > [ 0.140215] initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29() returned 0.
> > [ 0.140222] initcall 0xffffffff806efeb1 ran for 0 msecs: ksysfs_init+0x0/0x29()
> > [ 0.140230] Calling initcall 0xffffffff806f25be: filelock_init+0x0/0x31()
> > [ 0.140242] initcall 0xffffffff806f25be: filelock_init+0x0/0x31() returned 0.
> > [ 0.140249] initcall 0xffffffff806f25be ran for 0 msecs: filelock_init+0x0/0x31()
> > [ 0.140258] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
> > [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
> > [ 0.140276] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
> > [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
> > [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
> >
>
> So perhaps it locks during a timer interrupt.
>
> > .config is attached.
> >
> > Any ideas/suggestions?
>
> Just the usual: nothing from sysrq or NMI watchdog?
Nothing from either of those. I'll jiggle some config options.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-04-30 15:16 ` Randy Dunlap
@ 2007-04-30 23:51 ` Randy Dunlap
2007-05-01 0:12 ` Andrew Morton
0 siblings, 1 reply; 135+ messages in thread
From: Randy Dunlap @ 2007-04-30 23:51 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
On Mon, 30 Apr 2007 08:16:53 -0700 Randy Dunlap wrote:
> On Sun, 29 Apr 2007 22:23:54 -0700 Andrew Morton wrote:
>
> > On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >
> > > On Wed, 25 Apr 2007 22:57:16 -0700 Andrew Morton wrote:
> > >
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
> > >
> > > I'm getting a hang near the end of booting on x86_64 UP.
> > > The last initcall_debug function varies. E.g.:
> > >
> > > 1/
> > > [ 0.140257] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
> > > [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
> > > [ 0.140275] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
> > > [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
> > > [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
> > > [ 0.140302] initcall 0xffffffff806f2fe7 ran for 0 msecs: init_script_binfmt+0x0/0x12()
> > > [ 0.140310] Calling initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12()
> > > [ 0.140317] initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12() returned 0.
> > > [ 0.140326] initcall 0xffffffff806f2ff9 ran for 0 msecs: init_elf_binfmt+0x0/0x12()
> > > [ 0.140335] Calling initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a()
> > > [ 0.140344] initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a() returned 0.
> > > [ 0.140351] initcall 0xffffffff806f3de9 ran for 0 msecs: debugfs_init+0x0/0x4a()
> > >
> > > 2/
> > > [ 0.140206] Calling initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29()
> > > [ 0.140215] initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29() returned 0.
> > > [ 0.140222] initcall 0xffffffff806efeb1 ran for 0 msecs: ksysfs_init+0x0/0x29()
> > > [ 0.140230] Calling initcall 0xffffffff806f25be: filelock_init+0x0/0x31()
> > > [ 0.140242] initcall 0xffffffff806f25be: filelock_init+0x0/0x31() returned 0.
> > > [ 0.140249] initcall 0xffffffff806f25be ran for 0 msecs: filelock_init+0x0/0x31()
> > > [ 0.140258] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
> > > [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
> > > [ 0.140276] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
> > > [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
> > > [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
> > >
> >
> > So perhaps it locks during a timer interrupt.
> >
> > > .config is attached.
> > >
> > > Any ideas/suggestions?
> >
> > Just the usual: nothing from sysrq or NMI watchdog?
>
> Nothing from either of those. I'll jiggle some config options.
config option changes didn't help, but removing
netconsole=<params>
from the kernel command line makes it all happy. :(
Do we know of netconsole hang problems? (anyone?)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-04-30 23:51 ` 2.6.21-rc7-mm2 hangs in boot (netconsole) Randy Dunlap
@ 2007-05-01 0:12 ` Andrew Morton
2007-05-01 0:45 ` Randy Dunlap
0 siblings, 1 reply; 135+ messages in thread
From: Andrew Morton @ 2007-05-01 0:12 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-kernel
On Mon, 30 Apr 2007 16:51:01 -0700
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On Mon, 30 Apr 2007 08:16:53 -0700 Randy Dunlap wrote:
>
> > On Sun, 29 Apr 2007 22:23:54 -0700 Andrew Morton wrote:
> >
> > > On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > >
> > > > On Wed, 25 Apr 2007 22:57:16 -0700 Andrew Morton wrote:
> > > >
> > > > >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
> > > >
> > > > I'm getting a hang near the end of booting on x86_64 UP.
> > > > The last initcall_debug function varies. E.g.:
> > > >
> > > > 1/
> > > > [ 0.140257] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
> > > > [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
> > > > [ 0.140275] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
> > > > [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
> > > > [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
> > > > [ 0.140302] initcall 0xffffffff806f2fe7 ran for 0 msecs: init_script_binfmt+0x0/0x12()
> > > > [ 0.140310] Calling initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12()
> > > > [ 0.140317] initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12() returned 0.
> > > > [ 0.140326] initcall 0xffffffff806f2ff9 ran for 0 msecs: init_elf_binfmt+0x0/0x12()
> > > > [ 0.140335] Calling initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a()
> > > > [ 0.140344] initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a() returned 0.
> > > > [ 0.140351] initcall 0xffffffff806f3de9 ran for 0 msecs: debugfs_init+0x0/0x4a()
> > > >
> > > > 2/
> > > > [ 0.140206] Calling initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29()
> > > > [ 0.140215] initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29() returned 0.
> > > > [ 0.140222] initcall 0xffffffff806efeb1 ran for 0 msecs: ksysfs_init+0x0/0x29()
> > > > [ 0.140230] Calling initcall 0xffffffff806f25be: filelock_init+0x0/0x31()
> > > > [ 0.140242] initcall 0xffffffff806f25be: filelock_init+0x0/0x31() returned 0.
> > > > [ 0.140249] initcall 0xffffffff806f25be ran for 0 msecs: filelock_init+0x0/0x31()
> > > > [ 0.140258] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
> > > > [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
> > > > [ 0.140276] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
> > > > [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
> > > > [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
> > > >
> > >
> > > So perhaps it locks during a timer interrupt.
> > >
> > > > .config is attached.
> > > >
> > > > Any ideas/suggestions?
> > >
> > > Just the usual: nothing from sysrq or NMI watchdog?
> >
> > Nothing from either of those. I'll jiggle some config options.
>
> config option changes didn't help, but removing
> netconsole=<params>
> from the kernel command line makes it all happy. :(
argh.
> Do we know of netconsole hang problems? (anyone?)
You have "time" as well? I found on i386 uniproc that time+netconsole
caused hangs because the printk timestamping code was taking
xtime_lock for reading inside a write_seqlock. But I though that Andi
fixed that. Perhaps i386 got fixed but x86_64 did not.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 0:12 ` Andrew Morton
@ 2007-05-01 0:45 ` Randy Dunlap
2007-05-01 1:08 ` Andrew Morton
0 siblings, 1 reply; 135+ messages in thread
From: Randy Dunlap @ 2007-05-01 0:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton wrote:
> On Mon, 30 Apr 2007 16:51:01 -0700
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
>> On Mon, 30 Apr 2007 08:16:53 -0700 Randy Dunlap wrote:
>>
>>> On Sun, 29 Apr 2007 22:23:54 -0700 Andrew Morton wrote:
>>>
>>>> On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>>>>
>>>>> On Wed, 25 Apr 2007 22:57:16 -0700 Andrew Morton wrote:
>>>>>
>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
>>>>> I'm getting a hang near the end of booting on x86_64 UP.
>>>>> The last initcall_debug function varies. E.g.:
>>>>>
>>>>> 1/
>>>>> [ 0.140257] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
>>>>> [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
>>>>> [ 0.140275] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
>>>>> [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
>>>>> [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
>>>>> [ 0.140302] initcall 0xffffffff806f2fe7 ran for 0 msecs: init_script_binfmt+0x0/0x12()
>>>>> [ 0.140310] Calling initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12()
>>>>> [ 0.140317] initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12() returned 0.
>>>>> [ 0.140326] initcall 0xffffffff806f2ff9 ran for 0 msecs: init_elf_binfmt+0x0/0x12()
>>>>> [ 0.140335] Calling initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a()
>>>>> [ 0.140344] initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a() returned 0.
>>>>> [ 0.140351] initcall 0xffffffff806f3de9 ran for 0 msecs: debugfs_init+0x0/0x4a()
>>>>>
>>>>> 2/
>>>>> [ 0.140206] Calling initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29()
>>>>> [ 0.140215] initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29() returned 0.
>>>>> [ 0.140222] initcall 0xffffffff806efeb1 ran for 0 msecs: ksysfs_init+0x0/0x29()
>>>>> [ 0.140230] Calling initcall 0xffffffff806f25be: filelock_init+0x0/0x31()
>>>>> [ 0.140242] initcall 0xffffffff806f25be: filelock_init+0x0/0x31() returned 0.
>>>>> [ 0.140249] initcall 0xffffffff806f25be ran for 0 msecs: filelock_init+0x0/0x31()
>>>>> [ 0.140258] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
>>>>> [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
>>>>> [ 0.140276] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
>>>>> [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
>>>>> [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
>>>>>
>>>> So perhaps it locks during a timer interrupt.
>>>>
>>>>> .config is attached.
>>>>>
>>>>> Any ideas/suggestions?
>>>> Just the usual: nothing from sysrq or NMI watchdog?
>>> Nothing from either of those. I'll jiggle some config options.
>> config option changes didn't help, but removing
>> netconsole=<params>
>> from the kernel command line makes it all happy. :(
>
> argh.
>
>> Do we know of netconsole hang problems? (anyone?)
>
> You have "time" as well? I found on i386 uniproc that time+netconsole
> caused hangs because the printk timestamping code was taking
> xtime_lock for reading inside a write_seqlock. But I though that Andi
> fixed that. Perhaps i386 got fixed but x86_64 did not.
Yes, I have CONFIG_PRINTK_TIME=y and disabling it allows it to boot. Thanks.
Maybe the patch isn't merged yet?
Now if I can just remember this until the next time that I hit it...
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 0:45 ` Randy Dunlap
@ 2007-05-01 1:08 ` Andrew Morton
2007-05-01 3:43 ` Andi Kleen
0 siblings, 1 reply; 135+ messages in thread
From: Andrew Morton @ 2007-05-01 1:08 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-kernel, Andi Kleen
On Mon, 30 Apr 2007 17:45:55 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> Andrew Morton wrote:
> > On Mon, 30 Apr 2007 16:51:01 -0700
> > Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >
> >> On Mon, 30 Apr 2007 08:16:53 -0700 Randy Dunlap wrote:
> >>
> >>> On Sun, 29 Apr 2007 22:23:54 -0700 Andrew Morton wrote:
> >>>
> >>>> On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >>>>
> >>>>> On Wed, 25 Apr 2007 22:57:16 -0700 Andrew Morton wrote:
> >>>>>
> >>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
> >>>>> I'm getting a hang near the end of booting on x86_64 UP.
> >>>>> The last initcall_debug function varies. E.g.:
> >>>>>
> >>>>> 1/
> >>>>> [ 0.140257] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
> >>>>> [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
> >>>>> [ 0.140275] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
> >>>>> [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
> >>>>> [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
> >>>>> [ 0.140302] initcall 0xffffffff806f2fe7 ran for 0 msecs: init_script_binfmt+0x0/0x12()
> >>>>> [ 0.140310] Calling initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12()
> >>>>> [ 0.140317] initcall 0xffffffff806f2ff9: init_elf_binfmt+0x0/0x12() returned 0.
> >>>>> [ 0.140326] initcall 0xffffffff806f2ff9 ran for 0 msecs: init_elf_binfmt+0x0/0x12()
> >>>>> [ 0.140335] Calling initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a()
> >>>>> [ 0.140344] initcall 0xffffffff806f3de9: debugfs_init+0x0/0x4a() returned 0.
> >>>>> [ 0.140351] initcall 0xffffffff806f3de9 ran for 0 msecs: debugfs_init+0x0/0x4a()
> >>>>>
> >>>>> 2/
> >>>>> [ 0.140206] Calling initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29()
> >>>>> [ 0.140215] initcall 0xffffffff806efeb1: ksysfs_init+0x0/0x29() returned 0.
> >>>>> [ 0.140222] initcall 0xffffffff806efeb1 ran for 0 msecs: ksysfs_init+0x0/0x29()
> >>>>> [ 0.140230] Calling initcall 0xffffffff806f25be: filelock_init+0x0/0x31()
> >>>>> [ 0.140242] initcall 0xffffffff806f25be: filelock_init+0x0/0x31() returned 0.
> >>>>> [ 0.140249] initcall 0xffffffff806f25be ran for 0 msecs: filelock_init+0x0/0x31()
> >>>>> [ 0.140258] Calling initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f()
> >>>>> [ 0.140266] initcall 0xffffffff806f2fa8: init_misc_binfmt+0x0/0x3f() returned 0.
> >>>>> [ 0.140276] initcall 0xffffffff806f2fa8 ran for 0 msecs: init_misc_binfmt+0x0/0x3f()
> >>>>> [ 0.140284] Calling initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12()
> >>>>> [ 0.140293] initcall 0xffffffff806f2fe7: init_script_binfmt+0x0/0x12() returned 0.
> >>>>>
> >>>> So perhaps it locks during a timer interrupt.
> >>>>
> >>>>> .config is attached.
> >>>>>
> >>>>> Any ideas/suggestions?
> >>>> Just the usual: nothing from sysrq or NMI watchdog?
> >>> Nothing from either of those. I'll jiggle some config options.
> >> config option changes didn't help, but removing
> >> netconsole=<params>
> >> from the kernel command line makes it all happy. :(
> >
> > argh.
> >
> >> Do we know of netconsole hang problems? (anyone?)
> >
> > You have "time" as well? I found on i386 uniproc that time+netconsole
> > caused hangs because the printk timestamping code was taking
> > xtime_lock for reading inside a write_seqlock. But I though that Andi
> > fixed that. Perhaps i386 got fixed but x86_64 did not.
>
> Yes, I have CONFIG_PRINTK_TIME=y and disabling it allows it to boot. Thanks.
>
> Maybe the patch isn't merged yet?
Could be. I don't recall whether Andi's statement was before or after
2.6.21-rc7-mm2 actually.
> Now if I can just remember this until the next time that I hit it...
Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at
randomish times (presumably in the timer irq handler) when netconsole and
printk-time are enabled.
I was hitting the same thing on i386 uniprocessor, but I thought it got
fixed.
The problem was that the printable string which is newly passed to
mark_tsc_unstable() is printed out inside write_seqlock(xtime_lock) but
printk timestamping (and perhaps netconsole tx?) want to take xtime_lock
for reading, which will hang.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 1:08 ` Andrew Morton
@ 2007-05-01 3:43 ` Andi Kleen
2007-05-01 5:16 ` Randy Dunlap
0 siblings, 1 reply; 135+ messages in thread
From: Andi Kleen @ 2007-05-01 3:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: Randy Dunlap, linux-kernel, Andi Kleen
> Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at
> randomish times (presumably in the timer irq handler) when netconsole and
> printk-time are enabled.
A backtrace would be good. Does nmi_watchdog=2 show anything
interesting or if not sysrq-t?
>
> I was hitting the same thing on i386 uniprocessor, but I thought it got
> fixed.
Yes.
My current sched_clock does not take any locks anymore and it was removed
from the cpufreq handler too.
-Andi
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 3:43 ` Andi Kleen
@ 2007-05-01 5:16 ` Randy Dunlap
2007-05-01 5:23 ` Andrew Morton
2007-05-01 6:22 ` Andi Kleen
0 siblings, 2 replies; 135+ messages in thread
From: Randy Dunlap @ 2007-05-01 5:16 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel
On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote:
> > Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at
> > randomish times (presumably in the timer irq handler) when netconsole and
> > printk-time are enabled.
>
> A backtrace would be good. Does nmi_watchdog=2 show anything
> interesting or if not sysrq-t?
I can't get anything from sysrq or nmi_watchdog.
> > I was hitting the same thing on i386 uniprocessor, but I thought it got
> > fixed.
>
> Yes.
Fixed where? Merged into mainline or in your firstfloor patches?
> My current sched_clock does not take any locks anymore and it was removed
> from the cpufreq handler too.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 5:16 ` Randy Dunlap
@ 2007-05-01 5:23 ` Andrew Morton
2007-05-01 6:24 ` Andi Kleen
2007-05-01 6:22 ` Andi Kleen
1 sibling, 1 reply; 135+ messages in thread
From: Andrew Morton @ 2007-05-01 5:23 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Andi Kleen, linux-kernel
On Mon, 30 Apr 2007 22:16:24 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > > I was hitting the same thing on i386 uniprocessor, but I thought it got
> > > fixed.
> >
> > Yes.
>
> Fixed where? Merged into mainline or in your firstfloor patches?
The bug is in firstfloor only, and the fix (if present) will be there too.
<checks>
Nope,
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/sched-clock-share
is identical to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/x86_64-mm-sched-clock-share.patch
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 5:23 ` Andrew Morton
@ 2007-05-01 6:24 ` Andi Kleen
2007-05-01 5:38 ` Andrew Morton
0 siblings, 1 reply; 135+ messages in thread
From: Andi Kleen @ 2007-05-01 6:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Randy Dunlap, Andi Kleen, linux-kernel
> The bug is in firstfloor only, and the fix (if present) will be there too.
>
> <checks>
>
> Nope,
>
> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/sched-clock-share
>
> is identical to
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/x86_64-mm-sched-clock-share.patch
Or perhaps the deadlock is in the cpufrequency handler. Does it happen without CONFIG_CPUFREQ
too?
[cpufreq handler calls ktime_get which might take xtime lock for reading]
-Andi
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 6:24 ` Andi Kleen
@ 2007-05-01 5:38 ` Andrew Morton
2007-05-01 16:15 ` Randy Dunlap
0 siblings, 1 reply; 135+ messages in thread
From: Andrew Morton @ 2007-05-01 5:38 UTC (permalink / raw)
To: Andi Kleen; +Cc: Randy Dunlap, linux-kernel
On Tue, 1 May 2007 08:24:56 +0200 Andi Kleen <ak@suse.de> wrote:
> > The bug is in firstfloor only, and the fix (if present) will be there too.
> >
> > <checks>
> >
> > Nope,
> >
> > ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/sched-clock-share
> >
> > is identical to
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/x86_64-mm-sched-clock-share.patch
>
> Or perhaps the deadlock is in the cpufrequency handler. Does it happen without CONFIG_CPUFREQ
> too?
>
> [cpufreq handler calls ktime_get which might take xtime lock for reading]
>
Sounds right. That's what was happening to me for a while.
Randy, it'd be interesting to try:
--- a/arch/x86_64/kernel/tsc.c~a
+++ a/arch/x86_64/kernel/tsc.c
@@ -84,8 +84,8 @@ static int time_cpufreq_notifier(struct
cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new);
- if (!(freq->flags & CPUFREQ_CONST_LOOPS))
- mark_tsc_unstable("cpufreq changes");
+// if (!(freq->flags & CPUFREQ_CONST_LOOPS))
+// mark_tsc_unstable("cpufreq changes");
}
return 0;
_
and if that "fixes" it, disable netconsole and do
--- a/arch/x86_64/kernel/tsc.c~a
+++ a/arch/x86_64/kernel/tsc.c
@@ -85,7 +85,7 @@ static int time_cpufreq_notifier(struct
tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new);
if (!(freq->flags & CPUFREQ_CONST_LOOPS))
- mark_tsc_unstable("cpufreq changes");
+ dump_stack();
}
return 0;
_
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 5:38 ` Andrew Morton
@ 2007-05-01 16:15 ` Randy Dunlap
0 siblings, 0 replies; 135+ messages in thread
From: Randy Dunlap @ 2007-05-01 16:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Andi Kleen, linux-kernel
On Mon, 30 Apr 2007 22:38:59 -0700 Andrew Morton wrote:
> On Tue, 1 May 2007 08:24:56 +0200 Andi Kleen <ak@suse.de> wrote:
>
> > > The bug is in firstfloor only, and the fix (if present) will be there too.
> > >
> > > <checks>
> > >
> > > Nope,
> > >
> > > ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/sched-clock-share
> > >
> > > is identical to
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/x86_64-mm-sched-clock-share.patch
> >
> > Or perhaps the deadlock is in the cpufrequency handler. Does it happen without CONFIG_CPUFREQ
> > too?
> >
> > [cpufreq handler calls ktime_get which might take xtime lock for reading]
> >
>
> Sounds right. That's what was happening to me for a while.
>
> Randy, it'd be interesting to try:
>
> --- a/arch/x86_64/kernel/tsc.c~a
> +++ a/arch/x86_64/kernel/tsc.c
> @@ -84,8 +84,8 @@ static int time_cpufreq_notifier(struct
> cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
>
> tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new);
> - if (!(freq->flags & CPUFREQ_CONST_LOOPS))
> - mark_tsc_unstable("cpufreq changes");
> +// if (!(freq->flags & CPUFREQ_CONST_LOOPS))
> +// mark_tsc_unstable("cpufreq changes");
> }
>
> return 0;
> _
I don't have CPU_FREQ enabled, so that didn't change anything.
> and if that "fixes" it, disable netconsole and do
>
> --- a/arch/x86_64/kernel/tsc.c~a
> +++ a/arch/x86_64/kernel/tsc.c
> @@ -85,7 +85,7 @@ static int time_cpufreq_notifier(struct
>
> tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new);
> if (!(freq->flags & CPUFREQ_CONST_LOOPS))
> - mark_tsc_unstable("cpufreq changes");
> + dump_stack();
> }
>
> return 0;
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 5:16 ` Randy Dunlap
2007-05-01 5:23 ` Andrew Morton
@ 2007-05-01 6:22 ` Andi Kleen
2007-05-01 16:22 ` Randy Dunlap
1 sibling, 1 reply; 135+ messages in thread
From: Andi Kleen @ 2007-05-01 6:22 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Andi Kleen, Andrew Morton, linux-kernel
On Mon, Apr 30, 2007 at 10:16:24PM -0700, Randy Dunlap wrote:
> On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote:
>
> > > Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at
> > > randomish times (presumably in the timer irq handler) when netconsole and
> > > printk-time are enabled.
> >
> > A backtrace would be good. Does nmi_watchdog=2 show anything
> > interesting or if not sysrq-t?
>
> I can't get anything from sysrq or nmi_watchdog.
Hmm, ok when the console locks up those likely don't work.
>
> > > I was hitting the same thing on i386 uniprocessor, but I thought it got
> > > fixed.
> >
> > Yes.
>
> Fixed where? Merged into mainline or in your firstfloor patches?
None of the sched-clock changes are in mainline yet.
Can you perhaps test latest firstfloor alone (without rest of -mm)?
-Andi
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 6:22 ` Andi Kleen
@ 2007-05-01 16:22 ` Randy Dunlap
2007-05-01 17:26 ` Randy Dunlap
0 siblings, 1 reply; 135+ messages in thread
From: Randy Dunlap @ 2007-05-01 16:22 UTC (permalink / raw)
To: Andi Kleen; +Cc: Andrew Morton, linux-kernel
On Tue, 1 May 2007 08:22:58 +0200 Andi Kleen wrote:
> On Mon, Apr 30, 2007 at 10:16:24PM -0700, Randy Dunlap wrote:
> > On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote:
> >
> > > > Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at
> > > > randomish times (presumably in the timer irq handler) when netconsole and
> > > > printk-time are enabled.
> > >
> > > A backtrace would be good. Does nmi_watchdog=2 show anything
> > > interesting or if not sysrq-t?
> >
> > I can't get anything from sysrq or nmi_watchdog.
>
> Hmm, ok when the console locks up those likely don't work.
>
> >
> > > > I was hitting the same thing on i386 uniprocessor, but I thought it got
> > > > fixed.
> > >
> > > Yes.
> >
> > Fixed where? Merged into mainline or in your firstfloor patches?
>
> None of the sched-clock changes are in mainline yet.
>
> Can you perhaps test latest firstfloor alone (without rest of -mm)?
OK. so your 2.6.21-rc7-git5 patch, applied to 2.6.21-git4 or
applied to 2.6.21-rc7-git5 ?
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: 2.6.21-rc7-mm2 hangs in boot (netconsole)
2007-05-01 16:22 ` Randy Dunlap
@ 2007-05-01 17:26 ` Randy Dunlap
0 siblings, 0 replies; 135+ messages in thread
From: Randy Dunlap @ 2007-05-01 17:26 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Andi Kleen, Andrew Morton, linux-kernel
On Tue, 1 May 2007 09:22:33 -0700 Randy Dunlap wrote:
> On Tue, 1 May 2007 08:22:58 +0200 Andi Kleen wrote:
>
> > On Mon, Apr 30, 2007 at 10:16:24PM -0700, Randy Dunlap wrote:
> > > On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote:
> > >
> > > > > Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at
> > > > > randomish times (presumably in the timer irq handler) when netconsole and
> > > > > printk-time are enabled.
> > > >
> > > > A backtrace would be good. Does nmi_watchdog=2 show anything
> > > > interesting or if not sysrq-t?
> > >
> > > I can't get anything from sysrq or nmi_watchdog.
> >
> > Hmm, ok when the console locks up those likely don't work.
> >
> > >
> > > > > I was hitting the same thing on i386 uniprocessor, but I thought it got
> > > > > fixed.
> > > >
> > > > Yes.
> > >
> > > Fixed where? Merged into mainline or in your firstfloor patches?
> >
> > None of the sched-clock changes are in mainline yet.
> >
> > Can you perhaps test latest firstfloor alone (without rest of -mm)?
>
> OK. so your 2.6.21-rc7-git5 patch, applied to 2.6.21-git4 or
> applied to 2.6.21-rc7-git5 ?
Applied cleanly to 2.6.21-rc7-git5, but it has build errors:
arch/x86_64/mm/built-in.o: In function `mark_rodata_ro':
(.text+0x180): undefined reference to `_stext'
arch/x86_64/mm/built-in.o: In function `mem_init':
(.init.text+0x2cf): undefined reference to `_stext'
arch/x86_64/mm/built-in.o: In function `do_page_fault':
(.kprobes.text+0x59c): undefined reference to `_stext'
arch/x86_64/vdso/built-in.o: In function `arch_setup_additional_pages':
(.text+0x40): undefined reference to `vdso_end'
arch/x86_64/vdso/built-in.o: In function `arch_setup_additional_pages':
(.text+0x58): undefined reference to `vdso_start'
arch/x86_64/vdso/built-in.o: In function `init_vdso_vars':
vma.c:(.init.text+0x1b): undefined reference to `vdso_end'
vma.c:(.init.text+0x26): undefined reference to `vdso_start'
vma.c:(.init.text+0x3c): undefined reference to `vdso_start'
kernel/built-in.o: In function `profile_hits':
(.text+0x9609): undefined reference to `_stext'
kernel/built-in.o: In function `core_kernel_text':
(.text+0x197c4): undefined reference to `_stext'
kernel/built-in.o: In function `is_ksym_addr':
kallsyms.c:(.text+0x27042): undefined reference to `_stext'
kernel/built-in.o: In function `profile_init':
(.init.text+0xc57): undefined reference to `_stext'
make: *** [.tmp_vmlinux1] Error 1
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
2007-04-26 5:57 2.6.21-rc7-mm2 Andrew Morton
@ 2007-05-04 11:38 ` Andy Whitcroft
2007-04-26 12:16 ` 2.6.21-rc7-mm2 -- x86_64 VDSO compile error Andy Whitcroft
` (14 subsequent siblings)
15 siblings, 0 replies; 135+ messages in thread
From: Andy Whitcroft @ 2007-05-04 11:38 UTC (permalink / raw)
To: gregkh, paulus; +Cc: Andrew Morton, Andy Whitcroft, linux-kernel, linuxppc-dev
Trying to get 2.6.21-rc7-mm2 to boot on large PPC64 seems to be a
bit of a challenge. We have been seeing panics on boot from the
hvsi driver:
Couldn't register hvsi console driver
Tracking this back, this seems to come from hvsi driver trying to
register itself via tty_register_driver() with a zero units.
The failure is triggered by a change in semantics for kmalloc()
between SLAB and SLUB; kmalloc(0) now returns NULL rather than an
allocation at the smallest size. Looking at the code in question
even when the allocation succeeds we will not actually use the
memory when device->num is zero.
It is not clear to me if this is a bug in the hvsi driver in that
it should specify some units. It seems we will try and reserve zero
devices in this case, which seems pointless.
I have tested with the patch below which seems safe to me and stops
the errors and even seems to make the console work. But perhaps
someone with more driver fu, could verify if driver->num of zero
has any meaning and kick this to the hvsi people if not.
-apw
=== 8< ===
tty_register_driver: only allocate tty instances when defined
If device->num is zero we attempt to kmalloc() zero bytes.
When SLUB is enabled this returns a null pointer and take that as
an allocation failure and fail the device register. Check for no
devices and avoid the allocation.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index 959a616..71c4579 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -3724,7 +3724,7 @@ int tty_register_driver(struct tty_driver *driver)
if (driver->flags & TTY_DRIVER_INSTALLED)
return 0;
- if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM)) {
+ if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM) && driver->num) {
p = kmalloc(driver->num * 3 * sizeof(void *), GFP_KERNEL);
if (!p)
return -ENOMEM;
^ permalink raw reply related [flat|nested] 135+ messages in thread* [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
@ 2007-05-04 11:38 ` Andy Whitcroft
0 siblings, 0 replies; 135+ messages in thread
From: Andy Whitcroft @ 2007-05-04 11:38 UTC (permalink / raw)
To: gregkh, paulus; +Cc: Andrew Morton, linuxppc-dev, linux-kernel
Trying to get 2.6.21-rc7-mm2 to boot on large PPC64 seems to be a
bit of a challenge. We have been seeing panics on boot from the
hvsi driver:
Couldn't register hvsi console driver
Tracking this back, this seems to come from hvsi driver trying to
register itself via tty_register_driver() with a zero units.
The failure is triggered by a change in semantics for kmalloc()
between SLAB and SLUB; kmalloc(0) now returns NULL rather than an
allocation at the smallest size. Looking at the code in question
even when the allocation succeeds we will not actually use the
memory when device->num is zero.
It is not clear to me if this is a bug in the hvsi driver in that
it should specify some units. It seems we will try and reserve zero
devices in this case, which seems pointless.
I have tested with the patch below which seems safe to me and stops
the errors and even seems to make the console work. But perhaps
someone with more driver fu, could verify if driver->num of zero
has any meaning and kick this to the hvsi people if not.
-apw
=== 8< ===
tty_register_driver: only allocate tty instances when defined
If device->num is zero we attempt to kmalloc() zero bytes.
When SLUB is enabled this returns a null pointer and take that as
an allocation failure and fail the device register. Check for no
devices and avoid the allocation.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index 959a616..71c4579 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -3724,7 +3724,7 @@ int tty_register_driver(struct tty_driver *driver)
if (driver->flags & TTY_DRIVER_INSTALLED)
return 0;
- if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM)) {
+ if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM) && driver->num) {
p = kmalloc(driver->num * 3 * sizeof(void *), GFP_KERNEL);
if (!p)
return -ENOMEM;
^ permalink raw reply related [flat|nested] 135+ messages in thread* Re: [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
2007-05-04 11:38 ` Andy Whitcroft
@ 2007-05-04 19:04 ` Linas Vepstas
-1 siblings, 0 replies; 135+ messages in thread
From: Linas Vepstas @ 2007-05-04 19:04 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: gregkh, paulus, Andrew Morton, linuxppc-dev, linux-kernel
On Fri, May 04, 2007 at 12:38:58PM +0100, Andy Whitcroft wrote:
>
> Trying to get 2.6.21-rc7-mm2 to boot on large PPC64 seems to be a
> bit of a challenge. We have been seeing panics on boot from the
> hvsi driver:
>
> Couldn't register hvsi console driver
>
> Tracking this back, this seems to come from hvsi driver trying to
> register itself via tty_register_driver() with a zero units.
>
> The failure is triggered by a change in semantics for kmalloc()
> between SLAB and SLUB; kmalloc(0) now returns NULL rather than an
> allocation at the smallest size. Looking at the code in question
> even when the allocation succeeds we will not actually use the
> memory when device->num is zero.
>
> It is not clear to me if this is a bug in the hvsi driver in that
> it should specify some units. It seems we will try and reserve zero
> devices in this case, which seems pointless.
Yes, it seems pointless to me ...
> I have tested with the patch below which seems safe to me and stops
> the errors and even seems to make the console work. But perhaps
> someone with more driver fu, could verify if driver->num of zero
> has any meaning and kick this to the hvsi people if not.
Hollis nominated me to be "hvsi people", although I'm near-totally
ignorant of the thing.
If hvsi_count is zero, then the device tree did not have any
"serial" nodes that speak "hvterm-protocol". The hvsi should not
have even tried to register anything. The attached patch seems more
to the point.
--linas
The hvsi driver is used whenever the device-tree contains
nodes for serial ports, and those serial ports speak the hvterm
protocol. However, if no such nodes are found, then the hvsi
driver should not even register.
This patch avoids a kernel panic with "Couldn't register hvsi
console driver".
In addition, this patch makes tty_register_driver refuse
to do anything, if there are no actual tty ports to be
registered.
Utterly & completely untested.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/char/hvsi.c | 4 ++++
drivers/char/tty_io.c | 3 +++
2 files changed, 7 insertions(+)
Index: linux-2.6.21-rc7-mm2/drivers/char/hvsi.c
===================================================================
--- linux-2.6.21-rc7-mm2.orig/drivers/char/hvsi.c 2007-04-26 15:37:33.000000000 -0500
+++ linux-2.6.21-rc7-mm2/drivers/char/hvsi.c 2007-05-04 13:55:56.000000000 -0500
@@ -1148,6 +1148,10 @@ static int __init hvsi_init(void)
{
int i;
+ /* No serial hvterm-protocol device-tree nodes found. */
+ if (hvsi_count == 0)
+ return 0;
+
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
return -ENOMEM;
Index: linux-2.6.21-rc7-mm2/drivers/char/tty_io.c
===================================================================
--- linux-2.6.21-rc7-mm2.orig/drivers/char/tty_io.c 2007-04-26 15:37:33.000000000 -0500
+++ linux-2.6.21-rc7-mm2/drivers/char/tty_io.c 2007-05-04 13:54:14.000000000 -0500
@@ -3724,6 +3724,9 @@ int tty_register_driver(struct tty_drive
if (driver->flags & TTY_DRIVER_INSTALLED)
return 0;
+ if (driver->num == 0)
+ return -ENODEV;
+
if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM)) {
p = kmalloc(driver->num * 3 * sizeof(void *), GFP_KERNEL);
if (!p)
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
@ 2007-05-04 19:04 ` Linas Vepstas
0 siblings, 0 replies; 135+ messages in thread
From: Linas Vepstas @ 2007-05-04 19:04 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linuxppc-dev, gregkh, paulus, linux-kernel
On Fri, May 04, 2007 at 12:38:58PM +0100, Andy Whitcroft wrote:
>
> Trying to get 2.6.21-rc7-mm2 to boot on large PPC64 seems to be a
> bit of a challenge. We have been seeing panics on boot from the
> hvsi driver:
>
> Couldn't register hvsi console driver
>
> Tracking this back, this seems to come from hvsi driver trying to
> register itself via tty_register_driver() with a zero units.
>
> The failure is triggered by a change in semantics for kmalloc()
> between SLAB and SLUB; kmalloc(0) now returns NULL rather than an
> allocation at the smallest size. Looking at the code in question
> even when the allocation succeeds we will not actually use the
> memory when device->num is zero.
>
> It is not clear to me if this is a bug in the hvsi driver in that
> it should specify some units. It seems we will try and reserve zero
> devices in this case, which seems pointless.
Yes, it seems pointless to me ...
> I have tested with the patch below which seems safe to me and stops
> the errors and even seems to make the console work. But perhaps
> someone with more driver fu, could verify if driver->num of zero
> has any meaning and kick this to the hvsi people if not.
Hollis nominated me to be "hvsi people", although I'm near-totally
ignorant of the thing.
If hvsi_count is zero, then the device tree did not have any
"serial" nodes that speak "hvterm-protocol". The hvsi should not
have even tried to register anything. The attached patch seems more
to the point.
--linas
The hvsi driver is used whenever the device-tree contains
nodes for serial ports, and those serial ports speak the hvterm
protocol. However, if no such nodes are found, then the hvsi
driver should not even register.
This patch avoids a kernel panic with "Couldn't register hvsi
console driver".
In addition, this patch makes tty_register_driver refuse
to do anything, if there are no actual tty ports to be
registered.
Utterly & completely untested.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/char/hvsi.c | 4 ++++
drivers/char/tty_io.c | 3 +++
2 files changed, 7 insertions(+)
Index: linux-2.6.21-rc7-mm2/drivers/char/hvsi.c
===================================================================
--- linux-2.6.21-rc7-mm2.orig/drivers/char/hvsi.c 2007-04-26 15:37:33.000000000 -0500
+++ linux-2.6.21-rc7-mm2/drivers/char/hvsi.c 2007-05-04 13:55:56.000000000 -0500
@@ -1148,6 +1148,10 @@ static int __init hvsi_init(void)
{
int i;
+ /* No serial hvterm-protocol device-tree nodes found. */
+ if (hvsi_count == 0)
+ return 0;
+
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
return -ENOMEM;
Index: linux-2.6.21-rc7-mm2/drivers/char/tty_io.c
===================================================================
--- linux-2.6.21-rc7-mm2.orig/drivers/char/tty_io.c 2007-04-26 15:37:33.000000000 -0500
+++ linux-2.6.21-rc7-mm2/drivers/char/tty_io.c 2007-05-04 13:54:14.000000000 -0500
@@ -3724,6 +3724,9 @@ int tty_register_driver(struct tty_drive
if (driver->flags & TTY_DRIVER_INSTALLED)
return 0;
+ if (driver->num == 0)
+ return -ENODEV;
+
if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM)) {
p = kmalloc(driver->num * 3 * sizeof(void *), GFP_KERNEL);
if (!p)
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
2007-05-04 11:38 ` Andy Whitcroft
@ 2007-05-04 20:09 ` Andrew Morton
-1 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-05-04 20:09 UTC (permalink / raw)
To: Andy Whitcroft
Cc: gregkh, paulus, linux-kernel, linuxppc-dev, Christoph Lameter
On Fri, 04 May 2007 12:38:58 +0100
Andy Whitcroft <apw@shadowen.org> wrote:
>
> Trying to get 2.6.21-rc7-mm2 to boot on large PPC64 seems to be a
> bit of a challenge. We have been seeing panics on boot from the
> hvsi driver:
>
> Couldn't register hvsi console driver
>
> Tracking this back, this seems to come from hvsi driver trying to
> register itself via tty_register_driver() with a zero units.
>
> The failure is triggered by a change in semantics for kmalloc()
> between SLAB and SLUB; kmalloc(0) now returns NULL rather than an
> allocation at the smallest size. Looking at the code in question
> even when the allocation succeeds we will not actually use the
> memory when device->num is zero.
OK, thanks for working that out.
Christoph, we should be emitting loud warnings so that this problem is easy
to debug.
Better, we should be emitting loud warnigns which then disable themselves
and then succeeding the allocation so that people can proceed with their
kernel testing.
When all the loud-warning sites have been fixed, we can take that code out
again.
The present situation is maximally tester-hostile.
> It is not clear to me if this is a bug in the hvsi driver in that
> it should specify some units. It seems we will try and reserve zero
> devices in this case, which seems pointless.
>
> I have tested with the patch below which seems safe to me and stops
> the errors and even seems to make the console work. But perhaps
> someone with more driver fu, could verify if driver->num of zero
> has any meaning and kick this to the hvsi people if not.
>
> -apw
>
> === 8< ===
> tty_register_driver: only allocate tty instances when defined
>
> If device->num is zero we attempt to kmalloc() zero bytes.
> When SLUB is enabled this returns a null pointer and take that as
> an allocation failure and fail the device register. Check for no
> devices and avoid the allocation.
>
> Signed-off-by: Andy Whitcroft <apw@shadowen.org>
> ---
> diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
> index 959a616..71c4579 100644
> --- a/drivers/char/tty_io.c
> +++ b/drivers/char/tty_io.c
> @@ -3724,7 +3724,7 @@ int tty_register_driver(struct tty_driver *driver)
> if (driver->flags & TTY_DRIVER_INSTALLED)
> return 0;
>
> - if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM)) {
> + if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM) && driver->num) {
> p = kmalloc(driver->num * 3 * sizeof(void *), GFP_KERNEL);
> if (!p)
> return -ENOMEM;
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
@ 2007-05-04 20:09 ` Andrew Morton
0 siblings, 0 replies; 135+ messages in thread
From: Andrew Morton @ 2007-05-04 20:09 UTC (permalink / raw)
To: Andy Whitcroft
Cc: linuxppc-dev, gregkh, paulus, linux-kernel, Christoph Lameter
On Fri, 04 May 2007 12:38:58 +0100
Andy Whitcroft <apw@shadowen.org> wrote:
>
> Trying to get 2.6.21-rc7-mm2 to boot on large PPC64 seems to be a
> bit of a challenge. We have been seeing panics on boot from the
> hvsi driver:
>
> Couldn't register hvsi console driver
>
> Tracking this back, this seems to come from hvsi driver trying to
> register itself via tty_register_driver() with a zero units.
>
> The failure is triggered by a change in semantics for kmalloc()
> between SLAB and SLUB; kmalloc(0) now returns NULL rather than an
> allocation at the smallest size. Looking at the code in question
> even when the allocation succeeds we will not actually use the
> memory when device->num is zero.
OK, thanks for working that out.
Christoph, we should be emitting loud warnings so that this problem is easy
to debug.
Better, we should be emitting loud warnigns which then disable themselves
and then succeeding the allocation so that people can proceed with their
kernel testing.
When all the loud-warning sites have been fixed, we can take that code out
again.
The present situation is maximally tester-hostile.
> It is not clear to me if this is a bug in the hvsi driver in that
> it should specify some units. It seems we will try and reserve zero
> devices in this case, which seems pointless.
>
> I have tested with the patch below which seems safe to me and stops
> the errors and even seems to make the console work. But perhaps
> someone with more driver fu, could verify if driver->num of zero
> has any meaning and kick this to the hvsi people if not.
>
> -apw
>
> === 8< ===
> tty_register_driver: only allocate tty instances when defined
>
> If device->num is zero we attempt to kmalloc() zero bytes.
> When SLUB is enabled this returns a null pointer and take that as
> an allocation failure and fail the device register. Check for no
> devices and avoid the allocation.
>
> Signed-off-by: Andy Whitcroft <apw@shadowen.org>
> ---
> diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
> index 959a616..71c4579 100644
> --- a/drivers/char/tty_io.c
> +++ b/drivers/char/tty_io.c
> @@ -3724,7 +3724,7 @@ int tty_register_driver(struct tty_driver *driver)
> if (driver->flags & TTY_DRIVER_INSTALLED)
> return 0;
>
> - if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM)) {
> + if (!(driver->flags & TTY_DRIVER_DEVPTS_MEM) && driver->num) {
> p = kmalloc(driver->num * 3 * sizeof(void *), GFP_KERNEL);
> if (!p)
> return -ENOMEM;
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
2007-05-04 20:09 ` Andrew Morton
@ 2007-05-04 21:21 ` Christoph Lameter
-1 siblings, 0 replies; 135+ messages in thread
From: Christoph Lameter @ 2007-05-04 21:21 UTC (permalink / raw)
To: Andrew Morton
Cc: Andy Whitcroft, gregkh, paulus, linux-kernel, linuxppc-dev,
Christoph Lameter
On Fri, 4 May 2007, Andrew Morton wrote:
> Better, we should be emitting loud warnigns which then disable themselves
> and then succeeding the allocation so that people can proceed with their
> kernel testing.
>
> When all the loud-warning sites have been fixed, we can take that code out
> again.
>
> The present situation is maximally tester-hostile.
i
SLUB: Allocate smallest object size if the user asks for 0 bytes.
Makes SLUB behave like SLAB in this area to avoid issues....
Throw a stack dump to alert people.
At some point the behavior should be switched back. NULL is no
memory as far as I can tell and if the use asked for 0 bytes then
he need to get no memory.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
include/linux/slub_def.h | 8 ++++++--
mm/slub.c | 2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
Index: slub/mm/slub.c
===================================================================
--- slub.orig/mm/slub.c 2007-05-04 14:17:22.000000000 -0700
+++ slub/mm/slub.c 2007-05-04 14:19:36.000000000 -0700
@@ -2009,7 +2009,7 @@ static struct kmem_cache *get_slab(size_
{
int index = kmalloc_index(size);
- if (!size)
+ if (!index)
return NULL;
/* Allocation too large? */
Index: slub/include/linux/slub_def.h
===================================================================
--- slub.orig/include/linux/slub_def.h 2007-05-04 14:13:40.000000000 -0700
+++ slub/include/linux/slub_def.h 2007-05-04 14:18:25.000000000 -0700
@@ -81,8 +81,12 @@ extern struct kmem_cache kmalloc_caches[
*/
static inline int kmalloc_index(int size)
{
- if (size == 0)
- return 0;
+ /*
+ * We should return 0 if size == 0 but we use the smallest object
+ * here for SLAB legacy reasons.
+ */
+ WARN_ON(size == 0);
+
if (size > 64 && size <= 96)
return 1;
if (size > 128 && size <= 192)
^ permalink raw reply [flat|nested] 135+ messages in thread* Re: [PATCH] Re: 2.6.21-rc7-mm2 -- hvsi console driver registration failure
@ 2007-05-04 21:21 ` Christoph Lameter
0 siblings, 0 replies; 135+ messages in thread
From: Christoph Lameter @ 2007-05-04 21:21 UTC (permalink / raw)
To: Andrew Morton
Cc: gregkh, linux-kernel, linuxppc-dev, paulus, Christoph Lameter
On Fri, 4 May 2007, Andrew Morton wrote:
> Better, we should be emitting loud warnigns which then disable themselves
> and then succeeding the allocation so that people can proceed with their
> kernel testing.
>
> When all the loud-warning sites have been fixed, we can take that code out
> again.
>
> The present situation is maximally tester-hostile.
i
SLUB: Allocate smallest object size if the user asks for 0 bytes.
Makes SLUB behave like SLAB in this area to avoid issues....
Throw a stack dump to alert people.
At some point the behavior should be switched back. NULL is no
memory as far as I can tell and if the use asked for 0 bytes then
he need to get no memory.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
include/linux/slub_def.h | 8 ++++++--
mm/slub.c | 2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
Index: slub/mm/slub.c
===================================================================
--- slub.orig/mm/slub.c 2007-05-04 14:17:22.000000000 -0700
+++ slub/mm/slub.c 2007-05-04 14:19:36.000000000 -0700
@@ -2009,7 +2009,7 @@ static struct kmem_cache *get_slab(size_
{
int index = kmalloc_index(size);
- if (!size)
+ if (!index)
return NULL;
/* Allocation too large? */
Index: slub/include/linux/slub_def.h
===================================================================
--- slub.orig/include/linux/slub_def.h 2007-05-04 14:13:40.000000000 -0700
+++ slub/include/linux/slub_def.h 2007-05-04 14:18:25.000000000 -0700
@@ -81,8 +81,12 @@ extern struct kmem_cache kmalloc_caches[
*/
static inline int kmalloc_index(int size)
{
- if (size == 0)
- return 0;
+ /*
+ * We should return 0 if size == 0 but we use the smallest object
+ * here for SLAB legacy reasons.
+ */
+ WARN_ON(size == 0);
+
if (size > 64 && size <= 96)
return 1;
if (size > 128 && size <= 192)
^ permalink raw reply [flat|nested] 135+ messages in thread