2.6.21-rc7-mm2

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.

Quoted 9 lines · Andrew Morton

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'

Quoted 11 lines · On Thu, 26 Apr 2007 13:47:14 +0200 Gabriel C <[email protected]> wrote:

Quoted 9 lines · Andrew Morton

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.

Quoted 5 lines

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"

Quoted 21 lines · On Thu, 26 Apr 2007 13:37:20 -0700 Andrew Morton wrote:

Quoted 11 lines · On Thu, 26 Apr 2007 13:47:14 +0200 Gabriel C <[email protected]> wrote:

Quoted 9 lines · Andrew Morton

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.

Quoted 5 lines

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.

Quoted 3 lines

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...

Quoted 1 line

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.

Quoted 5 lines · Andrew Morton

Quoted 2 lines

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.

Quoted 5 lines · Andrew Morton

Quoted 2 lines

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?

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

On (26/04/07 13:16), Andy Whitcroft didst pronounce:

Quoted 5 lines

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

Quoted 6 lines

On (26/04/07 13:16), Andy Whitcroft didst pronounce:

Quoted 5 lines

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

On (26/04/07 13:16), Andy Whitcroft didst pronounce:

Quoted 10 lines

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.

Quoted 12 lines

On (26/04/07 13:16), Andy Whitcroft didst pronounce:

Quoted 10 lines

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

Quoted 7 lines

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
===================================================================

On (26/04/07 16:13), Andi Kleen didst pronounce:

Quoted 37 lines · On Thursday 26 April 2007 15:27:36 Mel Gorman wrote:

Quoted 12 lines

On (26/04/07 13:16), Andy Whitcroft didst pronounce:

Quoted 10 lines

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

Quoted 7 lines

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
===================================================================

arch/x86_64/vdso/Makefile +1 -1

@@ -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
 

arch/x86_64/vdso/Makefile $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso · line 38

Quoted 2 lines

arch/x86_64/vdso/Makefile +0 -0

 $(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

arch/x86_64/vdso/vdso.lds line 36

Quoted 9 lines

arch/x86_64/vdso/vdso.lds renamed from arch/x86_64/vdso/vdso.lds-orig +1 -1

@@ -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;

Quoted 5 lines

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

arch/x86_64/vdso/voffset.h line 1

Quoted 5 lines

arch/x86_64/vdso/voffset.h renamed from arch/x86_64/vdso/voffset.h.orig +1 -1

@@ -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?

On (27/04/07 02:39), Andi Kleen didst pronounce:

Quoted 5 lines

Quoted 5 lines

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

Quoted 8 lines

arch/x86_64/vdso/voffset.h line 1

Quoted 5 lines

arch/x86_64/vdso/voffset.h renamed from arch/x86_64/vdso/voffset.h.orig +1 -1

@@ -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.

On (27/04/07 09:59), Mel Gorman didst pronounce:

Quoted 15 lines

On (27/04/07 02:39), Andi Kleen didst pronounce:

Quoted 13 lines

arch/x86_64/vdso/voffset.h line 1

Quoted 10 lines

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

arch/x86_64/vdso/voffset.h renamed from arch/x86_64/vdso/voffset.h.orig +1 -1

@@ -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?

Quoted 2 lines

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.

Quoted 16 lines

On (27/04/07 09:59), Mel Gorman didst pronounce:

Quoted 15 lines

On (27/04/07 02:39), Andi Kleen didst pronounce:

Quoted 13 lines

arch/x86_64/vdso/voffset.h line 1

Quoted 10 lines

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

arch/x86_64/vdso/voffset.h renamed from arch/x86_64/vdso/voffset.h.orig +1 -1

@@ -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?

Quoted 4 lines

Quoted 2 lines

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?

Quoted 6 lines

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?

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

Quoted 12 lines · Andy Whitcroft

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]

Quoted 3 lines

Kernel config is here:

