On Thu, 2 Oct 2008, [email protected] 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
On Thu, 2 Oct 2008 17:17:16 -0700 (PDT)
"Randy.Dunlap" <[email protected]> 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 <[email protected]>
include/linux/stacktrace.h:13: warning:
'struct task_struct' declared inside parameter list
Reported-by: "Randy.Dunlap" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Arjan van de Ven <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
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;
_
On Thu, 2 Oct 2008 17:17:16 -0700 (PDT) Randy.Dunlap wrote:
> On Thu, 2 Oct 2008, [email protected] 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
On Thu, 2 Oct 2008 20:32:30 -0700 Randy Dunlap <[email protected]> wrote:
> On Thu, 2 Oct 2008 17:17:16 -0700 (PDT) Randy.Dunlap wrote:
>
> > On Thu, 2 Oct 2008, [email protected] 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?
> 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
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
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
On Tue, 07 Oct 2008 09:18:03 -0700
Yinghai Lu <[email protected]> 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
On Wed, 8 Oct 2008 08:47:53 +0900
KAMEZAWA Hiroyuki <[email protected]> wrote:
> On Tue, 07 Oct 2008 09:18:03 -0700
> Yinghai Lu <[email protected]> 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.
On Tue, 7 Oct 2008 17:01:03 -0700
Andrew Morton <[email protected]> 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;
* Andrew Morton <[email protected]> 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