Re: [PATCH powerpc] fix unpaired __trace_hcall_entry and __trace_hcall_exit
On Mon, 2011-12-19 at 10:06 +0800, Li Zhong wrote: > Unpaired calling of __trace_hcall_entry and __trace_hcall_exit could > cause incorrect preempt count. And it might happen as the global > variable hcall_tracepoint_refcount is checked separately before calling > them. > > I don't know much about the powerpc arch. But the idea here is to store > the hcall_tracepoint_refcount locally, so __trace_hcall_entry and > __trace_hcall_exit will be called or not called in pair by checking the > same value. Can you re-use an existing spot in the stack frame rather than adding this entry ? There's plenty of unused spots :-) For example the link editor doubleword is never going to be used in that function, we could hijack it safely. It would make the patch (and the code) simpler. Cheers, Ben. > Reported-by: Paul E. McKenney > Signed-off-by: Li Zhong > Tested-by: Paul E. McKenney > --- > arch/powerpc/platforms/pseries/hvCall.S | 20 +++- > 1 files changed, 11 insertions(+), 9 deletions(-) > > diff --git a/arch/powerpc/platforms/pseries/hvCall.S > b/arch/powerpc/platforms/pseries/hvCall.S > index fd05fde..1240bd2 100644 > --- a/arch/powerpc/platforms/pseries/hvCall.S > +++ b/arch/powerpc/platforms/pseries/hvCall.S > @@ -14,6 +14,7 @@ > #include > > #define STK_PARM(i) (48 + ((i)-3)*8) > +#define REG_SIZE(2*8) > > #ifdef CONFIG_TRACEPOINTS > > @@ -32,11 +33,12 @@ hcall_tracepoint_refcount: > * unconditional cpu feature. > */ > #define HCALL_INST_PRECALL(FIRST_REG)\ > + std r31,-8(r1); \ > BEGIN_FTR_SECTION; \ > b 1f; \ > END_FTR_SECTION(0, 1); \ > - ld r12,hcall_tracepoint_refcount@toc(r2); \ > - cmpdi r12,0; \ > + ld r31,hcall_tracepoint_refcount@toc(r2); \ > + cmpdi r31,0; \ > beq+1f; \ > mflrr0; \ > std r3,STK_PARM(r3)(r1);\ > @@ -49,9 +51,9 @@ END_FTR_SECTION(0, 1); > \ > std r10,STK_PARM(r10)(r1); \ > std r0,16(r1); \ > addir4,r1,STK_PARM(FIRST_REG); \ > - stdur1,-STACK_FRAME_OVERHEAD(r1); \ > + stdur1,-STACK_FRAME_OVERHEAD-REG_SIZE(r1); \ > bl .__trace_hcall_entry; \ > - addir1,r1,STACK_FRAME_OVERHEAD; \ > + addir1,r1,STACK_FRAME_OVERHEAD+REG_SIZE;\ > ld r0,16(r1); \ > ld r3,STK_PARM(r3)(r1);\ > ld r4,STK_PARM(r4)(r1);\ > @@ -74,8 +76,7 @@ END_FTR_SECTION(0, 1); > \ > BEGIN_FTR_SECTION; \ > b 1f; \ > END_FTR_SECTION(0, 1); \ > - ld r12,hcall_tracepoint_refcount@toc(r2); \ > - cmpdi r12,0; \ > + cmpdi r31,0; \ > beq+1f; \ > mflrr0; \ > ld r6,STK_PARM(r3)(r1);\ > @@ -83,13 +84,14 @@ END_FTR_SECTION(0, 1); > \ > mr r4,r3; \ > mr r3,r6; \ > std r0,16(r1); \ > - stdur1,-STACK_FRAME_OVERHEAD(r1); \ > + stdur1,-STACK_FRAME_OVERHEAD-REG_SIZE(r1); \ > bl .__trace_hcall_exit;\ > - addir1,r1,STACK_FRAME_OVERHEAD; \ > + addir1,r1,STACK_FRAME_OVERHEAD+REG_SIZE;\ > ld r0,16(r1); \ > ld r3,STK_PARM(r3)(r1);\ > mtlrr0; \ > -1: > +1: \ > + ld r31,-8(r1); > > #define HCALL_INST_POSTCALL_NORETS \ > li r5,0; \ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.
Problem in getting shared memory access on P1022RDK
Greetings All, Please excuse me for a 'not very precise' question but I just need some clue or point to look for the trouble. I am running linux in AMP configuration on P1022RDK dual core. My memory partitioning is given below Core Base Address (CONFIG_PHYSICAL_START / bootm_low) Size (bootm_size / mem kernel boot parameter) Core 0 0x, 0x1000, Core 1 0x1000, 0x0C00, Shared Memory 0x1C00, 0x0400, I have set bootm_low / bootm_size and provided mem parameter in both kernel configurations, both kernels are booting up fine. I have a shared memory driver running in both cores. My shared memory driver just exposes the physical memory (0x1C00,) to user-space. The problem I am facing is I can not get access to same shared memory in user-space on both kernels. I have verified my shared memory driver on another platform (p1022ds) and it works perfect. I have also tried using non-cached memory mapping in shared memory driver but that does not work as well. To me it seems one of my kernels is going beyond its defined memory partition (which I have set above), I have set kernel's partitioning as CONFIG_PHYSICAL_START, bootm_size, bootm_low and mem kernel boot param. Besides the shared memory driver, can anyone suggest or give me clue where should I look for the trouble in the kernel. Regards, Farrukh Arshad. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] DTS: fix the bug and add the chip compatible for eSDHC
On Fri, Dec 23, 2011 at 12:10 AM, wrote: > > Accordint to latest kernel, the auto-cmd12 property should be > "sdhci,auto-cmd12", and according to the SDHC binding and the workaround for > the special chip, add the chip compatible for eSDHC: "fsl,p1022-esdhc", > "fsl,mpc8536-esdhc", "fsl,p2020-esdhc" and "fsl,p1010-esdhc". Please do not use the phrase "fix the bug" in patch summaries. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] DTS: fix the bug and add the chip compatible for eSDHC
On 12/23/2011 12:10 AM, r66...@freescale.com wrote:
> From: Jerry Huang
>
> Accordint to latest kernel, the auto-cmd12 property should be
> "sdhci,auto-cmd12", and according to the SDHC binding and the workaround for
> the special chip, add the chip compatible for eSDHC: "fsl,p1022-esdhc",
> "fsl,mpc8536-esdhc", "fsl,p2020-esdhc" and "fsl,p1010-esdhc".
>
> Signed-off-by: Jerry Huang
> ---
> arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi |4
> arch/powerpc/boot/dts/fsl/p1010si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/p1022si-post.dtsi |3 ++-
> arch/powerpc/boot/dts/fsl/p2020si-post.dtsi |4
> 4 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> index 89af626..44e0ed9 100644
> --- a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
> @@ -236,6 +236,10 @@
> };
>
> /include/ "pq3-esdhc-0.dtsi"
> + sdhc@2e000 {
> + compatible = "fsl,esdhc", "fsl,mpc8536-esdhc";
> + };
More-specific compatible entries should come first.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mac address in the DTS file
On 12/30/2011 06:51 AM, smitha.va...@wipro.com wrote:
>
> Hi Scott,
>
> In my DTS file for mpc8247 I have defined the ether MAC in the node as below.
>
> ethernet@24000 {
>#address-cells = <1>;
>#size-cells = <0>;
>device_type = "network";
>device-id = <1>;
>compatible = "fs_enet";
>model = "FCC";
>reg = <11300 20 8400 100 11380 30>;
>mac-address = [ 00 e0 ee 00 05 2e ];
>interrupts = <20 2>;
>interrupt-parent = <10c00>;
>phy-handle = <2452000>;
>rx-clock = <13>;
>tx-clock = <12>;
>};
Others have answered your question (the mac address should not be in the
.dts file -- it should be patched in by boot software), but I'd like to
point out that this is a deprecated device tree binding that was very
short-lived in a very old kernel, from an early attempt at 82xx support
in arch/powerpc. Why are you still using it? It will not work with
current kernels (which suggests you're also using a very old kernel).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2][v2] Integrated Flash Controller support
On 12/28/2011 07:30 AM, dmitry pervushin wrote: > If you're using memory-mapped structure, shouldn't it be announced with > __attribute__(packed) ? Why? We know this isn't going to be compiled on some strange ABI where a struct with nothing but u32 gets padding. __attribute__((packed)) also tells GCC the struct itself could be unaligned which is not true. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: Move gfn_to_memslot() to kvm_host.h
On 01/02/2012 05:23 PM, Alexander Graf wrote: > > Or we could move the implementation into a header file, with an extra __ > > prefix, and have the C stubs call those inlines, so we have exactly on > > instantiation. Your real mode code can then call the inlines. > > I like this version. That way everyone should be happy :) Pretty much how everything is solved. Pile up another layer of indirection (compile-time here), everyone's happy, and the code bloats. (I'm not against this, just grumpy) -- error compiling committee.c: too many arguments to function ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mac address change in linux
Hi Smitha, first of: please try changing the MAC of the adapter, not of the virtual interface (btw: are you sure, that you really intend to have a physical and a virtual interface that have the same configurations and the same metric?). second: guess your copy+pasted log shows: that you concatenated "ifconfig eth0.246 up" to the actual MAC address change command by accident. Please try again, without these additional (surely non working) parameters. Regards, lorenz On 1/2/2012 12:24 PM, smitha.va...@wipro.com wrote: Hi Scott, When I execute below statements in linux to change the mac address I get the error Host name look up error. Below are the commands I execute to change the mac address and the console output. 1. ifconfig eth0.246 down 2. ifconfig eth0.246 hw ether 00:11:22:33:44:55 ifconfig: hw: Host name lookup failure sh-3.1# ifconfig eth0 Link encap:Ethernet HWaddr 00:E0:EE:00:05:2E inet addr:172.16.52.20 Bcast:172.16.53.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:999 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:93661 (91.4 KiB) TX bytes:0 (0.0 B) eth0.246 Link encap:Ethernet HWaddr 00:E0:EE:00:05:2E inet addr:172.16.52.20 Bcast:172.16.53.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:248 (248.0 B) TX bytes:248 (248.0 B) sh-3.1# ifconfig eth0.246 down sh-3.1# ifconfig eth0 Link encap:Ethernet HWaddr 00:E0:EE:00:05:2E inet addr:172.16.52.20 Bcast:172.16.53.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1005 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:94205 (91.9 KiB) TX bytes:0 (0.0 B) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:248 (248.0 B) TX bytes:248 (248.0 B) sh-3.1# ifconfig eth0.246 hw ether 00:11:22:33:44:55 ifconfig eth0.246 up ifconfig: hw: Host name lookup failure sh-3.1# Regards, Smitha Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] KVM: Move gfn_to_memslot() to kvm_host.h
On 26.12.2011, at 14:22, Avi Kivity wrote: > On 12/20/2011 11:21 AM, Paul Mackerras wrote: >> This moves gfn_to_memslot(), and the functions it calls, that is, >> search_memslots() and __gfn_to_memslot(), from kvm_main.c to kvm_host.h >> so that gfn_to_memslot() can be called from non-modular code even >> when KVM is a module. On powerpc, the Book3S HV style of KVM has >> code that is called from real mode which needs to call gfn_to_memslot() >> and thus needs this. (Module code is allocated in the vmalloc region, >> which can't be accessed in real mode.) >> >> With this, we can remove builtin_gfn_to_memslot() from book3s_hv_rm_mmu.c >> and thus eliminate a little bit of duplication. > > Those functions are too big to be inlined IMO. How about moving them to > another C file, and making it builtin for ppc? > > The only issue is what to call it. virt/kvm/builtin-for-ppc seems silly. Yeah - and it makes it pretty confusing to find the functions then. > Or we could move the implementation into a header file, with an extra __ > prefix, and have the C stubs call those inlines, so we have exactly on > instantiation. Your real mode code can then call the inlines. I like this version. That way everyone should be happy :) Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: p1020 unstable with 3.2
On 28.12.2011, at 06:01, Benjamin Herrenschmidt wrote: > On Sun, 2011-12-25 at 11:48 +0100, Alexander Graf wrote: >> On 24.12.2011, at 07:53, Benjamin Herrenschmidt wrote: >> >>> On Fri, 2011-12-23 at 17:54 +0100, Alexander Graf wrote: Hi guys, While trying to test my latest patch queue for ppc kvm, I realized that even though the device trees got updated, the p1020 box still is unstable. The trace below is the one I've seen the most. It only occurs during network I/O which happens a lot on that box, since I'm running it using NFS root. As for configuration, I use kumar's "merge" branch from today and the p1020rdb.dts device tree provided in that tree. The last known good configuration I'm aware of is 3.0. Any ideas what's going wrong here? >>> >>> Try SLAB instead of SLUB and let me know. It -could- be a bogon in SLUB >>> that should be fixed upstream now but I think did hit 3.2 >> >> Yup, things seem a lot more stable with SLAB now :). > > BTW. Fix for slub should be upstream: > > 42d623a8cd08eb93ab221d22cee5a62618895bbf Yup, works like a charm now again. Thanks a lot! Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Mac address change in linux
Hi Scott, When I execute below statements in linux to change the mac address I get the error Host name look up error. Below are the commands I execute to change the mac address and the console output. 1. ifconfig eth0.246 down 2. ifconfig eth0.246 hw ether 00:11:22:33:44:55 ifconfig: hw: Host name lookup failure sh-3.1# ifconfig eth0 Link encap:Ethernet HWaddr 00:E0:EE:00:05:2E inet addr:172.16.52.20 Bcast:172.16.53.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:999 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:93661 (91.4 KiB) TX bytes:0 (0.0 B) eth0.246 Link encap:Ethernet HWaddr 00:E0:EE:00:05:2E inet addr:172.16.52.20 Bcast:172.16.53.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:248 (248.0 B) TX bytes:248 (248.0 B) sh-3.1# ifconfig eth0.246 down sh-3.1# ifconfig eth0 Link encap:Ethernet HWaddr 00:E0:EE:00:05:2E inet addr:172.16.52.20 Bcast:172.16.53.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1005 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:94205 (91.9 KiB) TX bytes:0 (0.0 B) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:248 (248.0 B) TX bytes:248 (248.0 B) sh-3.1# ifconfig eth0.246 hw ether 00:11:22:33:44:55 ifconfig eth0.246 up ifconfig: hw: Host name lookup failure sh-3.1# Regards, Smitha Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Mon, Jan 2, 2012 at 1:25 AM, Grant Likely wrote: > On Wed, Dec 28, 2011 at 09:32:14PM +1100, Benjamin Herrenschmidt wrote: >> On Wed, 2011-12-28 at 19:49 +1100, Stephen Rothwell wrote: >> > Hi , >> > >> > After merging the final tree, today's linux-next build (powerpc >> > allyesconfig) failed like this: >> > >> > kernel/built-in.o: In function `irq_dispose_mapping': >> > (.opd+0x159f0): multiple definition of `irq_dispose_mapping' >> > arch/powerpc/kernel/built-in.o:(.opd+0x960): first defined here >> > kernel/built-in.o: In function `irq_create_of_mapping': >> > (.opd+0x15a20): multiple definition of `irq_create_of_mapping' >> > arch/powerpc/kernel/built-in.o:(.opd+0x9a8): first defined here >> > kernel/built-in.o: In function `.irq_create_of_mapping': >> > (.text+0x147030): multiple definition of `.irq_create_of_mapping' >> > arch/powerpc/kernel/built-in.o:(.text+0x9de0): first defined here >> > kernel/built-in.o: In function `.irq_dispose_mapping': >> > (.text+0x146f4c): multiple definition of `.irq_dispose_mapping' >> > arch/powerpc/kernel/built-in.o:(.text+0x9684): first defined here >> > >> > I am not sure what caused this. And have just left it broken. >> >> Grant, is your irq remapper misbehaving ? > > H, that's odd. I've not touched it. I'll investigate. It looks like CONFIG_IRQ_DOMAIN is getting selected by TWL4030_CORE. Drivers must not select that config symbol. It looks like commit da28adbd (mfd: twl-core: Add initial DT support for twl4030/twl6030) is the culprit. The following patch should solve the problem: diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 13c468e..e43a570 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -200,8 +200,7 @@ config MENELAUS config TWL4030_CORE bool "Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support" - depends on I2C=y && GENERIC_HARDIRQS - select IRQ_DOMAIN + depends on I2C=y && GENERIC_HARDIRQS && IRQ_DOMAIN help Say yes here if you have TWL4030 / TWL6030 family chip on your board. This core driver provides register access and IRQ handling ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Wed, Dec 28, 2011 at 09:32:14PM +1100, Benjamin Herrenschmidt wrote: > On Wed, 2011-12-28 at 19:49 +1100, Stephen Rothwell wrote: > > Hi , > > > > After merging the final tree, today's linux-next build (powerpc > > allyesconfig) failed like this: > > > > kernel/built-in.o: In function `irq_dispose_mapping': > > (.opd+0x159f0): multiple definition of `irq_dispose_mapping' > > arch/powerpc/kernel/built-in.o:(.opd+0x960): first defined here > > kernel/built-in.o: In function `irq_create_of_mapping': > > (.opd+0x15a20): multiple definition of `irq_create_of_mapping' > > arch/powerpc/kernel/built-in.o:(.opd+0x9a8): first defined here > > kernel/built-in.o: In function `.irq_create_of_mapping': > > (.text+0x147030): multiple definition of `.irq_create_of_mapping' > > arch/powerpc/kernel/built-in.o:(.text+0x9de0): first defined here > > kernel/built-in.o: In function `.irq_dispose_mapping': > > (.text+0x146f4c): multiple definition of `.irq_dispose_mapping' > > arch/powerpc/kernel/built-in.o:(.text+0x9684): first defined here > > > > I am not sure what caused this. And have just left it broken. > > Grant, is your irq remapper misbehaving ? H, that's odd. I've not touched it. I'll investigate. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