http://test.kernel.org/abat/85082/build/dotconfig

You should boot with earlyprintk=serial,ttyS1,19200

On (26/04/07 15:51), Andi Kleen didst pronounce:

Quoted 14 lines

Quoted 12 lines · Andy Whitcroft

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]

Quoted 6 lines

Quoted 3 lines

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 ([email protected]) (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

On (26/04/07 14:33), Mel Gorman didst pronounce:

Quoted 64 lines

On (26/04/07 15:51), Andi Kleen didst pronounce:

Quoted 14 lines

Quoted 12 lines · Andy Whitcroft

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]

Quoted 6 lines

Quoted 3 lines

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 ([email protected]) (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

Quoted 8 lines

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.

On (26/04/07 16:40), Siddha, Suresh B didst pronounce:

Quoted 1 line

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.

Quoted 4 lines · Mel Gorman

On (26/04/07 16:40), Siddha, Suresh B didst pronounce:

Quoted 1 line

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.

Mel, Please backout the existing x86_64-set-node_possible_map-at-runtime.patch in rc7-mm2 and apply the appended patch instead.

Andrew, as you already backedout x86_64-set-node_possible_map-at-runtime.patch from your -mm series, please include the appended patch (as try 2), after Mel confirms that it works fine on his setup.

Thanks!

---
From: Suresh Siddha <[email protected]> [patch] x86_64: set node_possible_map at runtime - try 2

Set the node_possible_map at runtime on x86_64. On a non NUMA system, num_possible_nodes() will now say '1'.

Signed-off-by Suresh Siddha <[email protected]>

Cc Andi Kleen <[email protected]>

Cc Eric Dumazet <[email protected]>

Cc David Rientjes <[email protected]>

Cc Christoph Lameter <[email protected]>

---

diff -pNru linux/arch/x86_64/mm/k8topology.c linux~/arch/x86_64/mm/k8topology.c

arch/x86_64/mm/k8topology.c +2 -5

@@ -49,11 +49,8 @@ int __init k8_scan_nodes(unsigned long s
 	int found = 0;
 	u32 reg;
 	unsigned numnodes;
-	nodemask_t nodes_parsed;
 	unsigned dualcore = 0;
 
-	nodes_clear(nodes_parsed);
-
 	if (!early_pci_allowed())
 		return -1;
 

@@ -102,7 +99,7 @@ int __init k8_scan_nodes(unsigned long s
 			       nodeid, (base>>8)&3, (limit>>8) & 3);
 			return -1;
 		}
-		if (node_isset(nodeid, nodes_parsed)) {
+		if (node_isset(nodeid, node_possible_map)) {
 			printk(KERN_INFO "Node %d already present. Skipping\n",
 			       nodeid);
 			continue;

@@ -155,7 +152,7 @@ int __init k8_scan_nodes(unsigned long s
 
 		prevbase = base;
 
-		node_set(nodeid, nodes_parsed);
+		node_set(nodeid, node_possible_map);
 	}
 
 	if (!found)

diff -pNru linux/arch/x86_64/mm/numa.c linux~/arch/x86_64/mm/numa.c

arch/x86_64/mm/numa.c +8 -2

@@ -298,7 +298,7 @@ static int __init setup_node_range(int n
 		ret = -1;
 	}
 	nodes[nid].end = *addr;
-	node_set_online(nid);
+	node_set(nid, node_possible_map);
 	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);

@@ -482,7 +482,7 @@ out:
 	 * SRAT.
 	 */
 	remove_all_active_ranges();
-	for_each_online_node(i) {
+	for_each_node_mask(i, node_possible_map) {
 		e820_register_active_regions(i, nodes[i].start >> PAGE_SHIFT,
 						nodes[i].end >> PAGE_SHIFT);
 		setup_node_bootmem(i, nodes[i].start, nodes[i].end);

@@ -497,20 +497,25 @@ void __init numa_initmem_init(unsigned l
 {
 	int i;
 
+	nodes_clear(node_possible_map);
+
 #ifdef CONFIG_NUMA_EMU
 	if (cmdline && !numa_emulation(start_pfn, end_pfn))
 		return;
+	nodes_clear(node_possible_map);
 #endif
 
 #ifdef CONFIG_ACPI_NUMA
 	if (!numa_off && !acpi_scan_nodes(start_pfn << PAGE_SHIFT,
 					  end_pfn << PAGE_SHIFT))
 		return;
+	nodes_clear(node_possible_map);
 #endif
 
 #ifdef CONFIG_K8_NUMA
 	if (!numa_off && !k8_scan_nodes(start_pfn<<PAGE_SHIFT, end_pfn<<PAGE_SHIFT))
 		return;
+	nodes_clear(node_possible_map);
 #endif
 	printk(KERN_INFO "%s\n",
 	       numa_off ? "NUMA turned off" : "No NUMA configuration found");

@@ -524,6 +529,7 @@ void __init numa_initmem_init(unsigned l
 	memnodemap[0] = 0;
 	nodes_clear(node_online_map);
 	node_set_online(0);
+	node_set(0, node_possible_map);
 	for (i = 0; i < NR_CPUS; i++)
 		numa_set_node(i, 0);
 	node_to_cpumask[0] = cpumask_of_cpu(0);

diff -pNru linux/arch/x86_64/mm/srat.c linux~/arch/x86_64/mm/srat.c

arch/x86_64/mm/srat.c +5 -3

@@ -419,19 +419,21 @@ int __init acpi_scan_nodes(unsigned long
 		return -1;
 	}
 
+	node_possible_map = nodes_parsed;
+
 	/* Finally register nodes */
-	for_each_node_mask(i, nodes_parsed)
+	for_each_node_mask(i, node_possible_map)
 		setup_node_bootmem(i, nodes[i].start, nodes[i].end);
 	/* Try again in case setup_node_bootmem missed one due
 	   to missing bootmem */
-	for_each_node_mask(i, nodes_parsed)
+	for_each_node_mask(i, node_possible_map)
 		if (!node_online(i))
 			setup_node_bootmem(i, nodes[i].start, nodes[i].end);
 
 	for (i = 0; i < NR_CPUS; i++) {
 		if (cpu_to_node[i] == NUMA_NO_NODE)
 			continue;
-		if (!node_isset(cpu_to_node[i], nodes_parsed))
+		if (!node_isset(cpu_to_node[i], node_possible_map))
 			numa_set_node(i, NUMA_NO_NODE);
 	}
 	numa_init_array();

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

Quoted 16 lines · Andy Whitcroft

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.

Quoted 3 lines

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?

Quoted 6 lines · Andy Whitcroft

Quoted 3 lines

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:

Quoted 7 lines

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?

Quoted 3 lines

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.

Quoted 4 lines

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?

I am inclined to suggest we change it for BUG:

	BUG(index < 0);

Perhaps only on older compilers.

Quoted 1 line

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

Quoted 2 lines · Andy Whitcroft

Quoted 1 line

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.

Quoted 3 lines

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?

Quoted 11 lines · Andy Whitcroft

Quoted 3 lines

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

Quoted 1 line

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.

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 <[email protected]>

---

Index: linux-mm/mm/memory.c
===================================================================

Quoted 14 lines · On Thu, 26 Apr 2007 20:25:19 +0200 Borislav Petkov <[email protected]> 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 <[email protected]>

---

Index: linux-mm/mm/memory.c
===================================================================

mm/memory.c 2007-04-26 20:00:30.000000000 +0200 line 1494

Quoted 8 lines

mm/memory.c 2007-04-26 20:00:30.000000000 +0200 renamed from mm/memory.c 2007-04-26 19:57:14.000000000 +0200 +1 -1

@@ -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.

mm/memory.c renamed from mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix +1 -1

@@ -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) :

_

Quoted 51 lines · Andrew Morton

Quoted 14 lines · On Thu, 26 Apr 2007 20:25:19 +0200 Borislav Petkov <[email protected]> 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 <[email protected]>

---

Index: linux-mm/mm/memory.c
===================================================================

mm/memory.c 2007-04-26 20:00:30.000000000 +0200 line 1494

Quoted 8 lines

mm/memory.c 2007-04-26 20:00:30.000000000 +0200 renamed from mm/memory.c 2007-04-26 19:57:14.000000000 +0200 +1 -1

@@ -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.

mm/memory.c renamed from mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix +1 -1

@@ -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) :

Quoted 1 line

_

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...

Quoted 3 lines

__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
===================================================================

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:

Quoted 13 lines · On Thu, 26 Apr 2007 20:25:19 +0200 Borislav Petkov <[email protected]> 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 <[email protected]>

---

Index: linux-mm/mm/memory.c
===================================================================

mm/memory.c 2007-04-26 20:00:30.000000000 +0200 line 1494

Quoted 8 lines

mm/memory.c 2007-04-26 20:00:30.000000000 +0200 renamed from mm/memory.c 2007-04-26 19:57:14.000000000 +0200 +1 -1

@@ -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.

mm/memory.c renamed from mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix +1 -1

@@ -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) :

_

Quoted 10 lines

+++ a/mm/memory.c

mm/memory.c renamed from mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix +1 -1

@@ -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) :

Quoted 2 lines

_

Perhaps we should have some kind definition helper.

#define suppress_unused(x) x = x

	spinlock_t *suppress_unused(ptl);

Perhaps?

Quoted 50 lines · Andrew Morton

Quoted 13 lines · On Thu, 26 Apr 2007 20:25:19 +0200 Borislav Petkov <[email protected]> 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 <[email protected]>

---

Index: linux-mm/mm/memory.c
===================================================================

mm/memory.c 2007-04-26 20:00:30.000000000 +0200 line 1494

Quoted 8 lines

mm/memory.c 2007-04-26 20:00:30.000000000 +0200 renamed from mm/memory.c 2007-04-26 19:57:14.000000000 +0200 +1 -1

@@ -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.

mm/memory.c renamed from mm/memory.c~add-apply_to_page_range-which-applies-a-function-to-a-pte-range-fix +1 -1

@@ -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) :

Quoted 2 lines

_

Perhaps we should have some kind definition helper.

#define suppress_unused(x) x = x

	spinlock_t *suppress_unused(ptl);

Introduce a macro for suppressing gcc from generating a warning about a probable unitialized state of a variable.

Signed-off-by Borislav Petkov <[email protected]>

---

Index: linux-mm/include/linux/compiler.h
===================================================================

include/linux/compiler.h +4 -0

@@ -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
===================================================================

Introduce a macro for suppressing gcc from generating a warning about a probable unitialized state of a variable.

Quoted 2 lines · On Sun, 29 Apr 2007 08:50:49 +0200 Borislav Petkov <[email protected]> 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.

Quoted 5 lines · Andrew Morton

Quoted 2 lines · On Sun, 29 Apr 2007 08:50:49 +0200 Borislav Petkov <[email protected]> wrote:

Introduce a macro for suppressing gcc from generating a warning about a probable unitialized state of a variable.

Quoted 5 lines

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)) ?

