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 > > > > -- - 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 (#8433): https://lists.yoctoproject.org/g/linux-yocto/message/8433 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]] -=-=-=-=-=-=-=-=-=-=-=-
