On 11/11/2021 13:42, Peter Maydell wrote: > [No suele recibir correo electrónico de peter.mayd...@linaro.org. Obtenga > información acerca de por qué esto es importante en > http://aka.ms/LearnAboutSenderIdentification.] > > On Thu, 11 Nov 2021 at 12:45, David Fernandez <david.fernan...@sen.com> wrote: >> On 11/11/2021 11:23, Peter Maydell wrote: >>> The problem is that the >>> udev machinery that creates nodes in /dev is being too slow >>> (or possibly is failing for some other reason, but given all the >>> other timeouts I'm guessing "everything is too slow") and so >>> the systemd unit that is waiting for /dev/ttyS0 to be created >>> times out. >> What is a bit puzzling is that this is supposed to all run in an >> emulated machine having its own simulated time, so yes things are slow, >> but everything should happen as expected, just slowly. > That's not the way QEMU's emulation of time works. In non-icount > mode, which is the default, wall clock time in the VM follows > wall clock time in the outside world. The guest just sees > itself as running on a rather slow CPU (and one with some odd > performance characteristics about what is slow compared to > what other things). I see... I wonder if a redhat system is likely to run better in such a situation, or if any other debian/ubuntu distro is known to run better when host performance might have an impact.
>> I guess I will compile from sources on Fedora and see if I get the same >> problem, as it is a bit hard to believe that the only way to run qemu is >> to have a high end machine dedicated just to run an install cd. > There's probably something odd going on, it's just not clear > what and trying to diagnose it is going to be really hard. > It is the case that if the host system is underpowered then > it's not going to be able to run complicated guests in > an acceptably performant way, but that ought to apply more > to situations like "I want to emulate a Windows guest on my > first-generation raspberry pi". > > What does 'file' say about the QEMU binary you're running > on the aarch64 system? (This is a check to eliminate an > almost-certainly-not-the-problem theory.) sen@vpm-devkit:~$ which qemu-system-x86_64 /usr/local/bin/qemu-system-x86_64 sen@vpm-devkit:~$ file /usr/local/bin/qemu-system-x86_64 /usr/local/bin/qemu-system-x86_64: ELF 64-bit LSB shared object, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=e05b26921bd35d96b6c749d23d5bfa5e6e43ab4c, stripped > -- PMM
