Thanks for your imformation. I have tested it that apply this
commit to linux-yocto-dev and it works well.
Will you apply it to linux-yocto-dev too?
Regards,
//Yanfei
On 3/4/20 12:01 AM, Bruce Ashfield wrote:
On Tue, Mar 3, 2020 at 10:30 AM Xu, Yanfei <[email protected]> wrote:
OK！ So If I understand correctly, this failure will disappear after you bring
the Makefile patch to linux-yocto recently？
It is there, and passing all of our autobuilder tests (or we never
would have made 5.4 the default for qemu*).
It is currently on all the v5.4 branches:
commit 239eea7ef5dd5ec7ce6712ea6fc8e9ba9bd49ece
Author: Victor Kamensky <[email protected]>
Date: Fri Jan 31 09:39:44 2020 -0800
mips: vdso: fix 'jalr $t9' crash in vdso code
Observed that when kernel is built with Yocto mips64-poky-linux-gcc,
and mips64-poky-linux-gnun32-gcc toolchain, resuling vdso contains
'jalr $t9' instructions in its code and since in vdso case nobody
sets GOT table code crashes when instruction reached. On other hand
observed that when kernel is built mips-poky-linux-gcc toolchain, the
same 'jalr $t9' instruction are replaced with PC relative function
calls using 'bal' instructions.
The difference boils down to -mrelax-pic-calls and -mexplicit-relocs
gcc options that gets different default values depending on gcc
target triplets and corresponding binutils. -mrelax-pic-calls got
enabled by default only in mips-poky-linux-gcc case. MIPS binuitls
ld relies on R_MIPS_JALR relocation to convert 'jalr $t9' into 'bal'
and such relocation is generated only if -mrelax-pic-calls option
is on.
Solution call out -mrelax-pic-calls and -mexplicit-relocs options
explicitely while compiling MIPS vdso code. That would get correct
and consitent between different toolchains behavior.
Reported-by: Bruce Ashfield <[email protected]>
Signed-off-by: Victor Kamensky <[email protected]>
:100644 100644 996a934ece7d 25b5adee5ade M arch/mips/vdso/Makefile
Cheers,
Bruce
Regards，
Yanfei
On 3/3/20 10:09 PM, Bruce Ashfield wrote:
On Tue, Mar 3, 2020 at 5:44 AM Xu, Yanfei <[email protected]> wrote:
Hi Bruce,
Do you still remember this issue about vDSO of mips boot failure.The
linux-yocto-dev
still have this problem, even though the mips kernel have some fixes
after that.
Any new progress in it？
Yes, it is fixed in both mainline and linux-yocto itself. It turned
out to be a code generation issue, and I'm carrying a Makefile patch
to address it in linux-yocto.
Bruce
Regards，
Yanfei
On 3/3/20 5:28 PM, He Zhe wrote:
FYI
-------- Forwarded Message --------
Subject: Re: temp: mips: undo vdso reverts
Date: Fri, 20 Dec 2019 15:41:41 -0500
From: Bruce Ashfield <[email protected]>
To: He Zhe <[email protected]>
FYI: I managed to get it booting today. I have a hack/temp patch that
I'm cleaning up now.
Bruce
On Fri, Dec 20, 2019 at 5:31 AM He Zhe <[email protected]> wrote:
Thanks for your effort and information.
Zhe
On 12/20/19 6:17 AM, Bruce Ashfield wrote:
On Thu, Dec 19, 2019 at 8:45 AM Bruce Ashfield <[email protected]> wrote:
On Thu, Dec 19, 2019 at 5:28 AM He Zhe <[email protected]> wrote:
Hi Bruce,
I saw your "temp: mips: undo vdso reverts". Any trick in it solving the boot
failure before the revert? Though I haven't finished the validation. Thanks.
I had to step away from it for a couple of weeks, but am back
debugging the problem now.
I still don't have a solution to booting with those reverts undone.
I emailed the mips kernel mailing list, since I can see this with a
pure mainline kernel, and linux-yocto-dev. But no one was able to
reproduce the problem there, and the idea was that this was
configuration related.
I haven't isolated any config option that is causing this (but yes,
there are those VDSO changes in 5.4+) .. I still say that if a new
option was created, and it has a default that breaks the boot ..
that's a bug .. but I haven't proven that yet.
I'll email again at the end of my day with an update on my progress.
The upstream mips developers suggested that GENERIC_COMPAT_VDSO needs
to be set, but isn't in our .config .. since that isn't an option that
can be specified in a fragment, I forced it on in my local builds.
The result is the same, an immediate segfault on hand over to userspace.
I'm currently hacking gettimeofday() to isolate the issue and will do
more on Friday.
Bruce
Bruce
[ 22.850343] Run /sbin/init as init process
[ 23.355137] do_page_fault(): sending SIGSEGV to init for invalid read access
from 0000000000000330
[ 23.484206] epc = 0000000000000330 in systemd[aaab5ce000+12e000]
[ 23.546202] ra = 000000fffd95c4fc in
[ 23.616964] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[ 23.748041] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b ]---
Zhe
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8438):
https://lists.yoctoproject.org/g/linux-yocto/message/8438
Mute This Topic: https://lists.yoctoproject.org/mt/71697594/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