Introduce a macro for suppressing gcc from generating a warning about a probable uninitialized state of a variable.

Example:

(quoted diff) +1 -1

-	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 <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

Quoted 20 lines

Introduce a macro for suppressing gcc from generating a warning about a probable uninitialized state of a variable.

Example:

(quoted diff) +1 -1

-	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.

Quoted 2 lines

Signed-off-by Borislav Petkov <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

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

...
Changes since 2.6.21-rc7-mm1:
...
git-ieee1394.patch
...
git trees
...

highlevel_host_reset no longer has any modular users.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/

Quoted 1 line · Andrew Morton

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

Any ideas?

Quoted 1 line · Andrew Morton

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.

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

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?

Quoted 4 lines

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:

Quoted 4 lines

Quoted 4 lines

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.

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.

Am 30.04.2007 20:21 schrieb Andrew Morton:

Quoted 2 lines

A lot of Greg's driver tree has gone upstream, so please check current mainline.

2.6.21-final is fine.

Quoted 3 lines

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?

Quoted 1 line

2.6.21-final is fine.

Sure, but what about 2.6.21-git3 (or, better, current -git)?

Quoted 5 lines

Quoted 3 lines

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.

Sure, but what about 2.6.21-git3 (or, better, current -git)?

Am 30.04.2007 21:46 schrieb Andrew Morton:

