Re: mmotm 2008-10-02-16-17 uploaded

Re: mmotm 2008-10-02-16-17 uploaded

[Randy.Dunlap]

On Thu, 2 Oct 2008, akpm@linux-foundation.org wrote:

> The mm-of-the-moment snapshot 2008-10-02-16-17 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/
> 
> It contains the following patches against 2.6.27-rc8:

10 out of 10 build randconfig failures on i386;
10 out of 10 build randconfig failures on x86_64.

Summary for i386:

build-r9491.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/include/linux/stacktrace.h:13: warning:
 'struct task_struct' declared inside parameter list
build-r9491.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/include/linux/stacktrace.h:13: warning:
 its scope is only this definition or declaration, which is probably not what you want
build-r9491.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/fs/autofs4/dev-ioctl.c:310: error: too 
many arguments to function 'dentry_open'

~~~ Lots of these:

build-r9494.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/process_32.c:87: error:
 implicit declaration of function 'cpu_uninit'
build-r9494.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/process_32.c:99: error:
 redefinition of 'play_dead'
build-r9494.out:include2/asm/smp.h:112: error: previous definition of 'play_dead' was here

~~~ (with copy-and-paste line breaks)

build-r9502.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_32.c:1539: warn
ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'u64'
build-r9502.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_32.c:1540: warn
ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'u64'
build-r9502.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/include/linux/stacktrace.h:13: warning:
 'struct task_struct' declared inside parameter list
build-r9502.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/include/linux/stacktrace.h:13: warning:
 its scope is only this definition or declaration, which is probably not what you want
build-r9502.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/drivers/char/stallion.c:615: error: imp
licit declaration of function 'tty_port_tty_get'
build-r9502.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/drivers/char/stallion.c:739: error: imp
licit declaration of function 'tty_port_tty_set'


Summary for x86_64:

(several of these)
build-r9492.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/process_64.c:95: error:
 redefinition of 'play_dead'
build-r9492.out:include2/asm/smp.h:112: error: previous definition of 'play_dead' was here

~~~

(lots of these)
build-r9493.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_64.c:1284: warn
ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
build-r9493.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_64.c:1285: warn
ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
build-r9493.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/k8.c:20: error: 'PCI_DE
VICE_ID_AMD_10H_NB_MISC' undeclared here (not in a function)
build-r9493.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/fs/autofs4/dev-ioctl.c:310: error: too 
many arguments to function 'dentry_open'

~~~

I'll work on some patches for them as time permits...
or you could drop them, push them back to their submitters...

-- 
~Randy

Re: mmotm 2008-10-02-16-17 uploaded

[Andrew Morton]

On Thu, 2 Oct 2008 17:17:16 -0700 (PDT)
"Randy.Dunlap" <rdunlap@xenotime.net> wrote:

> I'll work on some patches for them as time permits...
> or you could drop them, push them back to their submitters...

That tree's such a dog's breakfast that I haven't even tried to compile
it, and I hope not to do so until Stephen returns and puts it all back
together again.

I should have asked Stephen to try to find someone to keep it all
ticking over while he is away.

This one:

build-r9491.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/include/linux/stacktrace.h:13: warning:
 'struct task_struct' declared inside parameter list

is an honest-to-goodness, should-be-fixed-yesterday upstream bug.


From: Andrew Morton <akpm@linux-foundation.org>

include/linux/stacktrace.h:13: warning:
 'struct task_struct' declared inside parameter list

Reported-by: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/linux/stacktrace.h |    2 ++
 1 file changed, 2 insertions(+)

diff -puN include/linux/stacktrace.h~include-linux-stacktraceh-declare-struct-task_struct include/linux/stacktrace.h
--- a/include/linux/stacktrace.h~include-linux-stacktraceh-declare-struct-task_struct
+++ a/include/linux/stacktrace.h
@@ -1,6 +1,8 @@
 #ifndef __LINUX_STACKTRACE_H
 #define __LINUX_STACKTRACE_H
 
