diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/603 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/60339453 | 71 | ||||
| -rw-r--r-- | results/classifier/108/other/603872 | 65 | ||||
| -rw-r--r-- | results/classifier/108/other/603878 | 42 |
4 files changed, 194 insertions, 0 deletions
diff --git a/results/classifier/108/other/603 b/results/classifier/108/other/603 new file mode 100644 index 000000000..8d2679d62 --- /dev/null +++ b/results/classifier/108/other/603 @@ -0,0 +1,16 @@ +device: 0.758 +performance: 0.572 +other: 0.509 +graphic: 0.477 +network: 0.461 +permissions: 0.432 +debug: 0.331 +files: 0.321 +semantic: 0.303 +boot: 0.274 +PID: 0.228 +vnc: 0.114 +socket: 0.084 +KVM: 0.012 + +Unable to use mps2-an386 machine with qemu-6.0.0 version code diff --git a/results/classifier/108/other/60339453 b/results/classifier/108/other/60339453 new file mode 100644 index 000000000..b7db4b510 --- /dev/null +++ b/results/classifier/108/other/60339453 @@ -0,0 +1,71 @@ +boot: 0.782 +other: 0.776 +performance: 0.764 +permissions: 0.750 +device: 0.706 +PID: 0.685 +network: 0.682 +vnc: 0.680 +debug: 0.672 +graphic: 0.671 +KVM: 0.669 +semantic: 0.662 +files: 0.623 +socket: 0.607 + +[BUG] scsi: vmw_pvscsi: Boot hangs during scsi under qemu, post commit e662502b3a78 + +Hi, + +Commit e662502b3a78 ("scsi: vmw_pvscsi: Set correct residual data length"), +and its backports to stable trees, makes kernel hang during boot, when +ran as a VM under qemu with following parameters: + + -drive file=$DISKFILE,if=none,id=sda + -device pvscsi + -device scsi-hd,bus=scsi.0,drive=sda + +Diving deeper, commit e662502b3a78 + + @@ -585,7 +585,13 @@ static void pvscsi_complete_request(struct +pvscsi_adapter *adapter, + case BTSTAT_SUCCESS: + + /* + + * Commands like INQUIRY may transfer less data than + + * requested by the initiator via bufflen. Set residual + + * count to make upper layer aware of the actual amount + + * of data returned. + + */ + + scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen); + +assumes 'e->dataLen' is properly armed with actual num of bytes +transferred; alas qemu's hw/scsi/vmw_pvscsi.c never arms the 'dataLen' +field of the completion descriptor (kept zero). + +As a result, the residual count is set as the *entire* 'scsi_bufflen' of a +good transfer, which makes upper scsi layers repeatedly ignore this +valid transfer. + +Not properly arming 'dataLen' seems as an oversight in qemu, which needs +to be fixed. + +However, since kernels with commit e662502b3a78 (and backports) now fail +to boot under qemu's "-device pvscsi", a suggested workaround is to set +the residual count *only* if 'e->dataLen' is armed, e.g: + + @@ -588,7 +588,8 @@ static void pvscsi_complete_request(struct pvscsi_adapter +*adapter, + * count to make upper layer aware of the actual +amount + * of data returned. + */ + - scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen); + + if (e->dataLen) + + scsi_set_resid(cmd, scsi_bufflen(cmd) - +e->dataLen); + +in order to make kernels boot on old qemu binaries. + +Best, +Shmulik + diff --git a/results/classifier/108/other/603872 b/results/classifier/108/other/603872 new file mode 100644 index 000000000..8b9b1b2bb --- /dev/null +++ b/results/classifier/108/other/603872 @@ -0,0 +1,65 @@ +performance: 0.720 +graphic: 0.657 +device: 0.632 +PID: 0.576 +other: 0.531 +vnc: 0.521 +files: 0.477 +semantic: 0.467 +network: 0.452 +KVM: 0.418 +debug: 0.371 +permissions: 0.328 +socket: 0.326 +boot: 0.237 + +[Feature request] qemu-img image conversion does not show percentage + +It will be nice if qemu-img will be able to show percentage of completition and average speed of conversion and compress ratio (if converting to compressed qcow or qcow2) + +qemu-img convert -p does show a percentage completion (but not avg speed or compression ratio) so this is at least partially done. + +Incomplete patch. + +Usecase: `qemu-img convert` with -p now shows the write speed. + +1. I'm calculating the speed using the time taken to run the for(;;) +at qemu-img.c:1477. I figured that every time this loop runs, n1 +sectors are converted, and so I calculate the write_speed +accordingly. Is this correct? + +2. I have changed qemu-progress.c:qemu_progress_print() to take in a +speed parameter, thinking that it would be the best option. Should I +do it some other way instead (maybe write another function to print +just speed)? + +On Mon, Nov 18, 2013 at 03:55:45PM -0000, Varad wrote: +> Incomplete patch. +> +> Usecase: `qemu-img convert` with -p now shows the write speed. +> +> 1. I'm calculating the speed using the time taken to run the for(;;) +> at qemu-img.c:1477. I figured that every time this loop runs, n1 +> sectors are converted, and so I calculate the write_speed +> accordingly. Is this correct? +> +> 2. I have changed qemu-progress.c:qemu_progress_print() to take in a +> speed parameter, thinking that it would be the best option. Should I +> do it some other way instead (maybe write another function to print +> just speed)? +> +> ** Patch added: "[PATCH/RFC]" +> https://bugs.launchpad.net/qemu/+bug/603872/+attachment/3911803/+files/0001-qemu-img-show-image-conversion-speed.patch + +Patches attached on the bug tracker are not reviewed, they should be +sent to the qemu-devel mailing list instead. + +If you want to link to a submitted patch from launchpad, please post a +mailing list archive link. For example: +http://article.gmane.org/gmane.comp.emulators.qemu/242109 + + +Progress printing had been added here: +https://gitlab.com/qemu-project/qemu/-/commit/6b837bc4a4d +So I think it should be fine to close this ticket now. + diff --git a/results/classifier/108/other/603878 b/results/classifier/108/other/603878 new file mode 100644 index 000000000..a4a007e7e --- /dev/null +++ b/results/classifier/108/other/603878 @@ -0,0 +1,42 @@ +graphic: 0.742 +semantic: 0.676 +device: 0.548 +performance: 0.509 +vnc: 0.402 +other: 0.398 +network: 0.374 +files: 0.364 +permissions: 0.332 +socket: 0.329 +PID: 0.323 +debug: 0.217 +KVM: 0.137 +boot: 0.131 + +[Feature request] qemu-img option about recompressing + +Suppose I have a fresh compressed qcow2 image. After some time the data were recorded without compression. I decide to make "QEMU-IMG convert" for that image to reduce its size. + +I want a new option, which selects between the two algorithms overdriven images: +1. extract all / compress again when converting images (in the current implementation) +2. compress only uncompressed blocks and just copy the compressed blocks without re-compression. + +This option is only needed when converting compressed image to compressed and the compression algorithm is the same. + +(text was translated by translate.google.com) +overdriven=re-compressing +recorded=written + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/81 + + |