FEMU Crash?

[Daniel Obieglo]

Hi

i am currently trying to get fuchsia to run in the emulator with no success on multiple devices (AMD and Intel).

i already tried to boot different products (workstation, core) as debug and release builds but all of them seem to crash at the same point.

the emu_crash.log says that fuchsia is even able to boot the compnent_manager
[00000.521] 01089:01178> bootsvc: Launched bin/component_manager

but shortly after that it crashes
(Full log : https://ghostbin.com/paste/HLw6Z )

I start the femu with: fx vdl start --software-gpu on ubuntu 18.04 after a successful build
If i use the -N flag the Femu wont even show a GUI and the emu_log in /tmp/vdl_staging_*/emu_log will say:
"qemu-system-x86_64: could not configure /dev/net/tun (qemu): Operation not permitted"
I haven't looked into the net/tun error yet because the FEMU seems to get a little further without the -N flag (Also the tipps i found for this error are already in used by the vdl script).

So i'm currently out of ideas on what to do next...

i hope that someone can help me understand what i've done wrong here.

Thanks.

[Seth Ladd]

cc @Yuan Zhi 

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/discuss/7eb66e00-1016-4d58-b3df-469d4937c947n%40fuchsia.dev.

[Yuan Zhi]

Thanks Daniel,

I noticed from the emu_log that the emulator might have crashed because the host doesn't support the number of cpu cores that the launcher requested. Specifically this line.

```

qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please configure -smp options properly.

```

I'll update the launcher to adjust the -smp flag to use the number of cores available on the host, and reply back to this email after it's done. In the meantime, you can try launching the emulator with:

```

fx emu -s $(nproc)

```

Yuan

[Yilong Li]

Thanks for getting in touch!

1) In order to better understand and reproduce the issue, could you please let us know more about your machines running the emulator (CPU models, host OS version, etc.)?

2) Could you please try "fx emu" (and "fx emu -N") on Linux as well? This uses a slightly different launcher script to set up the network and launch FEMU. I was wondering if the emulator could go a bit further (or print out more error messages)

One thing I've noticed in the log is that it seems it tries to use hyperthreading but it's not supported though I am not sure if this caused the emulator crash, but this should be fixed in the "fx emu" script. And you could try running the emulator using fewer cores by adding "-s <number_of_cores>" to the "fx emu" script.

3) Regarding the TUNTAP error, 

> "qemu-system-x86_64: could not configure /dev/net/tun (qemu): Operation not permitted"

This looks like the ownership of the tuntap device was not set up correctly... Could you please reset your tuntap device by running the following commands: 

$ sudo ip tuntap del dev qemu mode tap

$ sudo ip tuntap add dev qemu mode tap user liyl

$ sudo ip link set qemu up

Yilong

On Thu, Jun 3, 2021 at 9:39 AM Daniel Obieglo <d.ob...@gmail.com> wrote:

[Yilong Li]

On Thu, Jun 3, 2021 at 10:11 AM Yilong Li <li...@google.com> wrote:

Thanks for getting in touch!

1) In order to better understand and reproduce the issue, could you please let us know more about your machines running the emulator (CPU models, host OS version, etc.)?

2) Could you please try "fx emu" (and "fx emu -N") on Linux as well? This uses a slightly different launcher script to set up the network and launch FEMU. I was wondering if the emulator could go a bit further (or print out more error messages)

One thing I've noticed in the log is that it seems it tries to use hyperthreading but it's not supported though I am not sure if this caused the emulator crash, but this should be fixed in the "fx emu" script. And you could try running the emulator using fewer cores by adding "-s <number_of_cores>" to the "fx emu" script.

3) Regarding the TUNTAP error, 

> "qemu-system-x86_64: could not configure /dev/net/tun (qemu): Operation not permitted"

This looks like the ownership of the tuntap device was not set up correctly... Could you please reset your tuntap device by running the following commands: 

$ sudo ip tuntap del dev qemu mode tap

$ sudo ip tuntap add dev qemu mode tap user <YOUR_USERNAME>

Here the argument after `user` should be your username...

[Daniel Obieglo]

Thank you very much.

1.
$lshw
https://ghostbin.com/paste/BtxEw (Its in german but i hope it still helps)
$uname -a
Linux helveteLinux 4.15.0-143-generic #147-Ubuntu SMP Wed Apr 14 16:10:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 18.04.5 LTS
Release:    18.04
Codename:    bionic

3. I did that and now i can start it with the -N flag and get the same result (and crash). So the log file looks the same as the -N flag version.

2. (As Yuan Zhi suggested as well) This gets me further than vdl

