[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH v4 1/4] iotests: add script_initial

From: John Snow
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v4 1/4] iotests: add script_initialize
Date: Tue, 17 Sep 2019 18:29:17 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 9/16/19 10:56 AM, Vladimir Sementsov-Ogievskiy wrote:
> 12.09.2019 3:16, John Snow wrote:
>> Like script_main, but doesn't require a single point of entry.
>> Replace all existing initialization sections with this drop-in replacement.
>> This brings debug support to all existing script-style iotests.
>> Note: supported_oses=['linux'] was omitted, as it is a default argument.
> But after this patch all test which didn't check os start to check linux
> (as it's default).. So all tests which worked on other platforms will now
> be skipped on these other platforms?
> Finally do we support something except linux for iotests?
> for bash tests _supported_os also used only with "Linux" in 87 tests..
> May be we'd better drop both _supported_os and supported_oses alltogether,
> and don't care?
> Anyway, if we support only linux, any reason to skip almost all tests,
> if someone tries to run test on other platform? Let him run what he wants.

Currently, the following tests are python:

030 040 041 044 045 055 056 057 065 093 096 118 124 129 132 136 139 147
148 149 151 152 155 163 165 169 194 196 199 202 203 205 206 207 208 209
210 211 212 213 216 218 219 222 224 228 234 235 236 237 238 242 245 246
248 254 255 256 257 258 262 266

And as it stands, none of the script-style python tests we've selected
to run in `make check` fail on the FreeBSD platform.

So as an experiment, I lifted the restriction on python tests. I kept
running ./check until I found some invocation that they didn't skip.

Failures: 045 147 149 169 194 199 211

Not too bad...

045: +qemu.machine.QEMUMachineError: socket_scm_helper does not exist
149: Wants to use 'sudo', but our freebsd image doesn't have that.
194: +OSError: AF_UNIX path too long
-[{ "start": 0, "length": 3072, "depth": 0, "zero": false, "data": true,
"offset": 1024},
-{ "start": 3072, "length": 33551360, "depth": 0, "zero": true, "data":
true, "offset": 4096}]
+[{ "start": 0, "length": 31744, "depth": 0, "zero": false, "data":
true, "offset": 1024},
+{ "start": 31744, "length": 33522688, "depth": 0, "zero": true, "data":
true, "offset": 32768}]

149 can probably be fixed, and 194 and 211 I have fail in similar ways
on my own Linux machine, so that's probably not BSD's fault.

Interestingly, 169 and 199, bitmap migration related tests, cause a

+WARNING:qemu.machine:qemu received signal 6:
-mon chardev=mon,mode=control -display none -vga none -qtest
-machine accel=qtest -nodefaults -display none -machine accel=qtest
-incoming defer -drive

The common thread in 169 is the +migbitmap trait, which ... makes me a
little nervous, of course!

+WARNING:qemu.machine:qemu received signal 6:
-mon chardev=mon,mode=control -display none -vga none -qtest
-machine accel=qtest -nodefaults -display none -machine accel=qtest
-incoming exec: cat

Vladimir, I was able to provoke this error by editing
./tests/vm/Makefile.include and removing the --snapshot invocation, then
using `make vm-build-freebsd` and finally typing `make vm-ssh-freebsd`
to open up a shell.

Then the tricks are the usual ones; navigate to iotests directory,
./check -v -qcow2 169, etc. You'll need to create a build that allows
Python tests to run; do it before you run the snapshot-less build.

aaand lastly, running `make check` doesn't happen to call any of the
tests that appear broken on FreeBSD right now, so I'm just going to go
ahead and say we can open Pandora's box and make the default python test
behavior to run on any OS, and start re-blacklisting the edge-cases as
we find them.

As far as iotests go, there are a few new broken ones that surface, but
they won't gate Peter Maydell's build process because they don't get run
by 'make check'.

I think it's a safe move to make.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]