* 3.4.0-rc1: No init found
@ 2012-04-03 7:20 Christian Kujau
2012-04-03 8:08 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 16+ messages in thread
From: Christian Kujau @ 2012-04-03 7:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: LKML
Going from 3.3-rc7 to 3.4-rc1 (with "make oldconfig" inbetween) did not
go well on this PowerBook G4 machine:
Apr 2 15:18:23 [ 8.318816] EXT4-fs (hda6): mounted filesystem with ordered data mode. Opts: (null)
Apr 2 15:18:23 [ 8.320286] VFS: Mounted root (ext4 filesystem) readonly on device 3:6.
Apr 2 15:18:23 [ 8.341555] devtmpfs: mounted
Apr 2 15:18:23 [ 8.343384] Freeing unused kernel memory: 204k freed
Apr 2 15:18:23 [ 8.457056] Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
Apr 2 15:18:23 [ 8.459936] Rebooting in 180 seconds..
No bootoptions were changed, no disks swapped, no partitions altered
whatsoever. Full .config & dmesg:
http://nerdbynature.de/bits/3.4.0-rc1/init/
Thanks,
Christian.
PS: Unfortunately I cannot boot into the old (3.3-rc7) kernel
right now (which is still installed via "yaboot" and present in
/boot), because of this:
http://nerdbynature.de/bits/3.4.0-rc1/init/mac-invalid-memory.JPG
Booting into Debian's "squeeze" kernel (2.6.32) which resides in
the same /boot directory succeeds.
--
BOFH excuse #334:
50% of the manual is in .pdf readme files
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
2012-04-03 7:20 3.4.0-rc1: No init found Christian Kujau
@ 2012-04-03 8:08 ` Benjamin Herrenschmidt
2012-04-03 17:18 ` Christian Kujau
2012-04-10 5:47 ` Christian Kujau
0 siblings, 2 replies; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2012-04-03 8:08 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML, Al Viro
On Tue, 2012-04-03 at 00:20 -0700, Christian Kujau wrote:
> Going from 3.3-rc7 to 3.4-rc1 (with "make oldconfig" inbetween) did not
> go well on this PowerBook G4 machine:
>
> Apr 2 15:18:23 [ 8.318816] EXT4-fs (hda6): mounted filesystem with ordered data mode. Opts: (null)
> Apr 2 15:18:23 [ 8.320286] VFS: Mounted root (ext4 filesystem) readonly on device 3:6.
> Apr 2 15:18:23 [ 8.341555] devtmpfs: mounted
> Apr 2 15:18:23 [ 8.343384] Freeing unused kernel memory: 204k freed
> Apr 2 15:18:23 [ 8.457056] Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
> Apr 2 15:18:23 [ 8.459936] Rebooting in 180 seconds..
I have observed this randomly on the G5 ... sometimes, if I try again,
it works... it's very very odd. There is some kind of race maybe with
async startup ? Or a problem with the vfs path walking ? It's certainly
not easily reproducable for me, it goes away from one boot to the next.
It also happens sometimes with an initramfs (cpio), it's not specific to
ext{2,3,4}.
Cheers,
Ben.
> No bootoptions were changed, no disks swapped, no partitions altered
> whatsoever. Full .config & dmesg:
>
> http://nerdbynature.de/bits/3.4.0-rc1/init/
>
> Thanks,
> Christian.
>
> PS: Unfortunately I cannot boot into the old (3.3-rc7) kernel
> right now (which is still installed via "yaboot" and present in
> /boot), because of this:
> http://nerdbynature.de/bits/3.4.0-rc1/init/mac-invalid-memory.JPG
> Booting into Debian's "squeeze" kernel (2.6.32) which resides in
> the same /boot directory succeeds.
Hrm, did it used to boot ? Can you do printenv in OF and tell me what
your load-base, real-base, virt-base etc... are ?
Might also be worth updating yaboot, debian should have 1.3.16 nowadays.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
2012-04-03 8:08 ` Benjamin Herrenschmidt
@ 2012-04-03 17:18 ` Christian Kujau
2012-04-03 18:53 ` Christian Kujau
2012-04-04 12:36 ` Suzuki K. Poulose
2012-04-10 5:47 ` Christian Kujau
1 sibling, 2 replies; 16+ messages in thread
From: Christian Kujau @ 2012-04-03 17:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, LKML, Al Viro
On Tue, 3 Apr 2012 at 18:08, Benjamin Herrenschmidt wrote:
> I have observed this randomly on the G5 ... sometimes, if I try again,
> it works... it's very very odd. There is some kind of race maybe with
> async startup ? Or a problem with the vfs path walking ? It's certainly
> not easily reproducable for me, it goes away from one boot to the next.
It's 100% reproducible for me. This PowerBook G4 (1.25Ghz) is not the
fastes though, maybe a race triggers more easily here...?
> > PS: Unfortunately I cannot boot into the old (3.3-rc7) kernel
> > right now (which is still installed via "yaboot" and present in
> > /boot), because of this:
> > http://nerdbynature.de/bits/3.4.0-rc1/init/mac-invalid-memory.JPG
> > Booting into Debian's "squeeze" kernel (2.6.32) which resides in
> > the same /boot directory succeeds.
>
> Hrm, did it used to boot ?
I'm using the "backup" kernel only when the new one has an issue, so I
have not tested it for a while, but it used to work, for sure.
> Can you do printenv in OF and tell me what
> your load-base, real-base, virt-base etc... are ?
load-base is 0x800000, real-base and virt-base is set to "-1", please see
http://nerdbynature.de/bits/3.4.0-rc1/init/printenv-1.JPG
Not sure if this is related, but at the end of each kernel compilation,
the following messages are printed:
------------
SYSMAP System.map
SYSMAP .tmp_System.map
WRAP arch/powerpc/boot/zImage.pmac
INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the wrapper(0x400000)
INFO: Fixing the link_address of wrapper to (0x700000)
WRAP arch/powerpc/boot/zImage.coff
INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the wrapper(0x500000)
INFO: Fixing the link_address of wrapper to (0x700000)
WRAP arch/powerpc/boot/zImage.miboot
INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the wrapper(0x400000)
INFO: Fixing the link_address of wrapper to (0x700000)
Building modules, stage 2.
MODPOST 24 modules
------------
I started to see these messages in January (around Linux 3.2.0), but never
investigated what it was since the produced kernels continued to boot just
fine.
> Might also be worth updating yaboot, debian should have 1.3.16 nowadays.
Debian/stable still has 1.3.13a, I'll try to install 1.3.16 from
Debian/testing.
Thanks for your help,
Christian.
--
BOFH excuse #217:
The MGs ran out of gas.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
2012-04-03 17:18 ` Christian Kujau
@ 2012-04-03 18:53 ` Christian Kujau
2012-04-04 12:36 ` Suzuki K. Poulose
1 sibling, 0 replies; 16+ messages in thread
From: Christian Kujau @ 2012-04-03 18:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, LKML, Al Viro
On Tue, 3 Apr 2012 at 10:18, Christian Kujau wrote:
> > > PS: Unfortunately I cannot boot into the old (3.3-rc7) kernel
> > > right now (which is still installed via "yaboot" and present in
> > > /boot), because of this:
> > > http://nerdbynature.de/bits/3.4.0-rc1/init/mac-invalid-memory.JPG
> > > Booting into Debian's "squeeze" kernel (2.6.32) which resides in
> > > the same /boot directory succeeds.
> >
FYI, upgrading to yaboot 1.3.16-4 from Debian/testing did the trick, I can
now boot the "old" (3.3.0) kernel[0].
The "No init found" problem with 3.4.0-rc1 remains of course :-\
Thanks,
Christian.
[0] http://nerdbynature.de/bits/3.4.0-rc1/init/yaboot.conf.txt
http://nerdbynature.de/bits/3.4.0-rc1/init/ls-boot.txt
> > Hrm, did it used to boot ?
>
> I'm using the "backup" kernel only when the new one has an issue, so I
> have not tested it for a while, but it used to work, for sure.
>
> > Can you do printenv in OF and tell me what
> > your load-base, real-base, virt-base etc... are ?
>
> load-base is 0x800000, real-base and virt-base is set to "-1", please see
> http://nerdbynature.de/bits/3.4.0-rc1/init/printenv-1.JPG
>
> Not sure if this is related, but at the end of each kernel compilation,
> the following messages are printed:
>
> ------------
> SYSMAP System.map
> SYSMAP .tmp_System.map
> WRAP arch/powerpc/boot/zImage.pmac
> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the wrapper(0x400000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> WRAP arch/powerpc/boot/zImage.coff
> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the wrapper(0x500000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> WRAP arch/powerpc/boot/zImage.miboot
> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the wrapper(0x400000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> Building modules, stage 2.
> MODPOST 24 modules
> ------------
>
> I started to see these messages in January (around Linux 3.2.0), but never
> investigated what it was since the produced kernels continued to boot just
> fine.
>
> > Might also be worth updating yaboot, debian should have 1.3.16 nowadays.
>
> Debian/stable still has 1.3.13a, I'll try to install 1.3.16 from
> Debian/testing.
>
> Thanks for your help,
> Christian.
--
BOFH excuse #372:
Forced to support NT servers; sysadmins quit.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
2012-04-03 17:18 ` Christian Kujau
@ 2012-04-04 12:36 ` Suzuki K. Poulose
2012-04-04 12:36 ` Suzuki K. Poulose
1 sibling, 0 replies; 16+ messages in thread
From: Suzuki K. Poulose @ 2012-04-04 12:36 UTC (permalink / raw)
To: Christian Kujau; +Cc: Benjamin Herrenschmidt, linuxppc-dev, LKML, Al Viro
On 04/03/2012 10:48 PM, Christian Kujau wrote:
> On Tue, 3 Apr 2012 at 18:08, Benjamin Herrenschmidt wrote:
>> I have observed this randomly on the G5 ... sometimes, if I try again,
>> it works... it's very very odd. There is some kind of race maybe with
>> async startup ? Or a problem with the vfs path walking ? It's certainly
>> not easily reproducable for me, it goes away from one boot to the next.
>
> It's 100% reproducible for me. This PowerBook G4 (1.25Ghz) is not the
> fastes though, maybe a race triggers more easily here...?
>
>>> PS: Unfortunately I cannot boot into the old (3.3-rc7) kernel
>>> right now (which is still installed via "yaboot" and present in
>>> /boot), because of this:
>>> http://nerdbynature.de/bits/3.4.0-rc1/init/mac-invalid-memory.JPG
>>> Booting into Debian's "squeeze" kernel (2.6.32) which resides in
>>> the same /boot directory succeeds.
>>
>> Hrm, did it used to boot ?
>
> I'm using the "backup" kernel only when the new one has an issue, so I
> have not tested it for a while, but it used to work, for sure.
>
>> Can you do printenv in OF and tell me what
>> your load-base, real-base, virt-base etc... are ?
>
> load-base is 0x800000, real-base and virt-base is set to "-1", please see
> http://nerdbynature.de/bits/3.4.0-rc1/init/printenv-1.JPG
>
> Not sure if this is related, but at the end of each kernel compilation,
> the following messages are printed:
>
> ------------
> SYSMAP System.map
> SYSMAP .tmp_System.map
> WRAP arch/powerpc/boot/zImage.pmac
> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the wrapper(0x400000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> WRAP arch/powerpc/boot/zImage.coff
> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the wrapper(0x500000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> WRAP arch/powerpc/boot/zImage.miboot
> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the wrapper(0x400000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> Building modules, stage 2.
> MODPOST 24 modules
> ------------
>
> I started to see these messages in January (around Linux 3.2.0), but never
> investigated what it was since the produced kernels continued to boot just
> fine.
The above change was added by me. The message is printed when the
'wrapper' script finds that decompressed kernel overlaps the 'bootstrap
code' which does the decompression. So it shifts the 'address' of the
bootstrap code to the next higher MB. As such it is harmless.
Thanks
Suzuki
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
@ 2012-04-04 12:36 ` Suzuki K. Poulose
0 siblings, 0 replies; 16+ messages in thread
From: Suzuki K. Poulose @ 2012-04-04 12:36 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML, Al Viro
On 04/03/2012 10:48 PM, Christian Kujau wrote:
> On Tue, 3 Apr 2012 at 18:08, Benjamin Herrenschmidt wrote:
>> I have observed this randomly on the G5 ... sometimes, if I try again,
>> it works... it's very very odd. There is some kind of race maybe with
>> async startup ? Or a problem with the vfs path walking ? It's certainly
>> not easily reproducable for me, it goes away from one boot to the next.
>
> It's 100% reproducible for me. This PowerBook G4 (1.25Ghz) is not the
> fastes though, maybe a race triggers more easily here...?
>
>>> PS: Unfortunately I cannot boot into the old (3.3-rc7) kernel
>>> right now (which is still installed via "yaboot" and present in
>>> /boot), because of this:
>>> http://nerdbynature.de/bits/3.4.0-rc1/init/mac-invalid-memory.JPG
>>> Booting into Debian's "squeeze" kernel (2.6.32) which resides in
>>> the same /boot directory succeeds.
>>
>> Hrm, did it used to boot ?
>
> I'm using the "backup" kernel only when the new one has an issue, so I
> have not tested it for a while, but it used to work, for sure.
>
>> Can you do printenv in OF and tell me what
>> your load-base, real-base, virt-base etc... are ?
>
> load-base is 0x800000, real-base and virt-base is set to "-1", please see
> http://nerdbynature.de/bits/3.4.0-rc1/init/printenv-1.JPG
>
> Not sure if this is related, but at the end of each kernel compilation,
> the following messages are printed:
>
> ------------
> SYSMAP System.map
> SYSMAP .tmp_System.map
> WRAP arch/powerpc/boot/zImage.pmac
> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the wrapper(0x400000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> WRAP arch/powerpc/boot/zImage.coff
> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the wrapper(0x500000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> WRAP arch/powerpc/boot/zImage.miboot
> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the wrapper(0x400000)
> INFO: Fixing the link_address of wrapper to (0x700000)
> Building modules, stage 2.
> MODPOST 24 modules
> ------------
>
> I started to see these messages in January (around Linux 3.2.0), but never
> investigated what it was since the produced kernels continued to boot just
> fine.
The above change was added by me. The message is printed when the
'wrapper' script finds that decompressed kernel overlaps the 'bootstrap
code' which does the decompression. So it shifts the 'address' of the
bootstrap code to the next higher MB. As such it is harmless.
Thanks
Suzuki
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
2012-04-04 12:36 ` Suzuki K. Poulose
(?)
@ 2012-04-04 16:45 ` Christian Kujau
2012-04-10 7:23 ` Benjamin Herrenschmidt
-1 siblings, 1 reply; 16+ messages in thread
From: Christian Kujau @ 2012-04-04 16:45 UTC (permalink / raw)
To: Suzuki K. Poulose; +Cc: linuxppc-dev, LKML
On Wed, 4 Apr 2012 at 18:06, Suzuki K. Poulose wrote:
> > INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
> > wrapper(0x400000)
> > INFO: Fixing the link_address of wrapper to (0x700000)
> > Building modules, stage 2.
> > MODPOST 24 modules
> > ------------
> >
> > I started to see these messages in January (around Linux 3.2.0), but never
> > investigated what it was since the produced kernels continued to boot just
> > fine.
>
> The above change was added by me. The message is printed when the 'wrapper'
> script finds that decompressed kernel overlaps the 'bootstrap code' which does
> the decompression. So it shifts the 'address' of the bootstrap code to the
> next higher MB. As such it is harmless.
OK, good to know that it's harmless. Thanks for the explanation.
Christian.
--
BOFH excuse #256:
You need to install an RTFM interface.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
2012-04-03 8:08 ` Benjamin Herrenschmidt
2012-04-03 17:18 ` Christian Kujau
@ 2012-04-10 5:47 ` Christian Kujau
1 sibling, 0 replies; 16+ messages in thread
From: Christian Kujau @ 2012-04-10 5:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, LKML
On Tue, 3 Apr 2012 at 18:08, Benjamin Herrenschmidt wrote:
> On Tue, 2012-04-03 at 00:20 -0700, Christian Kujau wrote:
> > Going from 3.3-rc7 to 3.4-rc1 (with "make oldconfig" inbetween) did not
> > go well on this PowerBook G4 machine:
> >
> > Apr 2 15:18:23 [ 8.318816] EXT4-fs (hda6): mounted filesystem with ordered data mode. Opts: (null)
> > Apr 2 15:18:23 [ 8.320286] VFS: Mounted root (ext4 filesystem) readonly on device 3:6.
> > Apr 2 15:18:23 [ 8.341555] devtmpfs: mounted
> > Apr 2 15:18:23 [ 8.343384] Freeing unused kernel memory: 204k freed
> > Apr 2 15:18:23 [ 8.457056] Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
> > Apr 2 15:18:23 [ 8.459936] Rebooting in 180 seconds..
>
> I have observed this randomly on the G5 ... sometimes, if I try again,
> it works... it's very very odd. There is some kind of race maybe with
> async startup ? Or a problem with the vfs path walking ? It's certainly
> not easily reproducable for me, it goes away from one boot to the next.
I tried to sit this one out, but when -rc2 did not magicially fix it I
started a git bisect, this is what I got:
* a546498f3bf9aac311c66f965186373aee2ca0b0 is the first bad commit
commit a546498f3bf9aac311c66f965186373aee2ca0b0
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed Mar 7 16:48:45 2012 +1100
powerpc: Call do_page_fault() with interrupts off
Full bisect-log & more: http://nerdbynature.de/bits/3.4.0-rc1/init/
Thanks,
Christian.
--
BOFH excuse #124:
user to computer ration too low.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
2012-04-04 16:45 ` Christian Kujau
@ 2012-04-10 7:23 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2012-04-10 7:23 UTC (permalink / raw)
To: Christian Kujau; +Cc: Suzuki K. Poulose, linuxppc-dev, LKML
On Wed, 2012-04-04 at 09:45 -0700, Christian Kujau wrote:
> On Wed, 4 Apr 2012 at 18:06, Suzuki K. Poulose wrote:
> > > INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
> > > wrapper(0x400000)
> > > INFO: Fixing the link_address of wrapper to (0x700000)
> > > Building modules, stage 2.
> > > MODPOST 24 modules
> > > ------------
> > >
> > > I started to see these messages in January (around Linux 3.2.0), but never
> > > investigated what it was since the produced kernels continued to boot just
> > > fine.
> >
> > The above change was added by me. The message is printed when the 'wrapper'
> > script finds that decompressed kernel overlaps the 'bootstrap code' which does
> > the decompression. So it shifts the 'address' of the bootstrap code to the
> > next higher MB. As such it is harmless.
>
> OK, good to know that it's harmless. Thanks for the explanation.
I think I found it :-)
can you test the patch below ?
>From 08f1ec8a594c60bf3856e3c45b6d15fd691d90bb Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue, 10 Apr 2012 17:21:35 +1000
Subject: [PATCH] powerpc: Fix page fault with lockdep regression
commit a546498f3bf9aac311c66f965186373aee2ca0b0
introduced a regression on 32-bit when irq tracing
is enabled by exposing an old bug in our irq tracing
code for exception entry.
The code would save and restore some GPRs around the
calls to the C lockdep code, however, it tries to be
too smart for its own good and restores some of the
GPRs from the exception frame (as saved there on
exception entry).
However, for page faults, we do replace those GPRs with
arguments to do_page_fault before we call transfer_to_handler
and so restoring from the exception frame is plain wrong in
this case.
This was fine as long as we didn't touch the interrupt state
when taking page fault, but when I started doing it, it would
trigger the lockdep calls and the bug.
This fixes it by cleaning up that code a bit. It did create
a small stack frame for the sake of backtraces, so let's
make it a bit bigger and use it to save and restore the
stuff we care about.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/entry_32.S | 39 +++++++++++++++++++++------------------
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 3e57a00..ba3aeb4 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -206,40 +206,43 @@ reenable_mmu: /* re-enable mmu so we can */
andi. r10,r10,MSR_EE /* Did EE change? */
beq 1f
- /* Save handler and return address into the 2 unused words
- * of the STACK_FRAME_OVERHEAD (sneak sneak sneak). Everything
- * else can be recovered from the pt_regs except r3 which for
- * normal interrupts has been set to pt_regs and for syscalls
- * is an argument, so we temporarily use ORIG_GPR3 to save it
- */
- stw r9,8(r1)
- stw r11,12(r1)
- stw r3,ORIG_GPR3(r1)
/*
* The trace_hardirqs_off will use CALLER_ADDR0 and CALLER_ADDR1.
* If from user mode there is only one stack frame on the stack, and
* accessing CALLER_ADDR1 will cause oops. So we need create a dummy
* stack frame to make trace_hardirqs_off happy.
+ *
+ * This is handy because we also need to save a bunch of GPRs,
+ * r3 can be different from GPR3(r1) at this point, r9 and r11
+ * contains the old MSR and handler address respectively,
+ * r4 & r5 can contain page fault arguments that need to be passed
+ * along as well. r12, CCR, CTR, XER etc... are left clobbered as
+ * they aren't useful past this point (aren't syscall arguments),
+ * the rest is restored from the exception frame.
*/
+ stwu r1,-32(r1)
+ stw r9,8(r1)
+ stw r11,12(r1)
+ stw r3,16(r1)
+ stw r4,20(r1)
+ stw r5,24(r1)
andi. r12,r12,MSR_PR
- beq 11f
- stwu r1,-16(r1)
+ b 11f
bl trace_hardirqs_off
- addi r1,r1,16
b 12f
-
11:
bl trace_hardirqs_off
12:
+ lwz r5,24(r1)
+ lwz r4,20(r1)
+ lwz r3,16(r1)
+ lwz r11,12(r1)
+ lwz r9,8(r1)
+ addi r1,r1,32
lwz r0,GPR0(r1)
- lwz r3,ORIG_GPR3(r1)
- lwz r4,GPR4(r1)
- lwz r5,GPR5(r1)
lwz r6,GPR6(r1)
lwz r7,GPR7(r1)
lwz r8,GPR8(r1)
- lwz r9,8(r1)
- lwz r11,12(r1)
1: mtctr r11
mtlr r9
bctr /* jump to handler */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
@ 2012-04-10 7:23 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2012-04-10 7:23 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, Suzuki K. Poulose, LKML
On Wed, 2012-04-04 at 09:45 -0700, Christian Kujau wrote:
> On Wed, 4 Apr 2012 at 18:06, Suzuki K. Poulose wrote:
> > > INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
> > > wrapper(0x400000)
> > > INFO: Fixing the link_address of wrapper to (0x700000)
> > > Building modules, stage 2.
> > > MODPOST 24 modules
> > > ------------
> > >
> > > I started to see these messages in January (around Linux 3.2.0), but never
> > > investigated what it was since the produced kernels continued to boot just
> > > fine.
> >
> > The above change was added by me. The message is printed when the 'wrapper'
> > script finds that decompressed kernel overlaps the 'bootstrap code' which does
> > the decompression. So it shifts the 'address' of the bootstrap code to the
> > next higher MB. As such it is harmless.
>
> OK, good to know that it's harmless. Thanks for the explanation.
I think I found it :-)
can you test the patch below ?
>From 08f1ec8a594c60bf3856e3c45b6d15fd691d90bb Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue, 10 Apr 2012 17:21:35 +1000
Subject: [PATCH] powerpc: Fix page fault with lockdep regression
commit a546498f3bf9aac311c66f965186373aee2ca0b0
introduced a regression on 32-bit when irq tracing
is enabled by exposing an old bug in our irq tracing
code for exception entry.
The code would save and restore some GPRs around the
calls to the C lockdep code, however, it tries to be
too smart for its own good and restores some of the
GPRs from the exception frame (as saved there on
exception entry).
However, for page faults, we do replace those GPRs with
arguments to do_page_fault before we call transfer_to_handler
and so restoring from the exception frame is plain wrong in
this case.
This was fine as long as we didn't touch the interrupt state
when taking page fault, but when I started doing it, it would
trigger the lockdep calls and the bug.
This fixes it by cleaning up that code a bit. It did create
a small stack frame for the sake of backtraces, so let's
make it a bit bigger and use it to save and restore the
stuff we care about.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/entry_32.S | 39 +++++++++++++++++++++------------------
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 3e57a00..ba3aeb4 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -206,40 +206,43 @@ reenable_mmu: /* re-enable mmu so we can */
andi. r10,r10,MSR_EE /* Did EE change? */
beq 1f
- /* Save handler and return address into the 2 unused words
- * of the STACK_FRAME_OVERHEAD (sneak sneak sneak). Everything
- * else can be recovered from the pt_regs except r3 which for
- * normal interrupts has been set to pt_regs and for syscalls
- * is an argument, so we temporarily use ORIG_GPR3 to save it
- */
- stw r9,8(r1)
- stw r11,12(r1)
- stw r3,ORIG_GPR3(r1)
/*
* The trace_hardirqs_off will use CALLER_ADDR0 and CALLER_ADDR1.
* If from user mode there is only one stack frame on the stack, and
* accessing CALLER_ADDR1 will cause oops. So we need create a dummy
* stack frame to make trace_hardirqs_off happy.
+ *
+ * This is handy because we also need to save a bunch of GPRs,
+ * r3 can be different from GPR3(r1) at this point, r9 and r11
+ * contains the old MSR and handler address respectively,
+ * r4 & r5 can contain page fault arguments that need to be passed
+ * along as well. r12, CCR, CTR, XER etc... are left clobbered as
+ * they aren't useful past this point (aren't syscall arguments),
+ * the rest is restored from the exception frame.
*/
+ stwu r1,-32(r1)
+ stw r9,8(r1)
+ stw r11,12(r1)
+ stw r3,16(r1)
+ stw r4,20(r1)
+ stw r5,24(r1)
andi. r12,r12,MSR_PR
- beq 11f
- stwu r1,-16(r1)
+ b 11f
bl trace_hardirqs_off
- addi r1,r1,16
b 12f
-
11:
bl trace_hardirqs_off
12:
+ lwz r5,24(r1)
+ lwz r4,20(r1)
+ lwz r3,16(r1)
+ lwz r11,12(r1)
+ lwz r9,8(r1)
+ addi r1,r1,32
lwz r0,GPR0(r1)
- lwz r3,ORIG_GPR3(r1)
- lwz r4,GPR4(r1)
- lwz r5,GPR5(r1)
lwz r6,GPR6(r1)
lwz r7,GPR7(r1)
lwz r8,GPR8(r1)
- lwz r9,8(r1)
- lwz r11,12(r1)
1: mtctr r11
mtlr r9
bctr /* jump to handler */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
2012-04-10 7:23 ` Benjamin Herrenschmidt
@ 2012-04-10 16:56 ` Christian Kujau
-1 siblings, 0 replies; 16+ messages in thread
From: Christian Kujau @ 2012-04-10 16:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Suzuki K. Poulose, linuxppc-dev, LKML
On Tue, 10 Apr 2012 at 17:23, Benjamin Herrenschmidt wrote:
> can you test the patch below ?
When applied to 3.4-rc2, Linux boots again, yay! :-)
Tested-by: Christian Kujau <lists@nerdbynature.de>
Thanks!
Christian.
> From 08f1ec8a594c60bf3856e3c45b6d15fd691d90bb Mon Sep 17 00:00:00 2001
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Tue, 10 Apr 2012 17:21:35 +1000
> Subject: [PATCH] powerpc: Fix page fault with lockdep regression
>
> commit a546498f3bf9aac311c66f965186373aee2ca0b0
> introduced a regression on 32-bit when irq tracing
> is enabled by exposing an old bug in our irq tracing
> code for exception entry.
>
> The code would save and restore some GPRs around the
> calls to the C lockdep code, however, it tries to be
> too smart for its own good and restores some of the
> GPRs from the exception frame (as saved there on
> exception entry).
>
> However, for page faults, we do replace those GPRs with
> arguments to do_page_fault before we call transfer_to_handler
> and so restoring from the exception frame is plain wrong in
> this case.
>
> This was fine as long as we didn't touch the interrupt state
> when taking page fault, but when I started doing it, it would
> trigger the lockdep calls and the bug.
>
> This fixes it by cleaning up that code a bit. It did create
> a small stack frame for the sake of backtraces, so let's
> make it a bit bigger and use it to save and restore the
> stuff we care about.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/entry_32.S | 39 +++++++++++++++++++++------------------
> 1 file changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 3e57a00..ba3aeb4 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -206,40 +206,43 @@ reenable_mmu: /* re-enable mmu so we can */
> andi. r10,r10,MSR_EE /* Did EE change? */
> beq 1f
>
> - /* Save handler and return address into the 2 unused words
> - * of the STACK_FRAME_OVERHEAD (sneak sneak sneak). Everything
> - * else can be recovered from the pt_regs except r3 which for
> - * normal interrupts has been set to pt_regs and for syscalls
> - * is an argument, so we temporarily use ORIG_GPR3 to save it
> - */
> - stw r9,8(r1)
> - stw r11,12(r1)
> - stw r3,ORIG_GPR3(r1)
> /*
> * The trace_hardirqs_off will use CALLER_ADDR0 and CALLER_ADDR1.
> * If from user mode there is only one stack frame on the stack, and
> * accessing CALLER_ADDR1 will cause oops. So we need create a dummy
> * stack frame to make trace_hardirqs_off happy.
> + *
> + * This is handy because we also need to save a bunch of GPRs,
> + * r3 can be different from GPR3(r1) at this point, r9 and r11
> + * contains the old MSR and handler address respectively,
> + * r4 & r5 can contain page fault arguments that need to be passed
> + * along as well. r12, CCR, CTR, XER etc... are left clobbered as
> + * they aren't useful past this point (aren't syscall arguments),
> + * the rest is restored from the exception frame.
> */
> + stwu r1,-32(r1)
> + stw r9,8(r1)
> + stw r11,12(r1)
> + stw r3,16(r1)
> + stw r4,20(r1)
> + stw r5,24(r1)
> andi. r12,r12,MSR_PR
> - beq 11f
> - stwu r1,-16(r1)
> + b 11f
> bl trace_hardirqs_off
> - addi r1,r1,16
> b 12f
> -
> 11:
> bl trace_hardirqs_off
> 12:
> + lwz r5,24(r1)
> + lwz r4,20(r1)
> + lwz r3,16(r1)
> + lwz r11,12(r1)
> + lwz r9,8(r1)
> + addi r1,r1,32
> lwz r0,GPR0(r1)
> - lwz r3,ORIG_GPR3(r1)
> - lwz r4,GPR4(r1)
> - lwz r5,GPR5(r1)
> lwz r6,GPR6(r1)
> lwz r7,GPR7(r1)
> lwz r8,GPR8(r1)
> - lwz r9,8(r1)
> - lwz r11,12(r1)
> 1: mtctr r11
> mtlr r9
> bctr /* jump to handler */
> --
> 1.7.9.5
>
--
BOFH excuse #292:
We ran out of dial tone and we're and waiting for the phone company to deliver another bottle.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
@ 2012-04-10 16:56 ` Christian Kujau
0 siblings, 0 replies; 16+ messages in thread
From: Christian Kujau @ 2012-04-10 16:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Suzuki K. Poulose, LKML
On Tue, 10 Apr 2012 at 17:23, Benjamin Herrenschmidt wrote:
> can you test the patch below ?
When applied to 3.4-rc2, Linux boots again, yay! :-)
Tested-by: Christian Kujau <lists@nerdbynature.de>
Thanks!
Christian.
> From 08f1ec8a594c60bf3856e3c45b6d15fd691d90bb Mon Sep 17 00:00:00 2001
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Tue, 10 Apr 2012 17:21:35 +1000
> Subject: [PATCH] powerpc: Fix page fault with lockdep regression
>
> commit a546498f3bf9aac311c66f965186373aee2ca0b0
> introduced a regression on 32-bit when irq tracing
> is enabled by exposing an old bug in our irq tracing
> code for exception entry.
>
> The code would save and restore some GPRs around the
> calls to the C lockdep code, however, it tries to be
> too smart for its own good and restores some of the
> GPRs from the exception frame (as saved there on
> exception entry).
>
> However, for page faults, we do replace those GPRs with
> arguments to do_page_fault before we call transfer_to_handler
> and so restoring from the exception frame is plain wrong in
> this case.
>
> This was fine as long as we didn't touch the interrupt state
> when taking page fault, but when I started doing it, it would
> trigger the lockdep calls and the bug.
>
> This fixes it by cleaning up that code a bit. It did create
> a small stack frame for the sake of backtraces, so let's
> make it a bit bigger and use it to save and restore the
> stuff we care about.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/entry_32.S | 39 +++++++++++++++++++++------------------
> 1 file changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 3e57a00..ba3aeb4 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -206,40 +206,43 @@ reenable_mmu: /* re-enable mmu so we can */
> andi. r10,r10,MSR_EE /* Did EE change? */
> beq 1f
>
> - /* Save handler and return address into the 2 unused words
> - * of the STACK_FRAME_OVERHEAD (sneak sneak sneak). Everything
> - * else can be recovered from the pt_regs except r3 which for
> - * normal interrupts has been set to pt_regs and for syscalls
> - * is an argument, so we temporarily use ORIG_GPR3 to save it
> - */
> - stw r9,8(r1)
> - stw r11,12(r1)
> - stw r3,ORIG_GPR3(r1)
> /*
> * The trace_hardirqs_off will use CALLER_ADDR0 and CALLER_ADDR1.
> * If from user mode there is only one stack frame on the stack, and
> * accessing CALLER_ADDR1 will cause oops. So we need create a dummy
> * stack frame to make trace_hardirqs_off happy.
> + *
> + * This is handy because we also need to save a bunch of GPRs,
> + * r3 can be different from GPR3(r1) at this point, r9 and r11
> + * contains the old MSR and handler address respectively,
> + * r4 & r5 can contain page fault arguments that need to be passed
> + * along as well. r12, CCR, CTR, XER etc... are left clobbered as
> + * they aren't useful past this point (aren't syscall arguments),
> + * the rest is restored from the exception frame.
> */
> + stwu r1,-32(r1)
> + stw r9,8(r1)
> + stw r11,12(r1)
> + stw r3,16(r1)
> + stw r4,20(r1)
> + stw r5,24(r1)
> andi. r12,r12,MSR_PR
> - beq 11f
> - stwu r1,-16(r1)
> + b 11f
> bl trace_hardirqs_off
> - addi r1,r1,16
> b 12f
> -
> 11:
> bl trace_hardirqs_off
> 12:
> + lwz r5,24(r1)
> + lwz r4,20(r1)
> + lwz r3,16(r1)
> + lwz r11,12(r1)
> + lwz r9,8(r1)
> + addi r1,r1,32
> lwz r0,GPR0(r1)
> - lwz r3,ORIG_GPR3(r1)
> - lwz r4,GPR4(r1)
> - lwz r5,GPR5(r1)
> lwz r6,GPR6(r1)
> lwz r7,GPR7(r1)
> lwz r8,GPR8(r1)
> - lwz r9,8(r1)
> - lwz r11,12(r1)
> 1: mtctr r11
> mtlr r9
> bctr /* jump to handler */
> --
> 1.7.9.5
>
--
BOFH excuse #292:
We ran out of dial tone and we're and waiting for the phone company to deliver another bottle.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
2012-04-04 12:36 ` Suzuki K. Poulose
@ 2012-07-05 22:36 ` Tabi Timur-B04825
-1 siblings, 0 replies; 16+ messages in thread
From: Tabi Timur-B04825 @ 2012-07-05 22:36 UTC (permalink / raw)
To: Suzuki K. Poulose
Cc: Christian Kujau, Benjamin Herrenschmidt, linuxppc-dev, LKML, Al Viro
On Wed, Apr 4, 2012 at 7:36 AM, Suzuki K. Poulose <suzuki@in.ibm.com> wrote:
>> Not sure if this is related, but at the end of each kernel compilation,
>> the following messages are printed:
>>
>> ------------
>> SYSMAP System.map
>> SYSMAP .tmp_System.map
>> WRAP arch/powerpc/boot/zImage.pmac
>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>> wrapper(0x400000)
>> INFO: Fixing the link_address of wrapper to (0x700000)
>> WRAP arch/powerpc/boot/zImage.coff
>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>> wrapper(0x500000)
>> INFO: Fixing the link_address of wrapper to (0x700000)
>> WRAP arch/powerpc/boot/zImage.miboot
>> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
>> wrapper(0x400000)
>> INFO: Fixing the link_address of wrapper to (0x700000)
>> Building modules, stage 2.
>> MODPOST 24 modules
>> ------------
>>
>> I started to see these messages in January (around Linux 3.2.0), but never
>> investigated what it was since the produced kernels continued to boot just
>> fine.
>
>
> The above change was added by me. The message is printed when the 'wrapper'
> script finds that decompressed kernel overlaps the 'bootstrap code' which
> does the decompression. So it shifts the 'address' of the bootstrap code to
> the next higher MB. As such it is harmless.
I see this message every time when I build the kernel. I know it's
harmless, but is this something that can be "fixed"? That is, can we
change some linker script (or whatever) to make 0x700000 the default
value? Or maybe modify the wrapper script to just automatically find
the right spot without printing a message?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
@ 2012-07-05 22:36 ` Tabi Timur-B04825
0 siblings, 0 replies; 16+ messages in thread
From: Tabi Timur-B04825 @ 2012-07-05 22:36 UTC (permalink / raw)
To: Suzuki K. Poulose; +Cc: Christian Kujau, linuxppc-dev, LKML, Al Viro
On Wed, Apr 4, 2012 at 7:36 AM, Suzuki K. Poulose <suzuki@in.ibm.com> wrote=
:
>> Not sure if this is related, but at the end of each kernel compilation,
>> the following messages are printed:
>>
>> ------------
>> SYSMAP System.map
>> SYSMAP .tmp_System.map
>> WRAP arch/powerpc/boot/zImage.pmac
>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>> wrapper(0x400000)
>> INFO: Fixing the link_address of wrapper to (0x700000)
>> WRAP arch/powerpc/boot/zImage.coff
>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>> wrapper(0x500000)
>> INFO: Fixing the link_address of wrapper to (0x700000)
>> WRAP arch/powerpc/boot/zImage.miboot
>> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
>> wrapper(0x400000)
>> INFO: Fixing the link_address of wrapper to (0x700000)
>> Building modules, stage 2.
>> MODPOST 24 modules
>> ------------
>>
>> I started to see these messages in January (around Linux 3.2.0), but nev=
er
>> investigated what it was since the produced kernels continued to boot ju=
st
>> fine.
>
>
> The above change was added by me. The message is printed when the 'wrappe=
r'
> script finds that decompressed kernel overlaps the 'bootstrap code' which
> does the decompression. So it shifts the 'address' of the bootstrap code =
to
> the next higher MB. As such it is harmless.
I see this message every time when I build the kernel. I know it's
harmless, but is this something that can be "fixed"? That is, can we
change some linker script (or whatever) to make 0x700000 the default
value? Or maybe modify the wrapper script to just automatically find
the right spot without printing a message?
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
2012-07-05 22:36 ` Tabi Timur-B04825
@ 2012-07-06 5:20 ` Suzuki K. Poulose
-1 siblings, 0 replies; 16+ messages in thread
From: Suzuki K. Poulose @ 2012-07-06 5:20 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Christian Kujau, Benjamin Herrenschmidt, linuxppc-dev, LKML, Al Viro
On 07/06/2012 04:06 AM, Tabi Timur-B04825 wrote:
> On Wed, Apr 4, 2012 at 7:36 AM, Suzuki K. Poulose <suzuki@in.ibm.com> wrote:
>
>>> Not sure if this is related, but at the end of each kernel compilation,
>>> the following messages are printed:
>>>
>>> ------------
>>> SYSMAP System.map
>>> SYSMAP .tmp_System.map
>>> WRAP arch/powerpc/boot/zImage.pmac
>>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>>> wrapper(0x400000)
>>> INFO: Fixing the link_address of wrapper to (0x700000)
>>> WRAP arch/powerpc/boot/zImage.coff
>>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>>> wrapper(0x500000)
>>> INFO: Fixing the link_address of wrapper to (0x700000)
>>> WRAP arch/powerpc/boot/zImage.miboot
>>> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
>>> wrapper(0x400000)
>>> INFO: Fixing the link_address of wrapper to (0x700000)
>>> Building modules, stage 2.
>>> MODPOST 24 modules
>>> ------------
>>>
>>> I started to see these messages in January (around Linux 3.2.0), but never
>>> investigated what it was since the produced kernels continued to boot just
>>> fine.
>>
>>
>> The above change was added by me. The message is printed when the 'wrapper'
>> script finds that decompressed kernel overlaps the 'bootstrap code' which
>> does the decompression. So it shifts the 'address' of the bootstrap code to
>> the next higher MB. As such it is harmless.
>
> I see this message every time when I build the kernel. I know it's
> harmless, but is this something that can be "fixed"? That is, can we
> change some linker script (or whatever) to make 0x700000 the default
> value?
You could do this by setting the link_address by checking your platform,
like some of the other platforms (e.g, pseries, ps3 ).
Or
we could add a parameter to the wrapper script to set the link_address ?
Ben, Josh,
What do you think ?
Or maybe modify the wrapper script to just automatically find
> the right spot without printing a message?
We need the message there for people who have restriction of a fixed
link address. This would help them to handle the situation accordingly
than blindly failing on boot.
Thanks
Suzuki
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 3.4.0-rc1: No init found
@ 2012-07-06 5:20 ` Suzuki K. Poulose
0 siblings, 0 replies; 16+ messages in thread
From: Suzuki K. Poulose @ 2012-07-06 5:20 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: Christian Kujau, linuxppc-dev, LKML, Al Viro
On 07/06/2012 04:06 AM, Tabi Timur-B04825 wrote:
> On Wed, Apr 4, 2012 at 7:36 AM, Suzuki K. Poulose <suzuki@in.ibm.com> wrote:
>
>>> Not sure if this is related, but at the end of each kernel compilation,
>>> the following messages are printed:
>>>
>>> ------------
>>> SYSMAP System.map
>>> SYSMAP .tmp_System.map
>>> WRAP arch/powerpc/boot/zImage.pmac
>>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>>> wrapper(0x400000)
>>> INFO: Fixing the link_address of wrapper to (0x700000)
>>> WRAP arch/powerpc/boot/zImage.coff
>>> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the
>>> wrapper(0x500000)
>>> INFO: Fixing the link_address of wrapper to (0x700000)
>>> WRAP arch/powerpc/boot/zImage.miboot
>>> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the
>>> wrapper(0x400000)
>>> INFO: Fixing the link_address of wrapper to (0x700000)
>>> Building modules, stage 2.
>>> MODPOST 24 modules
>>> ------------
>>>
>>> I started to see these messages in January (around Linux 3.2.0), but never
>>> investigated what it was since the produced kernels continued to boot just
>>> fine.
>>
>>
>> The above change was added by me. The message is printed when the 'wrapper'
>> script finds that decompressed kernel overlaps the 'bootstrap code' which
>> does the decompression. So it shifts the 'address' of the bootstrap code to
>> the next higher MB. As such it is harmless.
>
> I see this message every time when I build the kernel. I know it's
> harmless, but is this something that can be "fixed"? That is, can we
> change some linker script (or whatever) to make 0x700000 the default
> value?
You could do this by setting the link_address by checking your platform,
like some of the other platforms (e.g, pseries, ps3 ).
Or
we could add a parameter to the wrapper script to set the link_address ?
Ben, Josh,
What do you think ?
Or maybe modify the wrapper script to just automatically find
> the right spot without printing a message?
We need the message there for people who have restriction of a fixed
link address. This would help them to handle the situation accordingly
than blindly failing on boot.
Thanks
Suzuki
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-07-06 5:20 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-03 7:20 3.4.0-rc1: No init found Christian Kujau
2012-04-03 8:08 ` Benjamin Herrenschmidt
2012-04-03 17:18 ` Christian Kujau
2012-04-03 18:53 ` Christian Kujau
2012-04-04 12:36 ` Suzuki K. Poulose
2012-04-04 12:36 ` Suzuki K. Poulose
2012-04-04 16:45 ` Christian Kujau
2012-04-10 7:23 ` Benjamin Herrenschmidt
2012-04-10 7:23 ` Benjamin Herrenschmidt
2012-04-10 16:56 ` Christian Kujau
2012-04-10 16:56 ` Christian Kujau
2012-07-05 22:36 ` Tabi Timur-B04825
2012-07-05 22:36 ` Tabi Timur-B04825
2012-07-06 5:20 ` Suzuki K. Poulose
2012-07-06 5:20 ` Suzuki K. Poulose
2012-04-10 5:47 ` Christian Kujau
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.