On 30.05.2022 12:49, Jan Beulich wrote: > On 30.05.2022 11:03, osstest service owner wrote: >> flight 170771 linux-linus real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/170771/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. >> 170714 >> test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. >> 170714 >> test-amd64-amd64-libvirt-qcow2 8 xen-boot fail REGR. vs. >> 170714 >> test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. >> 170714 >> test-amd64-amd64-libvirt-raw 8 xen-boot fail REGR. vs. >> 170714 >> test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. >> 170714 >> test-amd64-amd64-xl-pvhv2-intel 14 guest-start fail REGR. vs. >> 170714 >> test-amd64-amd64-xl 14 guest-start fail REGR. vs. >> 170714 > > This > > vif vif-1-0 vif1.0: Asked for 0 slots but exceeds this limit > vif vif-1-0 vif1.0: fatal error; disabling device > > to me looks like a regression in netfront, considering that there > don't look to be any relevant netback changes. I have to admit > though that all three recent netfront commits don't have an > obvious connection to the slot count going wrong. Or wait - isn't > this a result of 6fac592cca60 ("xen: update ring.h") touching > only netfront, when netback also has a use of > RING_HAS_UNCONSUMED_REQUESTS() (in xenvif_tx_build_gops()) which > wants an actual count, not just a boolean?
One more general thing noticed in this context: It isn't very helpful to have both host and guest use the new kernel when wanting to isolate regressions like this one. It would imo be better two have three (host,guest) sets: (old,new), (new,old), and (new,new). I have no idea at all though how feasible it would be to arrange for such. Jan