$export LANG=C (Without this it wouldn't work)

$fx emu -s $(nproc) --software-gpu

But it seems like the emulator can't render anything and after typing "ls" in the console the system seems to stop working?

(Emulator on the right shows the console that was behind him while it was booting)

thanks again for the help :)

[Daniel Obieglo]

3. forgot to mention that TUNTAP seems to work now so i keep that in mind

Yilong Li schrieb am Donnerstag, 3. Juni 2021 um 19:14:57 UTC+2:

[Justin Mattson]

RE: the stall after `ls`, is your local Fuchsia package server running?

I think `ls` isn't typically included in the image the emulator uses, but instead comes from a package that is meant to be fetched from the development package server when `ls` is invoked.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/discuss/64ae8316-021d-4e4c-9376-1dee965282aen%40fuchsia.dev.

[Yuan Zhi]

Hi Daniel,

But crash related to `-smp` configuration should be fixed now. You have 2 options

Option 1:

 ```

fx vdl start -N --software-gpu

// Note: fx vdl starts a package server by default automatically, so no extra work is needed.

// From the emulator terminal created by `fx vdl ...`, type `ls`

```

Option 2:

```

fx emu -s $(nproc) -N --software-gpu

fx serve // Note: This will start a package server, which is required for the command `ls` to work, reference: https://fuchsia.dev/fuchsia-src/development/build/fx?hl=en#serve-a-build

// From the emulator terminal created by `fx emu ...`, type `ls`

```

Yuan

[Daniel Obieglo]

Hi Yuan,

thanks a lot.

Smp gets set correclty now but unfortunately femu still doesn't proceed any further than before. I can get a bit further when i use the fx emu call (even though the screen in femu stays black).

emu_crash.txt : https://ghostbin.com/paste/OUlz1

Maybe the parameter that get generated by the vdl and emu script are an indicator:
fx emu -s $(nproc) -N --software-gpu : https://ghostbin.com/paste/RmLdQ
fx vdl start -N --software-gpu : https://ghostbin.com/paste/ldaKL
(I changed the order of the parameter so that its easier to compare)

i'm still looking into this but maybe somebody can instantly point to an error i miss.

Thanks again.

[Justin Mattson]

How long have you waited before declaring the attempt a failure? Depending on the processing power of the underlying host I've seen initial boot take some time, even in a headless configuration.

When you say the emulator crashes, what is the crash symptom? Looking at the logs there aren't any crashes in the logs.

[Scott Graham]

Another thing you might try testing is to pass --headless to fx emu if you didn't already try that.

That doesn't start a graphics stack so might help narrow down what's crashing.

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@fuchsia.dev.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/discuss/b9c8ef3a-f9ed-40b2-8ec0-b8ede074fb0an%40fuchsia.dev.

[Daniel Obieglo]

Okay after some more testing and digging i'm kind of sure that the FEMU is not crashing...

For some reason the device_manager can boot the FEMU but can't get any info about the process after that.

After 2 minutes the device_launcher terminates himself and since the emulator is a child process it gets terminated as well.

I'm very sorry for the confusion i really thought that the emulator was crashing...

So the next question is, why is the device_launcher unable to get a hold of the child process?
I've seen that the device_launcher is written in Go but my knowledge about debugging Go is very minor so i am not sure what i can do to check why it can't find the process.

But the question with the Emulator (with a core/workstation product build running) showing just a black screen or some weird glitches from my desktop still remains. (Running with fx emu -s $(nproc) -N --software-gpu)

Thank you all for your help and sorry for the confusion.

[Yuan Zhi]

Thanks for the extra info, you are correct, the emulator did launch successfully, and the device_launcher by default checks that SSH connection works successfully before exiting. To skip checking SSH you can do 

```

fx vdl start --emu-only --software-gpu // This will launch the emulator to the foreground, and skip SSH check, similar to the experience for `fx emu`.

``` 

However, I think the issue you are experiencing is not related to the launcher. The emulator seem to be stuck at loading the fuchsia drivers. Just to confirm, did you run

```

fx set workstation.qemu-x64 --release // Reference: https://fuchsia.dev/fuchsia-src/get-started/set_up_femu?hl=en#building_fuchsia_for_femu

```

I'll work on finding a machine with an AMD processor in order to debug this issue on our side.

Thanks,

Yuan

[Daniel Obieglo]

Hello Yuan,

with the --emu-only flag the emu starts (with the mentioned visual bug).

i tested it with a core and workstation product as a debug and release version. All of them had the same issue in the EMU (every time i compiled fuchsia i did it with fx clean-build)

If there is any way i can help you, just let me know.

Thanks again.

Daniel