* Re: Hard-coded virtual address used by dma_alloc_coherent
From: Remi Machet @ 2008-07-24 21:43 UTC (permalink / raw)
To: Scott Wood; +Cc: Linux PPC
In-Reply-To: <4888D808.8000406@freescale.com>
On Thu, 2008-07-24 at 14:29 -0500, Scott Wood wrote:
> Remi Machet wrote:
> > I have noticed that the DMA allocation for non-coherent PowerPC
> > architecture is using a hard coded virtual memory address for its memory
> > pool. This address is typically 0xFF100000 (set by
> > CONFIG_CONSISTENT_START) and can conflict with early ioremap in systems
> > that enable HIGHMEM.
> >
> > Is there any reason why we have to use an arbitrary virtual address ? If
> > the virtual address must be known at compile time, can't we use fixmap ?
>
> The hardcoded address predates when fixmap was added to powerpc. It
> should be updated to use fixmap.
Ok, I will look into that.
> > I also can't figure out why we need to use a virtual address known at
> > compilation time and cannot just allocate pages using get_free_pages and
> > mark them as non cacheable and non swappable.
>
> We probably don't need a compile-time address, though we can't just
> change the page attributes in-place as the pages will often covered by
> large TLB entries.
If we use alloc_pages to allocate the physical memory and get_vm_area to
get a virtual address (and its associated PTE), wouldn't map_vm_area
take care of breaking the TLB into smaller chunks if necessary ?
Remi
^ permalink raw reply
* Re: [PATCH] powerpc: Fix build bug with binutils < 2.18 and GCC < 4.2
From: Segher Boessenkool @ 2008-07-24 22:27 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev list
In-Reply-To: <48882217.5010609@mindspring.com>
[putting linuxppc-dev on Cc:, hope you don't mind]
On 24 jul 2008, at 08:32, Chuck Meade wrote:
>>> I wanted to reply to your original message regarding this, but sadly
>>> I
>>> had
>>> already deleted it. So I am sending directly to you.
>>>
>>> This patch broke my link.
>>
>> Sorry. I didn't test with anything _that_ ancient.
>>
>>> Reverting it, I am again able to link the latest
>>> git fetch of the kernel, but with your patch, my ld breaks.
>>>
>>> I am using binutils 2.15, successfully until this patch was applied
>>> yesterday.
>>
>> What target / what config / what exact GCC version / what
>> exact binutils version / why are you using such an ancient
>> toolchain anyway? :-)
> I have been using gcc 3.4.4 and binutils 2.15 up to this point without
> problems. Yes they are not cutting-edge by any means,
Updating to GCC 3.4.6 might be a good idea, it's the latest bug fix
release in the 3.4 series. I agree PowerPC Linux should still be
buildable with GCC 3.4; I don't think we really care about 3.3 or
older anymore though.
> but the concern
> here is that this patch causes the linker to fail for the first time.
> Up until now the link has worked fine, and if I revert this patch, the
> link continues to work well.
Yeah, I understand. I'm not saying you need to upgrade your toolchain
(or, I'm not yet saying that anyway; will have to see what causes this
problem first); I just said I neglected to test with anything that old.
> For one of my customers, we use a customized build system that can
> share
> cross toolsets for builds of multiple platforms. So the fact that
> these tools have worked for us cross several 83xx platforms for a long
> time is valuable. It would be highly desirable to have the linker
> continue to work.
Sure, I'll try my best to find out what is wrong, and fix it for you
if possible.
> I am very willing to work with you and test the alternative patch ideas
> you have for vmlinux.lds.S on my tools here. This patch was in the
> general interest of backwards-compatibility with pre-2.18 binutils
> anyway.
Yes, exactly: 2.6.26 does not build with binutils 2.17.
> I can help you by testing on 2.15. Send me alternate vmlinux.lds.S
> files
> to try, and I will test and get back to you ASAP.
No, I will not send you randomly changed source files and hope they
will do something useful for you. Instead, why not provide me the
information I asked for? What target (arch/powerpc it sounds like?)
What _exact_ binutils version (FSF 2.15?) What _exact_ GCC version
(FSF 3.4.4?) What Linux config (either the full .config, or the
name of a defconfig)?
> The link error, in case you were wondering, was:
Yes, I forgot to ask for that :-)
> powerpc-8325-linux-gnu-ld: final link failed: File truncated
What was the command line here? Was it the linking of vmlinux?
Segher
^ permalink raw reply
* Re: section .dummy lma 0xc0294310 overlaps previous sections
From: Segher Boessenkool @ 2008-07-24 22:29 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080724001857.42fc7e09@lappy.seanm.ca>
> Anybody else seeing these? With Linus' latest I get three of these
> warnings: .tmp_vmlinux1, .tmp_vmlinux2, and vmlinux.
Ah, that's useful information, I think I know what's going on
now. What was your binutils version?
Segher
^ permalink raw reply
* Re: lockdep badness
From: Benjamin Herrenschmidt @ 2008-07-24 22:44 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080724192300.GE9594@localdomain>
On Thu, 2008-07-24 at 14:23 -0500, Nathan Lynch wrote:
> I'm seeing warnings from the lockdep code itself in recent kernels on
> a Power6 blade (v2.6.26 and benh's -next branch).
>
> Something to do with powerpc's "lazy" interrupt-disabling, perhaps?
>
> A couple of stack traces below, the first is from benh's tree, the
> second is from 2.6.26. The lockdep self-tests all pass at boot.
Interesting.
> [c0000000e787bc20] [c0000000e787bc70] 0xc0000000e787bc70 (unreliable)
> [c0000000e787bca0] [c0000000000b5ac8] .lock_release+0x7c/0x208
> [c0000000e787bd50] [c0000000005e12c0] ._spin_unlock_irqrestore+0x34/0x94
> [c0000000e787bde0] [c00000000004d648] .pSeries_log_error+0x380/0x3f0
> [c0000000e787bef0] [c00000000004d8e4] .rtasd+0x98/0x100
> [c0000000e787bf90] [c000000000029d20] .kernel_thread+0x4c/0x68
> Instruction dump:
This one is one I haven't managed to reproduce and didn't quite find out
what could be causing it, but it was already reported by Badari (and in
fact is referenced as a regression in Rafael list).
> Call Trace:
> [c00000000fffbb10] [c00000000fffbbb0] 0xc00000000fffbbb0 (unreliable)
> [c00000000fffbbb0] [c0000000005d8824] ._spin_unlock_irq+0x40/0x68
> [c00000000fffbc40] [c000000000426708] .ipr_ioa_reset_done+0x218/0x2ac
> [c00000000fffbd00] [c00000000041bdb8] .ipr_reset_ioa_job+0xc8/0xf4
> [c00000000fffbd90] [c000000000424ffc] .ipr_isr+0x280/0x628
> [c00000000fffbe50] [c0000000000ccc70] .handle_IRQ_event+0x58/0xd4
> [c00000000fffbef0] [c0000000000cef4c] .handle_fasteoi_irq+0x128/0x1c8
> [c00000000fffbf90] [c000000000029918] .call_handle_irq+0x1c/0x2c
> [c000000000a63a20] [c00000000000d9cc] .do_IRQ+0x138/0x248
> [c000000000a63ad0] [c000000000004ca8] hardware_interrupt_entry+0x28/0x2c
> --- Exception: 501 at .raw_local_irq_restore+0x8c/0xa4
> LR = .cpu_idle+0x140/0x210
> [c000000000a63e60] [c0000000005da07c] .rest_init+0x7c/0x98
> [c000000000a63ee0] [c000000000866f10] .start_kernel+0x488/0x4b0
> [c000000000a63f90] [c000000000008584] .start_here_common+0x4c/0xc8
> Instruction dump:
This one is new to me. I will have a look. What machine is this ?
I suspect the error is to do spin_lock/unlock_irq rather than
save/restore variants at IRQ time, which would be an IPR bug... or
rather something legal that Ingo decided shouldn't be anymore :-)
Cheers,
Ben.
^ permalink raw reply
* Re: lockdep badness
From: Benjamin Herrenschmidt @ 2008-07-24 22:47 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080724193828.GF9594@localdomain>
On Thu, 2008-07-24 at 14:38 -0500, Nathan Lynch wrote:
> Nathan Lynch wrote:
> >
> > A couple of stack traces below, the first is from benh's tree, the
> > second is from 2.6.26. The lockdep self-tests all pass at boot.
>
> Sorry, should have pointed out the code that is warning more
> specifically.
>
>
> > RTAS daemon started
> > RTAS: event: 295, Type: Dump Notification Event, Severity: 2
> > ------------[ cut here ]------------
> > Badness at kernel/lockdep.c:2719
>
> check_flags():
>
> if (irqs_disabled_flags(flags)) {
> if (DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)) {
> printk("possible reason: unannotated
> irqs-off.\n");
> }
> } else {
> >>> if (DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled)) {
> printk("possible reason: unannotated
> irqs-on.\n");
> }
> }
Yes, it looks like at some point the IRQ state gets out of sync, and I
haven't found out where yet. Having a repro case would help, what is the
setup of your machine ? I seems to be related to having an RTAS event at
boot.
> > ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
> > ipr 0000:00:01.0: Found IOA with IRQ: 289
> > ipr 0000:00:01.0: Starting IOA initialization sequence.
> > ipr 0000:00:01.0: Adapter firmware version: 02200023
> > ipr 0000:00:01.0: IOA initialized.
> > ------------[ cut here ]------------
> > Badness at kernel/lockdep.c:2037
>
> trace_hardirqs_on():
>
> if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> return;
> >>> if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
> return;
As I said before, I'm not 100% sure what that is, it smells like
something legal that Ingo made not so anymore but I need to double
check.
Cheers,
Ben.
^ permalink raw reply
* Re: lockdep badness
From: Nathan Lynch @ 2008-07-24 23:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1216939496.11188.58.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2008-07-24 at 14:23 -0500, Nathan Lynch wrote:
> > I'm seeing warnings from the lockdep code itself in recent kernels on
> > a Power6 blade (v2.6.26 and benh's -next branch).
> >
> > Something to do with powerpc's "lazy" interrupt-disabling, perhaps?
> >
> > A couple of stack traces below, the first is from benh's tree, the
> > second is from 2.6.26. The lockdep self-tests all pass at boot.
>
> Interesting.
>
> > [c0000000e787bc20] [c0000000e787bc70] 0xc0000000e787bc70 (unreliable)
> > [c0000000e787bca0] [c0000000000b5ac8] .lock_release+0x7c/0x208
> > [c0000000e787bd50] [c0000000005e12c0] ._spin_unlock_irqrestore+0x34/0x94
> > [c0000000e787bde0] [c00000000004d648] .pSeries_log_error+0x380/0x3f0
> > [c0000000e787bef0] [c00000000004d8e4] .rtasd+0x98/0x100
> > [c0000000e787bf90] [c000000000029d20] .kernel_thread+0x4c/0x68
> > Instruction dump:
>
> This one is one I haven't managed to reproduce and didn't quite find out
> what could be causing it, but it was already reported by Badari (and in
> fact is referenced as a regression in Rafael list).
Okay.
> > Call Trace:
> > [c00000000fffbb10] [c00000000fffbbb0] 0xc00000000fffbbb0 (unreliable)
> > [c00000000fffbbb0] [c0000000005d8824] ._spin_unlock_irq+0x40/0x68
> > [c00000000fffbc40] [c000000000426708] .ipr_ioa_reset_done+0x218/0x2ac
> > [c00000000fffbd00] [c00000000041bdb8] .ipr_reset_ioa_job+0xc8/0xf4
> > [c00000000fffbd90] [c000000000424ffc] .ipr_isr+0x280/0x628
> > [c00000000fffbe50] [c0000000000ccc70] .handle_IRQ_event+0x58/0xd4
> > [c00000000fffbef0] [c0000000000cef4c] .handle_fasteoi_irq+0x128/0x1c8
> > [c00000000fffbf90] [c000000000029918] .call_handle_irq+0x1c/0x2c
> > [c000000000a63a20] [c00000000000d9cc] .do_IRQ+0x138/0x248
> > [c000000000a63ad0] [c000000000004ca8] hardware_interrupt_entry+0x28/0x2c
> > --- Exception: 501 at .raw_local_irq_restore+0x8c/0xa4
> > LR = .cpu_idle+0x140/0x210
> > [c000000000a63e60] [c0000000005da07c] .rest_init+0x7c/0x98
> > [c000000000a63ee0] [c000000000866f10] .start_kernel+0x488/0x4b0
> > [c000000000a63f90] [c000000000008584] .start_here_common+0x4c/0xc8
> > Instruction dump:
>
> This one is new to me. I will have a look. What machine is this ?
Power6 blade - JS22 (four cores), with single disk attached via IPR,
HEA for network... nothing exotic, I guess. Not sure how recreatable
the ipr trace is, I've only seen it once (and with 2.6.26 only). The
rtasd trace is pretty consistent on powerpc/next.
^ permalink raw reply
* Re: lockdep badness
From: Arnd Bergmann @ 2008-07-24 23:04 UTC (permalink / raw)
To: linuxppc-dev, benh; +Cc: Brian King, Nathan Lynch
In-Reply-To: <1216939496.11188.58.camel@pasglop>
On Friday 25 July 2008, Benjamin Herrenschmidt wrote:
> > Call Trace:
> > [c00000000fffbb10] [c00000000fffbbb0] 0xc00000000fffbbb0 (unreliable)
> > [c00000000fffbbb0] [c0000000005d8824] ._spin_unlock_irq+0x40/0x68
> > [c00000000fffbc40] [c000000000426708] .ipr_ioa_reset_done+0x218/0x2ac
> > [c00000000fffbd00] [c00000000041bdb8] .ipr_reset_ioa_job+0xc8/0xf4
> > [c00000000fffbd90] [c000000000424ffc] .ipr_isr+0x280/0x628
> > [c00000000fffbe50] [c0000000000ccc70] .handle_IRQ_event+0x58/0xd4
> > [c00000000fffbef0] [c0000000000cef4c] .handle_fasteoi_irq+0x128/0x1c8
> > [c00000000fffbf90] [c000000000029918] .call_handle_irq+0x1c/0x2c
> > [c000000000a63a20] [c00000000000d9cc] .do_IRQ+0x138/0x248
> > [c000000000a63ad0] [c000000000004ca8] hardware_interrupt_entry+0x28/0x2c
> > --- Exception: 501 at .raw_local_irq_restore+0x8c/0xa4
> > =A0 =A0 LR =3D .cpu_idle+0x140/0x210
> > [c000000000a63e60] [c0000000005da07c] .rest_init+0x7c/0x98
> > [c000000000a63ee0] [c000000000866f10] .start_kernel+0x488/0x4b0
> > [c000000000a63f90] [c000000000008584] .start_here_common+0x4c/0xc8
> > Instruction dump:
>=20
> This one is new to me. I will have a look. What machine is this ?
>=20
> I suspect the error is to do spin_lock/unlock_irq rather than
> save/restore variants at IRQ time, which would be an IPR bug... or
> rather something legal that Ingo decided shouldn't be anymore :-)
Almost: The ipr_ioa_reset_done function does
spin_unlock_irq(ioa_cfg->host->host_lock);
scsi_unblock_requests(ioa_cfg->host);
spin_lock_irq(ioa_cfg->host->host_lock);
It seem that it is always called with interrupts disabled and
ioa_cfg->host->host_lock held (otherwise we would get a different
warning), so to get rid of the lockdep warning, it should be
replaced with
spin_unlock(ioa_cfg->host->host_lock);
scsi_unblock_requests(ioa_cfg->host);
spin_lock(ioa_cfg->host->host_lock);
I.e. leave the interrupts off, but still give up the lock. It
still feels wrong to do this, but I don't understand much about
the driver either.
Arnd <><
^ permalink raw reply
* link failure: file truncated
From: Jon Tollefson @ 2008-07-24 23:07 UTC (permalink / raw)
To: linuxppc-dev
Just tried to build the latest version from Linus' tree and I am getting
a link error.
building with the pseries_defconfig
...
LD drivers/built-in.o
LD vmlinux.o
MODPOST vmlinux.o
WARNING: modpost: Found 6 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
ld: final link failed: File truncated
make: *** [.tmp_vmlinux1] Error 1
~/src/linus/linux-2.6>cat /etc/SuSE-release
SUSE LINUX Enterprise Server 9 (ppc)
VERSION = 9
PATCHLEVEL = 3
~/src/linus/linux-2.6>ld --version
GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux)
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
~/src/linus/linux-2.6>gcc --version
gcc (GCC) 3.3.3 (SuSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
~/src/linus/linux-2.6>cat /etc/SuSE-release
SUSE LINUX Enterprise Server 9 (ppc)
VERSION = 9
PATCHLEVEL = 3
Jon
^ permalink raw reply
* [PATCH] Update cpu_sibling_maps dynamically
From: Nathan Lynch @ 2008-07-24 23:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
The per-cpu cpu_sibling_maps get out of sync if CPUs are
onlined/offlined at runtime. I don't believe this can cause any
oopses, but it does cause incorrect information to be displayed by
/sys/devices/system/cpu/cpu*/topology/thread_siblings.
Rather doing one initialization pass over all CPUs at boot, update the
maps at cpu online/offline time.
Note: while this is a bug fix, it is also a behavior change -- the
thread_siblings attribute now reflects only online siblings, whereas
it would display offline siblings before. The new behavior matches
that of x86.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/kernel/setup-common.c | 24 ------------------------
arch/powerpc/kernel/setup_64.c | 3 ---
arch/powerpc/kernel/smp.c | 32 +++++++++++++++++++++++++++++---
3 files changed, 29 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 61a3f41..9cc5a52 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -367,7 +367,6 @@ static void __init cpu_init_thread_core_maps(int tpc)
* setup_cpu_maps - initialize the following cpu maps:
* cpu_possible_map
* cpu_present_map
- * cpu_sibling_map
*
* Having the possible map set up early allows us to restrict allocations
* of things like irqstacks to num_possible_cpus() rather than NR_CPUS.
@@ -475,29 +474,6 @@ void __init smp_setup_cpu_maps(void)
*/
cpu_init_thread_core_maps(nthreads);
}
-
-/*
- * Being that cpu_sibling_map is now a per_cpu array, then it cannot
- * be initialized until the per_cpu areas have been created. This
- * function is now called from setup_per_cpu_areas().
- */
-void __init smp_setup_cpu_sibling_map(void)
-{
-#ifdef CONFIG_PPC64
- int i, cpu, base;
-
- for_each_possible_cpu(cpu) {
- DBG("Sibling map for CPU %d:", cpu);
- base = cpu_first_thread_in_core(cpu);
- for (i = 0; i < threads_per_core; i++) {
- cpu_set(base + i, per_cpu(cpu_sibling_map, cpu));
- DBG(" %d", base + i);
- }
- DBG("\n");
- }
-
-#endif /* CONFIG_PPC64 */
-}
#endif /* CONFIG_SMP */
#ifdef CONFIG_PCSPKR_PLATFORM
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 04d8de9..8b25f51 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -611,9 +611,6 @@ void __init setup_per_cpu_areas(void)
paca[i].data_offset = ptr - __per_cpu_start;
memcpy(ptr, __per_cpu_start, __per_cpu_end - __per_cpu_start);
}
-
- /* Now that per_cpu is setup, initialize cpu_sibling_map */
- smp_setup_cpu_sibling_map();
}
#endif
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index f5ae9fa..3c4d07e 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -41,6 +41,7 @@
#include <asm/smp.h>
#include <asm/time.h>
#include <asm/machdep.h>
+#include <asm/cputhreads.h>
#include <asm/cputable.h>
#include <asm/system.h>
#include <asm/mpic.h>
@@ -228,6 +229,7 @@ void __devinit smp_prepare_boot_cpu(void)
BUG_ON(smp_processor_id() != boot_cpuid);
cpu_set(boot_cpuid, cpu_online_map);
+ cpu_set(boot_cpuid, per_cpu(cpu_sibling_map, boot_cpuid));
#ifdef CONFIG_PPC64
paca[boot_cpuid].__current = current;
#endif
@@ -380,6 +382,7 @@ int __cpuinit __cpu_up(unsigned int cpu)
int __devinit start_secondary(void *unused)
{
unsigned int cpu = smp_processor_id();
+ int i, base;
atomic_inc(&init_mm.mm_count);
current->active_mm = &init_mm;
@@ -400,6 +403,14 @@ int __devinit start_secondary(void *unused)
ipi_call_lock();
cpu_set(cpu, cpu_online_map);
+ /* Update sibling maps */
+ base = cpu_first_thread_in_core(cpu);
+ for (i = 0; i < threads_per_core; i++) {
+ if (cpu_is_offline(base + i))
+ continue;
+ cpu_set(cpu, per_cpu(cpu_sibling_map, base + i));
+ cpu_set(base + i, per_cpu(cpu_sibling_map, cpu));
+ }
ipi_call_unlock();
local_irq_enable();
@@ -437,10 +448,25 @@ void __init smp_cpus_done(unsigned int max_cpus)
#ifdef CONFIG_HOTPLUG_CPU
int __cpu_disable(void)
{
- if (smp_ops->cpu_disable)
- return smp_ops->cpu_disable();
+ int cpu = smp_processor_id();
+ int base, i;
+ int err;
- return -ENOSYS;
+ if (!smp_ops->cpu_disable)
+ return -ENOSYS;
+
+ err = smp_ops->cpu_disable();
+ if (err)
+ return err;
+
+ /* Update sibling maps */
+ base = cpu_first_thread_in_core(cpu);
+ for (i = 0; i < threads_per_core; i++) {
+ cpu_clear(cpu, per_cpu(cpu_sibling_map, base + i));
+ cpu_clear(base + i, per_cpu(cpu_sibling_map, cpu));
+ }
+
+ return 0;
}
void __cpu_die(unsigned int cpu)
--
1.5.6.2
^ permalink raw reply related
* Re: section .dummy lma 0xc0294310 overlaps previous sections
From: Sean MacLennan @ 2008-07-24 23:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <c7d136a69bb02682bf5f3dbbd658d975@kernel.crashing.org>
On Fri, 25 Jul 2008 00:29:28 +0200
"Segher Boessenkool" <segher@kernel.crashing.org> wrote:
> > Anybody else seeing these? With Linus' latest I get three of these
> > warnings: .tmp_vmlinux1, .tmp_vmlinux2, and vmlinux.
>
> Ah, that's useful information, I think I know what's going on
> now. What was your binutils version?
2.16.1. Comes from the Denx 4.1 ELDK if that helps any.
Cheers,
Sean
^ permalink raw reply
* Re: link failure: file truncated
From: Chuck Meade @ 2008-07-24 23:17 UTC (permalink / raw)
To: kniht; +Cc: linuxppc-dev
In-Reply-To: <48890B3B.8060806@us.ibm.com>
Jon Tollefson wrote:
> Just tried to build the latest version from Linus' tree and I am getting
> a link error.
>
> building with the pseries_defconfig
>
> ...
> LD drivers/built-in.o
> LD vmlinux.o
> MODPOST vmlinux.o
> WARNING: modpost: Found 6 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> GEN .version
> CHK include/linux/compile.h
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> ld: final link failed: File truncated
> make: *** [.tmp_vmlinux1] Error 1
>
>
> ~/src/linus/linux-2.6>cat /etc/SuSE-release SUSE LINUX Enterprise Server
> 9 (ppc)
> VERSION = 9
> PATCHLEVEL = 3
> ~/src/linus/linux-2.6>ld --version
> GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux)
> Copyright 2002 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License. This program has absolutely no warranty.
> ~/src/linus/linux-2.6>gcc --version
> gcc (GCC) 3.3.3 (SuSE Linux)
> Copyright (C) 2003 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> ~/src/linus/linux-2.6>cat /etc/SuSE-release SUSE LINUX Enterprise Server
> 9 (ppc)
> VERSION = 9
> PATCHLEVEL = 3
>
>
>
> Jon
As you may have seen from Segher's email from about 40 minutes ago, I can
confirm that I am getting the same error at the same point in the build.
I am going to reply to his message in a few minutes with more details he
requested. Like you, I also have a 2.15-era ld version.
I can tell you that if you revert the patch that Segher sent on July 22
for file arch/powerpc/kernel/vmlinux.lds.S, the link should succeed (mine
does).
Regards,
Chuck
^ permalink raw reply
* Re: [PATCH] powerpc: Fix build bug with binutils < 2.18 and GCC < 4.2
From: Chuck Meade @ 2008-07-24 23:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <3c19f5225b292a011665f127c55e58f7@kernel.crashing.org>
Segher Boessenkool wrote:
> [putting linuxppc-dev on Cc:, hope you don't mind]
>
> On 24 jul 2008, at 08:32, Chuck Meade wrote:
>
>>>> I wanted to reply to your original message regarding this, but sadly I
>>>> had
>>>> already deleted it. So I am sending directly to you.
>>>>
>>>> This patch broke my link.
>>>
>>> Sorry. I didn't test with anything _that_ ancient.
>>>
>>>> Reverting it, I am again able to link the latest
>>>> git fetch of the kernel, but with your patch, my ld breaks.
>>>>
>>>> I am using binutils 2.15, successfully until this patch was applied
>>>> yesterday.
>>>
>>> What target / what config / what exact GCC version / what
>>> exact binutils version / why are you using such an ancient
>>> toolchain anyway? :-)
>
>> I have been using gcc 3.4.4 and binutils 2.15 up to this point without
>> problems. Yes they are not cutting-edge by any means,
>
> Updating to GCC 3.4.6 might be a good idea, it's the latest bug fix
> release in the 3.4 series. I agree PowerPC Linux should still be
> buildable with GCC 3.4; I don't think we really care about 3.3 or
> older anymore though.
>
>> but the concern
>> here is that this patch causes the linker to fail for the first time.
>> Up until now the link has worked fine, and if I revert this patch, the
>> link continues to work well.
>
> Yeah, I understand. I'm not saying you need to upgrade your toolchain
> (or, I'm not yet saying that anyway; will have to see what causes this
> problem first); I just said I neglected to test with anything that old.
>
>> For one of my customers, we use a customized build system that can share
>> cross toolsets for builds of multiple platforms. So the fact that
>> these tools have worked for us cross several 83xx platforms for a long
>> time is valuable. It would be highly desirable to have the linker
>> continue to work.
>
> Sure, I'll try my best to find out what is wrong, and fix it for you
> if possible.
>
>> I am very willing to work with you and test the alternative patch ideas
>> you have for vmlinux.lds.S on my tools here. This patch was in the
>> general interest of backwards-compatibility with pre-2.18 binutils
>> anyway.
>
> Yes, exactly: 2.6.26 does not build with binutils 2.17.
>
>> I can help you by testing on 2.15. Send me alternate vmlinux.lds.S files
>> to try, and I will test and get back to you ASAP.
>
> No, I will not send you randomly changed source files and hope they
> will do something useful for you. Instead, why not provide me the
> information I asked for? What target (arch/powerpc it sounds like?)
> What _exact_ binutils version (FSF 2.15?) What _exact_ GCC version
> (FSF 3.4.4?) What Linux config (either the full .config, or the
> name of a defconfig)?
No problem -- I thought it would be helpful to offer to test changes for you,
so we could work together toward a solution.
The gcc version is 3.4.4. This is from source tarball gcc-3.4.4.tar.bz2,
downloaded from ftp.gnu.org, built myself using crosstool.
Here is the version output:
$ ./powerpc-8325-linux-gnu-gcc --version
powerpc-8325-linux-gnu-gcc (GCC) 3.4.4
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The binutils are version 2.15, from source tarball binutils-2.15.tar.bz2.
Downloaded from ftp.gnu.org. Built myself using crosstool.
Here is the version output:
$ ./powerpc-8325-linux-gnu-ld --version
GNU ld version 2.15
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
The target arch/powerpc. The Linux defconfig was mpc836x_rdk_defconfig.
>> The link error, in case you were wondering, was:
>
> Yes, I forgot to ask for that :-)
>
>> powerpc-8325-linux-gnu-ld: final link failed: File truncated
>
> What was the command line here? Was it the linking of vmlinux?
The command line was "make ARCH=powerpc uImage". The step that failed
was the linking of vmlinux.
If you look at the email to the linuxppc-dev list from this evening at
7:07 pm (about 30 minutes ago), Jon Tollefson is encountering the same
error now.
At the risk of providing too much detail -- if you issue the same build
command with "V=1" appended, it shows the failing link command. Entering
that failing link command at the command line, I can remove all of the files
from the link, one by one, until only kernel/built-in.o is left, and still get
the "File truncated" error.
Of course once you remove enough files from the link line there are other
errors -- "undefined reference" problems that show up -- but the "File truncated"
error is related to kernel/built-in.o. Hope that helps a bit.
Let me know if you have any questions.
Thanks,
Chuck
>
>
> Segher
>
>
^ permalink raw reply
* Re: section .dummy lma 0xc0294310 overlaps previous sections
From: Sean MacLennan @ 2008-07-24 23:43 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <20080724191733.27dc4eb8@lappy.seanm.ca>
On Thu, 24 Jul 2008 19:17:33 -0400
"Sean MacLennan" <sean.maclennan@ottawa.kanatek.ca> wrote:
> On Fri, 25 Jul 2008 00:29:28 +0200
> "Segher Boessenkool" <segher@kernel.crashing.org> wrote:
>
> > > Anybody else seeing these? With Linus' latest I get three of these
> > > warnings: .tmp_vmlinux1, .tmp_vmlinux2, and vmlinux.
> >
> > Ah, that's useful information, I think I know what's going on
> > now. What was your binutils version?
>
> 2.16.1. Comes from the Denx 4.1 ELDK if that helps any.
If I back out c69cccc95fe4b90dde5fe33e6a3b77880b534fa4 "Fix build bug
with binutils < 2.18 and GCC < 4.2" then the warnings go away.
And yes, the compiler is GCC 4.0.
Cheers,
Sean
^ permalink raw reply
* Re: link failure: file truncated
From: Segher Boessenkool @ 2008-07-24 23:51 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev, kniht
In-Reply-To: <48890D8A.5040001@mindspring.com>
>> Just tried to build the latest version from Linus' tree and I am
>> getting
>> a link error.
I can reproduce this now, with 3.4.6 + 2.15, on powerpc64 defconfig
(with the drivers that don't compile with 3.4.6 disabled).
I have a fix for the warning with 2.17, but that's just a warning,
so I'll wait sending it until we know what causes the error.
Stay tuned :-)
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Fix build bug with binutils < 2.18 and GCC < 4.2
From: Segher Boessenkool @ 2008-07-25 0:18 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev list, Sean MacLennan
In-Reply-To: <488912BC.6040706@mindspring.com>
>>> I can help you by testing on 2.15. Send me alternate vmlinux.lds.S
>>> files
>>> to try, and I will test and get back to you ASAP.
>>
>> No, I will not send you randomly changed source files and hope they
>> will do something useful for you. Instead, why not provide me the
>> information I asked for? What target (arch/powerpc it sounds like?)
>> What _exact_ binutils version (FSF 2.15?) What _exact_ GCC version
>> (FSF 3.4.4?) What Linux config (either the full .config, or the
>> name of a defconfig)?
>
> No problem -- I thought it would be helpful to offer to test changes
> for you,
> so we could work together toward a solution.
Sure, and thanks for that! I need to be able to reproduce it myself
to create a patch in the first place though (or spend a few hundred
hours in a senseless guessing game) :-)
I now managed to reproduce it with 2.15 on powerpc64. You should see
the patch soon (I sent it, but for seem reason it takes a while to
get through ozlabs, half an hour or so the last time).
Please test, and thank you! Reply to the patch mail saying if it
worked please (Jon, Sean, you as well?).
Segher
^ permalink raw reply
* [PATCH] powerpc: Fix compile error with binutils 2.15
From: Segher Boessenkool @ 2008-07-25 0:08 UTC (permalink / raw)
To: linuxppc-dev, benh
My previous patch to fix compilation with binutils-2.17 causes
a "file truncated" build error from ld with binutils 2.15 (and
possibly older), and a warning with 2.16 and 2.17.
This fixes it.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/powerpc/kernel/vmlinux.lds.S | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index a914411..4a8ce62 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -85,7 +85,7 @@ SECTIONS
/* The dummy segment contents for the bug workaround mentioned above
near PHDRS. */
- .dummy : {
+ .dummy : AT(ADDR(.dummy) - LOAD_OFFSET) {
LONG(0xf177)
} :kernel :dummy
--
1.5.6.4.gf1ba5
^ permalink raw reply related
* linux-next: origin tree build failure
From: Stephen Rothwell @ 2008-07-25 0:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: ppc-dev, Steven Whitehouse, linux-next, LKML, Trond Myklebust
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
Hi all,
Today's linux-next (really just Linus' tree) build (powerpc
ppc64_defconfig) failed like this:
fs/nfs/nfsroot.c:130: error: tokens causes a section type conflict
"tokens" is a match_table_t which has const added to it in commit
f9247273cb69ba101877e946d2d83044409cc8c5 "UFS: add const to parser token
table". But "tokens" is also marked __initdata. I changed it to
__initconst.
--
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: [PATCH] powerpc: Fix compile error with binutils 2.15
From: Chuck Meade @ 2008-07-25 0:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <25a77ae6580f7ea388ccae2f190b1b3f7415a928.1216944498.git.segher@kernel.crashing.org>
Segher Boessenkool wrote:
> My previous patch to fix compilation with binutils-2.17 causes
> a "file truncated" build error from ld with binutils 2.15 (and
> possibly older), and a warning with 2.16 and 2.17.
>
> This fixes it.
>
> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Hi Segher,
That fixes it! Thanks very much for that.
Best regards,
Chuck
Acked-by: Chuck Meade <chuckmeade@mindspring.com>
> ---
> arch/powerpc/kernel/vmlinux.lds.S | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
> index a914411..4a8ce62 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -85,7 +85,7 @@ SECTIONS
>
> /* The dummy segment contents for the bug workaround mentioned above
> near PHDRS. */
> - .dummy : {
> + .dummy : AT(ADDR(.dummy) - LOAD_OFFSET) {
> LONG(0xf177)
> } :kernel :dummy
>
^ permalink raw reply
* Re: [RFC,PATCH] scripts/package: add powerpc images to tarball
From: Milton Miller @ 2008-07-25 1:08 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1216887460.306306.238738123378.1.gpush@pingu>
> Currently, tarball builds for powerpc kernels don't have any boot
> images (other than vmlinux) present.
>
> Add support for powerpc builds in the buildtar script, to include
> a few default images.
>
> Signed-off-by: Jeremy Kerr <jk at ozlabs.org>
>
> ---
> RFC: any requests for more/less boot images?
>
..
> + for img in zImage zImage.pseries zImage.iseries \
> + dtbImage dtbImage.ps3
Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
that are newer than vmlinux?
milton
^ permalink raw reply
* Re: [PATCH 0/6][RFC] kvmppc: paravirtualization interface
From: Tony Breeds @ 2008-07-25 1:08 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: linuxppc-dev, hollisb, kvm-ppc
In-Reply-To: <48883A9B.3050608@linux.vnet.ibm.com>
On Thu, Jul 24, 2008 at 10:17:31AM +0200, Christian Ehrhardt wrote:
> The aim is not really fixed. It would be nice to get into 2.6.27, but
> since I can't yet expect how long it takes ...
Ahh okay, Id say given that we're 2/3rds through the merge window then
2.8.28 is a safer target.
> Actually the guest patches would already go through reviews and
> upstream, due to the fact that the guest code changes are not that (the
> major part of the implementation will go over kvmppc -> kvm upstream).
> But since I want to discuss about the standardization on the embedded
> hypervisor list first, the naming of the device tree entries are not
> fixed yet.
Okay. When that's done we can take another look at them.
> Therefor I can't yet define which kernel version merge window I'll
> target/reach.
>
> btw - embedded hypervisor - I got advised that this is a closed list
> which I forgot.
... snipped from this reply
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] powerpc: Fix compile error with binutils 2.15
From: Sean MacLennan @ 2008-07-25 1:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <25a77ae6580f7ea388ccae2f190b1b3f7415a928.1216944498.git.segher@kernel.crashing.org>
On Fri, 25 Jul 2008 02:08:41 +0200
"Segher Boessenkool" <segher@kernel.crashing.org> wrote:
> My previous patch to fix compilation with binutils-2.17 causes
> a "file truncated" build error from ld with binutils 2.15 (and
> possibly older), and a warning with 2.16 and 2.17.
>
> This fixes it.
And it does ;) Compiles with no warnings and boots.
Cheers,
Sean
^ permalink raw reply
* Re: [RFC,PATCH] scripts/package: add powerpc images to tarball
From: Jeremy Kerr @ 2008-07-25 1:11 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200807250108.m6P18f4B099179@sullivan.realtime.net>
Milton,
> Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
> that are newer than vmlinux?
The existing arch code doesn't do any checks for timestamps, perhaps
this would be better implemented as an arch-independent change?
(but would you like me to add treeboot and cuboot?)
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH] powerpc: Fix compile error with binutils 2.15
From: Jon Tollefson @ 2008-07-25 1:12 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <25a77ae6580f7ea388ccae2f190b1b3f7415a928.1216944498.git.segher@kernel.crashing.org>
Segher Boessenkool wrote:
> My previous patch to fix compilation with binutils-2.17 causes
> a "file truncated" build error from ld with binutils 2.15 (and
> possibly older), and a warning with 2.16 and 2.17.
>
> This fixes it.
>
> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
> ---
> arch/powerpc/kernel/vmlinux.lds.S | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
> index a914411..4a8ce62 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -85,7 +85,7 @@ SECTIONS
>
> /* The dummy segment contents for the bug workaround mentioned above
> near PHDRS. */
> - .dummy : {
> + .dummy : AT(ADDR(.dummy) - LOAD_OFFSET) {
> LONG(0xf177)
> } :kernel :dummy
>
This fixed the file truncated error for me. Also the kernel booted fine.
Jon
~/src/linus/linux-2.6>make vmlinux
CHK include/linux/version.h
CHK include/linux/utsrelease.h
UPD include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
<stdin>:1397:2: warning: #warning syscall signalfd4 not implemented
<stdin>:1401:2: warning: #warning syscall eventfd2 not implemented
<stdin>:1405:2: warning: #warning syscall epoll_create1 not implemented
<stdin>:1409:2: warning: #warning syscall dup3 not implemented
<stdin>:1413:2: warning: #warning syscall pipe2 not implemented
<stdin>:1417:2: warning: #warning syscall inotify_init1 not implemented
CHK include/linux/compile.h
CC init/version.o
LD init/built-in.o
CALL arch/powerpc/kernel/systbl_chk.sh
CALL arch/powerpc/kernel/prom_init_check.sh
LDS arch/powerpc/kernel/vmlinux.lds
CC kernel/module.o
CC kernel/kexec.o
LD kernel/built-in.o
LD vmlinux.o
MODPOST vmlinux.o
WARNING: modpost: Found 6 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
^ permalink raw reply
* Re: [RFC] 4xx hardware watchpoint support
From: Benjamin Herrenschmidt @ 2008-07-25 4:00 UTC (permalink / raw)
To: luisgpm; +Cc: ppc-dev, Christoph Hellwig, Paul Mackerras
In-Reply-To: <1216829442.5727.97.camel@gargoyle>
On Wed, 2008-07-23 at 13:10 -0300, Luis Machado wrote:
> On Wed, 2008-07-23 at 11:53 -0400, Josh Boyer wrote:
> > Shouldn't this (and other places) be:
> >
> > #if defined(CONFIG_44x) || defined(CONFIG_BOOKE)
> >
> > if you are going to exclude 40x for now? Otherwise this is still
> > enabled on 405 and setting the wrong register.
> >
> > josh
>
> Yes, sorry. I wasn't aware of this specific define value. It makes
> things easier to support 405's later.
>
> Like so?
Please, next time, when you re-send a patch like that, re-include
the full subject and patch description. You can add then blurbs after
the --- line if you want to add things that won't make it to git.
I'll deal with that specific one for now.
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Stephen Rothwell @ 2008-07-25 4:13 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Benjamin, Milton Miller, linuxppc-dev, linux-next, Mackerras,
Paul
In-Reply-To: <20080707184038.aaeb8d40.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 614 bytes --]
Hi Sam,
On Mon, 7 Jul 2008 18:40:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
This still fails in linux-next today. We need some solution before you
send these commits to Linus.
--
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
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