Quoted 1 line

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.

Not really - everything's tangled up. A bisection search on the 2.6.21-rc7-mm2 driver tree would be the best bet.

Am 30.04.2007 21:46 schrieb Andrew Morton:

Quoted 2 lines

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.

Am 30.04.2007 21:46 schrieb Andrew Morton:

Quoted 2 lines

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.

Quoted 10 lines · On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <[email protected]> wrote:

Am 30.04.2007 21:46 schrieb Andrew Morton:

Quoted 2 lines

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.

(quoted diff) +7 -0

+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?

Quoted 10 lines · On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <[email protected]> wrote:

Am 30.04.2007 21:46 schrieb Andrew Morton:

Quoted 2 lines

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.

(quoted diff) +7 -0

+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.

Quoted 4 lines

Quoted 4 lines

And the winner is:

gregkh-driver-driver-core-make-uevent-environment-available-in-uevent-file.patch

Quoted 2 lines

Quoted 2 lines

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?

Quoted 11 lines · Greg KH

Quoted 6 lines

Quoted 6 lines

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...

Quoted 1 line

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

Quoted 23 lines · Andrew Morton

Quoted 10 lines · On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <[email protected]> wrote:

Am 30.04.2007 21:46 schrieb Andrew Morton:

Quoted 2 lines

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.

