Xen project Mailing List

Re: [linux-linus test] 170771: regressions - FAIL

To: osstest service owner <osstest-admin@xxxxxxxxxxxxxx>

Date: Mon, 30 May 2022 13:02:13 +0200

Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none

Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NH+F8tSCrSr3l0tFHnWetIpHjPscCt/xjHBzgzrq8vk=; b=SRt+T7pJ3965PVTZhU9tV3BafgTVtJszWi/ziit3OgKesYGbp71Be4pcsiGFU6AKQ5MlQ0pWmw66KKlLCRCAo87aL2kVvnxvbFRHpg7nmvHSVyQpCpJG7Dj92GCznKWmMwh7Yn7aIddzB5L0cHy3y+mKNNphVT/oy5SzJLJ2+D0swBszkyVeDIrTwUhOJHzhTu9ncwWvcJTSkLF8bTTQa53Pd9SW7qqg9axyiaGNy+GCMOBRqoSlCfuSUVF7V7AaRcedQH3xeTjRzXnpRRXRhIZNJaD1VikuCOH2MS7wWkI5oFJcIkoBfuUujPoUP2YGnqVjljGz2qmVUr1Vko6UBQ==

Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gMXBW0ED4NBWiKrFRDd9x9iEtuVVmpzzAwvJtSGwnY9g8E95/dLkg9RWwEwiWtwuLOB1GtfV8cg8+2r/R+t4OJyyZb+QKZbDDAPKj1Hd78vFy/zMBlSdrAbLyUpDd/fw/kSEfRaCAOfXOauYreVvzhpNzGTDBnxOokUgN2ncZz0YOUzDJ1AyeA2/4WETlBkvtrw7EQ+ynP8rg8qe2r4pArk3iR2LumVbLHaa5IoVp14xDnNXG/F3eVeEaLM32/r+14ri70shb+7IAvbG/fo2eONLjLgnXepMPg7OIQCxUg2EsvItYn0r94khaRlcIFkYE3Yoy6T/G3wik0Wni6XARw==

Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;

Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Juergen Gross <jgross@xxxxxxxx>

Delivery-date: Mon, 30 May 2022 11:02:26 +0000

List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.