diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1599 | 24 | ||||
| -rw-r--r-- | results/classifier/108/other/1599214 | 155 | ||||
| -rw-r--r-- | results/classifier/108/other/1599539 | 57 |
3 files changed, 236 insertions, 0 deletions
diff --git a/results/classifier/108/other/1599 b/results/classifier/108/other/1599 new file mode 100644 index 000000000..9140740d2 --- /dev/null +++ b/results/classifier/108/other/1599 @@ -0,0 +1,24 @@ +graphic: 0.776 +device: 0.767 +semantic: 0.502 +network: 0.457 +files: 0.451 +boot: 0.424 +socket: 0.421 +vnc: 0.344 +debug: 0.244 +permissions: 0.242 +PID: 0.235 +KVM: 0.230 +other: 0.128 +performance: 0.127 + +7.2.1 - Windows installer +Description of problem: +Please release windows installer for new stable version 7.2.1 in + +https://www.qemu.org/download/ +Steps to reproduce: + +Additional information: + diff --git a/results/classifier/108/other/1599214 b/results/classifier/108/other/1599214 new file mode 100644 index 000000000..b628d76f1 --- /dev/null +++ b/results/classifier/108/other/1599214 @@ -0,0 +1,155 @@ +permissions: 0.903 +graphic: 0.896 +debug: 0.893 +semantic: 0.883 +vnc: 0.868 +performance: 0.859 +network: 0.856 +boot: 0.854 +device: 0.849 +socket: 0.846 +PID: 0.841 +other: 0.841 +KVM: 0.811 +files: 0.802 + +virtlogd: qemu 2.6.0 doesn't log boot message + +This report is related to the OpenStack Nova bug [1]. + +OpenStack tries to utilize the "virtlogd" feature of qemu [2]. + +steps to reproduce: +1) launch a quest with qemu 2.6.0 which uses virtlogd for the stdout/stderr of its char device +2) check the contents of the backing file of that char device + +expected result: +The boot messages of the guest are logged in this file + +actual result: +The file is empty + +notes: +When I'm connected to that char device and reboot the guest, I see the boot messages in the terminal and also in the backing log file. + +References: +[1] https://bugs.launchpad.net/nova/+bug/1597789 +[2] http://git.qemu.org/?p=qemu.git;a=blobdiff;f=qemu-char.c;h=11caa5648de99c9e0ee158f280fbc02ab05915d3;hp=d7be1851e5e9d268aa924a05958da292b048839c;hb=d0d7708ba29cbcc343364a46bff981e0ff88366f;hpb=f1c17521e79df863a5771d96974fab0d07f02be0 + +Can you provide the full QEMU command line arguments you're using to reproduce this problem. I tested a guest with the following console config: + + <serial type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/f25-console.sock'/> + <log file='/var/lib/libvirt/qemu/f25-console.log'/> + <target port='1'/> + <alias name='serial1'/> + </serial> + +and confirmed that the log file gets written, even when no client is connected to the UNIX domain socket. + +qemu log: +http://paste.openstack.org/show/542559/ + +Ok, relevant part of command line is + +-add-fd set=2,fd=33 +-chardev socket,id=charconsole0,host=9.152.151.129,port=10000,server,nowait,logfile=/dev/fdset/2,logappend=on +-device virtconsole,chardev=charconsole0,id=console0 +-chardev pty,id=charconsole1 +-device sclpconsole,chardev=charconsole1,id=console1 + + +Which shows a TCP based serial console with log file + +> Which shows a TCP based serial console with log file + +Yes, that's true. It's also on the s390x architecture. + +The char device in the libvirt domain XML is this: + + <console type="tcp"> + <source host="9.152.151.133" mode="bind" service="10000"/> + <log file="/opt/stack/data/nova/instances/40fd2986-69f3-4db5-a17f-fd9ef1c69350/console.log" append="off"/> + </console> + +Full domain XML: http://paste.openstack.org/show/542597/ + +Ok, so the problem is a difference in behaviour for virtio-console vs serial ports. + +For plain x86 serial ports, if there's no client connected to the backend, any data is just discarded. + +For virtio-console, if there's no client connected to the backend, it'll refuse to send data, hence we never get to log it either. + +What i'm not sure on is whether this is supposed to work this way. The virtio-console device actually provides two separate services - a paravirt serial port and a paravirt interactive console. The paravirt serial port mode, certainly requires this behaviour, but I'm not convinced the console mode should do this. + +Patch at https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg06708.html + +Fix in 2.7.0 release thanks to + +commit bce6261eb2d879625126485d4ddd28cacb93152e +Author: Daniel P. Berrange <email address hidden> +Date: Wed Aug 3 17:22:36 2016 +0100 + + virtio-console: set frontend open permanently for console devs + + The virtio-console.c file handles both serial consoles + and interactive consoles, since they're backed by the + same device model. + + Since serial devices are expected to be reliable and + need to notify the guest when the backend is opened + or closed, the virtio-console.c file wires up support + for chardev events. This affects both serial consoles + and interactive consoles, using a network connection + based chardev backend such as 'socket', but not when + using a PTY based backend or plain 'file' backends. + + When the host side is not connected the handle_output() + method in virtio-serial-bus.c will drop any data sent + by the guest, before it even reaches the virtio-console.c + code. This means that if the chardev has a logfile + configured, the data will never get logged. + + Consider for example, configuring a x86_64 guest with a + plain UART serial port + + -chardev socket,id=charserial1,host=127.0.0.1,port=9001,server,nowait,logfile=console1.log,logappend=on + -device isa-serial,chardev=charserial1,id=serial1 + + vs a s390 guest which has to use the virtio-console port + + -chardev socket,id=charconsole1,host=127.0.0.1,port=9000,server,nowait,logfile=console2.log,logappend=on + -device virtconsole,chardev=charconsole1,id=console1 + + The isa-serial one gets data written to the log regardless + of whether a client is connected, while the virtioconsole + one only gets data written to the log when a client is + connected. + + There is no need for virtio-serial-bus.c to aggressively + drop the data for console devices, as the chardev code is + prefectly capable of discarding the data itself. + + So this patch changes virtconsole devices so that they + are always marked as having the host side open. This + ensures that the guest OS will always send any data it + has (Linux virtio-console hvc driver actually ignores + the host open state and sends data regardless, but we + should not rely on that), and also prevents the + virtio-serial-bus code prematurely discarding data. + + The behaviour of virtserialport devices is *not* changed, + only virtconsole, because for the former, it is important + that the guest OSknow exactly when the host side is opened + / closed so it can do any protocol re-negotiation that may + be required. + + Fixes bug: https://bugs.launchpad.net/qemu/+bug/1599214 + + Acked-by: Cornelia Huck <email address hidden> + Signed-off-by: Daniel P. Berrange <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Amit Shah <email address hidden> + + + diff --git a/results/classifier/108/other/1599539 b/results/classifier/108/other/1599539 new file mode 100644 index 000000000..2e9a16f0f --- /dev/null +++ b/results/classifier/108/other/1599539 @@ -0,0 +1,57 @@ +other: 0.896 +debug: 0.879 +semantic: 0.879 +device: 0.803 +performance: 0.774 +permissions: 0.742 +socket: 0.727 +graphic: 0.717 +vnc: 0.716 +PID: 0.690 +files: 0.670 +network: 0.649 +boot: 0.580 +KVM: 0.528 + +2.6.0: vvfat driver generates bad FAT entries + +The vvfat driver sometimes generates entries about which file system checking utilities generate complaints. + +For example, dosfsck will complain that the volume label entry has non-zero size. ScanDisk from Windows 9x complains about invalid dot (".") and dot-dot ("..") entries in directories and also about invalid long file name entries. MS-DOS ScanDisk also often manages to find "lost clusters" on the drive. + +Tangentially: qemu-img convert fat:test test.img doesn't seem to work -- it generates an 504MiB of zero bytes and hangs. qemu-img map fat:test generates an assertion failure. Having qemu-img working might have helped with debugging the above issue. + + + +Please send your patch to the qemu-devel (and qemu-block) mailing list. See http://qemu-project.org/Contribute/SubmitAPatch for details on how to submit a patch. Thanks! + +I noticed another bug in vvfat disk image generation. Applying the patch I attached earlier made testing easier. I'm less sure what the actual problem is. + +Steps to reproduce (you'll need to have cpio, md5sum and GNU GRUB 2.x installed): +0. Apply the patch and build qemu-img. +1. Create a directory, cd into it and unpack the attached cpio file. +2. Run: qemu-img convert fat:. ../xxx.img +3. Run: for fname in $(grub-fstest ../xxx.img ls '(loop0,msdos1)/'); do grub-fstest ../xxx.img cat "(loop0,msdos1)/$fname" | md5sum | sed -e "s,-,$fname,"; done | md5sum -c +4. Observe how almost all checksum tests fail. + +Alternatively, the image can be tested inside a virtual machine. You probably get the idea. + +(File names and data have been changed for the sake of anonymity and better compressibility) + +The original issue turned out to be trivial. The dot and dot-dot entries need to be the two very first entries in a non-root directory table; however, readdir() does not guarantee that "." and ".." will be the first items returned. When I patched read_directory() to generate "." and ".." entries first (and also ensured that volume label entry is generated with zero size), ScanDisk stopped complaining. + +The latter issue is also easy. The FAT16 file system cannot hold more than 512 entries in its root directory table. The vvfat driver does not recognise this limit and tries to squeeze more entries into the table than is normally possible. FAT-reading software doesn't seem to appreciate it. The driver should emit a warning and refuse to generate a FAT image altogether. (I have actually thought of a way to do it anyway, but it will not work everywhere.) + +Thanks for looking into this, Felix. If you think that your fix to read_directory() is ready for inclusion, please do send the patch to both the qemu-devel and qemu-block mailing lists as Thomas suggested. As each patch should address a single point, this can be done even while the second problem isn't fully solved yet. + +I agree that erroring out when trying to open a vvfat image on a directory with too many entries is probably the best option. Instead of thinking of ways to do it anyway, I'd rather suggest to look into fixing/fully implementing FAT32 support. There are a few scary comments in the code, so I suppose it might not yet be as stable as you'd want it to be, but it shouldn't have the root directory limit anyway. + +I believe commits f82d92bb028a1d674bab4ccc7e6cde6c04956230 and 6817efea3a0d1bf87be815970cdb014c5a64b628 have fixed this particular bug; although I've since noticed the vvfat driver remains quite fragile, especially FAT32 and writing support. I've got some patches for it of my own, which I might submit someday (they aren't quite ready yet). + +Also, after some testing, it turns one can simply grow the fixed-size root directory table above 512 entries, and it doesn't seem to actually cause any problems after all; although I haven't tested any extreme cases or obscure implementations. Shrinking it (entry-wise) should be fine in any case: 1440 KiB floppy disks typically allow 224 root directory entries, which is 14 clusters = 14 sectors. + + +Another patch has apparently been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=f80256b7eebfbe20683 +I assume we can close this ticket now as fixed? + |