[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7e1cf4a7-47a5-9763-545e-1157f9b2f91a@c-s.fr>
Date: Tue, 21 Nov 2017 10:58:31 +0100
From: Christophe LEROY <christophe.leroy@....fr>
To: Balbir Singh <bsingharora@...il.com>
Cc: Meelis Roos <mroos@...ux.ee>,
Michael Ellerman <mpe@...erman.id.au>,
Linux Kernel list <linux-kernel@...r.kernel.org>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@...ts.ozlabs.org>
Subject: Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4
Le 21/11/2017 à 03:28, Balbir Singh a écrit :
> On Sun, Nov 19, 2017 at 1:36 AM, LEROY Christophe
> <christophe.leroy@....fr> wrote:
>> Meelis Roos <mroos@...ux.ee> a écrit :
>>
>>>>>> How early does it hang ? Any oops or trace ?
>>>>>
>>>>> Very early - instead oif kernel emssages, I see some repeated gibberish
>>>>> of some characteers, and the background turns white.
>>>>> I am booting from yaboot, background is normally black.
>>>>
>>>> Ok, could you try by replacing #ifdef CONFIG_STRICT_KERNEL_RWX by #if 0
>>>> in arch/powerpc/lib/code-patching.c
>>>
>>>
>>> With this change and CONFIG_STRICT_KERNEL_RWX=y, it still boots.
>>>
>>> BTW, I get these warnings (sorry for the word wrap from screen paste) -
>>> may they be related or rather not?
>>>
>>> WRAP arch/powerpc/boot/zImage.pmac
>>> WRAP arch/powerpc/boot/zImage.coff
>>> WRAP arch/powerpc/boot/zImage.miboot
>>> INFO: Uncompressed kernel (size 0x5d4c3c) overlaps the address of the
>>> wrapper(0x400000)
>>> INFO: Fixing the link_address of wrapper to (0x600000)
>>>
>>
>> Then i believe there is something wrong with commit
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20171115&id=37bc3e5fd764fb258ff4fcbb90b6d1b67fb466c1
>>
>> Balbir, do you have any idea ?
>>
>
> Hmm.. interesting, so nobats works, but code-patching has issues? Any
> chance you can boot with xmon=on on the command line
> when you drop into the xmon> prompt, type dl to get the kernel log.
I have the same issue with a 83xx board allthought it is booting well on
my 8xx boards.
Indeed the issue is that patch_instruction() is called from
early_init(), therefor all static data must be addressed using PTRRELOC()
I have submitted a fixup patch, can you review it ?
slab_is_available() cannot be called that early for the same reason but
I believe it is not needed.
Christophe
>
> Balbir Singh.
>
Powered by blists - more mailing lists