RX and TX interrupt bits were reversed, resulting in an endless sequence
of serial interupts in the emulated system and the following repeated
error message when booting Linux.
serial8250: too much work for irq61
This results in a boot failure most of the time.
Qemu command line used to reproduce the problem:
qemu-system-aarch64 -M raspi3 -m 1024 \
-kernel arch/arm64/boot/Image \
--append "rdinit=/sbin/init console=ttyS1,115200"
-initrd rootfs.cpio \
-dtb arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb \
-nographic -monitor null -serial null -serial stdio
This is with arm64:defconfig. The root file system was generated using
buildroot.
NB that this error likely arises from an erratum in the
BCM2835 datasheet where the TX and RX bits were swapped
in the AU_MU_IER_REG description (but correct for IIR):
https://elinux.org/BCM2835_datasheet_errata#p12
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Message-id: 1529355846-25102-1-git-send-email-linux@roeck-us.net
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: added NB about datasheet]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Store the property in a CharBackend instead of CharDriverState*. This
also replace systematically chr by chr.chr to access the
CharDriverState*. The following patches will replace it with calls to
qemu_chr_fe CharBackend functions.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-12-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The qemu_chr_fe_write method will return -1 on EAGAIN if the
chardev backend write would block. Almost no callers of the
qemu_chr_fe_write() method check the return value, instead
blindly assuming data was successfully sent. In most cases
this will lead to silent data loss on interactive consoles,
but in some cases (eg RNG EGD) it'll just cause corruption
of the protocol being spoken.
We unfortunately can't fix the virtio-console code, due to
a bug in the Linux guest drivers, which would cause the
entire Linux kernel to hang if we delay processing of the
incoming data in any way. Fixing this requires first fixing
the guest driver to not hold spinlocks while writing to the
hvc device backend.
Fixes bug: https://bugs.launchpad.net/qemu/+bug/1586756
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <1473170165-540-4-git-send-email-berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