+struct task_struct;
+
 #ifdef CONFIG_STACKTRACE
 struct stack_trace {
 	unsigned int nr_entries, max_entries;
_

Re: mmotm 2008-10-02-16-17 uploaded

[Randy Dunlap]

On Thu, 2 Oct 2008 17:17:16 -0700 (PDT) Randy.Dunlap wrote:

> On Thu, 2 Oct 2008, akpm@linux-foundation.org wrote:
> 
> > The mm-of-the-moment snapshot 2008-10-02-16-17 has been uploaded to
> > 
> >    http://userweb.kernel.org/~akpm/mmotm/
> > 
> > It contains the following patches against 2.6.27-rc8:
> 
> 10 out of 10 build randconfig failures on i386;
> 10 out of 10 build randconfig failures on x86_64.
> 
> Summary for i386:
> 
> build-r9491.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/fs/autofs4/dev-ioctl.c:310: error: too 
> many arguments to function 'dentry_open'
> 
> ~~~ (with copy-and-paste line breaks)
> 
> build-r9502.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_32.c:1539: warn
> ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'u64'
> build-r9502.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_32.c:1540: warn
> ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'u64'

Weren't these already fixed once?  Could they be in one of the 180-or-so
-tip branches but you don't have it?

> 
> Summary for x86_64:
> 
> (lots of these)
> build-r9493.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_64.c:1284: warn
> ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
> build-r9493.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_64.c:1285: warn
> ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'

Same question for these...

> build-r9493.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/fs/autofs4/dev-ioctl.c:310: error: too 
> many arguments to function 'dentry_open'

You (akpm) made a patch (autofs4-add-miscellaneous-device-for-ioctls-fix-fix-3.patch)
which adds arg4 to this call to dentry_open() but I can't find why/where a 4th arg
was added and the patch doesn't seem to be needed here/now.  what gives?


---
~Randy

Re: mmotm 2008-10-02-16-17 uploaded

[Andrew Morton]

On Thu, 2 Oct 2008 20:32:30 -0700 Randy Dunlap <rdunlap@xenotime.net> wrote:

> On Thu, 2 Oct 2008 17:17:16 -0700 (PDT) Randy.Dunlap wrote:
> 
> > On Thu, 2 Oct 2008, akpm@linux-foundation.org wrote:
> > 
> > > The mm-of-the-moment snapshot 2008-10-02-16-17 has been uploaded to
> > > 
> > >    http://userweb.kernel.org/~akpm/mmotm/
> > > 
> > > It contains the following patches against 2.6.27-rc8:
> > 
> > 10 out of 10 build randconfig failures on i386;
> > 10 out of 10 build randconfig failures on x86_64.
> > 
> > Summary for i386:
> > 
> > build-r9491.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/fs/autofs4/dev-ioctl.c:310: error: too 
> > many arguments to function 'dentry_open'
> > 
> > ~~~ (with copy-and-paste line breaks)
> > 
> > build-r9502.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_32.c:1539: warn
> > ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'u64'
> > build-r9502.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_32.c:1540: warn
> > ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'u64'
> 
> Weren't these already fixed once?  Could they be in one of the 180-or-so
> -tip branches but you don't have it?

That's a workable theory.

> > 
> > Summary for x86_64:
> > 
> > (lots of these)
> > build-r9493.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_64.c:1284: warn
> > ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
> > build-r9493.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/arch/x86/kernel/io_apic_64.c:1285: warn
> > ing: format '%08x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
> 
> Same question for these...
> 
> > build-r9493.out:/home/rdunlap/linsrc/mmotm-2008-1002-1617/fs/autofs4/dev-ioctl.c:310: error: too 
> > many arguments to function 'dentry_open'
> 
> You (akpm) made a patch (autofs4-add-miscellaneous-device-for-ioctls-fix-fix-3.patch)
> which adds arg4 to this call to dentry_open() but I can't find why/where a 4th arg
> was added and the patch doesn't seem to be needed here/now.  what gives?
> 

Some other tree which fell out of the pile changed the dentry_open()
interface so that fix isn't needed until it is needed again.

Really, it's not worth bothering about at present.  I wonder what's on TV?

Re: mmotm 2008-10-02-16-17 uploaded

[Randy Dunlap]

> Some other tree which fell out of the pile changed the dentry_open()
> interface so that fix isn't needed until it is needed again.
> 
> Really, it's not worth bothering about at present.  I wonder what's on TV?

OK, I'll follow that with something drinkable.

cya,
---
~Randy

Re: mmotm 2008-10-02-16-17 uploaded

[KAMEZAWA Hiroyuki]

I'm sorry if alread fixed.

Folloing function in git-x86.patch touches invalid address.
==
+void __init early_cpu_init(void)
+{
+       struct cpu_dev **cdev;
+       int count = 0;
+
+       printk("KERNEL supported cpus:\n");
+       for (cdev = __x86_cpu_dev_start; cdev < __x86_cpu_dev_end; cdev++) {
+               struct cpu_dev *cpudev = *cdev;
+               unsigned int j;
+
+               if (count >= X86_VENDOR_NUM)
+                       break;
+               cpu_devs[count] = cpudev;
+               count++;
+
+               for (j = 0; j < 2; j++) {
+                       if (!cpudev->c_ident[j])
+                               continue;
+                       printk("  %s %s\n", cpudev->c_vendor,
+                               cpudev->c_ident[j]);
+               }
+       }
+
+       early_identify_cpu(&boot_cpu_data);
 }
==
printk("  %s %s\n", cpudev->c_vendor, cpudev->c_ident[j]);
touches invalid address. (following is printk() result by
replacing %s with %p.
==
  ffffffff8066e38a ffffffff8066e383
  ffffffff8066e3ab ffffffff8066e3a2
  ffffffff8066e3af ffffffff8066e3b7
  807064c0c7c74855 08ec834853e58948
  807064c0c7c74855 74c085fffffe9fe8
==
and the kernel never boots on my box.

Thanks,
-Kame

Re: mmotm 2008-10-02-16-17 uploaded

[Yinghai Lu]

KAMEZAWA Hiroyuki wrote:
> I'm sorry if alread fixed.
> 
> Folloing function in git-x86.patch touches invalid address.
> ==
> +void __init early_cpu_init(void)
> +{
> +       struct cpu_dev **cdev;
> +       int count = 0;
> +
> +       printk("KERNEL supported cpus:\n");
> +       for (cdev = __x86_cpu_dev_start; cdev < __x86_cpu_dev_end; cdev++) {
> +               struct cpu_dev *cpudev = *cdev;
> +               unsigned int j;
> +
> +               if (count >= X86_VENDOR_NUM)
> +                       break;
> +               cpu_devs[count] = cpudev;
> +               count++;
> +
> +               for (j = 0; j < 2; j++) {
> +                       if (!cpudev->c_ident[j])
> +                               continue;
> +                       printk("  %s %s\n", cpudev->c_vendor,
> +                               cpudev->c_ident[j]);
> +               }
> +       }
> +
> +       early_identify_cpu(&boot_cpu_data);
>  }
> ==
> printk("  %s %s\n", cpudev->c_vendor, cpudev->c_ident[j]);
> touches invalid address. (following is printk() result by
> replacing %s with %p.
> ==
>   ffffffff8066e38a ffffffff8066e383
>   ffffffff8066e3ab ffffffff8066e3a2
>   ffffffff8066e3af ffffffff8066e3b7
>   807064c0c7c74855 08ec834853e58948
>   807064c0c7c74855 74c085fffffe9fe8
> ==
> and the kernel never boots on my box.

could be merging problem again.

please check in arch/x86/kernel/vmliux_64.lds.S

it should be like 

  __con_initcall_end = .;
  __x86_cpu_dev_start = .;
  .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
        *(.x86_cpu_dev.init)
  }
  __x86_cpu_dev_end = .;

  DYN_ARRAY_INIT(8)

  SECURITY_INIT


YH

Re: mmotm 2008-10-02-16-17 uploaded

[KAMEZAWA Hiroyuki]

On Tue, 07 Oct 2008 09:18:03 -0700
Yinghai Lu <yinghai@kernel.org> wrote:

> KAMEZAWA Hiroyuki wrote:
> > I'm sorry if alread fixed.
> > 
> > Folloing function in git-x86.patch touches invalid address.
> > ==
> > +void __init early_cpu_init(void)
> > +{
> > +       struct cpu_dev **cdev;
> > +       int count = 0;
> > +
> > +       printk("KERNEL supported cpus:\n");
> > +       for (cdev = __x86_cpu_dev_start; cdev < __x86_cpu_dev_end; cdev++) {
> > +               struct cpu_dev *cpudev = *cdev;
> > +               unsigned int j;
> > +
> > +               if (count >= X86_VENDOR_NUM)
> > +                       break;
> > +               cpu_devs[count] = cpudev;
> > +               count++;
> > +
> > +               for (j = 0; j < 2; j++) {
> > +                       if (!cpudev->c_ident[j])
> > +                               continue;
> > +                       printk("  %s %s\n", cpudev->c_vendor,
> > +                               cpudev->c_ident[j]);
> > +               }
> > +       }
> > +
> > +       early_identify_cpu(&boot_cpu_data);
> >  }
> > ==
> > printk("  %s %s\n", cpudev->c_vendor, cpudev->c_ident[j]);
> > touches invalid address. (following is printk() result by
> > replacing %s with %p.
> > ==
> >   ffffffff8066e38a ffffffff8066e383
> >   ffffffff8066e3ab ffffffff8066e3a2
> >   ffffffff8066e3af ffffffff8066e3b7
> >   807064c0c7c74855 08ec834853e58948
> >   807064c0c7c74855 74c085fffffe9fe8
> > ==
> > and the kernel never boots on my box.
> 
> could be merging problem again.
> 
> please check in arch/x86/kernel/vmliux_64.lds.S
> 
> it should be like 
> 
>   __con_initcall_end = .;
>   __x86_cpu_dev_start = .;
>   .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
>         *(.x86_cpu_dev.init)
>   }
>   __x86_cpu_dev_end = .;
> 
>   DYN_ARRAY_INIT(8)
> 
>   SECURITY_INIT
> 
Oh, yes. like this.
==
 __con_initcall_end = .;
  __x86_cpu_dev_start = .;
  .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
        *(.x86_cpu_dev.init)
  }
  SECURITY_INIT
  __x86_cpu_dev_end = .;
==

I'll try next version when it comes.

Thanks,
-Kame

Re: mmotm 2008-10-02-16-17 uploaded

[Andrew Morton]

On Wed, 8 Oct 2008 08:47:53 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Tue, 07 Oct 2008 09:18:03 -0700
> Yinghai Lu <yinghai@kernel.org> wrote:
> 
> > KAMEZAWA Hiroyuki wrote:
> > > I'm sorry if alread fixed.
> > > 
> > > Folloing function in git-x86.patch touches invalid address.
> > > ==
> > > +void __init early_cpu_init(void)
> > > +{
> > > +       struct cpu_dev **cdev;
> > > +       int count = 0;
> > > +
> > > +       printk("KERNEL supported cpus:\n");
> > > +       for (cdev = __x86_cpu_dev_start; cdev < __x86_cpu_dev_end; cdev++) {
> > > +               struct cpu_dev *cpudev = *cdev;
> > > +               unsigned int j;
> > > +
> > > +               if (count >= X86_VENDOR_NUM)
> > > +                       break;
> > > +               cpu_devs[count] = cpudev;
> > > +               count++;
> > > +
> > > +               for (j = 0; j < 2; j++) {
> > > +                       if (!cpudev->c_ident[j])
> > > +                               continue;
> > > +                       printk("  %s %s\n", cpudev->c_vendor,
> > > +                               cpudev->c_ident[j]);
> > > +               }
> > > +       }
> > > +
> > > +       early_identify_cpu(&boot_cpu_data);
> > >  }
> > > ==
> > > printk("  %s %s\n", cpudev->c_vendor, cpudev->c_ident[j]);
> > > touches invalid address. (following is printk() result by
> > > replacing %s with %p.
> > > ==
> > >   ffffffff8066e38a ffffffff8066e383
> > >   ffffffff8066e3ab ffffffff8066e3a2
> > >   ffffffff8066e3af ffffffff8066e3b7
> > >   807064c0c7c74855 08ec834853e58948
> > >   807064c0c7c74855 74c085fffffe9fe8
> > > ==
> > > and the kernel never boots on my box.
> > 
> > could be merging problem again.
> > 
> > please check in arch/x86/kernel/vmliux_64.lds.S
> > 
> > it should be like 
> > 
> >   __con_initcall_end = .;
> >   __x86_cpu_dev_start = .;
> >   .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
> >         *(.x86_cpu_dev.init)
> >   }
> >   __x86_cpu_dev_end = .;
> > 
> >   DYN_ARRAY_INIT(8)
> > 
> >   SECURITY_INIT

The above is what's presently in Ingo's "tip" tree.

> Oh, yes. like this.
> ==
>  __con_initcall_end = .;
>   __x86_cpu_dev_start = .;
>   .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
>         *(.x86_cpu_dev.init)
>   }
>   SECURITY_INIT
>   __x86_cpu_dev_end = .;
> ==
> 
> I'll try next version when it comes.

