Hi folks! We are doing some automatic experiments using FreeBSD running in a virtual machine. To control the experiment from the outside, we use serial ports to communicate with an userspace program. The communication via serial does work with QEMU. However, it does not work with BOCHS which is our desired emulator. Even simple operations like 'echo FOO | tee /dev/ttyu1' or 'cat /dev/ttyu1' do not work. Both commands block 'forever'. It does not matter whether we use ttyu0 (file backend) or ttyu1 (tcp socket). I put some debug output in sys/dev/uart/uart_dev_ns8250.c. The output suggests that the driver more or less reads and writes to the serial ports. At least it does something... Do you have any hints how we can further analyze this problem? Did anyone came across a similar problem? Thank you! Regards, Alex -- Technische Universit?t Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20180813/1bde4da9/attachment.sig>
13.08.2018 20:52, Alexander Lochmann wrote:> Hi folks! > > We are doing some automatic experiments using FreeBSD running in a > virtual machine. > To control the experiment from the outside, we use serial ports to > communicate with an userspace program. > The communication via serial does work with QEMU. However, it does not > work with BOCHS which is our desired emulator. > Even simple operations like 'echo FOO | tee /dev/ttyu1' or 'cat > /dev/ttyu1' do not work. Both commands block 'forever'. > It does not matter whether we use ttyu0 (file backend) or ttyu1 (tcp > socket). > I put some debug output in sys/dev/uart/uart_dev_ns8250.c. The output > suggests that the driver more or less reads and writes to the serial > ports. At least it does something... > > Do you have any hints how we can further analyze this problem? > Did anyone came across a similar problem?This could be modem control line "Carrier Detection" (CD) or flow control problem: emulators can have distinct default settings for serial ports. You should not rely on defaults and make sure you disable modem control/CD either explicitly (using stty(1) etc.) or implicitly by switching to /dev/cuau0 instead of /dev/ttyu0. Flow control settings should match too, for both sides of virtual port.