* linux-next: manual merge of the trivial tree with the tree
From: Stephen Rothwell @ 2009-11-09 4:43 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-next, linux-kernel, Thadeu Lima de Souza Cascardo,
Bartlomiej Zolnierkiewicz, John W. Linville
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
drivers/net/wireless/rt2x00/rt2800usb.c between commit
fcf5154118849cca3cdf424e83f863225d8173e7 ("rt2800: add rt2800lib (part
three)") from the wireless tree and commit
305409a25f7df3c359ba67cbeb62763eeb7156e9 ("tree-wide: fix some typos and
punctuation in comments") from the trivial tree.
The misspelling is moved to a new file
(drivers/net/wireless/rt2x00/rt2800lib.c), but I didn't bother fixing it up.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build failure
From: David Miller @ 2009-11-09 4:41 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, arnd
In-Reply-To: <20091109132151.0e0ec7bc.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 9 Nov 2009 13:21:51 +1100
> Subject: [PATCH] net/appletalk: using compat_ptr needs inclusion of linux/compat.h
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks Stephen.
^ permalink raw reply
* linux-next: pcmcia tree build warning
From: Stephen Rothwell @ 2009-11-09 3:54 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
Hi Dominik,
Today's linux-next build (x86_64 allmodconfig) produced this warning:
drivers/char/pcmcia/cm4000_cs.c: In function 'cmm_ioctl':
/scratch/sfr/next/drivers/char/pcmcia/cm4000_cs.c:1630: warning: the frame size of 2176 bytes is larger than 2048 bytes
Introduced by commit 7194198b163c83725f52ce8e34b24cca053deea7 ("pcmcia:
use dynamic debug infrastructure, deprecate CS_CHECK (char)") which
unconditionalised "char *ioctl_names[CM_IOC_MAXNR + 1]" on the stack.
CM_IOC_MAXNR is 255, so this adds 2k to the stack frame just to allow the
printing of one of five ioctl names in a debug message. It could be made
static ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* linux-next: manual merge of the pcmcia tree with the mtd tree
From: Stephen Rothwell @ 2009-11-09 3:42 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: linux-next, linux-kernel, David Woodhouse
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
Hi Dominik,
Today's linux-next merge of the pcmcia tree got a conflict in
drivers/mtd/maps/pcmciamtd.c between commit
5da6bbe2f9e1db56b4a94cad2ace7d9992b1d666 ("pcmcia: convert pcmciamtd
driver to use new CIS helpers") from the mtd tree and commit
18b61b97294dad74dd00a1aa8efed0cfacb95aff ("pcmcia: convert pcmciamtd
driver to use new CIS helpers") from the pcmcia tree.
Presumably two different versions of the same change? I just used the
version from the pcmcia tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* linux-next: net tree build failure
From: Stephen Rothwell @ 2009-11-09 2:21 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: linux-next, linux-kernel, Arnd Bergmann
Hi all,
Today's linux-next build (x86_64 allmodconfig) failed like this:
net/appletalk/ddp.c: In function 'atalk_compat_ioctl':
net/appletalk/ddp.c:1866: error: implicit declaration of function 'compat_ptr'
Caused by commit 206602217747382488fcae68351673cc9103debc
("appletalk: handle SIOCATALKDIFADDR compat ioctl").
I applied this patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 9 Nov 2009 13:11:26 +1100
Subject: [PATCH] net/appletalk: using compat_ptr needs inclusion of linux/compat.h
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/appletalk/ddp.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index b631cc7..73ca4d5 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -56,6 +56,7 @@
#include <linux/if_arp.h>
#include <linux/smp_lock.h>
#include <linux/termios.h> /* For TIOCOUTQ/INQ */
+#include <linux/compat.h>
#include <net/datalink.h>
#include <net/psnap.h>
#include <net/sock.h>
--
1.6.5.2
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2009-11-09 2:03 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Wolfgang Grandegger, Sebastian Haas
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/can/usb/ems_usb.c between commit
2b2072e902848a63168570f500a5726744b3873a ("ems_usb: Fix byte order issues
on big endian machines") from the net-current tree and commit
7b6856a0296a8f187bb88ba31fa83a08abba7966 ("can: provide library functions
for skb allocation") from the net tree.
Just context changes. I fixed it up (see below) and can carry the fix
for a while.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/can/usb/ems_usb.c
index abdbd9c,3685f3e..0000000
--- a/drivers/net/can/usb/ems_usb.c
+++ b/drivers/net/can/usb/ems_usb.c
@@@ -315,11 -315,7 +315,7 @@@ static void ems_usb_rx_can_msg(struct e
if (skb == NULL)
return;
- skb->protocol = htons(ETH_P_CAN);
-
- cf = (struct can_frame *)skb_put(skb, sizeof(struct can_frame));
-
- cf->can_id = msg->msg.can_msg.id;
+ cf->can_id = le32_to_cpu(msg->msg.can_msg.id);
cf->can_dlc = min_t(u8, msg->msg.can_msg.length, 8);
if (msg->type == CPC_MSG_TYPE_EXT_CAN_FRAME
^ permalink raw reply
* Re: linux-next: tip tree build warning
From: Stephen Rothwell @ 2009-11-08 23:39 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel
In-Reply-To: <20091108131645.GD5300@lenovo>
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]
Hi Cyril,
On Sun, 8 Nov 2009 16:16:45 +0300 Cyrill Gorcunov <gorcunov@openvz.org> wrote:
>
> (Btw, Stephen could you CC me next time if you get commit id
> with me in authors, so I wouldn't miss problem).
Yeah, sorry about that - at the time I didn't know if this was caused
directly by your commit or was just a side effect of some some other tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* linux-next: limits tree fetch failure
From: Stephen Rothwell @ 2009-11-08 23:30 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
Hi Jiri,
Today's linux-next fetch of the limits tree produced this error:
decibel.fi.muni.cz[0: 147.251.50.163]: errno=Connection timed out
fatal: unable to connect a socket (Connection timed out)
I will use the version of the tree from next-20091106.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* linux-next: device-mapper quilt series fetch failure
From: Stephen Rothwell @ 2009-11-08 23:26 UTC (permalink / raw)
To: Alasdair G Kergon; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
Hi Alasdair,
Today's fetch of the device-mapper tree produced this error:
device-mapper: quilt
receiving incremental file list
rsync: change_dir "/pub/linux/kernel/people/agk/patches/2.6/editing/" failed: Permission denied (13)
(I rsync this directly from master.kernel.org.)
I will use the version of the tree from next-20091106.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: linux-next: tip tree build warning
From: Cyrill Gorcunov @ 2009-11-08 21:30 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Maciej W. Rozycki, Yinghai Lu
In-Reply-To: <20091028075012.GD19402@elte.hu>
[Ingo Molnar - Wed, Oct 28, 2009 at 08:50:12AM +0100]
|
| * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
|
| > Hi all,
| >
| > On Wed, 28 Oct 2009 18:41:26 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
| > >
| > > static inline physid_mask_t default_apicid_to_cpu_present(int phys_apicid)
| > > {
| > > return physid_mask_of_physid(phys_apicid);
| > > }
| >
| > I just noticed that this function (default_apicid_to_cpu_present) is
| > declared "static inline in a header" but looks like it is only used by
| > assigning its address to a function pointer. Its only use for x86_64
| > is in arch/x86/kernel/apic/apic_noop.c ...
|
| yes, that might be a real problem - returning the mask like that is
| messy. Thanks, will check.
|
| Ingo
|
ok, here is what I've just cooked. Please review, I've CC'ed a few
"knowing-apic-code-quite-well" persons just to be sure.
Note that we still have a few items in "struct apic" which
operate with physid_mask_t on stack.
I think perhaps it's a good idea to touch this data via pointers
povided by caller:
physid_mask_t (*ioapic_phys_id_map)(physid_mask_t map);
I didn't manage to cover it today -- will do tomorrow if patch
approach would be approved.
Also, it's just warning (yet) since we don't use those routines
in x86-64 so it doesn't harm.
Anyway, please review, comment, complain and etc... would appreciate.
-- Cyrill
p.s.: i don't have inet access in office so will be able to reply
at tomorrow evening only.
---
x86,apic: Do not use stack'ed physid_mask_t in apicid_to_cpu_present
Stephen Rothwell pointed out that apic-noop (when gets compiled
in x86-84 environment) potentially may consume too much stack space.
|
| Hi all,
|
| Today's linux-next build (x86_64 allmodconfig) produced this warning:
|
| In file included from arch/x86/include/asm/smp.h:13,
| from arch/x86/include/asm/mmzone_64.h:12,
| from arch/x86/include/asm/mmzone.h:4,
| from include/linux/mmzone.h:783,
| from include/linux/gfp.h:4,
| from include/linux/kmod.h:22,
| from include/linux/module.h:13,
| from arch/x86/kernel/apic/apic_noop.c:14:
| arch/x86/include/asm/apic.h: In function 'default_apicid_to_cpu_present':
| arch/x86/include/asm/apic.h:591: warning: the frame size of 8192 bytes is larger than 2048 bytes
|
| It may not have been caused by the tip tree, but I can't find what
| changed to cause this and a commit from the tip tree has exposed it
| (9844ab11c763bfed9f054c82366b19dcda66aca9 "x86, apic: Introduce the NOOP
| apic driver").
|
So I would say this is a bug in apic-noop (in fact we don't use
default_apicid_to_cpu_present if operate in 64bit mode but it's a sign
that something is wrong with code design). The key problem is that
physid_mask_t is an array with a size depending on MAX_APICS, which
in turn is big enough on x86-64 to trigger compiler warning.
So to prevent such a situation in future we should use physid_mask_t
pointer leaving apic driver with a task to operate over data but not
allocate it. Caller should instead.
This allow us throw out some code as well since physid_set_mask_of_physid
already implement the functionality we need.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---
arch/x86/include/asm/apic.h | 7 +------
arch/x86/kernel/apic/apic_noop.c | 2 +-
arch/x86/kernel/apic/bigsmp_32.c | 7 +------
arch/x86/kernel/apic/es7000_32.c | 8 ++------
arch/x86/kernel/apic/io_apic.c | 4 ++--
arch/x86/kernel/apic/numaq_32.c | 4 ++--
arch/x86/kernel/apic/probe_32.c | 2 +-
arch/x86/kernel/apic/summit_32.c | 4 ++--
arch/x86/kernel/visws_quirks.c | 2 +-
9 files changed, 13 insertions(+), 27 deletions(-)
Index: linux-2.6.git/arch/x86/include/asm/apic.h
=====================================================================
--- linux-2.6.git.orig/arch/x86/include/asm/apic.h
+++ linux-2.6.git/arch/x86/include/asm/apic.h
@@ -310,7 +310,7 @@ struct apic {
int (*apicid_to_node)(int logical_apicid);
int (*cpu_to_logical_apicid)(int cpu);
int (*cpu_present_to_apicid)(int mps_cpu);
- physid_mask_t (*apicid_to_cpu_present)(int phys_apicid);
+ void (*apicid_to_cpu_present)(int phys_apicid, physid_mask_t *map);
void (*setup_portio_remap)(void);
int (*check_phys_apicid_present)(int phys_apicid);
void (*enable_apic_mode)(void);
@@ -585,11 +585,6 @@ extern int default_cpu_present_to_apicid
extern int default_check_phys_apicid_present(int phys_apicid);
#endif
-static inline physid_mask_t default_apicid_to_cpu_present(int phys_apicid)
-{
- return physid_mask_of_physid(phys_apicid);
-}
-
#endif /* CONFIG_X86_LOCAL_APIC */
#ifdef CONFIG_X86_32
Index: linux-2.6.git/arch/x86/kernel/apic/apic_noop.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/apic_noop.c
+++ linux-2.6.git/arch/x86/kernel/apic/apic_noop.c
@@ -162,7 +162,7 @@ struct apic apic_noop = {
.cpu_to_logical_apicid = noop_cpu_to_logical_apicid,
.cpu_present_to_apicid = default_cpu_present_to_apicid,
- .apicid_to_cpu_present = default_apicid_to_cpu_present,
+ .apicid_to_cpu_present = physid_set_mask_of_physid,
.setup_portio_remap = NULL,
.check_phys_apicid_present = default_check_phys_apicid_present,
Index: linux-2.6.git/arch/x86/kernel/apic/bigsmp_32.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/bigsmp_32.c
+++ linux-2.6.git/arch/x86/kernel/apic/bigsmp_32.c
@@ -93,11 +93,6 @@ static int bigsmp_cpu_present_to_apicid(
return BAD_APICID;
}
-static physid_mask_t bigsmp_apicid_to_cpu_present(int phys_apicid)
-{
- return physid_mask_of_physid(phys_apicid);
-}
-
/* Mapping from cpu number to logical apicid */
static inline int bigsmp_cpu_to_logical_apicid(int cpu)
{
@@ -230,7 +225,7 @@ struct apic apic_bigsmp = {
.apicid_to_node = bigsmp_apicid_to_node,
.cpu_to_logical_apicid = bigsmp_cpu_to_logical_apicid,
.cpu_present_to_apicid = bigsmp_cpu_present_to_apicid,
- .apicid_to_cpu_present = bigsmp_apicid_to_cpu_present,
+ .apicid_to_cpu_present = physid_set_mask_of_physid,
.setup_portio_remap = NULL,
.check_phys_apicid_present = bigsmp_check_phys_apicid_present,
.enable_apic_mode = NULL,
Index: linux-2.6.git/arch/x86/kernel/apic/es7000_32.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/es7000_32.c
+++ linux-2.6.git/arch/x86/kernel/apic/es7000_32.c
@@ -539,14 +539,10 @@ static int es7000_cpu_present_to_apicid(
static int cpu_id;
-static physid_mask_t es7000_apicid_to_cpu_present(int phys_apicid)
+static void es7000_apicid_to_cpu_present(int phys_apicid, physid_mask_t *map)
{
- physid_mask_t mask;
-
- mask = physid_mask_of_physid(cpu_id);
+ physid_set_mask_of_physid(cpu_id, map);
++cpu_id;
-
- return mask;
}
/* Mapping from cpu number to logical apicid */
Index: linux-2.6.git/arch/x86/kernel/apic/io_apic.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/io_apic.c
+++ linux-2.6.git/arch/x86/kernel/apic/io_apic.c
@@ -2073,7 +2073,7 @@ void __init setup_ioapic_ids_from_mpc(vo
mp_ioapics[apic_id].apicid = i;
} else {
physid_mask_t tmp;
- tmp = apic->apicid_to_cpu_present(mp_ioapics[apic_id].apicid);
+ apic->apicid_to_cpu_present(mp_ioapics[apic_id].apicid, &tmp);
apic_printk(APIC_VERBOSE, "Setting %d in the "
"phys_id_present_map\n",
mp_ioapics[apic_id].apicid);
@@ -3969,7 +3969,7 @@ int __init io_apic_get_unique_id(int ioa
apic_id = i;
}
- tmp = apic->apicid_to_cpu_present(apic_id);
+ apic->apicid_to_cpu_present(apic_id, &tmp);
physids_or(apic_id_map, apic_id_map, tmp);
if (reg_00.bits.ID != apic_id) {
Index: linux-2.6.git/arch/x86/kernel/apic/numaq_32.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/numaq_32.c
+++ linux-2.6.git/arch/x86/kernel/apic/numaq_32.c
@@ -402,12 +402,12 @@ static inline int numaq_apicid_to_node(i
return logical_apicid >> 4;
}
-static inline physid_mask_t numaq_apicid_to_cpu_present(int logical_apicid)
+static void numaq_apicid_to_cpu_present(int logical_apicid, physid_mask_t *map)
{
int node = numaq_apicid_to_node(logical_apicid);
int cpu = __ffs(logical_apicid & 0xf);
- return physid_mask_of_physid(cpu + 4*node);
+ physid_set_mask_of_physid(cpu + 4*node, map);
}
/* Where the IO area was mapped on multiquad, always 0 otherwise */
Index: linux-2.6.git/arch/x86/kernel/apic/probe_32.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/probe_32.c
+++ linux-2.6.git/arch/x86/kernel/apic/probe_32.c
@@ -108,7 +108,7 @@ struct apic apic_default = {
.apicid_to_node = default_apicid_to_node,
.cpu_to_logical_apicid = default_cpu_to_logical_apicid,
.cpu_present_to_apicid = default_cpu_present_to_apicid,
- .apicid_to_cpu_present = default_apicid_to_cpu_present,
+ .apicid_to_cpu_present = physid_set_mask_of_physid,
.setup_portio_remap = NULL,
.check_phys_apicid_present = default_check_phys_apicid_present,
.enable_apic_mode = NULL,
Index: linux-2.6.git/arch/x86/kernel/apic/summit_32.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/summit_32.c
+++ linux-2.6.git/arch/x86/kernel/apic/summit_32.c
@@ -267,9 +267,9 @@ static physid_mask_t summit_ioapic_phys_
return physids_promote(0x0F);
}
-static physid_mask_t summit_apicid_to_cpu_present(int apicid)
+static void summit_apicid_to_cpu_present(int apicid, physid_mask_t *map)
{
- return physid_mask_of_physid(0);
+ physid_set_mask_of_physid(0, map);
}
static int summit_check_phys_apicid_present(int physical_apicid)
Index: linux-2.6.git/arch/x86/kernel/visws_quirks.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/visws_quirks.c
+++ linux-2.6.git/arch/x86/kernel/visws_quirks.c
@@ -183,7 +183,7 @@ static void __init MP_processor_info(str
return;
}
- apic_cpus = apic->apicid_to_cpu_present(m->apicid);
+ apic->apicid_to_cpu_present(m->apicid, &apic_cpus);
physids_or(phys_cpu_present_map, phys_cpu_present_map, apic_cpus);
/*
* Validate version
^ permalink raw reply
* Re: linux-next: tip tree build warning
From: Cyrill Gorcunov @ 2009-11-08 18:42 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel
In-Reply-To: <20091108133247.GA14807@elte.hu>
[Ingo Molnar - Sun, Nov 08, 2009 at 02:32:47PM +0100]
|
...
| > +
| > +#ifdef CONFIG_X86_32
| > .apicid_to_cpu_present = default_apicid_to_cpu_present,
| > +#else
| > + .apicid_to_cpu_present = NULL,
| > +#endif
|
| would be better to unify this instead ...
|
| Ingo
|
[not for inclusion]
Here is what I'm going to implement (it is not finished yet,
but just to show the idea -- ie to get rid of physid_mask_t
passed as an argument at all but use pointers instead since
callers already have bitmask allocated).
And physid_set_mask_of_physid already do the work for us.
Hmm?
(Ingo, I think you may apply the former patch just to
have the issue fixed this way temporary)
-- Cyrill
---
arch/x86/include/asm/apic.h | 7 +------
arch/x86/kernel/apic/apic_noop.c | 2 +-
arch/x86/kernel/apic/bigsmp_32.c | 7 +------
arch/x86/kernel/apic/probe_32.c | 2 +-
4 files changed, 4 insertions(+), 14 deletions(-)
Index: linux-2.6.git/arch/x86/include/asm/apic.h
=====================================================================
--- linux-2.6.git.orig/arch/x86/include/asm/apic.h
+++ linux-2.6.git/arch/x86/include/asm/apic.h
@@ -310,7 +310,7 @@ struct apic {
int (*apicid_to_node)(int logical_apicid);
int (*cpu_to_logical_apicid)(int cpu);
int (*cpu_present_to_apicid)(int mps_cpu);
- physid_mask_t (*apicid_to_cpu_present)(int phys_apicid);
+ void (*apicid_to_cpu_present)(int phys_apicid, physid_mask_t *bitmap);
void (*setup_portio_remap)(void);
int (*check_phys_apicid_present)(int phys_apicid);
void (*enable_apic_mode)(void);
@@ -585,11 +585,6 @@ extern int default_cpu_present_to_apicid
extern int default_check_phys_apicid_present(int phys_apicid);
#endif
-static inline physid_mask_t default_apicid_to_cpu_present(int phys_apicid)
-{
- return physid_mask_of_physid(phys_apicid);
-}
-
#endif /* CONFIG_X86_LOCAL_APIC */
#ifdef CONFIG_X86_32
Index: linux-2.6.git/arch/x86/kernel/apic/apic_noop.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/apic_noop.c
+++ linux-2.6.git/arch/x86/kernel/apic/apic_noop.c
@@ -162,7 +162,7 @@ struct apic apic_noop = {
.cpu_to_logical_apicid = noop_cpu_to_logical_apicid,
.cpu_present_to_apicid = default_cpu_present_to_apicid,
- .apicid_to_cpu_present = default_apicid_to_cpu_present,
+ .apicid_to_cpu_present = physid_set_mask_of_physid,
.setup_portio_remap = NULL,
.check_phys_apicid_present = default_check_phys_apicid_present,
Index: linux-2.6.git/arch/x86/kernel/apic/bigsmp_32.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/bigsmp_32.c
+++ linux-2.6.git/arch/x86/kernel/apic/bigsmp_32.c
@@ -93,11 +93,6 @@ static int bigsmp_cpu_present_to_apicid(
return BAD_APICID;
}
-static physid_mask_t bigsmp_apicid_to_cpu_present(int phys_apicid)
-{
- return physid_mask_of_physid(phys_apicid);
-}
-
/* Mapping from cpu number to logical apicid */
static inline int bigsmp_cpu_to_logical_apicid(int cpu)
{
@@ -230,7 +225,7 @@ struct apic apic_bigsmp = {
.apicid_to_node = bigsmp_apicid_to_node,
.cpu_to_logical_apicid = bigsmp_cpu_to_logical_apicid,
.cpu_present_to_apicid = bigsmp_cpu_present_to_apicid,
- .apicid_to_cpu_present = bigsmp_apicid_to_cpu_present,
+ .apicid_to_cpu_present = physid_set_mask_of_physid,
.setup_portio_remap = NULL,
.check_phys_apicid_present = bigsmp_check_phys_apicid_present,
.enable_apic_mode = NULL,
Index: linux-2.6.git/arch/x86/kernel/apic/probe_32.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/probe_32.c
+++ linux-2.6.git/arch/x86/kernel/apic/probe_32.c
@@ -108,7 +108,7 @@ struct apic apic_default = {
.apicid_to_node = default_apicid_to_node,
.cpu_to_logical_apicid = default_cpu_to_logical_apicid,
.cpu_present_to_apicid = default_cpu_present_to_apicid,
- .apicid_to_cpu_present = default_apicid_to_cpu_present,
+ .apicid_to_cpu_present = physid_set_mask_of_physid,
.setup_portio_remap = NULL,
.check_phys_apicid_present = default_check_phys_apicid_present,
.enable_apic_mode = NULL,
^ permalink raw reply
* Re: linux-next: tip tree build warning
From: Cyrill Gorcunov @ 2009-11-08 13:43 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel
In-Reply-To: <20091108133247.GA14807@elte.hu>
[Ingo Molnar - Sun, Nov 08, 2009 at 02:32:47PM +0100]
...
|
| > +
| > +#ifdef CONFIG_X86_32
| > .apicid_to_cpu_present = default_apicid_to_cpu_present,
| > +#else
| > + .apicid_to_cpu_present = NULL,
| > +#endif
|
| would be better to unify this instead ...
|
| Ingo
|
OK, wait a bit.
-- Cyrill
^ permalink raw reply
* Re: linux-next: tip tree build warning
From: Ingo Molnar @ 2009-11-08 13:32 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel
In-Reply-To: <20091108131645.GD5300@lenovo>
* Cyrill Gorcunov <gorcunov@openvz.org> wrote:
> [Ingo Molnar - Wed, Oct 28, 2009 at 08:50:12AM +0100]
> |
> | * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> |
> | > Hi all,
> | >
> | > On Wed, 28 Oct 2009 18:41:26 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> | > >
> | > > static inline physid_mask_t default_apicid_to_cpu_present(int phys_apicid)
> | > > {
> | > > return physid_mask_of_physid(phys_apicid);
> | > > }
> | >
> | > I just noticed that this function (default_apicid_to_cpu_present) is
> | > declared "static inline in a header" but looks like it is only used by
> | > assigning its address to a function pointer. Its only use for x86_64
> | > is in arch/x86/kernel/apic/apic_noop.c ...
> |
> | yes, that might be a real problem - returning the mask like that is
> | messy. Thanks, will check.
> |
> | Ingo
> |
>
> Darn, my fault sorry! Here is an update which fixes the issue.
> (Btw, Stephen could you CC me next time if you get commit id
> with me in authors, so I wouldn't miss problem).
>
> Please review, comments/complains are quite welcome!
>
> -- Cyrill
> ---
> x86,apic: Get rid of apicid_to_cpu_present assign on X86-64
>
> In fact it's never get used on x86-64 (for 64 bit platform
> we use differ technique to enumerate io-units).
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
> ---
> arch/x86/kernel/apic/apic_noop.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> Index: linux-2.6.git/arch/x86/kernel/apic/apic_noop.c
> =====================================================================
> --- linux-2.6.git.orig/arch/x86/kernel/apic/apic_noop.c
> +++ linux-2.6.git/arch/x86/kernel/apic/apic_noop.c
> @@ -162,7 +162,12 @@ struct apic apic_noop = {
>
> .cpu_to_logical_apicid = noop_cpu_to_logical_apicid,
> .cpu_present_to_apicid = default_cpu_present_to_apicid,
> +
> +#ifdef CONFIG_X86_32
> .apicid_to_cpu_present = default_apicid_to_cpu_present,
> +#else
> + .apicid_to_cpu_present = NULL,
> +#endif
would be better to unify this instead ...
Ingo
^ permalink raw reply
* Re: linux-next: tip tree build warning
From: Cyrill Gorcunov @ 2009-11-08 13:16 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel
In-Reply-To: <20091028075012.GD19402@elte.hu>
[Ingo Molnar - Wed, Oct 28, 2009 at 08:50:12AM +0100]
|
| * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
|
| > Hi all,
| >
| > On Wed, 28 Oct 2009 18:41:26 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
| > >
| > > static inline physid_mask_t default_apicid_to_cpu_present(int phys_apicid)
| > > {
| > > return physid_mask_of_physid(phys_apicid);
| > > }
| >
| > I just noticed that this function (default_apicid_to_cpu_present) is
| > declared "static inline in a header" but looks like it is only used by
| > assigning its address to a function pointer. Its only use for x86_64
| > is in arch/x86/kernel/apic/apic_noop.c ...
|
| yes, that might be a real problem - returning the mask like that is
| messy. Thanks, will check.
|
| Ingo
|
Darn, my fault sorry! Here is an update which fixes the issue.
(Btw, Stephen could you CC me next time if you get commit id
with me in authors, so I wouldn't miss problem).
Please review, comments/complains are quite welcome!
-- Cyrill
---
x86,apic: Get rid of apicid_to_cpu_present assign on X86-64
In fact it's never get used on x86-64 (for 64 bit platform
we use differ technique to enumerate io-units).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
---
arch/x86/kernel/apic/apic_noop.c | 5 +++++
1 file changed, 5 insertions(+)
Index: linux-2.6.git/arch/x86/kernel/apic/apic_noop.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/apic_noop.c
+++ linux-2.6.git/arch/x86/kernel/apic/apic_noop.c
@@ -162,7 +162,12 @@ struct apic apic_noop = {
.cpu_to_logical_apicid = noop_cpu_to_logical_apicid,
.cpu_present_to_apicid = default_cpu_present_to_apicid,
+
+#ifdef CONFIG_X86_32
.apicid_to_cpu_present = default_apicid_to_cpu_present,
+#else
+ .apicid_to_cpu_present = NULL,
+#endif
.setup_portio_remap = NULL,
.check_phys_apicid_present = default_check_phys_apicid_present,
^ permalink raw reply
* Re: [PATCH] edac: fix i7core build
From: Mauro Carvalho Chehab @ 2009-11-08 3:45 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <20091104135733.cb878718.randy.dunlap@oracle.com>
Em Wed, 4 Nov 2009 13:57:33 -0800
Randy Dunlap <randy.dunlap@oracle.com> escreveu:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix build warning (missing header file) and
> build error when CONFIG_SMP=n.
>
> drivers/edac/i7core_edac.c:860: error: implicit declaration of function 'msleep'
> drivers/edac/i7core_edac.c:1700: error: 'struct cpuinfo_x86' has no member named 'phys_proc_id'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Hi Randy,
Thank you for the patch.
FYI, I've just added your and Alan's fixes on my linux-next tree for i7core:
http://git.kernel.org/?p=linux/kernel/git/mchehab/i7core.git;a=commit;h=0480ce880b999703fbb73912054f4de187da543a
http://git.kernel.org/?p=linux/kernel/git/mchehab/i7core.git;a=commit;h=df0a7a70df5e9c5d612b249661f8b3883be41331
Sorry for not doing it earlier. I was handling a big backlog I had here, due to
a training course and my trip to Japan (that happened at the week after the training).
Cheers,
Mauro
^ permalink raw reply
* Re: [PATCH -next] staging/wireless: don't build when NET etc. are not enabled
From: John W. Linville @ 2009-11-07 23:32 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, Greg Kroah-Hartman
In-Reply-To: <4AF4B2B3.8020109@oracle.com>
I'd better take this one...
Thanks, Randy!
John
On Fri, Nov 06, 2009 at 03:35:15PM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> These wireless drivers in staging could be built when
> CONFIG_NET=n, CONFIG_NETDEVICES=n, causing this build error:
>
> net/wireless/wext-priv.c: In function 'ioctl_private_call':
> net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
>
> due to faulty selects.
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> ---
> drivers/staging/arlan/Kconfig | 2 +-
> drivers/staging/netwave/Kconfig | 2 +-
> drivers/staging/wavelan/Kconfig | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> --- linux-next-20091106.orig/drivers/staging/arlan/Kconfig
> +++ linux-next-20091106/drivers/staging/arlan/Kconfig
> @@ -1,6 +1,6 @@
> config ARLAN
> tristate "Aironet Arlan 655 & IC2200 DS support"
> - depends on ISA && !64BIT
> + depends on ISA && !64BIT && WLAN
> select WIRELESS_EXT
> ---help---
> Aironet makes Arlan, a class of wireless LAN adapters. These use the
> --- linux-next-20091106.orig/drivers/staging/netwave/Kconfig
> +++ linux-next-20091106/drivers/staging/netwave/Kconfig
> @@ -1,6 +1,6 @@
> config PCMCIA_NETWAVE
> tristate "Xircom Netwave AirSurfer Pcmcia wireless support"
> - depends on PCMCIA
> + depends on PCMCIA && WLAN
> select WIRELESS_EXT
> select WEXT_PRIV
> help
> --- linux-next-20091106.orig/drivers/staging/wavelan/Kconfig
> +++ linux-next-20091106/drivers/staging/wavelan/Kconfig
> @@ -1,6 +1,6 @@
> config WAVELAN
> tristate "AT&T/Lucent old WaveLAN & DEC RoamAbout DS ISA support"
> - depends on ISA
> + depends on ISA && WLAN
> select WIRELESS_EXT
> select WEXT_SPY
> select WEXT_PRIV
> @@ -25,7 +25,7 @@ config WAVELAN
>
> config PCMCIA_WAVELAN
> tristate "AT&T/Lucent old WaveLAN Pcmcia wireless support"
> - depends on PCMCIA
> + depends on PCMCIA && WLAN
> select WIRELESS_EXT
> select WEXT_SPY
> select WEXT_PRIV
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: linux-next: Tree for November 5
From: Sachin Sant @ 2009-11-07 16:57 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: LKML, linux-next, jbarnes
In-Reply-To: <200911060856.09405.bjorn.helgaas@hp.com>
Bjorn Helgaas wrote:
> On Thursday 05 November 2009 10:17:11 am Bjorn Helgaas wrote:
>
>> On Thursday 05 November 2009 09:31:04 am Bjorn Helgaas wrote:
>>
>>> On Thursday 05 November 2009 03:38:27 am Sachin Sant wrote:
>>>
>>>> Today's next tree fails to build on i386 with
>>>>
>>>> arch/x86/pci/built-in.o: In function `align_resource':
>>>> arch/x86/pci/acpi.c:82: undefined reference to `__udivdi3'
>>>>
>>>> The code in question was added by commit
>>>> 03db42adfeeabe856dbb6894dd3aaff55838330a.
>>>>
>>> I'll look into this. I did build and test a 32-bit x86 kernel, but
>>> I built it on an x86_64 box using "linux32 make ...", which looks like
>>> it used gcc 4.3.2.
>>>
>> Can you try the patch below, please?
>>
>
> Sachin, can you please try this patch and report whether it
> fixes the undefined reference? I hate to have linux-next
> broken longer than necessary.
>
Sorry was away from office for a day. Yes the patch
fixed the build break for me.
Thanks for the patch.
Regards
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: linux-next: Tree for November 2 (wireless/wl1271)
From: Kalle Valo @ 2009-11-07 10:37 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext John W. Linville, Randy Dunlap, Stephen Rothwell,
linux-next@vger.kernel.org, LKML, linux-wireless@vger.kernel.org
In-Reply-To: <4AEFC7CF.1020909@nokia.com>
Luciano Coelho <luciano.coelho@nokia.com> writes:
> Coelho Luciano (Nokia-D/Helsinki) wrote:
>> ext John W. Linville wrote:
>>> Helps if I actually Cc: Luca...
>>
>> Yes, it does. :) I would see this at some point but CCing me speed
>> things up quite a lot.
>
>
> BTW, I think we need this for wl1251 as well. CC'ing Kalle too.
Thanks, but upstream wl1251 doesn't have ARP filter. There is an
internal patch but I haven't submitted it, yet.
--
Kalle Valo
^ permalink raw reply
* Re: linux-next: sparc tree build failure
From: Stephen Rothwell @ 2009-11-07 2:35 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, linux-kernel, kristoffer
In-Reply-To: <20091106.002651.21006753.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
Hi Dave,
On Fri, 06 Nov 2009 00:26:51 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Stephen, can you let me know if this takes care of everything?
Sorry, sleep intervened :-)
That patch fixes the build of the .o (I didn't do the link).
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH -next] staging/wireless: don't build when NET etc. are not enabled
From: Randy Dunlap @ 2009-11-06 23:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Greg Kroah-Hartman
In-Reply-To: <20091106181330.80bca052.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
These wireless drivers in staging could be built when
CONFIG_NET=n, CONFIG_NETDEVICES=n, causing this build error:
net/wireless/wext-priv.c: In function 'ioctl_private_call':
net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
due to faulty selects.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/staging/arlan/Kconfig | 2 +-
drivers/staging/netwave/Kconfig | 2 +-
drivers/staging/wavelan/Kconfig | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
--- linux-next-20091106.orig/drivers/staging/arlan/Kconfig
+++ linux-next-20091106/drivers/staging/arlan/Kconfig
@@ -1,6 +1,6 @@
config ARLAN
tristate "Aironet Arlan 655 & IC2200 DS support"
- depends on ISA && !64BIT
+ depends on ISA && !64BIT && WLAN
select WIRELESS_EXT
---help---
Aironet makes Arlan, a class of wireless LAN adapters. These use the
--- linux-next-20091106.orig/drivers/staging/netwave/Kconfig
+++ linux-next-20091106/drivers/staging/netwave/Kconfig
@@ -1,6 +1,6 @@
config PCMCIA_NETWAVE
tristate "Xircom Netwave AirSurfer Pcmcia wireless support"
- depends on PCMCIA
+ depends on PCMCIA && WLAN
select WIRELESS_EXT
select WEXT_PRIV
help
--- linux-next-20091106.orig/drivers/staging/wavelan/Kconfig
+++ linux-next-20091106/drivers/staging/wavelan/Kconfig
@@ -1,6 +1,6 @@
config WAVELAN
tristate "AT&T/Lucent old WaveLAN & DEC RoamAbout DS ISA support"
- depends on ISA
+ depends on ISA && WLAN
select WIRELESS_EXT
select WEXT_SPY
select WEXT_PRIV
@@ -25,7 +25,7 @@ config WAVELAN
config PCMCIA_WAVELAN
tristate "AT&T/Lucent old WaveLAN Pcmcia wireless support"
- depends on PCMCIA
+ depends on PCMCIA && WLAN
select WIRELESS_EXT
select WEXT_SPY
select WEXT_PRIV
^ permalink raw reply
* Re: [PATCH -next] kmemleak: fix kconfig for crc32 build error
From: Catalin Marinas @ 2009-11-06 23:12 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML
In-Reply-To: <4AF4B259.8030506@oracle.com>
On Fri, 2009-11-06 at 15:33 -0800, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> kmemleak uses crc32 functions so it needs to select CRC32.
> Fixes build error:
>
> kmemleak.c:(.text+0x7ce62): undefined reference to `crc32_le'
Thanks for the patch. I'll included it in my kmemleak branch.
--
Catalin
^ permalink raw reply
* [PATCH -next] kmemleak: fix kconfig for crc32 build error
From: Randy Dunlap @ 2009-11-06 23:33 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, Catalin Marinas
In-Reply-To: <20091106181330.80bca052.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
kmemleak uses crc32 functions so it needs to select CRC32.
Fixes build error:
kmemleak.c:(.text+0x7ce62): undefined reference to `crc32_le'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
lib/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20091106.orig/lib/Kconfig.debug
+++ linux-next-20091106/lib/Kconfig.debug
@@ -372,6 +372,7 @@ config DEBUG_KMEMLEAK
select DEBUG_FS if SYSFS
select STACKTRACE if STACKTRACE_SUPPORT
select KALLSYMS
+ select CRC32
help
Say Y here if you want to enable the memory leak
detector. The memory allocation/freeing is traced in a way
^ permalink raw reply
* Re: linux-next: Tree for November 5
From: Jesse Barnes @ 2009-11-06 22:00 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Sachin Sant, LKML, linux-next
In-Reply-To: <200911051017.12135.bjorn.helgaas@hp.com>
On Thu, 5 Nov 2009 11:17:11 -0600
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> On Thursday 05 November 2009 09:31:04 am Bjorn Helgaas wrote:
> > On Thursday 05 November 2009 03:38:27 am Sachin Sant wrote:
> > > Today's next tree fails to build on i386 with
> > >
> > > arch/x86/pci/built-in.o: In function `align_resource':
> > > arch/x86/pci/acpi.c:82: undefined reference to `__udivdi3'
> > >
> > > The code in question was added by commit
> > > 03db42adfeeabe856dbb6894dd3aaff55838330a.
> >
> > I'll look into this. I did build and test a 32-bit x86 kernel, but
> > I built it on an x86_64 box using "linux32 make ...", which looks
> > like it used gcc 4.3.2.
>
> Can you try the patch below, please?
>
>
> commit 00f16f0a2f4826eadec0565e4b454ab8bc7824cc
> Author: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Date: Thu Nov 5 10:03:57 2009 -0700
>
> x86/PCI: remove 64-bit division
>
> The roundup() caused a build error (undefined reference to
> `__udivdi3'). We're aligning to power-of-two boundaries, so it's
> simpler to just use ALIGN() anyway, which avoids the division.
>
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Applied with Randy's ack. Thanks.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [BUILD-FAILURE] next-20091015 - vbus_enet driver breaks with allmodconfig
From: Gregory Haskins @ 2009-11-06 19:02 UTC (permalink / raw)
To: Gregory Haskins, Randy Dunlap
Cc: sfr, greg, Kamalesh Babulal, LKML, linux-next, netdev
In-Reply-To: <20091106093856.e9eac13e.randy.dunlap@oracle.com>
>>> On 11/6/2009 at 12:38 PM, in message
<20091106093856.e9eac13e.randy.dunlap@oracle.com>, Randy Dunlap
<randy.dunlap@oracle.com> wrote:
> On Thu, 15 Oct 2009 18:25:05 -0400 Gregory Haskins wrote:
>
>> Randy Dunlap wrote:
>> > On Thu, 15 Oct 2009 13:39:44 -0400 Gregory Haskins wrote:
>> >
>> >>
>> >> I am having difficulty reproducing the problem. When I look at the
>> >> Kconfig, I see that VBUS_ENET has a "select VBUS_PROXY" as I would
>> >> expect. Additionally, if I run allmodconfig I can confirm that I get
>> >> VBUS_ENET=m, VBUS_PROXY=y:
>> >
>> > Greg,
>> >
>> > Did you try to reproduce it with the ppc64 config file?
>> > allmodconfig on what arch?
>> >
>> > I think the problem is that arch/x86/Kconfig says:
>> >
>> > source "drivers/vbus/Kconfig"
>> >
>> > and that should actually be in drivers/Kconfig, so that it applies
>> > to ppc64 et al, not just x86.
>>
>> Ah, indeed. I only have/tried x86, and that is the issue. I will have
>> to fix this (and the create_irq() dependency you mention in the next mail).
>
> Hi Greg,
>
> I'm still getting
> pci-bridge.c:(.text+0x31b633): undefined reference to `create_irq'
>
> on today's linux-next-20091106.
> CONFIG_SMP=n
> CONFIG_X86_UP_APIC=n
>
> full config attached.
>
>
> ---
> ~Randy
Indeed. Looks like I need to be smarter about how the create_irq facility is used. I will fix this.
Thanks Randy,
-Greg
^ permalink raw reply
* Re: linux-next: Tree for November 5
From: Randy Dunlap @ 2009-11-06 17:53 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Sachin Sant, LKML, linux-next, jbarnes
In-Reply-To: <200911051017.12135.bjorn.helgaas@hp.com>
On Thu, 5 Nov 2009 11:17:11 -0600 Bjorn Helgaas wrote:
> On Thursday 05 November 2009 09:31:04 am Bjorn Helgaas wrote:
> > On Thursday 05 November 2009 03:38:27 am Sachin Sant wrote:
> > > Today's next tree fails to build on i386 with
> > >
> > > arch/x86/pci/built-in.o: In function `align_resource':
> > > arch/x86/pci/acpi.c:82: undefined reference to `__udivdi3'
> > >
> > > The code in question was added by commit
> > > 03db42adfeeabe856dbb6894dd3aaff55838330a.
> >
> > I'll look into this. I did build and test a 32-bit x86 kernel, but
> > I built it on an x86_64 box using "linux32 make ...", which looks like
> > it used gcc 4.3.2.
>
> Can you try the patch below, please?
>
This patch fixes this problem for me in today's linux-next-20091106.
Thanks.
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
>
> commit 00f16f0a2f4826eadec0565e4b454ab8bc7824cc
> Author: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Date: Thu Nov 5 10:03:57 2009 -0700
>
> x86/PCI: remove 64-bit division
>
> The roundup() caused a build error (undefined reference to `__udivdi3').
> We're aligning to power-of-two boundaries, so it's simpler to just use
> ALIGN() anyway, which avoids the division.
>
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 8ddf4f4..959e548 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -69,17 +69,17 @@ align_resource(struct acpi_device *bridge, struct resource *res)
> * that claim this address space have starting alignment and length
> * constraints, so fix any obvious BIOS goofs.
> */
> - if (res->start & (align - 1)) {
> + if (!IS_ALIGNED(res->start, align)) {
> dev_printk(KERN_DEBUG, &bridge->dev,
> "host bridge window %pR invalid; "
> "aligning start to %d-byte boundary\n", res, align);
> res->start &= ~(align - 1);
> }
> - if ((res->end + 1) & (align - 1)) {
> + if (!IS_ALIGNED(res->end + 1, align)) {
> dev_printk(KERN_DEBUG, &bridge->dev,
> "host bridge window %pR invalid; "
> "aligning end to %d-byte boundary\n", res, align);
> - res->end = roundup(res->end, align) - 1;
> + res->end = ALIGN(res->end, align) - 1;
> }
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
---
~Randy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox