Boot stuck with latest master (dunfell) on qemu
Description
Environment
Attachments
- 06 May 2020, 01:48 PM
- 06 May 2020, 09:35 AM
Activity
Marius Vlad December 2, 2020 at 12:25 PM
The "solution" for this is to attempt the following: https://lists.automotivelinux.org/g/agl-dev-community/message/8474
Marius Vlad May 18, 2020 at 12:32 PM
Yeah 
, unfortunately I don't know when I'll have time to further look into this. Seems to be quite dependent on the machine and distro + the modifications done in dunfell.
Jan-Simon Moeller May 18, 2020 at 11:45 AM
I'd use the flags also seen in runqemu in your local script.
Marius Vlad May 7, 2020 at 7:02 PM
So, around round of updates, but I'm afraid I don't have any conclusive behaviour, as due to differences between machines I can't get to replicate the behaviour on both sides.
I've tested this on two machines (one remote and one local). I initially tried building remotely, then copy the image over the local one and booting the image with the same script that I've used for icefish/previous master (n the hopes of speeding up things). The remote one is a old IvyBridge and my local machine is even older SandyBridge.
As I was able to pass https://lf-automotivelinux.atlassian.net/browse/SPEC-3361#icft=SPEC-3361 and was able to build current master on both machines, this what I've further tried (I'm using the generated image for each time of machine – as opposed to what I've tried initially):
on the remote machine, I don't have any monitor plugged in so I passed -nographic to opts to the qemu conf and runqemu is able to run and I'm able to get to a login prompt.
on my local machine, running runqemu does absolutely nothing, I only get/see the psplash with no serial on stdio. The command passed to qemu for serial is vc instead of stdio and there's no KVM option passed by (so it seems it does emulation). Running it manually, I was able to enable KVM and pass stdio for serial. Doing that shows the machine boots but, upon logging in, weston dies and psplash is always displaying the AGL logo. I don't have an explanation why runqemu uses different args, nor I tried even more fiddling with it.
Fiddled quite a bit with the CPU flags on my script and discovered that on my local machine, passing -machine q35 it allows to machine to further continue and I'm able to get weston up and running. While this works, rebooting displays general protections faults from all the processes that need to be stopped. I need to test it a bit more to see if there aren't any other issues at stage, but this does the trick for me.
Unfortunately I can't keep debugging it forever, and it seems that there are fine differences even between same types of machines.
Jan-Simon Moeller May 7, 2020 at 12:34 PM
Try the qemu cmdline shown above taken from runqemu .
Details
Details
Assignee
Reporter
Hardware Platform(s) Affected
Priority
Major
Trying to boot with the qemu image, the pslash image stays forever, while the serial will be stuck on the audio bit, finally ending up with:
[ 5.102529] e1000 0000:00:02.0 enp0s2: renamed from eth0 [ 5.132978] e1000 0000:00:07.0 enp0s7: renamed from eth1 [ 5.259650] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: line_outs=1 (0x3/0x0/0x0/0x0/0x0) type:line [ 5.263026] snd_hda_codec_generic hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 5.271496] snd_hda_codec_generic hdaudioC0D0: hp_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 5.276178] snd_hda_codec_generic hdaudioC0D0: mono: mono_out=0x0 [ 5.277270] snd_hda_codec_generic hdaudioC0D0: inputs: [ 5.278158] snd_hda_codec_generic hdaudioC0D0: Line=0x5 Press Enter for maintenance (or press Control-D to continue):