If that fixes it then Ingo's tree will need fixing too, I suppose.

Re: mmotm 2008-10-02-16-17 uploaded

[KAMEZAWA Hiroyuki]

On Tue, 7 Oct 2008 17:01:03 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> > Oh, yes. like this.
> > ==
> >  __con_initcall_end = .;
> >   __x86_cpu_dev_start = .;
> >   .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
> >         *(.x86_cpu_dev.init)
> >   }
> >   SECURITY_INIT
> >   __x86_cpu_dev_end = .;
> > ==
> > 
> > I'll try next version when it comes.
> 
> If that fixes it then Ingo's tree will need fixing too, I suppose.
> 
Sad..

just for information. I used...

 - 3 fixes to git-x86.patch.
 - 1 fix to patches/usb-usb-remove-warn-macro-from-usbh.patch
 - 1 fix to patches/autofs4-add-miscellaneous-device-for-ioctls-fix-fix-3.patch 

Maybe some are fixed. Merged one is here.

==
Index: mmotm-2.6.27-rc8+/arch/x86/kernel/process_64.c
===================================================================
--- mmotm-2.6.27-rc8+.orig/arch/x86/kernel/process_64.c
+++ mmotm-2.6.27-rc8+/arch/x86/kernel/process_64.c
@@ -86,31 +86,6 @@ void exit_idle(void)
 	__exit_idle();
 }
 