(quoted diff) +7 -0

+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];

Quoted 1 line

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?

Quoted 10 lines · On Wed, 02 May 2007 09:01:22 +0200 Tilman Schmidt <[email protected]> wrote:

Am 30.04.2007 21:46 schrieb Andrew Morton:

Quoted 2 lines

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.

(quoted diff) +7 -0

+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?

---
 drivers/base/core.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/base/core.c +6 -1

@@ -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;
 }
 

Am 02.05.2007 09:52 schrieb Greg KH:

Quoted 1 line

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.

Quoted 1 line

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.

Am 30.04.2007 21:46 schrieb Andrew Morton:

Quoted 2 lines

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

...
Changes since 2.6.21-rc7-mm1:
...
git-acpi.patch
...
git trees
...

Quoted 7 lines · Andrew Morton

...
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 <[email protected]>

---

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...

drivers/misc/thinkpad_acpi.h renamed from drivers/misc/thinkpad_acpi.h.old +1 -1

@@ -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;
 

Quoted 2 lines

This patch makes the needlessly global fan_mutex static.

On Sat, 28 Apr 2007, Adrian Bunk wrote:
...

Quoted 3 lines

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...

Quoted 6 lines

drivers/misc/thinkpad_acpi.h renamed from drivers/misc/thinkpad_acpi.h.old +0 -0

@@ -382,7 +382,7 @@
 static u8 fan_control_desired_level;
 static int fan_watchdog_maxinterval;
 

drivers/misc/thinkpad_acpi.h line 388

Quoted 5 lines

drivers/misc/thinkpad_acpi.h renamed from drivers/misc/thinkpad_acpi.h.old +1 -1

-struct mutex fan_mutex;
+static struct mutex fan_mutex;
 
 static acpi_handle fans_handle, gfan_handle, sfan_handle;
 

