On 2022-10-26 at 17:15 EDT, Colin Percival <cperc...@freebsd.org> wrote:
On 10/26/22 13:48, Ed Maste wrote:On Mon, 24 Oct 2022 at 22:11, void <v...@f-m.fm> wrote:this started appearing in dmesg ns8250: UART FCR is broken ns8250: UART FCR is brokenThis message was added as part of Colin's work to support FreeBSD in the Firecracker VMM https://cgit.freebsd.org/src/commit/?id=c4b68e7e53bb352be3fa16995b99764c03097e66In this case it indicates that bhyve has the same bug/missing functionality as Firecracker -- it doesn't implement the FCR_XMT_RST or FCR_RCV_RST bits. You can safely ignore the message, and it will disappear once someone adds the required support to bhyve. We should probably also have the kernel emit the message only once. I've CC'd Colin for comment.Indeed, looking at usr.sbin/bhyve/uart_emul.c it looks like FCR_XMT_RST is not emulated. This is different from Firecracker, which doesn't emulate either anything from the FCR and where I was seeing the receive side not being flushed, but I'm glad my warning was able to flag a bug. :-)If "void" is comfortable with kernel hacking, it would be great to confirm >that the warning is indeed coming from the transmit side not being flushed; a printf("drain = %d\n", drain); would be sufficient.And yes, only emitting this warning once per device (or once per boot?) would probably be good.
I got the same message on real hardware, no virtualization involved as either host or guest. Is that expected at all?
Relevant lines from /var/run/dmesg.boot: ns8250: UART FCR is broken ns8250: UART FCR is broken uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (115200,n,8,1) ns8250: UART FCR is broken ns8250: UART FCR is broken uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ns8250: UART FCR is broken Thanks, Matteo
signature.asc
Description: PGP signature