-#ifdef CONFIG_HOTPLUG_CPU
-DECLARE_PER_CPU(int, cpu_state);
-
-#include <asm/nmi.h>
-/* We halt the CPU with physical CPU hotplug */
-static inline void play_dead(void)
-{
-	idle_task_exit();
-	c1e_remove_cpu(raw_smp_processor_id());
-
-	mb();
-	/* Ack it */
-	__get_cpu_var(cpu_state) = CPU_DEAD;
-
-	local_irq_disable();
-	/* mask all interrupts, flush any and all caches, and halt */
-	wbinvd_halt();
-}
-#else
-static inline void play_dead(void)
-{
-	BUG();
-}
-#endif
-
 /*
  * The idle thread. There's no useful work to be
  * done, so just try to conserve power and have a
Index: mmotm-2.6.27-rc8+/include/linux/pci_ids.h
===================================================================
--- mmotm-2.6.27-rc8+.orig/include/linux/pci_ids.h
+++ mmotm-2.6.27-rc8+/include/linux/pci_ids.h
@@ -497,6 +497,11 @@
 #define PCI_DEVICE_ID_AMD_K8_NB_ADDRMAP	0x1101
 #define PCI_DEVICE_ID_AMD_K8_NB_MEMCTL	0x1102
 #define PCI_DEVICE_ID_AMD_K8_NB_MISC	0x1103
+#define PCI_DEVICE_ID_AMD_10H_NB_HT    0x1200
+#define PCI_DEVICE_ID_AMD_10H_NB_MAP   0x1201
+#define PCI_DEVICE_ID_AMD_10H_NB_DRAM  0x1202
+#define PCI_DEVICE_ID_AMD_10H_NB_MISC  0x1203
+#define PCI_DEVICE_ID_AMD_10H_NB_LINK  0x1204 
 #define PCI_DEVICE_ID_AMD_11H_NB_HT	0x1300
 #define PCI_DEVICE_ID_AMD_11H_NB_MAP	0x1301
 #define PCI_DEVICE_ID_AMD_11H_NB_DRAM	0x1302
Index: mmotm-2.6.27-rc8+/arch/x86/kernel/cpu/common.c
===================================================================
--- mmotm-2.6.27-rc8+.orig/arch/x86/kernel/cpu/common.c
+++ mmotm-2.6.27-rc8+/arch/x86/kernel/cpu/common.c
@@ -536,13 +536,14 @@ void __init early_cpu_init(void)
 			break;
 		cpu_devs[count] = cpudev;
 		count++;
-
+#if 0
 		for (j = 0; j < 2; j++) {
 			if (!cpudev->c_ident[j])
 				continue;
 			printk("  %s %s\n", cpudev->c_vendor,
 				cpudev->c_ident[j]);
 		}
+#endif
 	}
 
 	early_identify_cpu(&boot_cpu_data);
Index: mmotm-2.6.27-rc8+/drivers/hid/usbhid/hid-core.c
===================================================================
--- mmotm-2.6.27-rc8+.orig/drivers/hid/usbhid/hid-core.c
+++ mmotm-2.6.27-rc8+/drivers/hid/usbhid/hid-core.c
@@ -414,7 +414,7 @@ void usbhid_submit_report(struct hid_dev
 
 		if ((head = (usbhid->outhead + 1) & (HID_OUTPUT_FIFO_SIZE - 1)) == usbhid->outtail) {
 			spin_unlock_irqrestore(&usbhid->outlock, flags);
-			dev_warn(hid->dev, "output queue full\n");
+			dev_warn(&hid->dev, "output queue full\n");
 			return;
 		}
 
@@ -433,7 +433,7 @@ void usbhid_submit_report(struct hid_dev
 
 	if ((head = (usbhid->ctrlhead + 1) & (HID_CONTROL_FIFO_SIZE - 1)) == usbhid->ctrltail) {
 		spin_unlock_irqrestore(&usbhid->ctrllock, flags);
-		dev_warn(hid->dev, "control queue full\n");
+		dev_warn(&hid->dev, "control queue full\n");
 		return;
 	}
 
@@ -565,7 +565,7 @@ void usbhid_init_reports(struct hid_devi
 	}
 
 	if (err)
-		dev_warn(hid->dev, "timeout initializing reports\n");
+		dev_warn(&hid->dev, "timeout initializing reports\n");
 }
 
 /*
Index: mmotm-2.6.27-rc8+/fs/autofs4/dev-ioctl.c
===================================================================
--- mmotm-2.6.27-rc8+.orig/fs/autofs4/dev-ioctl.c
+++ mmotm-2.6.27-rc8+/fs/autofs4/dev-ioctl.c
@@ -307,7 +307,7 @@ static int autofs_dev_ioctl_open_mountpo
 			goto out;
 		}
 
-		filp = dentry_open(nd.path.dentry, nd.path.mnt, O_RDONLY, NULL);
+		filp = dentry_open(nd.path.dentry, nd.path.mnt, O_RDONLY);
 		if (IS_ERR(filp)) {
 			err = PTR_ERR(filp);
 			goto out;

Re: mmotm 2008-10-02-16-17 uploaded

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> > > could be merging problem again.
> > > 
> > > please check in arch/x86/kernel/vmliux_64.lds.S
> > > 
> > > it should be like 
> > > 
> > >   __con_initcall_end = .;
> > >   __x86_cpu_dev_start = .;
> > >   .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
> > >         *(.x86_cpu_dev.init)
> > >   }
> > >   __x86_cpu_dev_end = .;
> > > 
> > >   DYN_ARRAY_INIT(8)
> > > 
> > >   SECURITY_INIT
> 
> The above is what's presently in Ingo's "tip" tree.
> 
> > Oh, yes. like this.
> > ==
> >  __con_initcall_end = .;
> >   __x86_cpu_dev_start = .;
> >   .x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
> >         *(.x86_cpu_dev.init)
> >   }
> >   SECURITY_INIT
> >   __x86_cpu_dev_end = .;
> > ==
> > 
> > I'll try next version when it comes.
> 
> If that fixes it then Ingo's tree will need fixing too, I suppose.

it should be:

  __x86_cpu_dev_end = .;

  DYN_ARRAY_INIT(8)

  SECURITY_INIT

and that's what it is in -tip. Am i missing something?

	Ingo