On Wed, Mar 4, 2020 at 4:59 AM Xu, Yanfei <[email protected]> wrote: > > 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?
It was there for v5.4, but I just pulled it into the v5.5 branches. (I'll be renaming them v5.5/* shortly, since I'm about to release the -dev kernel for v5.6). Cheers, Bruce > > 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 > >> > >> > >> > >> > > > > -- - 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 (#8439): https://lists.yoctoproject.org/g/linux-yocto/message/8439 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]] -=-=-=-=-=-=-=-=-=-=-=-
