From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D8EBC388F9 for ; Mon, 23 Nov 2020 13:51:47 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 028EC206F1 for ; Mon, 23 Nov 2020 13:51:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=crudebyte.com header.i=@crudebyte.com header.b="pgr9eTBV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 028EC206F1 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=crudebyte.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:33790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khCFs-0003Ec-Ss for qemu-devel@archiver.kernel.org; Mon, 23 Nov 2020 08:51:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58894) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khCCj-0001uG-SO for qemu-devel@nongnu.org; Mon, 23 Nov 2020 08:48:31 -0500 Received: from lizzy.crudebyte.com ([91.194.90.13]:43559) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khCCe-0006nO-Gr for qemu-devel@nongnu.org; Mon, 23 Nov 2020 08:48:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crudebyte.com; s=lizzy; h=Content-Type:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Content-ID:Content-Description; bh=Mc4gmjHRnVpbnUApP1x3UQuUXcjdQW4BXNayeLJrkUo=; b=pgr9eTBVVdrNLmGM2nhD4HxJxH qnbqamvHjBWbjoRf/bE7whCFzAqND+BLVNAbVaH8CdQyyQC16ditUJDQEQlFgOLxI9FyhsagIyRZT C1XdoCQTa4AnvJhuAfbbRfGq0JH+RaJ6/82FL8rK3fLFsRWOxLTbKmPACFznzEjav48qKhNoF/IqX 4MELpG1KM/JAwGeBCi0DoT3qsxpDpv19TahBAogYWavUSBpaDNfCx2pHNXptS4fLvC3V9RvuwvwFn o3ApcT2w3XHvx0nMw+ShT+NCb4oqwsWiDqUMRsT+jhqU6lf0EjtVa1C2p2GcRTwvrfRvhi6uNBZ0d BWryh4Zw==; From: Christian Schoenebeck To: qemu-devel@nongnu.org Cc: Greg Kurz , Cole Robinson Subject: Re: virtio-9p-test.c:300:v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73) Date: Mon, 23 Nov 2020 14:48:15 +0100 Message-ID: <7836238.thhSn8XZEd@silver> In-Reply-To: <20201123141734.0c03f21a@bahia.lan> References: <20201123141734.0c03f21a@bahia.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: pass client-ip=91.194.90.13; envelope-from=qemu_oss@crudebyte.com; helo=lizzy.crudebyte.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Montag, 23. November 2020 14:17:34 CET Greg Kurz wrote: > Fixed maintainer's address: s/oss@crudebyte.com/qemu_oss@crudebyte.com > > On Sat, 21 Nov 2020 17:03:14 -0500 > > Cole Robinson wrote: > > Hi, I'm consistently seeing this assertion running the qemu-5.2.0 test > > suite. rc0, rc1, rc2 have been consistently affected, it reproduces > > consistently in parts of Fedora's build system. Here's an example build > > log for rc2 x86 against Fedora 32 > > > > https://download.copr.fedorainfracloud.org/results/@kubevirt/qemu-5.2.0-0. > > 6.rc2/fedora-32-x86_64/01781514-qemu/builder-live.log.gz > > > > The full test error: > > > > ... > > PASS 26 qtest-arm/qos-test > > /arm/virt/virtio-mmio/virtio-bus/virtio-9p-device/virtio-9p/virtio-9p-test > > s/synth/readdir/split_128 PASS 27 qtest-arm/qos-test > > /arm/virt/virtio-mmio/virtio-bus/virtio-9p-device/virtio-9p/virtio-9p-test > > s/local/config > Ok so the next test is supposed to be: > > /arm/virt/virtio-mmio/virtio-bus/virtio-9p-device/virtio-9p/virtio-9p-tests/ > local/create_dir > > This was added recently. This configures the virtio-9p device in QEMU > to serve a real test directory from the host. This test directory is > created under the current directory of the test process. The purpose > of the test is then to ask the 9p server to create a directory within > the test directory. > > > Received response 7 (RLERROR) instead of 73 (RMKDIR) > > ERROR qtest-arm/qos-test - Bail out! > > ERROR:../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion > > failed (hdr.id == id): (7 == 73) > > Rlerror has errno 95 (Operation not supported) > > So this basically means that QEMU got ENOTSUP/EOPNOTSUPP when calling > mkdir() into the test directory... not sure what could cause that. I'd > need more details on the filesystem setup for the build. > > Anyway, we already experienced some breakage in upstream CI because of > the same family of tests that do real access to the host filesystem. > Since they're being introduced in QEMU 5.2, I'll try to see if I can > disable them to be run by default for RC3. > > Cheers, > > -- > Greg > > > ** > > ERROR:../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion > > failed (hdr.id == id): (7 == 73) > > make: *** [Makefile.mtest:1257: run-test-155] Error 1 > > error: Bad exit status from /var/tmp/rpm-tmp.EG4Dav (%check) > > > > > > Thanks, > > Cole Yeah, looks like the mkdir() call which is supposed to create the 9p test directory, is failing there for some reason. The question is how to find that out (effectively) without having access to an affected system. It's now too late for 5.2, but I think for 6.0 it would make sense introducing a dedicated 9p option loglevel=..., so we can tell people to enable this to capture the precise source location where an error ocurred. That would mean spreading a huge bunch of macros all over the 9p code base, but it would definitely help a lot understanding the root cause of reported issues in an efficient way. Best regards, Christian Schoenebeck