18.09.2019 1:29, John Snow wrote:
>
>
> 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
> 211:
> -[{ "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
> SIGSEGV in QEMU ...
>
>
> 169:
> +EEEE....EEEE........
> +WARNING:qemu.machine:qemu received signal 6:
> /usr/home/qemu/qemu-test.IfsR68/build/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64
> -chardev
> socket,id=mon,path=/usr/home/qemu/qemu-test.IfsR68/build/tests/qemu-iotests/scratch/tmprpc0idbx/qemub-26617-monitor.sock
> -mon chardev=mon,mode=control -display none -vga none -qtest
> unix:path=/usr/home/qemu/qemu-test.IfsR68/build/tests/qemu-iotests/scratch/qemub-26617-qtest.sock
> -machine accel=qtest -nodefaults -display none -machine accel=qtest
> -incoming defer -drive
> if=virtio,id=drive0,file=/usr/home/qemu/qemu-test.IfsR68/build/tests/qemu-iotests/scratch/disk_b,format=qcow2,cache=writeback
>
> The common thread in 169 is the +migbitmap trait, which ... makes me a
> little nervous, of course!
>
>
> 199:
> +WARNING:qemu.machine:qemu received signal 6:
> /usr/home/qemu/qemu-test.IfsR68/build/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64
> -chardev
> socket,id=mon,path=/usr/home/qemu/qemu-test.IfsR68/build/tests/qemu-iotests/scratch/tmpvzpyc9j6/qemub-30170-monitor.sock
> -mon chardev=mon,mode=control -display none -vga none -qtest
> unix:path=/usr/home/qemu/qemu-test.IfsR68/build/tests/qemu-iotests/scratch/qemub-30170-qtest.sock
> -machine accel=qtest -nodefaults -display none -machine accel=qtest
> -drive
> if=virtio,id=drive0,file=/usr/home/qemu/qemu-test.IfsR68/build/tests/qemu-iotests/scratch/disk_b,format=qcow2,cache=none
> -incoming exec: cat
> '/usr/home/qemu/qemu-test.IfsR68/build/tests/qemu-iotests/scratch/mig_fifo'
> +E
>
>
> 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.
>
>
Interesting, I'll try to reproduce.
>
>
> 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.
>
> --js
>
--
Best regards,
Vladimir
