Linux-Next discussions
 help / color / mirror / Atom feed
* Re: linux-next: manual merge of the net tree
From: David Miller @ 2008-12-29  4:00 UTC (permalink / raw)
  To: sfr; +Cc: linux-next, johannes, sam
In-Reply-To: <20081229145300.0a86e1de.sfr@canb.auug.org.au>

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Dec 2008 14:53:00 +1100

> Hi Dave,
> 
> On Sun, 07 Dec 2008 23:26:58 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 8 Dec 2008 14:48:51 +1100
> > 
> > > Today's linux-next merge of the net tree got a conflict in
> > > arch/sparc64/kernel/idprom.c between commit
> > > a88b5ba8bd8ac18aad65ee6c6a254e2e74876db3 (sparc,sparc64: unify kernel/"")
> > > from the sparc tree and commit 7c510e4b730a92cecf94ada45c989d8be0200d47
> > > ("net: convert more to %pM") from the net tree.
> > 
> > Thanks for reporting this.
> > 
> > > The former renamed the file while the latter modified it.  I just deleted
> > > the renamed file for now, the %pM conversion can be done later.
> > 
> > Yes it's probably the best way to handle this for now.
> 
> This conflict is now between the sparc tree and Linus' tree ...

I'll take care of this as I prepare the sparc-next-2.6 tree for
merging.

^ permalink raw reply

* Re: linux-next: usb tree build failure
From: Stephen Rothwell @ 2008-12-29  3:55 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, Inaky Perez-Gonzalez
In-Reply-To: <20081222113335.667c2d01.sfr@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

Hi Greg,

