Hide Forgot
Description of problem: I'm using 2 virtconsole (virtio-serial sockets) for Host-Guest communication (Host: unix domain sockets, Guest: getty on /dev/hvc0, /dev/hvc1...). If the domain socket is written to between the qemu-kvm terminating and being restarting, the tty does not work inside the guest even though the virtio-ports are present. The output of QEMU's info qtree and the guest's debugfs does not match - /dev/vport0p0 and /dev/vport0p1 is still existing - qemu-kvm-command: /usr/libexec/qemu-kvm -monitor tcp:localhost:1234,server,nowait -daemonize -drive file=/home/kvm_stuff/images/Guest3.img,if=virtio,boot=on -device virtio-serial -chardev socket,path=/tmp/socket1,id=socket1,server,nowait -chardev socket,path=/tmp/socket2,id=socket2,server,nowait -device virtconsole,chardev=socket1,name=console.socket1 -device virtconsole,chardev=socket2,name=console.socket2 2>/home/tsa_stuff/guest3/error - $ cat /sys/kernel/debug/virtio-ports/vport0p1: name: console.socket1 guest_connected: 1 host_connected: 1 outvq_full: 0 is_console: yes console_vtermno: 0 - $ cat /sys/kernel/debug/virtio-ports/vport0p1 name: guest_connected: 0 host_connected: 1 outvq_full: 0 is_console: no console_vtermno: 0 - info qtree: bus: main-system-bus type System dev: i440FX-pcihost, id "" bus: pci.0 type PCI dev: virtio-blk-pci, id "" dev-prop: class = 0x100 dev-prop: drive = virtio0 dev-prop: logical_block_size = 512 dev-prop: physical_block_size = 512 dev-prop: min_io_size = 0 dev-prop: opt_io_size = 0 dev-prop: vectors = 2 dev-prop: indirect_desc = off dev-prop: scsi = on bus-prop: addr = 05.0 bus-prop: romfile = <null> bus-prop: rombar = 1 class SCSI controller, addr 00:05.0, pci id 1af4:1001 (sub 1af4:0002) bar 0: i/o at 0xc240 [0xc27f] bar 1: mem at 0xf2041000 [0xf2041fff] dev: virtio-serial-pci, id "" dev-prop: vectors = 32 dev-prop: class = 0x780 dev-prop: indirect_desc = off dev-prop: max_ports = 31 bus-prop: addr = 04.0 bus-prop: romfile = <null> bus-prop: rombar = 1 class Class 0780, addr 00:04.0, pci id 1af4:1003 (sub 1af4:0003) bar 0: i/o at 0xc200 [0xc21f] bar 1: mem at 0xf2040000 [0xf2040fff] bus: virtio-serial-bus.0 type virtio-serial-bus dev: virtconsole, id "" dev-prop: is_console = 1 dev-prop: nr = 1 dev-prop: chardev = socket2 dev-prop: name = "console.socket2" dev-prop-int: id: 1 dev-prop-int: guest_connected: 1 dev-prop-int: host_connected: 0 dev-prop-int: throttled: 0 dev: virtconsole, id "" dev-prop: is_console = 1 dev-prop: nr = 0 dev-prop: chardev = socket1 dev-prop: name = "console.socket1" dev-prop-int: id: 0 dev-prop-int: guest_connected: 1 dev-prop-int: host_connected: 0 dev-prop-int: throttled: 0 dev: piix3-ide, id "" bus-prop: addr = 01.1 bus-prop: romfile = <null> bus-prop: rombar = 1 class IDE controller, addr 00:01.1, pci id 8086:7010 (sub 1af4:1100) bar 4: i/o at 0xc000 [0xc00f] bus: ide.1 type IDE dev: ide-drive, id "" dev-prop: unit = 0 dev-prop: drive = ide1-cd0 dev-prop: logical_block_size = 512 dev-prop: physical_block_size = 512 dev-prop: min_io_size = 0 dev-prop: opt_io_size = 0 dev-prop: ver = <null> bus: ide.0 type IDE dev: rtl8139, id "" dev-prop: mac = 52:54:00:12:34:56 dev-prop: vlan = 0 dev-prop: netdev = <null> bus-prop: addr = 03.0 bus-prop: romfile = "pxe-rtl8139.bin" bus-prop: rombar = 1 class Ethernet controller, addr 00:03.0, pci id 10ec:8139 (sub 1af4:1100) bar 0: i/o at 0xc100 [0xc1ff] bar 1: mem at 0xf2020000 [0xf20200ff] bar 6: mem at 0xffffffffffffffff [0xfffe] dev: cirrus-vga, id "" bus-prop: addr = 02.0 bus-prop: romfile = "vgabios-cirrus.bin" bus-prop: rombar = 1 class VGA controller, addr 00:02.0, pci id 1013:00b8 (sub 1af4:1100) bar 0: mem at 0xf0000000 [0xf1ffffff] bar 1: mem at 0xf2000000 [0xf2000fff] bar 6: mem at 0xffffffffffffffff [0xfffe] dev: PIIX3, id "" bus-prop: addr = 01.0 bus-prop: romfile = <null> bus-prop: rombar = 1 class ISA bridge, addr 00:01.0, pci id 8086:7000 (sub 1af4:1100) bus: isa.0 type ISA dev: isa-fdc, id "" dev-prop: driveA = floppy0 dev-prop: driveB = <null> isa irq 6 dev: i8042, id "" isa irqs 1,12 dev: isa-parallel, id "" dev-prop: index = 0 dev-prop: iobase = 0x378 dev-prop: irq = 7 dev-prop: chardev = parallel0 isa irq 7 dev: isa-serial, id "" dev-prop: index = 0 dev-prop: iobase = 0x3f8 dev-prop: irq = 4 dev-prop: chardev = serial0 isa irq 4 dev: mc146818rtc, id "" dev-prop: base_year = 2000 isa irq 8 dev: i440FX, id "" bus-prop: addr = 00.0 bus-prop: romfile = <null> bus-prop: rombar = 1 class Host bridge, addr 00:00.0, pci id 8086:1237 (sub 1af4:1100) Version-Release number of selected component (if applicable): Host: qemu-kvm, Version: 0.12.1.2, Release: 2.113.el6_0.3 Guest: Fedora, Version: 14 Laughlin How reproducible: always Steps to Reproduce: 1. start guest with two sockets, like mentioned above 2. manually write on the sockets several times (e.g. echo "ls" | socat unix-connect:/tmp/socket2 stdio) or use a script, which will write on the two sockets periodly (e.g. 2-20 seconds) the whole time 3. kill the qemu-kvm process or got it to crash and start it again Actual results: second socket (hvc1) not working Expected results: Additional info:
I'm unable to reproduce this on a RHEL 6 (qemu-kvm 0.12.1.2 2.113.el6) host: $ /usr/libexec/qemu-kvm -monitor tcp:localhost:1234,server,nowait -daemonize -cdrom Fedora-14-i686-Live-Desktop.iso -device virtio-serial -chardev socket,path=/tmp/socket1,id=socket1,server,nowait -chardev socket,path=/tmp/socket2,id=socket2,server,nowait -device virtconsole,chardev=socket1,name=console.socket1 -device virtconsole,chardev=socket2,name=console.socket2 -vnc :0 -m 1024 $ echo "ls" | socat unix-connect:/tmp/socket2 stdio [everything working, now let's kill qemu-kvm] $ pkill -9 qemu-kvm [keep poking the UNIX domain socket while qemu-kvm is down] $ echo "ls" | socat unix-connect:/tmp/socket2 stdio 2011/01/23 07:05:42 socat[15619] E connect(3, AF=1 "/tmp/socket2", 14): Connection refused [this makes sense because no process is listening on that socket. Now restart qemu-kvm] $ /usr/libexec/qemu-kvm -monitor tcp:localhost:1234,server,nowait -daemonize -cdrom Fedora-14-i686-Live-Desktop.iso -device virtio-serial -chardev socket,path=/tmp/socket1,id=socket1,server,nowait -chardev socket,path=/tmp/socket2,id=socket2,server,nowait -device virtconsole,chardev=socket1,name=console.socket1 -device virtconsole,chardev=socket2,name=console.socket2 -vnc :0 -m 1024 [keep hammering the socket during boot in case this can trigger the bug] $ echo "ls" | socat unix-connect:/tmp/socket2 stdio But once booted up I find /sys/kernel/debug/virtio-ports prints out expected info and /dev/hvc0 and /dev/hvc1 both work. Marcel: Can you spot a difference between how you trigger the bug and how I failed to reproduce it?
> Marcel: Can you spot a difference between how you trigger the bug and how I > failed to reproduce it? So you wrote to the socket only once time? Maybe its because in my case I'm or my monitor script is writing on the socket several times during the kill, offline and startup time, this means writing on the socket the whole time in iterating time intervals.
Sorry, I overlooked you did wrote on the socket several times. I think the only difference to the way I do it is: I'm writing to both sockets the whole time, maybe that's the problem?
Could you try the same on non-console ports (-device virtserialport)?
Can you please re-test with latest guest kernel and qemu-kvm packages (corresponding to RHEL6.1 or later)? Please also test virtserialport devices instead of virtconsole to try to localise the problem.
Hi Amit, Marcel was a placement student and is back at university now. I wasn't able to reproduce the problem when I tried in my own environment back in January. Perhaps this bug should be archived/closed for now.
(In reply to comment #8) > Hi Amit, > Marcel was a placement student and is back at university now. I wasn't able to > reproduce the problem when I tried in my own environment back in January. > Perhaps this bug should be archived/closed for now. Thanks! Closing this for now.