LinuxLists.cc - linux-next: Tree for October 14

[permalink] [raw]

Subject: Re: linux-next: Tree for October 14

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

2009-10-14 21:13:29

by Stephen Rothwell

[permalink] [raw]

Subject: Re: linux-next: Tree for October 14

Hi Randy,

On Wed, 14 Oct 2009 08:55:15 -0700 Randy Dunlap <[email protected]> wrote:
>
> Where are today's .bz2 file and the .sign files?

I only upload the .gz and some global script creates the other files
automatically. That seems to have failed sometime yesterday but someone
has fixed it, now.

> and when did pub/kernel/people/sfr/linux-next/ disappear?

/pub/linux/kernel/people/sfr/linux-next is still there (it is a symlink
to /pub/linux/kernel/v2.6/next).

> The kernel.org/kdist/finger_banner file now reports:
> The latest linux-next version of the Linux kernel is: next-20091013

That would probably be the same problem as above.

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/

Attachments:

(No filename) (763.00 B)
(No filename) (198.00 B)
Download all attachments

2009-10-14 22:13:47

[permalink] [raw]

Subject: [PATCH -next] ia64/sn: fix percpu warnings

From: Randy Dunlap <[email protected]>

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 <[email protected]>
Cc: Jes Sorensen <[email protected]>
---
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]))

2009-10-14 22:12:45

[permalink] [raw]

Subject: [PATCH -next] kvm: fix ia64 printk formats

From: Randy Dunlap <[email protected]>

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 <[email protected]>
Cc: Xiantao Zhang <[email protected]>
---
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;

2009-10-15 01:18:09

[permalink] [raw]

Subject: [PATCH -next] vmxnet: fix 2 build problems

From: Randy Dunlap <[email protected]>

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

2009-10-15 01:33:41

[permalink] [raw]

Subject: Re: [PATCH -next] ia64/sn: fix percpu warnings

Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> 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 <[email protected]>
> Cc: Jes Sorensen <[email protected]>

Acked-by: Tejun Heo <[email protected]>

Can this go through ia64 tree? If not, I can route it through
percpu#for-fixes.

Thanks.

--
tejun

2009-10-15 02:01:26

by Bhavesh Davda

[permalink] [raw]

Subject: Re: [Pv-drivers] [PATCH -next] vmxnet: fix 2 build problems

Looks great! Thanks for making this change!

Signed-off-by: Bhavesh davda <[email protected]<mailto:[email protected]>>

- 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" <[email protected]<mailto:[email protected]>> wrote:

Signed-off-by: Randy Dunlap <<mailto:[email protected]>[email protected]<mailto:[email protected]>>
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?

2009-10-15 02:33:51

by Zhang, Xiantao

[permalink] [raw]

Subject: RE: [PATCH -next] kvm: fix ia64 printk formats

Seems strict checks are applied to latest kernel. Okay to me. Thanks!
Acked-By Xiantao Zhang <[email protected]>
Xiantao

Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> 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 <[email protected]>
> Cc: Xiantao Zhang <[email protected]>
> ---
> 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;

2009-10-15 03:39:19

by David Miller

[permalink] [raw]

Subject: Re: [Pv-drivers] [PATCH -next] vmxnet: fix 2 build problems

From: Bhavesh Davda <[email protected]>
Date: Wed, 14 Oct 2009 19:00:45 -0700

> Looks great! Thanks for making this change!
>
> Signed-off-by: Bhavesh davda <[email protected]<mailto:[email protected]>>

Applied, thanks Randy.

2009-10-26 18:23:59

[permalink] [raw]

Subject: Re: [PATCH -next] ia64/sn: fix percpu warnings

> Acked-by: Tejun Heo <[email protected]>
>
> 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

2009-10-26 23:35:09

[permalink] [raw]

Subject: RE: [PATCH -next] ia64/sn: fix percpu warnings

> 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

2009-10-28 15:03:08

[permalink] [raw]

Subject: Re: [PATCH -next] ia64/sn: fix percpu warnings

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

2009-10-28 16:24:22

[permalink] [raw]

Subject: RE: [PATCH -next] ia64/sn: fix percpu warnings

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

2009-10-28 16:37:13

[permalink] [raw]

Subject: Re: [PATCH -next] ia64/sn: fix percpu warnings

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

2009-10-28 16:58:36

[permalink] [raw]

Subject: RE: [PATCH -next] ia64/sn: fix percpu warnings

> 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

2009-10-28 22:23:28

[permalink] [raw]

Subject: RE: [PATCH -next] ia64/sn: fix percpu warnings

> 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

2009-10-29 14:42:32

[permalink] [raw]

Subject: Re: [PATCH -next] ia64/sn: fix percpu warnings

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

2009-10-29 15:42:22