* Re: mmotm 2008-10-02-16-17 uploaded [not found] <200810022318.m92NI14X031834@imap1.linux-foundation.org> @ 2008-10-03 0:17 ` Randy.Dunlap 2008-10-03 0:45 ` Andrew Morton ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Randy.Dunlap @ 2008-10-03 0:17 UTC (permalink / raw) To: linux-kernel; +Cc: akpm 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: mmotm 2008-10-02-16-17 uploaded 2008-10-03 0:17 ` mmotm 2008-10-02-16-17 uploaded Randy.Dunlap @ 2008-10-03 0:45 ` Andrew Morton 2008-10-03 3:32 ` Randy Dunlap 2008-10-07 7:33 ` KAMEZAWA Hiroyuki 2 siblings, 0 replies; 11+ messages in thread From: Andrew Morton @ 2008-10-03 0:45 UTC (permalink / raw) To: Randy.Dunlap; +Cc: linux-kernel 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; _ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: mmotm 2008-10-02-16-17 uploaded 2008-10-03 0:17 ` mmotm 2008-10-02-16-17 uploaded Randy.Dunlap 2008-10-03 0:45 ` Andrew Morton @ 2008-10-03 3:32 ` Randy Dunlap 2008-10-03 3:37 ` Andrew Morton 2008-10-07 7:33 ` KAMEZAWA Hiroyuki 2 siblings, 1 reply; 11+ messages in thread From: Randy Dunlap @ 2008-10-03 3:32 UTC (permalink / raw) To: Randy.Dunlap; +Cc: linux-kernel, akpm 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: mmotm 2008-10-02-16-17 uploaded 2008-10-03 3:32 ` Randy Dunlap @ 2008-10-03 3:37 ` Andrew Morton 2008-10-03 3:43 ` Randy Dunlap 0 siblings, 1 reply; 11+ messages in thread From: Andrew Morton @ 2008-10-03 3:37 UTC (permalink / raw) To: Randy Dunlap; +Cc: linux-kernel 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: mmotm 2008-10-02-16-17 uploaded 2008-10-03 3:37 ` Andrew Morton @ 2008-10-03 3:43 ` Randy Dunlap 0 siblings, 0 replies; 11+ messages in thread From: Randy Dunlap @ 2008-10-03 3:43 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: mmotm 2008-10-02-16-17 uploaded 2008-10-03 0:17 ` mmotm 2008-10-02-16-17 uploaded Randy.Dunlap 2008-10-03 0:45 ` Andrew Morton 2008-10-03 3:32 ` Randy Dunlap @ 2008-10-07 7:33 ` KAMEZAWA Hiroyuki 2008-10-07 16:18 ` Yinghai Lu 2 siblings, 1 reply; 11+ messages in thread From: KAMEZAWA Hiroyuki @ 2008-10-07 7:33 UTC (permalink / raw) To: mingo@elte.hu; +Cc: linux-kernel, akpm 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: mmotm 2008-10-02-16-17 uploaded 2008-10-07 7:33 ` KAMEZAWA Hiroyuki @ 2008-10-07 16:18 ` Yinghai Lu 2008-10-07 23:47 ` KAMEZAWA Hiroyuki 0 siblings, 1 reply; 11+ messages in thread From: Yinghai Lu @ 2008-10-07 16:18 UTC (permalink / raw) To: KAMEZAWA Hiroyuki; +Cc: mingo@elte.hu, linux-kernel, akpm 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: mmotm 2008-10-02-16-17 uploaded 2008-10-07 16:18 ` Yinghai Lu @ 2008-10-07 23:47 ` KAMEZAWA Hiroyuki 2008-10-08 0:01 ` Andrew Morton 0 siblings, 1 reply; 11+ messages in thread From: KAMEZAWA Hiroyuki @ 2008-10-07 23:47 UTC (permalink / raw) To: Yinghai Lu; +Cc: mingo@elte.hu, linux-kernel, akpm 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: mmotm 2008-10-02-16-17 uploaded 2008-10-07 23:47 ` KAMEZAWA Hiroyuki @ 2008-10-08 0:01 ` Andrew Morton 2008-10-08 0:34 ` KAMEZAWA Hiroyuki 2008-10-08 9:50 ` Ingo Molnar 0 siblings, 2 replies; 11+ messages in thread From: Andrew Morton @ 2008-10-08 0:01 UTC (permalink / raw) To: KAMEZAWA Hiroyuki; +Cc: yinghai, mingo, linux-kernel 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: mmotm 2008-10-02-16-17 uploaded 2008-10-08 0:01 ` Andrew Morton @ 2008-10-08 0:34 ` KAMEZAWA Hiroyuki 2008-10-08 9:50 ` Ingo Molnar 1 sibling, 0 replies; 11+ messages in thread From: KAMEZAWA Hiroyuki @ 2008-10-08 0:34 UTC (permalink / raw) To: Andrew Morton; +Cc: yinghai, mingo, linux-kernel 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; ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: mmotm 2008-10-02-16-17 uploaded 2008-10-08 0:01 ` Andrew Morton 2008-10-08 0:34 ` KAMEZAWA Hiroyuki @ 2008-10-08 9:50 ` Ingo Molnar 1 sibling, 0 replies; 11+ messages in thread From: Ingo Molnar @ 2008-10-08 9:50 UTC (permalink / raw) To: Andrew Morton; +Cc: KAMEZAWA Hiroyuki, yinghai, linux-kernel * 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-10-08 9:50 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200810022318.m92NI14X031834@imap1.linux-foundation.org>
2008-10-03 0:17 ` mmotm 2008-10-02-16-17 uploaded Randy.Dunlap
2008-10-03 0:45 ` Andrew Morton
2008-10-03 3:32 ` Randy Dunlap
2008-10-03 3:37 ` Andrew Morton
2008-10-03 3:43 ` Randy Dunlap
2008-10-07 7:33 ` KAMEZAWA Hiroyuki
2008-10-07 16:18 ` Yinghai Lu
2008-10-07 23:47 ` KAMEZAWA Hiroyuki
2008-10-08 0:01 ` Andrew Morton
2008-10-08 0:34 ` KAMEZAWA Hiroyuki
2008-10-08 9:50 ` Ingo Molnar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).