* Re: linux-next: Tree for October 14
2009-10-14 5:34 linux-next: Tree for October 14 Stephen Rothwell
@ 2009-10-14 15:55 ` Randy Dunlap
2009-10-14 21:12 ` Stephen Rothwell
2009-10-14 22:10 ` [PATCH -next] ia64/sn: fix percpu warnings Randy Dunlap
` (2 subsequent siblings)
3 siblings, 1 reply; 20+ messages in thread
From: Randy Dunlap @ 2009-10-14 15:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
On Wed, 14 Oct 2009 16:34:45 +1100 Stephen Rothwell wrote:
> Changes since 20091013:
>
> Undropped tree: i7core_edac
>
> My fixes tree contains a build fix for powerpc/kvm.
>
> The pci tree gained a conflict against Linus' tree.
>
> The kbuild tree gained a build failure that required me to remove
> include/asm/asm-offsets.h from my object tree.
>
> The net tree lost its build failure.
>
> The percpu tree lost its build failure.
>
> The tty tree still had a build failure for which I reverted a commit.
>
> ----------------------------------------------------------------------------
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one. You should use "git fetch" as mentioned in the FAQ on the wiki
> (see below).
Hi Stephen,
Where are today's .bz2 file and the .sign files?
and when did pub/kernel/people/sfr/linux-next/ disappear?
The kernel.org/kdist/finger_banner file now reports:
The latest linux-next version of the Linux kernel is: next-20091013
instead of 20091014.
---
~Randy
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH -next] ia64/sn: fix percpu warnings
2009-10-14 5:34 linux-next: Tree for October 14 Stephen Rothwell
2009-10-14 15:55 ` Randy Dunlap
@ 2009-10-14 22:10 ` Randy Dunlap
2009-10-15 1:33 ` Tejun Heo
2009-10-14 22:10 ` [PATCH -next] kvm: fix ia64 printk formats Randy Dunlap
2009-10-15 1:17 ` [PATCH -next] vmxnet: fix 2 build problems Randy Dunlap
3 siblings, 1 reply; 20+ messages in thread
From: Randy Dunlap @ 2009-10-14 22:10 UTC (permalink / raw)
To: Stephen Rothwell, Jes Sorensen, linux-ia64, Tejun Heo
Cc: linux-next, LKML, akpm
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix percpu types warning in ia64/sn:
arch/ia64/sn/kernel/setup.c:74: error: conflicting types for '__pcpu_scope___sn_cnodeid_to_nasid'
arch/ia64/include/asm/sn/arch.h:74: error: previous declaration of '__pcpu_scope___sn_cnodeid_to_nasid' was here
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Jes Sorensen <jes@sgi.com>
---
arch/ia64/include/asm/sn/arch.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20091014.orig/arch/ia64/include/asm/sn/arch.h
+++ linux-next-20091014/arch/ia64/include/asm/sn/arch.h
@@ -71,7 +71,7 @@ DECLARE_PER_CPU(struct sn_hub_info_s, __
* Compact node ID to nasid mappings kept in the per-cpu data areas of each
* cpu.
*/
-DECLARE_PER_CPU(short, __sn_cnodeid_to_nasid[MAX_COMPACT_NODES]);
+DECLARE_PER_CPU(short [MAX_COMPACT_NODES], __sn_cnodeid_to_nasid);
#define sn_cnodeid_to_nasid (&__get_cpu_var(__sn_cnodeid_to_nasid[0]))
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-14 22:10 ` [PATCH -next] ia64/sn: fix percpu warnings Randy Dunlap
@ 2009-10-15 1:33 ` Tejun Heo
2009-10-26 18:24 ` Tony Luck
0 siblings, 1 reply; 20+ messages in thread
From: Tejun Heo @ 2009-10-15 1:33 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Jes Sorensen, linux-ia64, linux-next, LKML,
akpm
Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix percpu types warning in ia64/sn:
>
> arch/ia64/sn/kernel/setup.c:74: error: conflicting types for '__pcpu_scope___sn_cnodeid_to_nasid'
> arch/ia64/include/asm/sn/arch.h:74: error: previous declaration of '__pcpu_scope___sn_cnodeid_to_nasid' was here
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> Cc: Jes Sorensen <jes@sgi.com>
Acked-by: Tejun Heo <tj@kernel.org>
Can this go through ia64 tree? If not, I can route it through
percpu#for-fixes.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-15 1:33 ` Tejun Heo
@ 2009-10-26 18:24 ` Tony Luck
2009-10-26 23:35 ` Luck, Tony
0 siblings, 1 reply; 20+ messages in thread
From: Tony Luck @ 2009-10-26 18:24 UTC (permalink / raw)
To: Tejun Heo, Randy Dunlap
Cc: Stephen Rothwell, Jes Sorensen, linux-ia64, linux-next, LKML,
akpm
> Acked-by: Tejun Heo <tj@kernel.org>
>
> Can this go through ia64 tree? If not, I can route it through
> percpu#for-fixes.
It can ... but I'm getting a strange warning since I applied it:
Building modules, stage 2.
GZIP arch/ia64/hp/sim/boot/vmlinux.gz
MODPOST 198 modules
WARNING: "per_cpu____sn_cnodeid_to_nasid" [drivers/misc/sgi-xp/xpc.ko]
has no CRC!
Any idea what this means?
-Tony
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-26 18:24 ` Tony Luck
@ 2009-10-26 23:35 ` Luck, Tony
2009-10-28 15:03 ` Tejun Heo
0 siblings, 1 reply; 20+ messages in thread
From: Luck, Tony @ 2009-10-26 23:35 UTC (permalink / raw)
To: Tejun Heo, Randy Dunlap
Cc: Stephen Rothwell, Jes Sorensen, linux-ia64@vger.kernel.org,
linux-next@vger.kernel.org, LKML, akpm
> WARNING: "per_cpu____sn_cnodeid_to_nasid" [drivers/misc/sgi-xp/xpc.ko] has no CRC!
Note that this warning goes away if I fix the mismatch declaration so
that we have:
DECLARE_PER_CPU(short, __sn_cnodeide_to_nasid[MAX_COMPACT_NODES]);
in arch.h
and
DEFINE_PER_CPU(short, __sn_cnodeide_to_nasid[MAX_COMPACT_NODES]);
in setup.c
-Tony
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-26 23:35 ` Luck, Tony
@ 2009-10-28 15:03 ` Tejun Heo
2009-10-28 16:24 ` Luck, Tony
0 siblings, 1 reply; 20+ messages in thread
From: Tejun Heo @ 2009-10-28 15:03 UTC (permalink / raw)
To: Luck, Tony
Cc: Randy Dunlap, Stephen Rothwell, Jes Sorensen,
linux-ia64@vger.kernel.org, linux-next@vger.kernel.org, LKML,
akpm
Hello,
Luck, Tony wrote:
>> WARNING: "per_cpu____sn_cnodeid_to_nasid" [drivers/misc/sgi-xp/xpc.ko] has no CRC!
>
> Note that this warning goes away if I fix the mismatch declaration so
> that we have:
>
> DECLARE_PER_CPU(short, __sn_cnodeide_to_nasid[MAX_COMPACT_NODES]);
> in arch.h
>
> and
>
> DEFINE_PER_CPU(short, __sn_cnodeide_to_nasid[MAX_COMPACT_NODES]);
> in setup.c
Umm... the correct correct declaration and definition would be
DECLARE_PER_CPU(short [MAX_COMPACT_NODES], __sn_cnodeide_to_nasid);
and
DEFINE_PER_CPU(short [MAX_COMPACT_NODES], __sn_cnodeide_to_nasid);
So that the first part contains full type. Doing it the other way
might cause problems if the __weak trick is turned on.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-28 15:03 ` Tejun Heo
@ 2009-10-28 16:24 ` Luck, Tony
2009-10-28 16:37 ` Tejun Heo
0 siblings, 1 reply; 20+ messages in thread
From: Luck, Tony @ 2009-10-28 16:24 UTC (permalink / raw)
To: Tejun Heo
Cc: Randy Dunlap, Stephen Rothwell, linux-ia64@vger.kernel.org,
linux-next@vger.kernel.org, LKML, akpm
> Umm... the correct correct declaration and definition would be
>
> DECLARE_PER_CPU(short [MAX_COMPACT_NODES], __sn_cnodeide_to_nasid);
>
> and
>
> DEFINE_PER_CPU(short [MAX_COMPACT_NODES], __sn_cnodeide_to_nasid);
>
> So that the first part contains full type. Doing it the other way
> might cause problems if the __weak trick is turned on.
That's what Randy's patch uses ... but doing it the "right" way gives
me the "has no CRC!" warning.
This seems to be a feature of exported per cpu arrays. If I hack
up a driver to make use of softirq_work_list, I see a similar
no CRC warning for it.
Is this problem in the ia64 tool chain[1]? Or do other architectures
have problems with exported per cpu arrays?
-Tony
[1] My default toolchain is uses gcc 4.1.2. But 4.4.1 has the same
behavior.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-28 16:24 ` Luck, Tony
@ 2009-10-28 16:37 ` Tejun Heo
2009-10-28 16:58 ` Luck, Tony
0 siblings, 1 reply; 20+ messages in thread
From: Tejun Heo @ 2009-10-28 16:37 UTC (permalink / raw)
To: Luck, Tony
Cc: Randy Dunlap, Stephen Rothwell, linux-ia64@vger.kernel.org,
linux-next@vger.kernel.org, LKML, akpm
Hello,
Luck, Tony wrote:
> That's what Randy's patch uses ... but doing it the "right" way gives
> me the "has no CRC!" warning.
Ah, right. I got confused.
> This seems to be a feature of exported per cpu arrays. If I hack
> up a driver to make use of softirq_work_list, I see a similar
> no CRC warning for it.
>
> Is this problem in the ia64 tool chain[1]? Or do other architectures
> have problems with exported per cpu arrays?
kern/softirq.c has the followings.
DEFINE_PER_CPU(struct list_head [NR_SOFTIRQS], softirq_work_list);
EXPORT_PER_CPU_SYMBOL(softirq_work_list);
and it doesn't cause any warning on x86 neither does it on ia64 with
defconfig. softirq_work_list doesn't trigger any warning there,
right?
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-28 16:37 ` Tejun Heo
@ 2009-10-28 16:58 ` Luck, Tony
2009-10-28 22:23 ` Luck, Tony
0 siblings, 1 reply; 20+ messages in thread
From: Luck, Tony @ 2009-10-28 16:58 UTC (permalink / raw)
To: Tejun Heo
Cc: Randy Dunlap, Stephen Rothwell, linux-ia64@vger.kernel.org,
linux-next@vger.kernel.org, LKML, akpm
> DEFINE_PER_CPU(struct list_head [NR_SOFTIRQS], softirq_work_list);
> EXPORT_PER_CPU_SYMBOL(softirq_work_list);
>
> and it doesn't cause any warning on x86 neither does it on ia64 with
> defconfig. softirq_work_list doesn't trigger any warning there,
> right?
Of the 10 EXPORT_PER_CPU_SYMBOL and 4 EXPORT_PER_CPU_SYMBOL_GPL
items on ia64, only __sn_cnodeid_to_nasid and softirq_work_list are
arrays. The latter appears not to be actually used by any in-tree
modules (janitors: does it need to be exported?).
The CRC warning only shows up on a module that uses an exported
per-cpu array. There seems to be nothing special about the
__sn_cnodeid_to_nasid. When I hacked a module to make a random
use of softirq_work_list, it too gave a CRC error.
I just tried an x86_64 build with a module also modified to access
softirq_work_list. It did NOT get a CRC error. So the x86_64
toolchain doesn't seem to have the same issue as ia64.
-Tony
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-28 16:58 ` Luck, Tony
@ 2009-10-28 22:23 ` Luck, Tony
2009-10-29 14:43 ` Tejun Heo
0 siblings, 1 reply; 20+ messages in thread
From: Luck, Tony @ 2009-10-28 22:23 UTC (permalink / raw)
To: Tejun Heo
Cc: Randy Dunlap, Stephen Rothwell, linux-ia64@vger.kernel.org,
linux-next@vger.kernel.org, LKML, akpm
> I just tried an x86_64 build with a module also modified to access
> softirq_work_list. It did NOT get a CRC error. So the x86_64
> toolchain doesn't seem to have the same issue as ia64.
Ok. x86 doesn't see this because the defconfig has
CONFIG_MODVERSIONS is not set
If I turn MODVERSION off, then the problem disappears for me.
If I turn MODVERSIONS on for x86 (and fudge a driver to make use of
softirq_work_list), then x86 gets the CRC warning too.
So this isn't a tool chain problem. Neither x86 nor ia64
can handle exported per-cpu array objects when CONFIG_MODVERSIONS
is set.
Looking at the __crc symbols in the vmlinux for x86 with
CONFIG_MODVERSIONS=y I see:
000000006dcaeb88 A __crc_per_cpu__kernel_stack
00000000b3994c7a A __crc_per_cpu__kstat
00000000d917c158 A __crc_per_cpu__node_number
w __crc_per_cpu__softirq_work_list
0000000036a1f502 A __crc_per_cpu__softnet_data
0000000057adf756 A __crc_per_cpu__this_cpu_off
which explains why "modpost" is unable to find a CRC.
Maybe the comments in <linux/module.h> are supposed to be a
clue? :
#ifdef CONFIG_MODVERSIONS
/* Mark the CRC weak since genksyms apparently decides not to
* generate a checksums for some symbols */
#define __CRC_SYMBOL(sym, sec) \
extern void *__crc_##sym __attribute__((weak)); \
static const unsigned long __kcrctab_##sym \
__used \
__attribute__((section("__kcrctab" sec), unused)) \
= (unsigned long) &__crc_##sym;
But not enough of a clue for me :-(
-Tony
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-28 22:23 ` Luck, Tony
@ 2009-10-29 14:43 ` Tejun Heo
2009-10-29 15:43 ` Tejun Heo
0 siblings, 1 reply; 20+ messages in thread
From: Tejun Heo @ 2009-10-29 14:43 UTC (permalink / raw)
To: Luck, Tony
Cc: Randy Dunlap, Stephen Rothwell, linux-ia64@vger.kernel.org,
linux-next@vger.kernel.org, LKML, akpm
Hello,
Luck, Tony wrote:
> Ok. x86 doesn't see this because the defconfig has
> CONFIG_MODVERSIONS is not set
>
> If I turn MODVERSION off, then the problem disappears for me.
>
> If I turn MODVERSIONS on for x86 (and fudge a driver to make use of
> softirq_work_list), then x86 gets the CRC warning too.
Right, I can reproduce it here too.
> So this isn't a tool chain problem. Neither x86 nor ia64
> can handle exported per-cpu array objects when CONFIG_MODVERSIONS
> is set.
>
> Looking at the __crc symbols in the vmlinux for x86 with
> CONFIG_MODVERSIONS=y I see:
>
> 000000006dcaeb88 A __crc_per_cpu__kernel_stack
> 00000000b3994c7a A __crc_per_cpu__kstat
> 00000000d917c158 A __crc_per_cpu__node_number
> w __crc_per_cpu__softirq_work_list
> 0000000036a1f502 A __crc_per_cpu__softnet_data
> 0000000057adf756 A __crc_per_cpu__this_cpu_off
>
> which explains why "modpost" is unable to find a CRC.
>
> Maybe the comments in <linux/module.h> are supposed to be a
> clue? :
>
> #ifdef CONFIG_MODVERSIONS
> /* Mark the CRC weak since genksyms apparently decides not to
> * generate a checksums for some symbols */
> #define __CRC_SYMBOL(sym, sec) \
> extern void *__crc_##sym __attribute__((weak)); \
> static const unsigned long __kcrctab_##sym \
> __used \
> __attribute__((section("__kcrctab" sec), unused)) \
> = (unsigned long) &__crc_##sym;
>
> But not enough of a clue for me :-(
I have no idea either. I'll dig a bit and try to find out what's
going on.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-29 14:43 ` Tejun Heo
@ 2009-10-29 15:43 ` Tejun Heo
2009-10-30 16:05 ` Jan Beulich
0 siblings, 1 reply; 20+ messages in thread
From: Tejun Heo @ 2009-10-29 15:43 UTC (permalink / raw)
To: Luck, Tony
Cc: Randy Dunlap, Stephen Rothwell, linux-ia64@vger.kernel.org,
linux-next@vger.kernel.org, LKML, akpm, Sam Ravnborg,
Andreas Gruenbacher, Jan Beulich
Yiee... lexer/parser problem in genksyms. cc'ing Andreas, Sam and Jan
for help and quoting whole body.
Hello,
Tejun Heo wrote:
> Hello,
>
> Luck, Tony wrote:
>> Ok. x86 doesn't see this because the defconfig has
>> CONFIG_MODVERSIONS is not set
>>
>> If I turn MODVERSION off, then the problem disappears for me.
>>
>> If I turn MODVERSIONS on for x86 (and fudge a driver to make use of
>> softirq_work_list), then x86 gets the CRC warning too.
>
> Right, I can reproduce it here too.
>
>> So this isn't a tool chain problem. Neither x86 nor ia64
>> can handle exported per-cpu array objects when CONFIG_MODVERSIONS
>> is set.
>>
>> Looking at the __crc symbols in the vmlinux for x86 with
>> CONFIG_MODVERSIONS=y I see:
>>
>> 000000006dcaeb88 A __crc_per_cpu__kernel_stack
>> 00000000b3994c7a A __crc_per_cpu__kstat
>> 00000000d917c158 A __crc_per_cpu__node_number
>> w __crc_per_cpu__softirq_work_list
>> 0000000036a1f502 A __crc_per_cpu__softnet_data
>> 0000000057adf756 A __crc_per_cpu__this_cpu_off
>>
>> which explains why "modpost" is unable to find a CRC.
>>
>> Maybe the comments in <linux/module.h> are supposed to be a
>> clue? :
>>
>> #ifdef CONFIG_MODVERSIONS
>> /* Mark the CRC weak since genksyms apparently decides not to
>> * generate a checksums for some symbols */
>> #define __CRC_SYMBOL(sym, sec) \
>> extern void *__crc_##sym __attribute__((weak)); \
>> static const unsigned long __kcrctab_##sym \
>> __used \
>> __attribute__((section("__kcrctab" sec), unused)) \
>> = (unsigned long) &__crc_##sym;
>>
>> But not enough of a clue for me :-(
>
> I have no idea either. I'll dig a bit and try to find out what's
> going on.
So, the problem is that genksyms can't understand the following.
__typeof__(int [10]) my_ar;
EXPORT_SYMBOL(my_ar);
Would it be difficult to teach it how to parse it?
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH -next] ia64/sn: fix percpu warnings
2009-10-29 15:43 ` Tejun Heo
@ 2009-10-30 16:05 ` Jan Beulich
0 siblings, 0 replies; 20+ messages in thread
From: Jan Beulich @ 2009-10-30 16:05 UTC (permalink / raw)
To: Tony Luck, Tejun Heo
Cc: Stephen Rothwell, akpm, Randy Dunlap, Sam Ravnborg,
Andreas Gruenbacher, linux-ia64@vger.kernel.org, LKML,
linux-next@vger.kernel.org
>>> Tejun Heo <tj@kernel.org> 29.10.09 16:43 >>>
>So, the problem is that genksyms can't understand the following.
>
> __typeof__(int [10]) my_ar;
> EXPORT_SYMBOL(my_ar);
In fact almost no use of typeof() works with genksyms: Out of
#include <linux/module.h>
extern int x;
#define export(t, n) typeof(t) export_##n; EXPORT_SYMBOL(export_##n)
export(x, a);
export(&x, b);
export(int, c);
export(int*, d);
export(int**, e);
export(int[4], f);
export(typeof(x), g);
export(typeof(&x), h);
export(typeof(x)*, i);
only c and d get a non-zero CRC. This is clearly due to the naive parsing
scripts/genksyms/parse.y does:
type_specifier:
simple_type_specifier
| cvar_qualifier
| TYPEOF_KEYW '(' decl_specifier_seq '*' ')'
| TYPEOF_KEYW '(' decl_specifier_seq ')'
...
>Would it be difficult to teach it how to parse it?
For someone familiar with bison/yacc this would seem not very difficult
a job, but as far as I'm concerned this is not something I would feel
comfortable trying to fix. Of course one could go the simplistic route
and just add the array case here, but imo this wouldn't be the right
way to deal with it.
Jan
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH -next] kvm: fix ia64 printk formats
2009-10-14 5:34 linux-next: Tree for October 14 Stephen Rothwell
2009-10-14 15:55 ` Randy Dunlap
2009-10-14 22:10 ` [PATCH -next] ia64/sn: fix percpu warnings Randy Dunlap
@ 2009-10-14 22:10 ` Randy Dunlap
2009-10-15 2:32 ` Zhang, Xiantao
2009-10-15 1:17 ` [PATCH -next] vmxnet: fix 2 build problems Randy Dunlap
3 siblings, 1 reply; 20+ messages in thread
From: Randy Dunlap @ 2009-10-14 22:10 UTC (permalink / raw)
To: Stephen Rothwell, Xiantao Zhang; +Cc: linux-next, LKML, kvm-ia64, akpm
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix printk formats in ia64/kvm:
arch/ia64/kvm/kvm-ia64.c:250: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'uint64_t'
arch/ia64/kvm/kvm-ia64.c:774: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'uint64_t'
arch/ia64/kvm/kvm_fw.c:151: warning: format '%ld' expects type 'long int', but argument 3 has type 's64'
arch/ia64/kvm/kvm_fw.c:151: warning: format '%lx' expects type 'long unsigned int', but argument 4 has type 'u64'
arch/ia64/kvm/kvm_fw.c:151: warning: format '%lx' expects type 'long unsigned int', but argument 5 has type 'u64'
arch/ia64/kvm/kvm_fw.c:548: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'u64'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Xiantao Zhang <xiantao.zhang@intel.com>
---
arch/ia64/kvm/kvm-ia64.c | 4 ++--
arch/ia64/kvm/kvm_fw.c | 9 +++++----
2 files changed, 7 insertions(+), 6 deletions(-)
--- linux-next-20091014.orig/arch/ia64/kvm/kvm-ia64.c
+++ linux-next-20091014/arch/ia64/kvm/kvm-ia64.c
@@ -247,7 +247,7 @@ mmio:
r = kvm_io_bus_write(&vcpu->kvm->mmio_bus, p->addr,
p->size, &p->data);
if (r)
- printk(KERN_ERR"kvm: No iodevice found! addr:%lx\n", p->addr);
+ printk(KERN_ERR "kvm: No iodevice found! addr:%llx\n", p->addr);
p->state = STATE_IORESP_READY;
return 1;
@@ -771,7 +771,7 @@ static struct kvm *kvm_alloc_kvm(void)
kvm = (struct kvm *)(vm_base +
offsetof(struct kvm_vm_data, kvm_vm_struct));
kvm->arch.vm_base = vm_base;
- printk(KERN_DEBUG"kvm: vm's data area:0x%lx\n", vm_base);
+ printk(KERN_DEBUG "kvm: vm's data area:0x%llx\n", vm_base);
return kvm;
}
--- linux-next-20091014.orig/arch/ia64/kvm/kvm_fw.c
+++ linux-next-20091014/arch/ia64/kvm/kvm_fw.c
@@ -146,9 +146,10 @@ static struct ia64_pal_retval pal_cache_
&result.v0);
local_irq_restore(psr);
if (result.status != 0)
- printk(KERN_ERR"vcpu:%p crashed due to cache_flush err:%ld"
+ printk(KERN_ERR "vcpu:%p crashed due to cache_flush err:%ld"
"in1:%lx,in2:%lx\n",
- vcpu, result.status, gr29, gr30);
+ vcpu, (long)result.status,
+ (unsigned long)gr29, (unsigned long)gr30);
#if 0
if (gr29 == PAL_CACHE_TYPE_COHERENT) {
@@ -544,8 +545,8 @@ int kvm_pal_emul(struct kvm_vcpu *vcpu,
break;
default:
INIT_PAL_STATUS_UNIMPLEMENTED(result);
- printk(KERN_WARNING"kvm: Unsupported pal call,"
- " index:0x%lx\n", gr28);
+ printk(KERN_WARNING "kvm: Unsupported pal call,"
+ " index:0x%lx\n", (unsigned long)gr28);
}
set_pal_result(vcpu, result);
return ret;
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: [PATCH -next] kvm: fix ia64 printk formats
2009-10-14 22:10 ` [PATCH -next] kvm: fix ia64 printk formats Randy Dunlap
@ 2009-10-15 2:32 ` Zhang, Xiantao
0 siblings, 0 replies; 20+ messages in thread
From: Zhang, Xiantao @ 2009-10-15 2:32 UTC (permalink / raw)
To: Randy Dunlap, Stephen Rothwell
Cc: linux-next@vger.kernel.org, LKML, kvm-ia64@vger.kernel.org, akpm
Seems strict checks are applied to latest kernel. Okay to me. Thanks!
Acked-By Xiantao Zhang <xiantao.zhang@intel.com>
Xiantao
Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix printk formats in ia64/kvm:
>
> arch/ia64/kvm/kvm-ia64.c:250: warning: format '%lx' expects type
> 'long unsigned int', but argument 2 has type 'uint64_t'
> arch/ia64/kvm/kvm-ia64.c:774: warning: format '%lx' expects type
> 'long unsigned int', but argument 2 has type 'uint64_t'
> arch/ia64/kvm/kvm_fw.c:151: warning: format '%ld' expects type 'long
> int', but argument 3 has type 's64' arch/ia64/kvm/kvm_fw.c:151:
> warning: format '%lx' expects type 'long unsigned int', but argument
> 4 has type 'u64' arch/ia64/kvm/kvm_fw.c:151: warning: format '%lx'
> expects type 'long unsigned int', but argument 5 has type 'u64'
> arch/ia64/kvm/kvm_fw.c:548: warning: format '%lx' expects type 'long
> unsigned int', but argument 2 has type 'u64'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> Cc: Xiantao Zhang <xiantao.zhang@intel.com>
> ---
> arch/ia64/kvm/kvm-ia64.c | 4 ++--
> arch/ia64/kvm/kvm_fw.c | 9 +++++----
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> --- linux-next-20091014.orig/arch/ia64/kvm/kvm-ia64.c
> +++ linux-next-20091014/arch/ia64/kvm/kvm-ia64.c
> @@ -247,7 +247,7 @@ mmio:
> r = kvm_io_bus_write(&vcpu->kvm->mmio_bus, p->addr,
> p->size, &p->data);
> if (r)
> - printk(KERN_ERR"kvm: No iodevice found! addr:%lx\n", p->addr);
> + printk(KERN_ERR "kvm: No iodevice found! addr:%llx\n", p->addr);
> p->state = STATE_IORESP_READY;
>
> return 1;
> @@ -771,7 +771,7 @@ static struct kvm *kvm_alloc_kvm(void)
> kvm = (struct kvm *)(vm_base +
> offsetof(struct kvm_vm_data, kvm_vm_struct));
> kvm->arch.vm_base = vm_base;
> - printk(KERN_DEBUG"kvm: vm's data area:0x%lx\n", vm_base);
> + printk(KERN_DEBUG "kvm: vm's data area:0x%llx\n", vm_base);
>
> return kvm;
> }
> --- linux-next-20091014.orig/arch/ia64/kvm/kvm_fw.c
> +++ linux-next-20091014/arch/ia64/kvm/kvm_fw.c
> @@ -146,9 +146,10 @@ static struct ia64_pal_retval pal_cache_
> &result.v0);
> local_irq_restore(psr);
> if (result.status != 0)
> - printk(KERN_ERR"vcpu:%p crashed due to cache_flush err:%ld"
> + printk(KERN_ERR "vcpu:%p crashed due to cache_flush err:%ld"
> "in1:%lx,in2:%lx\n",
> - vcpu, result.status, gr29, gr30);
> + vcpu, (long)result.status,
> + (unsigned long)gr29, (unsigned long)gr30);
>
> #if 0
> if (gr29 == PAL_CACHE_TYPE_COHERENT) {
> @@ -544,8 +545,8 @@ int kvm_pal_emul(struct kvm_vcpu *vcpu,
> break;
> default:
> INIT_PAL_STATUS_UNIMPLEMENTED(result);
> - printk(KERN_WARNING"kvm: Unsupported pal call,"
> - " index:0x%lx\n", gr28);
> + printk(KERN_WARNING "kvm: Unsupported pal call,"
> + " index:0x%lx\n", (unsigned long)gr28);
> }
> set_pal_result(vcpu, result);
> return ret;
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH -next] vmxnet: fix 2 build problems
2009-10-14 5:34 linux-next: Tree for October 14 Stephen Rothwell
` (2 preceding siblings ...)
2009-10-14 22:10 ` [PATCH -next] kvm: fix ia64 printk formats Randy Dunlap
@ 2009-10-15 1:17 ` Randy Dunlap
2009-10-15 2:00 ` [Pv-drivers] " Bhavesh Davda
3 siblings, 1 reply; 20+ messages in thread
From: Randy Dunlap @ 2009-10-15 1:17 UTC (permalink / raw)
To: Stephen Rothwell, netdev, Shreyas Bhatewara
Cc: linux-next, LKML, davem, pv-drivers
From: Randy Dunlap <randy.dunlap@oracle.com>
vmxnet3 uses in_dev* interfaces so it should depend on INET.
Also fix so that the driver builds when CONFIG_PCI_MSI is disabled.
vmxnet3_drv.c:(.text+0x2a88cb): undefined reference to `in_dev_finish_destroy'
drivers/net/vmxnet3/vmxnet3_drv.c:1335: error: 'struct vmxnet3_intr' has no member named 'msix_entries'
drivers/net/vmxnet3/vmxnet3_drv.c:1384: error: 'struct vmxnet3_intr' has no member named 'msix_entries'
drivers/net/vmxnet3/vmxnet3_drv.c:2137: error: 'struct vmxnet3_intr' has no member named 'msix_entries'
drivers/net/vmxnet3/vmxnet3_drv.c:2138: error: 'struct vmxnet3_intr' has no member named 'msix_entries'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/net/Kconfig | 2 +-
drivers/net/vmxnet3/vmxnet3_drv.c | 11 ++++++++++-
2 files changed, 11 insertions(+), 2 deletions(-)
--- linux-next-20091014.orig/drivers/net/vmxnet3/vmxnet3_drv.c
+++ linux-next-20091014/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -1314,9 +1314,11 @@ vmxnet3_netpoll(struct net_device *netde
struct vmxnet3_adapter *adapter = netdev_priv(netdev);
int irq;
+#ifdef CONFIG_PCI_MSI
if (adapter->intr.type == VMXNET3_IT_MSIX)
irq = adapter->intr.msix_entries[0].vector;
else
+#endif
irq = adapter->pdev->irq;
disable_irq(irq);
@@ -1330,12 +1332,15 @@ vmxnet3_request_irqs(struct vmxnet3_adap
{
int err;
+#ifdef CONFIG_PCI_MSI
if (adapter->intr.type == VMXNET3_IT_MSIX) {
/* we only use 1 MSI-X vector */
err = request_irq(adapter->intr.msix_entries[0].vector,
vmxnet3_intr, 0, adapter->netdev->name,
adapter->netdev);
- } else if (adapter->intr.type == VMXNET3_IT_MSI) {
+ } else
+#endif
+ if (adapter->intr.type == VMXNET3_IT_MSI) {
err = request_irq(adapter->pdev->irq, vmxnet3_intr, 0,
adapter->netdev->name, adapter->netdev);
} else {
@@ -1376,6 +1381,7 @@ vmxnet3_free_irqs(struct vmxnet3_adapter
adapter->intr.num_intrs <= 0);
switch (adapter->intr.type) {
+#ifdef CONFIG_PCI_MSI
case VMXNET3_IT_MSIX:
{
int i;
@@ -1385,6 +1391,7 @@ vmxnet3_free_irqs(struct vmxnet3_adapter
adapter->netdev);
break;
}
+#endif
case VMXNET3_IT_MSI:
free_irq(adapter->pdev->irq, adapter->netdev);
break;
@@ -2134,6 +2141,7 @@ vmxnet3_alloc_intr_resources(struct vmxn
if (adapter->intr.type == VMXNET3_IT_AUTO) {
int err;
+#ifdef CONFIG_PCI_MSI
adapter->intr.msix_entries[0].entry = 0;
err = pci_enable_msix(adapter->pdev, adapter->intr.msix_entries,
VMXNET3_LINUX_MAX_MSIX_VECT);
@@ -2142,6 +2150,7 @@ vmxnet3_alloc_intr_resources(struct vmxn
adapter->intr.type = VMXNET3_IT_MSIX;
return;
}
+#endif
err = pci_enable_msi(adapter->pdev);
if (!err) {
--- linux-next-20091014.orig/drivers/net/Kconfig
+++ linux-next-20091014/drivers/net/Kconfig
@@ -3232,7 +3232,7 @@ config VIRTIO_NET
config VMXNET3
tristate "VMware VMXNET3 ethernet driver"
- depends on PCI && X86
+ depends on PCI && X86 && INET
help
This driver supports VMware's vmxnet3 virtual ethernet NIC.
To compile this driver as a module, choose M here: the
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [Pv-drivers] [PATCH -next] vmxnet: fix 2 build problems
2009-10-15 1:17 ` [PATCH -next] vmxnet: fix 2 build problems Randy Dunlap
@ 2009-10-15 2:00 ` Bhavesh Davda
2009-10-15 3:39 ` David Miller
0 siblings, 1 reply; 20+ messages in thread
From: Bhavesh Davda @ 2009-10-15 2:00 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, netdev, Shreyas Bhatewara,
pv-drivers@vmware.com, linux-next@vger.kernel.org, LKML,
davem@davemloft.net
Looks great! Thanks for making this change!
Signed-off-by: Bhavesh davda <bhavesh@vmware.com<mailto:bhavesh@vmware.com>>
- Bhavesh
I'm usually not as bad with my spelling as my iPhone makes it appear.
On Oct 14, 2009, at 6:18 PM, "Randy Dunlap" <randy.dunlap@oracle.com<mailto:randy.dunlap@oracle.com>> wrote:
Signed-off-by: Randy Dunlap <<mailto:randy.dunlap@oracle.com>randy.dunlap@oracle.com<mailto:randy.dunlap@oracle.com>>
^ permalink raw reply [flat|nested] 20+ messages in thread