Henrique Holschuh

Forward declarations of static functions (if required) and actual variables (like fan_mutex) belong into the C file, not the header.

Quoted 2 lines

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.

...
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 <[email protected]>

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 [email protected]

- 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

(quoted diff) +134 -88

-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 [email protected]
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.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/

Quoted 2 lines · 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?

Quoted 23 lines · On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <[email protected]> wrote:

Quoted 2 lines · 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/

Quoted 12 lines

[    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.

Quoted 3 lines

.config is attached.

Any ideas/suggestions?

Just the usual: nothing from sysrq or NMI watchdog?

Quoted 40 lines · On Sun, 29 Apr 2007 22:23:54 -0700 Andrew Morton wrote:

Quoted 23 lines · On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <[email protected]> wrote:

Quoted 2 lines · 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/

Quoted 12 lines

[    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.

Quoted 5 lines

Quoted 3 lines

.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.

Quoted 46 lines · On Mon, 30 Apr 2007 08:16:53 -0700 Randy Dunlap wrote:

Quoted 44 lines · On Sun, 29 Apr 2007 22:23:54 -0700 Andrew Morton wrote:

Quoted 23 lines · On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <[email protected]> wrote:

Quoted 2 lines · 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/

Quoted 12 lines

[    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.

Quoted 3 lines

.config is attached.

Any ideas/suggestions?

Quoted 3 lines

Quoted 1 line

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?)

Quoted 41 lines · On Mon, 30 Apr 2007 16:51:01 -0700 Randy Dunlap <[email protected]> wrote:

Quoted 39 lines · On Mon, 30 Apr 2007 08:16:53 -0700 Randy Dunlap wrote:

Quoted 37 lines · On Sun, 29 Apr 2007 22:23:54 -0700 Andrew Morton wrote:

Quoted 21 lines · On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <[email protected]> wrote:

Quoted 1 line · 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/

Quoted 12 lines

[    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.

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

.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.

Quoted 1 line

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.

Quoted 57 lines · Andrew Morton

Quoted 41 lines · On Mon, 30 Apr 2007 16:51:01 -0700 Randy Dunlap <[email protected]> wrote:

Quoted 39 lines · On Mon, 30 Apr 2007 08:16:53 -0700 Randy Dunlap wrote:

Quoted 37 lines · On Sun, 29 Apr 2007 22:23:54 -0700 Andrew Morton wrote:

Quoted 21 lines · On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <[email protected]> wrote:

Quoted 1 line · 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/

Quoted 12 lines

[    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.

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

.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.

Quoted 1 line

Do we know of netconsole hang problems? (anyone?)

Quoted 4 lines

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...

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 4 lines

Quoted 2 lines

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

Quoted 8 lines

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

Quoted 3 lines

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]

Quoted 8 lines · On Tue, 1 May 2007 08:24:56 +0200 Andi Kleen <[email protected]> wrote:

Quoted 8 lines

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

Quoted 9 lines

Quoted 3 lines

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:

arch/x86_64/kernel/tsc.c renamed from arch/x86_64/kernel/tsc.c~a +2 -2

@@ -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;

_

Quoted 6 lines · On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote:

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

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?

Quoted 10 lines · Randy Dunlap

Quoted 6 lines · On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote:

Quoted 3 lines

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.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

I was hitting the same thing on i386 uniprocessor, but I thought it got fixed.

Quoted 3 lines

Quoted 1 line

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)?

Quoted 20 lines · On Tue, 1 May 2007 08:22:58 +0200 Andi Kleen wrote:

Quoted 10 lines · Randy Dunlap

Quoted 6 lines · On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote:

Quoted 3 lines

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.

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

I was hitting the same thing on i386 uniprocessor, but I thought it got fixed.

Yes.

Quoted 5 lines

Quoted 1 line

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 ?