On 6/26/19 8:27 PM, Bruce Ashfield wrote: > On Tue, Jun 25, 2019 at 10:55 PM He Zhe <zhe...@windriver.com> wrote: >> >> >> On 6/26/19 10:49 AM, Bruce Ashfield wrote: >>> On Tue, Jun 25, 2019 at 10:25 AM He Zhe <zhe...@windriver.com> wrote: >>>> Hi Bruce, >>>> >>>> Have you ever met the following error with features/security/security.scc, >>>> when running qemux86? >>> Hmm. No, I haven't seen that. >>> >>> My old builds were using sysvinit, so I didn't have a recent build >>> ready to go. But I just started a new one, and will do a boot test on >>> (my) Tuesday. >> Coming together with endless: >> "uvesafb: 5000 ms task timeout, infinitely waiting." >> I found it was stuck on loading uvesafb and should be related Yocto #8245 >> I'm reading the history. > My build completed overnight. I assume with your updated security > fragment you were able to boot again ?
Yes. This happens when we boot qemu with both kernel parameter "uvesafb.task_timeout=-1" and CONFIG_DEVMEM disabled, a set in features/security. And it's not caused by my new additions. This is probably because disabling CONFIG_DEVMEM affects uvesafb which might have to use physical memory access from userspace. With the endless retry from the following commit, the uvesafb driver cannot gracefully fail and quit, and this also drives systemd insanely timed out. See https://bugzilla.yoctoproject.org/show_bug.cgi?id=8245 for more details about uvesafb issue. commit fd9e1ba8f70402bd3c4b873d349057f96f5bcb19 Author: Saul Wold <s...@linux.intel.com> Date: Thu Sep 15 13:29:33 2016 -0700 qemuboot-x86: Add task_timeout = -1 to uvesafb This causes the default timeout to be set to infinity, it will still report out every 5000 milliseconds Signed-off-by: Saul Wold <s...@linux.intel.com> Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org> So we can go with our security updates and add a note in .cfg for uvesafb users. Zhe > > Bruce > >> Thanks, >> Zhe >> >>> Bruce >>> >>>> ... >>>> [ **] A start job is running for Load Kernel Modules (7min 26s / 7min >>>> 31s) >>>> >>>> >>>> * systemd-modules-load.service - Load Kernel Modules >>>> Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; >>>> static; vendor preset: disabled) >>>> Active: failed (Result: timeout) since Tue 2019-06-25 13:55:28 UTC; >>>> 6min ago >>>> Docs: man:systemd-modules-load.service(8) >>>> man:modules-load.d(5) >>>> Main PID: 110 >>>> Tasks: 1 (limit: 570) >>>> Memory: 968.0K >>>> CGroup: /system.slice/systemd-modules-load.service >>>> `-110 /lib/systemd/systemd-modules-load >>>> >>>> Jun 25 13:47:58 qemux86 systemd-modules-load[110]: Inserted module >>>> 'openvswitch' >>>> Jun 25 13:49:27 qemux86 systemd[1]: systemd-modules-load.service: Start >>>> operation timed out. Terminating. >>>> Jun 25 13:50:58 qemux86 systemd[1]: systemd-modules-load.service: State >>>> 'stop-sigterm' timed out. Killing. >>>> Jun 25 13:50:58 qemux86 systemd[1]: systemd-modules-load.service: Killing >>>> process 110 (systemd-modules) with signal SIGKILL. >>>> Jun 25 13:52:28 qemux86 systemd[1]: systemd-modules-load.service: >>>> Processes still around after SIGKILL. Ignoring. >>>> Jun 25 13:53:58 qemux86 systemd[1]: systemd-modules-load.service: State >>>> 'stop-final-sigterm' timed out. Killing. >>>> Jun 25 13:53:58 qemux86 systemd[1]: systemd-modules-load.service: Killing >>>> process 110 (systemd-modules) with signal SIGKILL. >>>> Jun 25 13:55:28 qemux86 systemd[1]: systemd-modules-load.service: >>>> Processes still around after final SIGKILL. Entering failed mode. >>>> Jun 25 13:55:28 qemux86 systemd[1]: systemd-modules-load.service: Failed >>>> with result 'timeout'. >>>> Jun 25 13:55:28 qemux86 systemd[1]: Failed to start Load Kernel Modules. >>>> >>>> >>>> Zhe >>> > -- _______________________________________________ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