On Mon, 22 Dec 2008 11:33:35 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> x86_64-linux-ld: drivers/net/wimax/built-in.o: No such file: No such file or directory
> 
> I reverted commit 66aa675719ab82a03a66b75210fd40be6541f8fb ("wimax:
> Makefile, Kconfig and docbook linkage for the stack") just to make the
> build work.

Still there today.  Inaky sent you a patch, I think.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the net tree
From: Stephen Rothwell @ 2008-12-29  3:53 UTC (permalink / raw)
  To: David Miller; +Cc: linux-next, johannes, sam
In-Reply-To: <20081207.232658.64516148.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Hi Dave,

On Sun, 07 Dec 2008 23:26:58 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 8 Dec 2008 14:48:51 +1100
> 
> > Today's linux-next merge of the net tree got a conflict in
> > arch/sparc64/kernel/idprom.c between commit
> > a88b5ba8bd8ac18aad65ee6c6a254e2e74876db3 (sparc,sparc64: unify kernel/"")
> > from the sparc tree and commit 7c510e4b730a92cecf94ada45c989d8be0200d47
> > ("net: convert more to %pM") from the net tree.
> 
> Thanks for reporting this.
> 
> > The former renamed the file while the latter modified it.  I just deleted
> > the renamed file for now, the %pM conversion can be done later.
> 
> Yes it's probably the best way to handle this for now.

This conflict is now between the sparc tree and Linus' tree ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: Pull request for FS-Cache, including NFS patches
From: Stephen Rothwell @ 2008-12-29  3:45 UTC (permalink / raw)
  To: dhowells
  Cc: Andrew Morton, Bernd Schubert, nfsv4, hch, linux-kernel, steved,
	linux-fsdevel, rwheeler, linux-next, Trond Myklebust
In-Reply-To: <20081219110539.7e7e230c.sfr@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

Hi David,

On Fri, 19 Dec 2008 11:05:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Given the ongoing discussions around FS-Cache, I have removed it from
> linux-next.  Please ask me to include it again (if sensible) once some
> decision has been reached about its future.

What was the result of discussions around FS-Cache?  I ask because it
reappeared in linux-next today via the nfs tree (merged into that on Dec
24 and 25) ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: origin tree build failure
From: Roland Dreier @ 2008-12-29  3:44 UTC (permalink / raw)
  To: general, Aleksey Senin; +Cc: linux-next, LKML, Linus, Stephen Rothwell
In-Reply-To: <20081229114321.4b6baea5.sfr@canb.auug.org.au>

 > ERROR: ".ipv6_chk_addr" [drivers/infiniband/core/ib_addr.ko] undefined!
 > ERROR: ".ip6_route_output" [drivers/infiniband/core/ib_addr.ko] undefined!
 > 
 > Caused by commit 38617c64bf9a10bf20e41d95b69bb81e8560fe9d ("RDMA/addr:
 > Add support for translating IPv6 addresses").  This requires a dependency
 > on IPV6.

So how do we want to fix this?  (This question is mostly directed to the
IB guys)  One possibility is to make all this depend on IPV6 in Kconfig,
but I think we want the RDMA CM to be buildable/usable even if IPv6
isn't enabled.  A better option is to just put all the IPv6 related
stuff into

#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)

and add a Kconfig dependency on (IPV6 || IPV6=n) as we did for IPoIB.

But then this leads to the behavior that loading the RDMA CM will cause
the ipv6 module to be loaded if IPV6=m in the kernel config, even if the
administrator doesn't want to enable IPv6, just as with IPoIB today.
And people already complain about that.

Anyone see a better solution (which we could use for IPoIB even)?

 - R.

^ permalink raw reply

* Re: linux-next: origin tree build failure
From: Roland Dreier @ 2008-12-29  3:36 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: general, linux-next, LKML, Linus, Aleksey Senin
In-Reply-To: <20081229114321.4b6baea5.sfr@canb.auug.org.au>

 > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
 > 
 > ERROR: ".ipv6_chk_addr" [drivers/infiniband/core/ib_addr.ko] undefined!
 > ERROR: ".ip6_route_output" [drivers/infiniband/core/ib_addr.ko] undefined!
 > 
 > Caused by commit 38617c64bf9a10bf20e41d95b69bb81e8560fe9d ("RDMA/addr:
 > Add support for translating IPv6 addresses").  This requires a dependency
 > on IPV6.

Thanks, I'll get a fix queued up.  Sorry about that.

 - R.

^ permalink raw reply

* linux-next: timers tree build failure
From: Stephen Rothwell @ 2008-12-29  2:30 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin; +Cc: linux-next, Takashi Iwai

Hi all,

Today's linux-next build (x86_64 allmodconfig) failed like this:

sound/core/hrtimer.c: In function 'snd_hrtimer_open':
sound/core/hrtimer.c:60: error: 'struct hrtimer' has no member named 'cb_mode'
sound/core/hrtimer.c:60: error: 'HRTIMER_CB_IRQSAFE_UNLOCKED' undeclared (first use in this function)

See below ... the sound tree changes are now in Linus' tree, so this
needs fixing before the timers tree gets merged.

I have applied the merge fix below (which is also in the sound tree) to
the timers tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Date: Mon, 15 Dec 2008 15:43:01 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Takashi Iwai <tiwai@suse.de>
Cc: linux-next@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>, Ingo
 Molnar <mingo@elte.hu>
Subject: linux-next: sound tree build failure

Hi Takashi,

Today's linux-next build (x86_64 allmodconfig) failed like this:

sound/core/hrtimer.c: In function 'snd_hrtimer_open':
sound/core/hrtimer.c:60: error: 'struct hrtimer' has no member named 'cb_mode'
sound/core/hrtimer.c:60: error: 'HRTIMER_CB_IRQSAFE_UNLOCKED' undeclared (first use in this function)

An interaction between commit bbaf5e97337287479eb78dbc3822d9560bbfd2e2
("ALSA: Add hrtimer backend for ALSA timer interface") from the sound
tree and commit ca109491f612aab5c8152207631c0444f63da97f ("hrtimer:
removing all ur callback modes") from the timers tree.

I have added the below fixup for the merge and can carry it as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 15 Dec 2008 15:38:14 +1100
Subject: [PATCH] sound: fixup for timers tree interaction

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 sound/core/hrtimer.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/sound/core/hrtimer.c b/sound/core/hrtimer.c
index c1d2859..34c7d48 100644
--- a/sound/core/hrtimer.c
+++ b/sound/core/hrtimer.c
@@ -57,7 +57,6 @@ static int snd_hrtimer_open(struct snd_timer *t)
 		return -ENOMEM;
 	hrtimer_init(&stime->hrt, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	stime->timer = t;
-	stime->hrt.cb_mode = HRTIMER_CB_IRQSAFE_UNLOCKED;
 	stime->hrt.function = snd_hrtimer_callback;
 	t->private_data = stime;
 	return 0;
-- 
1.6.0.5

^ permalink raw reply related

* linux-next: manual merge of the timers tree
From: Stephen Rothwell @ 2008-12-29  2:02 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: linux-next, Rusty Russell, Woodruff, Richard, Andrew Morton

Hi all,

Today's linux-next merge of the timers tree got a conflict in
kernel/time/tick-sched.c between commit
6a7b3dc3440f7b5a9b67594af01ed562cdeb41e4 ("sched: convert nohz_cpu_mask
to cpumask_var_t") from the cpus4096 tree and commit
001474491fabeca233168a8598f721c808040f90 ("nohz: suppress needless timer
reprogramming") from the timers tree.

Just context changing.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc kernel/time/tick-sched.c
index 70f872c,8f3fc25..0000000
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@@ -282,8 -282,31 +282,31 @@@ void tick_nohz_stop_sched_tick(int inid
  	/* Schedule the tick, if we are at least one jiffie off */
  	if ((long)delta_jiffies >= 1) {
  
+ 		/*
+ 		* calculate the expiry time for the next timer wheel
+ 		* timer
+ 		*/
+ 		expires = ktime_add_ns(last_update, tick_period.tv64 *
+ 				   delta_jiffies);
+ 
+ 		/*
+ 		 * If this cpu is the one which updates jiffies, then
+ 		 * give up the assignment and let it be taken by the
+ 		 * cpu which runs the tick timer next, which might be
+ 		 * this cpu as well. If we don't drop this here the
+ 		 * jiffies might be stale and do_timer() never
+ 		 * invoked.
+ 		 */
+ 		if (cpu == tick_do_timer_cpu)
+ 			tick_do_timer_cpu = TICK_DO_TIMER_NONE;
+ 
  		if (delta_jiffies > 1)
 -			cpu_set(cpu, nohz_cpu_mask);
 +			cpumask_set_cpu(cpu, nohz_cpu_mask);
+ 
+ 		/* Skip reprogram of event if its not changed */
+ 		if (ts->tick_stopped && ktime_equal(expires, dev->next_event))
+ 			goto out;
+ 
  		/*
  		 * nohz_stop_sched_tick can be called several times before
  		 * the nohz_restart_sched_tick is called. This happens when

^ permalink raw reply

* linux-next: origin tree build failure
From: Stephen Rothwell @ 2008-12-29  0:43 UTC (permalink / raw)
  To: Roland Dreier, general; +Cc: linux-next, LKML, Linus, Aleksey Senin

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

Hi Roland,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

ERROR: ".ipv6_chk_addr" [drivers/infiniband/core/ib_addr.ko] undefined!
ERROR: ".ip6_route_output" [drivers/infiniband/core/ib_addr.ko] undefined!

Caused by commit 38617c64bf9a10bf20e41d95b69bb81e8560fe9d ("RDMA/addr:
Add support for translating IPv6 addresses").  This requires a dependency
on IPV6.

I have reverted that commit for today (which fixes the build, but may not
be the correct solution).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* linux-next: origin tree build warnings
From: Stephen Rothwell @ 2008-12-29  0:35 UTC (permalink / raw)
  To: Neil Horman; +Cc: linux-next, LKML, David S. Miller, netdev

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Hi Neil,

Today's linux-next build (powerpc ppc64_defconfig) produced these new
warnings:

drivers/net/pasemi_mac.c: In function 'pasemi_mac_rx_intr':
drivers/net/pasemi_mac.c:957: warning: unused variable 'dev'
drivers/net/pasemi_mac.c: In function 'pasemi_mac_poll':
drivers/net/pasemi_mac.c:1637: warning: unused variable 'dev'
drivers/net/spider_net.c: In function 'spider_net_poll':
drivers/net/spider_net.c:1280: warning: unused variable 'netdev'

Probably caused by commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net:
Remove unused netdev arg from some NAPI interfaces").

Please fix these up.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: origin tree build failure
From: Linus Torvalds @ 2008-12-29  0:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Steve French, linux-cifs-client, David S. Miller, linux-next,
	LKML, Andrew Morton
In-Reply-To: <20081229103849.1cb1eb54.sfr@canb.auug.org.au>



On Mon, 29 Dec 2008, Stephen Rothwell wrote:
> 
> Maybe someone should have warned Linus about the below known interaction
> between the net tree and the cifs tree ...

Gaah. I should have grepped for it, since the other place caused a 
conflict that I fixed. And I even tested that the result of my conflict 
resolution compiled, but since I don't configure cifs myself, I literally 
tested just the conflicting file.

Applied the fix, thanks,

		Linus

^ permalink raw reply

* linux-next: origin tree build failure
From: Stephen Rothwell @ 2008-12-29  0:00 UTC (permalink / raw)
  To: David S. Miller, Neil Horman; +Cc: linux-next, LKML, Linus, netdev, ppc-dev

Hi Dave, Neil,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

drivers/net/ibmveth.c: In function 'ibmveth_poll':
drivers/net/ibmveth.c:1034: warning: passing argument 1 of 'netif_rx_reschedule' from incompatible pointer type
drivers/net/ibmveth.c:1034: error: too many arguments to function 'netif_rx_reschedule'

Another miss in commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net: Remove
unused netdev arg from some NAPI interfaces").

I have added the following patch for today.

(I wonder how many more there will be? :-()

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Dec 2008 10:56:00 +1100
Subject: [PATCH] net: ibmveth NAPI interface cleanup fix

Commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net: Remove unused
netdev arg from some NAPI interfaces") missed one spot.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/ibmveth.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
index 1f055a9..9bc0f17 100644
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -1031,7 +1031,7 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
 		netif_rx_complete(napi);
 
 		if (ibmveth_rxq_pending_buffer(adapter) &&
-		    netif_rx_reschedule(netdev, napi)) {
+		    netif_rx_reschedule(napi)) {
 			lpar_rc = h_vio_signal(adapter->vdev->unit_address,
 					       VIO_IRQ_DISABLE);
 			goto restart_poll;
-- 
1.6.0.5

^ permalink raw reply related

* linux-next: origin tree build failure
From: Stephen Rothwell @ 2008-12-28 23:51 UTC (permalink / raw)
  To: David S. Miller, Neil Horman; +Cc: linux-next, LKML, Linus, netdev

Hi Dave, Neil,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

drivers/net/ehea/ehea_main.c: In function 'ehea_poll':
drivers/net/ehea/ehea_main.c:844: warning: passing argument 1 of 'netif_rx_reschedule' from incompatible pointer type
drivers/net/ehea/ehea_main.c:844: error: too many arguments to function 'netif_rx_reschedule'

Caused by commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net: Remove
unused netdev arg from some NAPI interfaces") which missed a call that
needed fixing up.  This commit was never in a linux-next tree.

I have added the below patch for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Dec 2008 10:46:13 +1100
Subject: [PATCH] net: ehea NAPI interface cleanup fix

Commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net: Remove unused
netdev arg from some NAPI interfaces") missed one spot.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/ehea/ehea_main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 035aa7d..a2f1905 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -841,7 +841,7 @@ static int ehea_poll(struct napi_struct *napi, int budget)
 		if (!cqe && !cqe_skb)
 			return rx;
 
-		if (!netif_rx_reschedule(dev, napi))
+		if (!netif_rx_reschedule(napi))
 			return rx;
 
 		cqe_skb = ehea_proc_cqes(pr, EHEA_POLL_MAX_CQES);
-- 
1.6.0.5

^ permalink raw reply related

* linux-next: origin tree build failure
From: Stephen Rothwell @ 2008-12-28 23:38 UTC (permalink / raw)
  To: Steve French, linux-cifs-client, David S. Miller
  Cc: linux-next, LKML, Linus, Andrew Morton

Hi Steve, Dave,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

fs/cifs/cifsfs.c: In function 'cifs_show_options':
fs/cifs/cifsfs.c:364: error: 'NIP6_FMT' undeclared (first use in this function)
fs/cifs/cifsfs.c:364: error: (Each undeclared identifier is reported only once
fs/cifs/cifsfs.c:364: error: for each function it appears in.)
fs/cifs/cifsfs.c:365: error: implicit declaration of function 'NIP6'

Maybe someone should have warned Linus about the below known interaction
between the net tree and the cifs tree ...

I have applied the patch to today's linux-next tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Date: Wed, 3 Dec 2008 13:53:12 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Steve French <smfrench@gmail.com>, <linux-cifs-client@lists.samba.org>
Cc: linux-next@vger.kernel.org, Harvey Harrison <harvey.harrison@gmail.com>,
 "David S. Miller" <davem@davemloft.net>, Jeff Layton <jlayton@redhat.com>
Subject: Re: linux-next: cifs tree build failure
Message-Id: <20081203135312.60d4518d.sfr@canb.auug.org.au>
In-Reply-To: <20081202132318.7e1581db.sfr@canb.auug.org.au>
References: <20081202132318.7e1581db.sfr@canb.auug.org.au>
X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Steve, Dave,

On Tue, 2 Dec 2008 13:23:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> fs/cifs/cifsfs.c: In function 'cifs_show_options':
> fs/cifs/cifsfs.c:363: error: 'NIP6_FMT' undeclared (first use in this function)
> fs/cifs/cifsfs.c:363: error: (Each undeclared identifier is reported only once
> fs/cifs/cifsfs.c:363: error: for each function it appears in.)
> fs/cifs/cifsfs.c:364: error: implicit declaration of function 'NIP6'
> 
> Caused by the interaction of commits
> b189db5d299c6824780af5590564ff608adb3dea ("net: remove NIP6(), NIP6_FMT,
> NIP6_SEQFMT and final users") from the net tree and
> 20c4eef4f817ff65337e2fb3f1f5df52eeca09eb ("cifs: display addr and
> prefixpath options in /proc/mounts") from the cifs tree.

Today I have fixed this by applying a merge fix patch (see below) and
will carry this as necessary.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 3 Dec 2008 13:49:23 +1100
Subject: [PATCH] cifs: update for new IP4/6 address printing

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/cifs/cifsfs.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index 061a1dc..1b09330 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -362,12 +362,12 @@ cifs_show_options(struct seq_file *s, struct vfsmount *m)
 					switch (server->addr.sockAddr6.
 						sin6_family) {
 					case AF_INET6:
-						seq_printf(s, NIP6_FMT,
-							   NIP6(server->addr.sockAddr6.sin6_addr));
+						seq_printf(s, "%pI6",
+							   &server->addr.sockAddr6.sin6_addr);
 						break;
 					case AF_INET:
-						seq_printf(s, NIPQUAD_FMT,
-							   NIPQUAD(server->addr.sockAddr.sin_addr.s_addr));
+						seq_printf(s, "%pI4",
+							   &server->addr.sockAddr.sin_addr.s_addr);
 						break;
 					}
 				}
-- 
1.5.6.5

^ permalink raw reply related

* Re: [PATCH] kbuild, sparseirq: work around GCC bug with __weak aliases
From: Paul Mackerras @ 2008-12-28 23:27 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Sam Ravnborg, Yinghai Lu, David Howells, Kamalesh Babulal,
	Andrew Morton, Stephen Rothwell, linux-next, LKML, mel
In-Reply-To: <20081227105944.GA13198@elte.hu>

Ingo Molnar writes:

> hm, does Yinghai's patch below do the trick? (also in perfcounters/core 
> and tip/master)

Yes, it seems to fix the problem.

Paul.

^ permalink raw reply

* Re: [BUG] next-20081216 - WARNING: at kernel/smp.c:333 smp_call_function_mask
From: Yinghai Lu @ 2008-12-28 23:09 UTC (permalink / raw)
  To: Kamalesh Babulal
  Cc: Ingo Molnar, Sam Ravnborg, David Howells, Andrew Morton,
	Stephen Rothwell, linux-next, LKML, mel
In-Reply-To: <20081228161119.GA29660@linux.vnet.ibm.com>

Kamalesh Babulal wrote:
> * Ingo Molnar <mingo@elte.hu> [2008-12-28 13:55:10]:
> 
>> * Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>
>>> Hi Ingo,
>>>
>>> 	kernel still crashes, with the updated patch.
>> hm, i thought we got all bugs fixed - could you try latest tip/master:
>>
>>   http://people.redhat.com/mingo/tip.git/README
>>
>> does it still crash in the same way? (if yes then please attach the new 
>> crashlog if it's easy to do)
>>
>> Thanks,
>>
>> 	Ingo
> 
> Hi Ingo/Yinghai,
> 
> 	I tried today's tip/master against 2.6.28, the kernel still crashes
> at boot up.

please try following patch on top of tip/master

YH

---

[PATCH] sparseirq: change arch_init_chip_data to pointer

Impact: fix panic

some gcc compiler will remove the weak global blank function

try to workaround it:
1. one time path: add printk
2. multi time path: change to function pointer

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/kernel/io_apic.c |    7 ++++++-
 include/linux/irq.h       |    2 +-
 init/main.c               |    4 ++++
 kernel/irq/handle.c       |    5 ++++-
 4 files changed, 15 insertions(+), 3 deletions(-)

Index: linux-2.6/arch/x86/kernel/io_apic.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/io_apic.c
+++ linux-2.6/arch/x86/kernel/io_apic.c
@@ -170,6 +170,8 @@ static struct irq_cfg irq_cfgx[NR_IRQS]
 	[15] = { .vector = IRQ15_VECTOR, },
 };
 
+static int real_arch_init_chip_data(struct irq_desc *desc, int cpu);
+
 int __init arch_early_irq_init(void)
 {
 	struct irq_cfg *cfg;
@@ -189,6 +191,9 @@ int __init arch_early_irq_init(void)
 			cpumask_setall(cfg[i].domain);
 	}
 
+#ifdef CONFIG_SPARSE_IRQ
+	arch_init_chip_data = real_arch_init_chip_data;
+#endif
 	return 0;
 }
 
@@ -232,7 +237,7 @@ static struct irq_cfg *get_one_free_irq_
 	return cfg;
 }
 
-int arch_init_chip_data(struct irq_desc *desc, int cpu)
+static int real_arch_init_chip_data(struct irq_desc *desc, int cpu)
 {
 	struct irq_cfg *cfg;
 
Index: linux-2.6/include/linux/irq.h
===================================================================
--- linux-2.6.orig/include/linux/irq.h
+++ linux-2.6/include/linux/irq.h
@@ -196,7 +196,7 @@ struct irq_desc {
 
 extern int early_irq_init(void);
 extern int arch_early_irq_init(void);
-extern int arch_init_chip_data(struct irq_desc *desc, int cpu);
+extern int (*arch_init_chip_data)(struct irq_desc *desc, int cpu);
 extern void arch_init_copy_chip_data(struct irq_desc *old_desc,
 					struct irq_desc *desc, int cpu);
 extern void arch_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc);
Index: linux-2.6/init/main.c
===================================================================
--- linux-2.6.orig/init/main.c
+++ linux-2.6/init/main.c
@@ -544,11 +544,15 @@ void __init __weak thread_info_cache_ini
 
 int __init __weak arch_early_irq_init(void)
 {
+	printk(KERN_DEBUG "calling __weak arch_early_irq_init()\n");
+
 	return 0;
 }
 
 int __init __weak early_irq_init(void)
 {
+	printk(KERN_DEBUG "calling __weak early_irq_init()\n");
+
 	return arch_early_irq_init();
 }
 
Index: linux-2.6/kernel/irq/handle.c
===================================================================
--- linux-2.6.orig/kernel/irq/handle.c
+++ linux-2.6/kernel/irq/handle.c
@@ -86,11 +86,14 @@ void init_kstat_irqs(struct irq_desc *de
 		desc->kstat_irqs = (unsigned int *)ptr;
 }
 
-int __weak arch_init_chip_data(struct irq_desc *desc, int cpu)
+static int weak_arch_init_chip_data(struct irq_desc *desc, int cpu)
 {
 	return 0;
 }
 
+int (*arch_init_chip_data)(struct irq_desc *desc, int cpu) =
+			 weak_arch_init_chip_data;
+
 static void init_one_irq_desc(int irq, struct irq_desc *desc, int cpu)
 {
 	memcpy(desc, &irq_desc_init, sizeof(struct irq_desc));

^ permalink raw reply

* linux-next: rr tree import failure
From: Stephen Rothwell @ 2008-12-28 22:16 UTC (permalink / raw)
  To: Rusty Russell; +Cc: linux-next

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

Hi Rusty,

Today's linux-next import of the rr tree filed like this:

cpumask:cpumask_of_node-x86.patch
error: patch failed: arch/x86/include/asm/pci.h:98
error: arch/x86/include/asm/pci.h: patch does not apply
error: patch failed: arch/x86/include/asm/topology.h:61
error: arch/x86/include/asm/topology.h: patch does not apply
error: patch failed: arch/x86/kernel/setup_percpu.c:334
error: arch/x86/kernel/setup_percpu.c: patch does not apply

So I have dropped the rr 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: 197 bytes --]

^ permalink raw reply

* Re: [BUG] next-20081216 - WARNING: at kernel/smp.c:333 smp_call_function_mask
From: Kamalesh Babulal @ 2008-12-28 16:11 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Yinghai Lu, Sam Ravnborg, David Howells, Andrew Morton,
	Stephen Rothwell, linux-next, LKML, mel
In-Reply-To: <20081228125510.GA10387@elte.hu>

* Ingo Molnar <mingo@elte.hu> [2008-12-28 13:55:10]:

> 
> * Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> 
> > Hi Ingo,
> > 
> > 	kernel still crashes, with the updated patch.
> 
> hm, i thought we got all bugs fixed - could you try latest tip/master:
> 
>   http://people.redhat.com/mingo/tip.git/README
> 
> does it still crash in the same way? (if yes then please attach the new 
> crashlog if it's easy to do)
> 
> Thanks,
> 
> 	Ingo

Hi Ingo/Yinghai,

	I tried today's tip/master against 2.6.28, the kernel still crashes
at boot up.

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-autotest root=/dev/mapper/VolGroup00-LogVol00 ro console=tty0 c
onsole=ttyS1,19200 selinux=no debug nmi_watchdog=1 unknown_nmi_panic=1 initcall
_debug earlyprintk=serial,ttyS1,19200 IDENT=1230478484
   [Linux-bzImage, setup=0x3000, size=0x276670]
initrd /initrd-autotest
   [Linux-initrd @ 0x37e5f000, 0x19097f bytes]

Linux version 2.6.28-autotest-tip (root@bl6-13.ltc.austin.ibm.com) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Sun Dec 28 09:27:57 CST 2008
Command line: root=/dev/mapper/VolGroup00-LogVol00 ro console=tty0 console=ttyS1,19200 selinux=no debug nmi_watchdog=1 unknown_nmi_panic=1 initcall_debug earlyprintk=serial,ttyS1,19200 IDENT=1230478484
KERNEL supported cpus:
  Intel GenuineIntel
  AMD AuthenticAMD
  Centaur CentaurHauls
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
 BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ffcddc0 (usable)
 BIOS-e820: 000000003ffcddc0 - 000000003ffd0000 (ACPI data)
 BIOS-e820: 000000003ffd0000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
console [earlyser0] enabled
DMI 2.3 present.
last_pfn = 0x3ffcd max_arch_pfn = 0x100000000
init_memory_mapping: 0000000000000000-000000003ffcd000
 0000000000 - 003fe00000 page 2M
 003fe00000 - 003ffcd000 page 4k
kernel direct mapping tables up to 3ffcd000 @ 8000-b000
last_map_addr: 3ffcd000 end: 3ffcd000
RAMDISK: 37e5f000 - 37fef97f
ACPI: RSDP 000FDFC0, 0014 (r0 IBM   )
ACPI: RSDT 3FFCFF80, 0034 (r1 IBM    SERBLADE     1000 IBM  45444F43)
ACPI: FACP 3FFCFEC0, 0084 (r2 IBM    SERBLADE     1000 IBM  45444F43)
ACPI: DSDT 3FFCDDC0, 1EA6 (r1 IBM    SERBLADE     1000 INTL  2002025)
ACPI: FACS 3FFCFCC0, 0040
ACPI: APIC 3FFCFE00, 009C (r1 IBM    SERBLADE     1000 IBM  45444F43)
ACPI: SRAT 3FFCFD40, 0098 (r1 IBM    SERBLADE     1000 IBM  45444F43)
ACPI: HPET 3FFCFD00, 0038 (r1 IBM    SERBLADE     1000 IBM  45444F43)
ACPI: Local APIC address 0xfee00000
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: PXM 1 -> APIC 2 -> Node 1
SRAT: PXM 1 -> APIC 3 -> Node 1
SRAT: Node 0 PXM 0 0-40000000
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 0000000000000000-000000003ffcd000
  NODE_DATA [0000000000009000 - 000000000000efff]
  bootmap [000000000000f000 -  0000000000016fff] pages 8
(6 early reservations) ==> bootmem [0000000000 - 003ffcd000]
  #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
  #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]
  #2 [0000200000 - 0000977030]    TEXT DATA BSS ==> [0000200000 - 0000977030]
  #3 [0037e5f000 - 0037fef97f]          RAMDISK ==> [0037e5f000 - 0037fef97f]
  #4 [000009d400 - 0000100000]    BIOS reserved ==> [000009d400 - 0000100000]
  #5 [0000008000 - 0000009000]          PGTABLE ==> [0000008000 - 0000009000]
found SMP MP-table at [ffff88000009d540] 0009d540
Zone PFN ranges:
  DMA      0x00000000 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
    0: 0x00000000 -> 0x0000009d
    0: 0x00000100 -> 0x0003ffcd
On node 0 totalpages: 261994
  DMA zone: 64 pages used for memmap
  DMA zone: 2015 pages reserved
  DMA zone: 1918 pages, LIFO batch:0
  DMA32 zone: 4032 pages used for memmap
  DMA32 zone: 253965 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
Detected use of extended apic ids on hypertransport bus
Detected use of extended apic ids on hypertransport bus
ACPI: PM-Timer IO Port: 0x2208
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x0e] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 14, version 0, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x0d] address[0xfec10000] gsi_base[24])
IOAPIC[1]: apic_id 13, version 0, address 0xfec10000, GSI 24-27
ACPI: IOAPIC (id[0x0c] address[0xfec20000] gsi_base[48])
IOAPIC[2]: apic_id 12, version 0, address 0xfec20000, GSI 48-51
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ11 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x10228203 base: 0xfecff000
SMP: Allowing 4 CPUs, 0 hotplug CPUs
Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
NR_CPUS:255 nr_cpumask_bits:255 nr_cpu_ids:4 nr_node_ids:1
PERCPU: Allocating 65536 bytes of per cpu data
per cpu data for cpu0 on node0 at 000000000100e000
per cpu data for cpu1 on node0 at 000000000101e000
per cpu data for cpu2 on node0 at 000000000102e000
per cpu data for cpu3 on node0 at 000000000103e000
Built 1 zonelists in Node order, mobility grouping on.  Total pages: 255883
Policy zone: DMA32
Kernel command line: root=/dev/mapper/VolGroup00-LogVol00 ro console=tty0 console=ttyS1,19200 selinux=no debug nmi_watchdog=1 unknown_nmi_panic=1 initcall_debug earlyprintk=serial,ttyS1,19200 IDENT=1230478484
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Fast TSC calibration using PIT
Detected 1993.984 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Linux version 2.6.28-autotest-tip (root@bl6-13.ltc.austin.ibm.com) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Sun Dec 28 09:27:57 CST 2008
Command line: root=/dev/mapper/VolGroup00-LogVol00 ro console=tty0 console=ttyS1,19200 selinux=no debug nmi_watchdog=1 unknown_nmi_panic=1 initcall_debug earlyprintk=serial,ttyS1,19200 IDENT=1230478484
KERNEL supported cpus:
  Intel GenuineIntel
  AMD AuthenticAMD
  Centaur CentaurHauls
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
 BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ffcddc0 (usable)
 BIOS-e820: 000000003ffcddc0 - 000000003ffd0000 (ACPI data)
 BIOS-e820: 000000003ffd0000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
console [earlyser0] enabled
DMI 2.3 present.
last_pfn = 0x3ffcd max_arch_pfn = 0x100000000
init_memory_mapping: 0000000000000000-000000003ffcd000
 0000000000 - 003fe00000 page 2M
 003fe00000 - 003ffcd000 page 4k
kernel direct mapping tables up to 3ffcd000 @ 8000-b000
last_map_addr: 3ffcd000 end: 3ffcd000
RAMDISK: 37e5f000 - 37fef97f
ACPI: RSDP 000FDFC0, 0014 (r0 IBM   )
ACPI: RSDT 3FFCFF80, 0034 (r1 IBM    SERBLADE     1000 IBM  45444F43)
ACPI: FACP 3FFCFEC0, 0084 (r2 IBM    SERBLADE     1000 IBM  45444F43)
ACPI: DSDT 3FFCDDC0, 1EA6 (r1 IBM    SERBLADE     1000 INTL  2002025)
ACPI: FACS 3FFCFCC0, 0040
ACPI: APIC 3FFCFE00, 009C (r1 IBM    SERBLADE     1000 IBM  45444F43)
ACPI: SRAT 3FFCFD40, 0098 (r1 IBM    SERBLADE     1000 IBM  45444F43)
ACPI: HPET 3FFCFD00, 0038 (r1 IBM    SERBLADE     1000 IBM  45444F43)
ACPI: Local APIC address 0xfee00000
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: PXM 1 -> APIC 2 -> Node 1
SRAT: PXM 1 -> APIC 3 -> Node 1
SRAT: Node 0 PXM 0 0-40000000
NUMA: Using 63 for the hash shift.
Bootmem setup node 0 0000000000000000-000000003ffcd000
  NODE_DATA [0000000000009000 - 000000000000efff]
  bootmap [000000000000f000 -  0000000000016fff] pages 8
(6 early reservations) ==> bootmem [0000000000 - 003ffcd000]
  #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
  #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]
  #2 [0000200000 - 0000977030]    TEXT DATA BSS ==> [0000200000 - 0000977030]
  #3 [0037e5f000 - 0037fef97f]          RAMDISK ==> [0037e5f000 - 0037fef97f]
  #4 [000009d400 - 0000100000]    BIOS reserved ==> [000009d400 - 0000100000]
  #5 [0000008000 - 0000009000]          PGTABLE ==> [0000008000 - 0000009000]
found SMP MP-table at [ffff88000009d540] 0009d540
Zone PFN ranges:
  DMA      0x00000000 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
    0: 0x00000000 -> 0x0000009d
    0: 0x00000100 -> 0x0003ffcd
On node 0 totalpages: 261994
  DMA zone: 64 pages used for memmap
  DMA zone: 2015 pages reserved
  DMA zone: 1918 pages, LIFO batch:0
  DMA32 zone: 4032 pages used for memmap
  DMA32 zone: 253965 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
Detected use of extended apic ids on hypertransport bus
Detected use of extended apic ids on hypertransport bus
ACPI: PM-Timer IO Port: 0x2208
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x0e] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 14, version 0, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x0d] address[0xfec10000] gsi_base[24])
IOAPIC[1]: apic_id 13, version 0, address 0xfec10000, GSI 24-27
ACPI: IOAPIC (id[0x0c] address[0xfec20000] gsi_base[48])
IOAPIC[2]: apic_id 12, version 0, address 0xfec20000, GSI 48-51
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ11 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x10228203 base: 0xfecff000
SMP: Allowing 4 CPUs, 0 hotplug CPUs
Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
NR_CPUS:255 nr_cpumask_bits:255 nr_cpu_ids:4 nr_node_ids:1
PERCPU: Allocating 65536 bytes of per cpu data
per cpu data for cpu0 on node0 at 000000000100e000
per cpu data for cpu1 on node0 at 000000000101e000
per cpu data for cpu2 on node0 at 000000000102e000
per cpu data for cpu3 on node0 at 000000000103e000
Built 1 zonelists in Node order, mobility grouping on.  Total pages: 255883
Policy zone: DMA32
Kernel command line: root=/dev/mapper/VolGroup00-LogVol00 ro console=tty0 console=ttyS1,19200 selinux=no debug nmi_watchdog=1 unknown_nmi_panic=1 initcall_debug earlyprintk=serial,ttyS1,19200 IDENT=1230478484
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Fast TSC calibration using PIT
Detected 1993.984 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console handover: boot [earlyser0] -> real [ttyS1]
Checking aperture...
No AGP bridge found
Node 0: aperture @ dc000000 size 64 MB
Node 1: aperture @ dc000000 size 64 MB
Memory: 1021920k/1048372k available (3245k kernel code, 396k absent, 26056k reserved, 2111k data, 456k init)
SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
hpet clockevent registered
Calibrating delay loop (skipped), value calculated using timer frequency.. 3987.96 BogoMIPS (lpj=7975936)
Security Framework initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0/0x0 -> Node 0
tseg: 0000000000
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
ACPI: Core revision 20080926
Setting APIC routing to flat
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
IP: [<ffffffff8021f9a8>] add_pin_to_irq_cpu+0x14/0x74
PGD 0 
Oops: 0000 [#1] SMP 
last sysfs file: 
CPU 0 
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.28-autotest-tip #1
RIP: 0010:[<ffffffff8021f9a8>]  [<ffffffff8021f9a8>] add_pin_to_irq_cpu+0x14/0x74
RSP: 0018:ffff88003f9d7e40  EFLAGS: 00010282
RAX: ffffffff8073c300 RBX: 0000000000000001 RCX: 0000000000000001
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000018 R09: 0000000000000002
R10: 000000000000000f R11: ffffffff8021e8aa R12: 0000000000000001
R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff80855480(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff88003f9d6000, task ffff88003f9d8000)
Stack:
 0000000000000000 0000000000000001 ffffffff8073c300 0000000000000001
 0000000000000001 ffffffff80874282 0000000000000286 0000000000000286
 0000000000010000 0000000000000206 0000000000000002 0000000000000002
Call Trace:
 [<ffffffff80874282>] setup_IO_APIC+0x12f/0x720
 [<ffffffff80525711>] _spin_lock_irqsave+0x9/0xe
 [<ffffffff8022221b>] get_apic_id+0x0/0x9
 [<ffffffff8087116f>] native_smp_prepare_cpus+0x256/0x2f1
 [<ffffffff808637ca>] kernel_init+0x50/0x1eb
 [<ffffffff8020ce9a>] child_rip+0xa/0x20
 [<ffffffff8086377a>] kernel_init+0x0/0x1eb
 [<ffffffff8020ce90>] child_rip+0x0/0x20
Code: 48 c7 c7 75 3c 5f 80 31 c0 e8 08 8d 01 00 5b 4c 89 e0 41 5c 41 5d c3 41 55 49 89 fd 89 f7 41 54 41 89 cc 55 89 d5 53 48 83 ec 08 <49> 8b 5d 00 48 85 db 75 36 e8 88 ff ff ff 48 85 c0 75 19 41 5b 
RIP  [<ffffffff8021f9a8>] add_pin_to_irq_cpu+0x14/0x74
 RSP <ffff88003f9d7e40>
CR2: 0000000000000000
---[ end trace 4eaa2a86a8e2da22 ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G      D    2.6.28-autotest-tip #1
Call Trace:
 [<ffffffff80237b4d>] panic+0x86/0x144
 [<ffffffff802373f4>] mm_release+0x3f/0xd3
 [<ffffffff802393b2>] exit_fs+0x35/0x46
 [<ffffffff8023a842>] do_exit+0x75/0x787
 [<ffffffff805262ce>] oops_end+0xa8/0xad
 [<ffffffff80527b1d>] do_page_fault+0x756/0x80f
 [<ffffffff805258df>] page_fault+0x1f/0x30
 [<ffffffff8021e8aa>] native_apic_mem_write+0x0/0x9
 [<ffffffff8021f9a8>] add_pin_to_irq_cpu+0x14/0x74
 [<ffffffff80874282>] setup_IO_APIC+0x12f/0x720
 [<ffffffff80525711>] _spin_lock_irqsave+0x9/0xe
 [<ffffffff8022221b>] get_apic_id+0x0/0x9
 [<ffffffff8087116f>] native_smp_prepare_cpus+0x256/0x2f1
 [<ffffffff808637ca>] kernel_init+0x50/0x1eb
 [<ffffffff8020ce9a>] child_rip+0xa/0x20
 [<ffffffff8086377a>] kernel_init+0x0/0x1eb
 [<ffffffff8020ce90>] child_rip+0x0/0x20
-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

^ permalink raw reply

* Re: [BUG] next-20081216 - WARNING: at kernel/smp.c:333 smp_call_function_mask
From: Ingo Molnar @ 2008-12-28 12:55 UTC (permalink / raw)
  To: Kamalesh Babulal
  Cc: Yinghai Lu, Sam Ravnborg, David Howells, Andrew Morton,
	Stephen Rothwell, linux-next, LKML, mel
In-Reply-To: <20081227152918.GD4530@linux.vnet.ibm.com>


* Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:

> Hi Ingo,
> 
> 	kernel still crashes, with the updated patch.

hm, i thought we got all bugs fixed - could you try latest tip/master:

  http://people.redhat.com/mingo/tip.git/README

does it still crash in the same way? (if yes then please attach the new 
crashlog if it's easy to do)

Thanks,

	Ingo

^ permalink raw reply

* Re: [PATCH] sparc64: use unsigned long long for u64
From: Sam Ravnborg @ 2008-12-28 12:32 UTC (permalink / raw)
  To: David Miller
  Cc: akpm, sparclinux, mingo, sfr, linux-kernel, kenchen, paulus, tglx,
	hpa, linux-next
In-Reply-To: <20081227.202552.27482357.davem@davemloft.net>

On Sat, Dec 27, 2008 at 08:25:52PM -0800, David Miller wrote:
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Sat, 27 Dec 2008 10:49:55 +0100
> 
> > I have ordered a used Sun Blade 100(*) that should show up
> > before new eve.
> > So when I have it and it is up and running I will redo this
> > patch set. That will likely take a few weeks though.
> 
> Another option, of course, is to use 64-bit cross tools
> on an x86_64 system if you have access to one of those.
It needs a new motherboard and I used my savings on a Sun blade...

> 
> > (*) Any distribution recommendations? I will only use it for
> >     sparc kernel development so nothing fancy...
> 
> Debian testing works fine, and that's what I'm typing this
> on.
Thanks!

	Sam

^ permalink raw reply

* Re: [PATCH] sparc64: use unsigned long long for u64
From: David Miller @ 2008-12-28  4:25 UTC (permalink / raw)
  To: sam
  Cc: akpm, sparclinux, mingo, sfr, linux-kernel, kenchen, paulus, tglx,
	hpa, linux-next
In-Reply-To: <20081227094955.GA1355@uranus.ravnborg.org>

From: Sam Ravnborg <sam@ravnborg.org>
Date: Sat, 27 Dec 2008 10:49:55 +0100

> I have ordered a used Sun Blade 100(*) that should show up
> before new eve.
> So when I have it and it is up and running I will redo this
> patch set. That will likely take a few weeks though.

Another option, of course, is to use 64-bit cross tools
on an x86_64 system if you have access to one of those.

> (*) Any distribution recommendations? I will only use it for
>     sparc kernel development so nothing fancy...

Debian testing works fine, and that's what I'm typing this
on.

^ permalink raw reply

* linux-next: 2.6.30 inclusions
From: Stephen Rothwell @ 2008-12-27 23:46 UTC (permalink / raw)
  To: LKML; +Cc: linux-next

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

Hi all,

Just a reminder that I do *not* want anything destined for 2.6.30 in
linux-next until (at least) 2.6.29-rc1 is released.  We should give the
current trees a chance to drain :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: [BUG] next-20081216 - WARNING: at kernel/smp.c:333 smp_call_function_mask
From: Yinghai Lu @ 2008-12-27 21:10 UTC (permalink / raw)
  To: Kamalesh Babulal, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
	Andrew Morton
  Cc: Sam Ravnborg, David Howells, Stephen Rothwell, linux-next, LKML,
	mel
In-Reply-To: <20081227152918.GD4530@linux.vnet.ibm.com>

On Sat, Dec 27, 2008 at 7:29 AM, Kamalesh Babulal
<kamalesh@linux.vnet.ibm.com> wrote:
> * Ingo Molnar <mingo@elte.hu> [2008-12-27 13:26:32]:
>
>>
>> * Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>
>> > > yes, indeed - updated patch below.
>> > >
>> > >   Ingo
>> > >
>> >
>> > Hi Ingo,
>> >
>> >     Sorry, for not mentioning that the previous kernel trace, was
>> > after adding the return statement to the arch_init_chip_data().
>>
>> ah, i missed that detail. There was a stupid typo in one of the conflict
>> resolutions i had to do - could you check the updated patch below?
>>
>> Thanks,
>>
>>       Ingo
>>
>
>
> Hi Ingo,
>
>        kernel still crashes, with the updated patch.
>
>
>> ----------->
>> From 13a0c3c269b223f60abfac8a9811d77111a8b4ba Mon Sep 17 00:00:00 2001
>> From: Yinghai Lu <yinghai@kernel.org>
>> Date: Fri, 26 Dec 2008 02:05:47 -0800
>> Subject: [PATCH] sparseirq: work around compiler optimizing away __weak functions
>>
>> Impact: fix panic on null pointer with sparseirq
>>
>> Some GCC versions seem to inline the weak global function,
>> when that function is empty.
>>
>> Work it around, by making the functions return a (dummy) integer.
>>
>> Signed-off-by: Yinghai <yinghai@kernel.org>
>> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>> ---
>>  arch/x86/kernel/io_apic.c |    8 ++++++--
>>  include/linux/irq.h       |    6 +++---
>>  init/main.c               |    7 ++++---
>>  kernel/irq/handle.c       |    7 ++++---
>>  4 files changed, 17 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/x86/kernel/io_apic.c b/arch/x86/kernel/io_apic.c
>> index 2fe543f..9760393 100644
>> --- a/arch/x86/kernel/io_apic.c
>> +++ b/arch/x86/kernel/io_apic.c
>> @@ -170,7 +170,7 @@ static struct irq_cfg irq_cfgx[NR_IRQS] = {
>>       [15] = { .domain = CPU_MASK_ALL, .vector = IRQ15_VECTOR, },
>>  };
>>
>> -void __init arch_early_irq_init(void)
>> +int __init arch_early_irq_init(void)
>>  {
>>       struct irq_cfg *cfg;
>>       struct irq_desc *desc;
>> @@ -184,6 +184,8 @@ void __init arch_early_irq_init(void)
>>               desc = irq_to_desc(i);
>>               desc->chip_data = &cfg[i];
>>       }
>> +
>> +     return 0;

can you try current tip/master?

current there are several blank __weak, and __weak + return 0..in the
whole tree.

it seems there three solution:
1. use printk?
2. not use __weak with blank function any more, and use #ifdef and
inline functions instead
3. blacklist that gcc 4.1.1 complier..

YH

^ permalink raw reply

* Re: [BUG] next-20081216 - WARNING: at kernel/smp.c:333 smp_call_function_mask
From: Kamalesh Babulal @ 2008-12-27 15:29 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Yinghai Lu, Sam Ravnborg, David Howells, Andrew Morton,
	Stephen Rothwell, linux-next, LKML, mel
In-Reply-To: <20081227122632.GA18909@elte.hu>

* Ingo Molnar <mingo@elte.hu> [2008-12-27 13:26:32]:

> 
> * Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> 
> > > yes, indeed - updated patch below.
> > > 
> > > 	Ingo
> > > 
> > 
> > Hi Ingo,
> > 
> > 	Sorry, for not mentioning that the previous kernel trace, was 
> > after adding the return statement to the arch_init_chip_data().
> 
> ah, i missed that detail. There was a stupid typo in one of the conflict 
> resolutions i had to do - could you check the updated patch below?
> 
> Thanks,
> 
> 	Ingo
>


Hi Ingo,

	kernel still crashes, with the updated patch.


> ----------->
> From 13a0c3c269b223f60abfac8a9811d77111a8b4ba Mon Sep 17 00:00:00 2001
> From: Yinghai Lu <yinghai@kernel.org>
> Date: Fri, 26 Dec 2008 02:05:47 -0800
> Subject: [PATCH] sparseirq: work around compiler optimizing away __weak functions
> 
> Impact: fix panic on null pointer with sparseirq
> 
> Some GCC versions seem to inline the weak global function,
> when that function is empty.
> 
> Work it around, by making the functions return a (dummy) integer.
> 
> Signed-off-by: Yinghai <yinghai@kernel.org>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  arch/x86/kernel/io_apic.c |    8 ++++++--
>  include/linux/irq.h       |    6 +++---
>  init/main.c               |    7 ++++---
>  kernel/irq/handle.c       |    7 ++++---
>  4 files changed, 17 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/x86/kernel/io_apic.c b/arch/x86/kernel/io_apic.c
> index 2fe543f..9760393 100644
> --- a/arch/x86/kernel/io_apic.c
> +++ b/arch/x86/kernel/io_apic.c
> @@ -170,7 +170,7 @@ static struct irq_cfg irq_cfgx[NR_IRQS] = {
>  	[15] = { .domain = CPU_MASK_ALL, .vector = IRQ15_VECTOR, },
>  };
> 
> -void __init arch_early_irq_init(void)
> +int __init arch_early_irq_init(void)
>  {
>  	struct irq_cfg *cfg;
>  	struct irq_desc *desc;
> @@ -184,6 +184,8 @@ void __init arch_early_irq_init(void)
>  		desc = irq_to_desc(i);
>  		desc->chip_data = &cfg[i];
>  	}
> +
> +	return 0;
>  }
> 
>  #ifdef CONFIG_SPARSE_IRQ
> @@ -212,7 +214,7 @@ static struct irq_cfg *get_one_free_irq_cfg(int cpu)
>  	return cfg;
>  }
> 
> -void arch_init_chip_data(struct irq_desc *desc, int cpu)
> +int arch_init_chip_data(struct irq_desc *desc, int cpu)
>  {
>  	struct irq_cfg *cfg;
> 
> @@ -224,6 +226,8 @@ void arch_init_chip_data(struct irq_desc *desc, int cpu)
>  			BUG_ON(1);
>  		}
>  	}
> +
> +	return 0;
>  }
> 
>  #ifdef CONFIG_NUMA_MIGRATE_IRQ_DESC
> diff --git a/include/linux/irq.h b/include/linux/irq.h
> index 69da275..0e40af4 100644
> --- a/include/linux/irq.h
> +++ b/include/linux/irq.h
> @@ -193,9 +193,9 @@ struct irq_desc {
>  	const char		*name;
>  } ____cacheline_internodealigned_in_smp;
> 
> -extern void early_irq_init(void);
> -extern void arch_early_irq_init(void);
> -extern void arch_init_chip_data(struct irq_desc *desc, int cpu);
> +extern int early_irq_init(void);
> +extern int arch_early_irq_init(void);
> +extern int arch_init_chip_data(struct irq_desc *desc, int cpu);
>  extern void arch_init_copy_chip_data(struct irq_desc *old_desc,
>  					struct irq_desc *desc, int cpu);
>  extern void arch_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc);
> diff --git a/init/main.c b/init/main.c
> index c1f999a..c314aa1 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -539,13 +539,14 @@ void __init __weak thread_info_cache_init(void)
>  {
>  }
> 
> -void __init __weak arch_early_irq_init(void)
> +int __init __weak arch_early_irq_init(void)
>  {
> +	return 0;
>  }
> 
> -void __init __weak early_irq_init(void)
> +int __init __weak early_irq_init(void)
>  {
> -	arch_early_irq_init();
> +	return arch_early_irq_init();
>  }
> 
>  asmlinkage void __init start_kernel(void)
> diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
> index 893da67..0bef3ec 100644
> --- a/kernel/irq/handle.c
> +++ b/kernel/irq/handle.c
> @@ -86,8 +86,9 @@ void init_kstat_irqs(struct irq_desc *desc, int cpu, int nr)
>  		desc->kstat_irqs = (unsigned int *)ptr;
>  }
> 
> -void __attribute__((weak)) arch_init_chip_data(struct irq_desc *desc, int cpu)
> +int __weak arch_init_chip_data(struct irq_desc *desc, int cpu)
>  {
> +	return 0;
>  }
> 
>  static void init_one_irq_desc(int irq, struct irq_desc *desc, int cpu)
> @@ -132,7 +133,7 @@ static struct irq_desc irq_desc_legacy[NR_IRQS_LEGACY] __cacheline_aligned_in_sm
>  /* FIXME: use bootmem alloc ...*/
>  static unsigned int kstat_irqs_legacy[NR_IRQS_LEGACY][NR_CPUS];
> 
> -void __init early_irq_init(void)
> +int __init early_irq_init(void)
>  {
>  	struct irq_desc *desc;
>  	int legacy_count;
> @@ -151,7 +152,7 @@ void __init early_irq_init(void)
>  	for (i = legacy_count; i < NR_IRQS; i++)
>  		irq_desc_ptrs[i] = NULL;
> 
> -	arch_early_irq_init();
> +	return arch_early_irq_init();
>  }
> 
>  struct irq_desc *irq_to_desc(unsigned int irq)
> 
> --
> 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/

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

^ permalink raw reply

* Re: [BUG] next-20081216 - WARNING: at kernel/smp.c:333 smp_call_function_mask
From: Ingo Molnar @ 2008-12-27 12:26 UTC (permalink / raw)
  To: Kamalesh Babulal
  Cc: Yinghai Lu, Sam Ravnborg, David Howells, Andrew Morton,
	Stephen Rothwell, linux-next, LKML, mel
In-Reply-To: <20081227115712.GC4530@linux.vnet.ibm.com>


* Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:

> > yes, indeed - updated patch below.
> > 
> > 	Ingo
> > 
> 
> Hi Ingo,
> 
> 	Sorry, for not mentioning that the previous kernel trace, was 
> after adding the return statement to the arch_init_chip_data().

ah, i missed that detail. There was a stupid typo in one of the conflict 
resolutions i had to do - could you check the updated patch below?

Thanks,

	Ingo

----------->
>From 13a0c3c269b223f60abfac8a9811d77111a8b4ba Mon Sep 17 00:00:00 2001
From: Yinghai Lu <yinghai@kernel.org>
Date: Fri, 26 Dec 2008 02:05:47 -0800
Subject: [PATCH] sparseirq: work around compiler optimizing away __weak functions

Impact: fix panic on null pointer with sparseirq

Some GCC versions seem to inline the weak global function,
when that function is empty.

Work it around, by making the functions return a (dummy) integer.

Signed-off-by: Yinghai <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/kernel/io_apic.c |    8 ++++++--
 include/linux/irq.h       |    6 +++---
 init/main.c               |    7 ++++---
 kernel/irq/handle.c       |    7 ++++---
 4 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/io_apic.c b/arch/x86/kernel/io_apic.c
index 2fe543f..9760393 100644
--- a/arch/x86/kernel/io_apic.c
+++ b/arch/x86/kernel/io_apic.c
@@ -170,7 +170,7 @@ static struct irq_cfg irq_cfgx[NR_IRQS] = {
 	[15] = { .domain = CPU_MASK_ALL, .vector = IRQ15_VECTOR, },
 };
 
-void __init arch_early_irq_init(void)
+int __init arch_early_irq_init(void)
 {
 	struct irq_cfg *cfg;
 	struct irq_desc *desc;
@@ -184,6 +184,8 @@ void __init arch_early_irq_init(void)
 		desc = irq_to_desc(i);
 		desc->chip_data = &cfg[i];
 	}
+
+	return 0;
 }
 
 #ifdef CONFIG_SPARSE_IRQ
@@ -212,7 +214,7 @@ static struct irq_cfg *get_one_free_irq_cfg(int cpu)
 	return cfg;
 }
 
-void arch_init_chip_data(struct irq_desc *desc, int cpu)
+int arch_init_chip_data(struct irq_desc *desc, int cpu)
 {
 	struct irq_cfg *cfg;
 
@@ -224,6 +226,8 @@ void arch_init_chip_data(struct irq_desc *desc, int cpu)
 			BUG_ON(1);
 		}
 	}
+
+	return 0;
 }
 
 #ifdef CONFIG_NUMA_MIGRATE_IRQ_DESC
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 69da275..0e40af4 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -193,9 +193,9 @@ struct irq_desc {
 	const char		*name;
 } ____cacheline_internodealigned_in_smp;
 
-extern void early_irq_init(void);
-extern void arch_early_irq_init(void);
-extern void arch_init_chip_data(struct irq_desc *desc, int cpu);
+extern int early_irq_init(void);
+extern int arch_early_irq_init(void);
+extern int arch_init_chip_data(struct irq_desc *desc, int cpu);
 extern void arch_init_copy_chip_data(struct irq_desc *old_desc,
 					struct irq_desc *desc, int cpu);
 extern void arch_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc);
diff --git a/init/main.c b/init/main.c
index c1f999a..c314aa1 100644
--- a/init/main.c
+++ b/init/main.c
@@ -539,13 +539,14 @@ void __init __weak thread_info_cache_init(void)
 {
 }
 
-void __init __weak arch_early_irq_init(void)
+int __init __weak arch_early_irq_init(void)
 {
+	return 0;
 }
 
-void __init __weak early_irq_init(void)
+int __init __weak early_irq_init(void)
 {
-	arch_early_irq_init();
+	return arch_early_irq_init();
 }
 
 asmlinkage void __init start_kernel(void)
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 893da67..0bef3ec 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -86,8 +86,9 @@ void init_kstat_irqs(struct irq_desc *desc, int cpu, int nr)
 		desc->kstat_irqs = (unsigned int *)ptr;
 }
 
-void __attribute__((weak)) arch_init_chip_data(struct irq_desc *desc, int cpu)
+int __weak arch_init_chip_data(struct irq_desc *desc, int cpu)
 {
+	return 0;
 }
 
 static void init_one_irq_desc(int irq, struct irq_desc *desc, int cpu)
@@ -132,7 +133,7 @@ static struct irq_desc irq_desc_legacy[NR_IRQS_LEGACY] __cacheline_aligned_in_sm
 /* FIXME: use bootmem alloc ...*/
 static unsigned int kstat_irqs_legacy[NR_IRQS_LEGACY][NR_CPUS];
 
-void __init early_irq_init(void)
+int __init early_irq_init(void)
 {
 	struct irq_desc *desc;
 	int legacy_count;
@@ -151,7 +152,7 @@ void __init early_irq_init(void)
 	for (i = legacy_count; i < NR_IRQS; i++)
 		irq_desc_ptrs[i] = NULL;
 
-	arch_early_irq_init();
+	return arch_early_irq_init();
 }
 
 struct irq_desc *irq_to_desc(unsigned int irq)

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox