From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F06A343DAE; Tue, 2 Apr 2024 00:26:58 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E749F402E5; Tue, 2 Apr 2024 00:26:58 +0200 (CEST) Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) by mails.dpdk.org (Postfix) with ESMTP id BB8684025D for ; Tue, 2 Apr 2024 00:26:55 +0200 (CEST) Received: by mail-oo1-f49.google.com with SMTP id 006d021491bc7-5a46abf093cso3148740eaf.2 for ; Mon, 01 Apr 2024 15:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1712010415; x=1712615215; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kIK96E8fsNKFV5vJh8KCNmAfyf0Sn1xg2ysRgI8473w=; b=QRiqSLG4E5VEk3cwGkSdS2d1oHEVW8ncxX58LfOyDZw0PahHM8E5VYYmpXtpDuEWDK Owjt3byuTTpWVBLtp2A7cCOmDTxnSkUtKxwcsqMJwEmhxJFxV4ZUa81jiPg6oILdFsid BMkThPCNagOhI7KpkiAHYqYdwp5jQriO7vnyk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712010415; x=1712615215; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kIK96E8fsNKFV5vJh8KCNmAfyf0Sn1xg2ysRgI8473w=; b=sSLccFVmeyo6QVdipM8xMKkZ6OKIJo9cf9km1BHz2W3S8VeeBZX0EUYqB8Jt3Dv3iU UPR3jywZRh6fi4HUkEOReBHFXoxrkZ+rZtz9I6i58qnDXj5unse4J6T4lTYjPHaKi/yJ YHyg6+HUxt4MgAs/x7SivFK8M0n38ajzXofYInfaE1hKscZMV6rN/t7ArIDByFXWpN+v wpiKq0xR5pO6rQyweqzMwYtpqjsiXNDwYhqpIt0kH6eIxOydjx5orXJ4O4AZ8c50HV+L MuNG0OTY0TcTMjokq4WLNW2XfTsqRi7ZCchGWpOEVWJrNbHnLRjqP5jTSKPhiBC+McxN 1BDg== X-Forwarded-Encrypted: i=1; AJvYcCVld1YB9ymdYoQSbItiuUtcHJt8NWTq7TGebfFqBjvlPU89uRAwKORRQcD0UFllAogvDkQNTSPZ6NlQ4g== X-Gm-Message-State: AOJu0Yw1wf9V7beexZbxXKDXbq7sepUvi4b237iiB+4IfC4+aeFiD4fJ /EJkCf1XH4iXYi5a7W0MArKrCeFQlNQf65eYHxTLV08FbBnOpff4cs3QMeGOSv8inc+/gVKXPo5 laVC2cIShCDPzW9YCPx4jKCxDNjb2F4lq+R8REw== X-Google-Smtp-Source: AGHT+IFIVKm6IE3AQZV8UZQNFpTUG22vX4U4nQESEmoltUOzSRPQVi2JrMMJ6S1BEnhnPEivrdz14uvDhnfaXVCCKW0= X-Received: by 2002:a4a:ee86:0:b0:5a1:c13d:ac32 with SMTP id dk6-20020a4aee86000000b005a1c13dac32mr10632985oob.8.1712010414918; Mon, 01 Apr 2024 15:26:54 -0700 (PDT) MIME-Version: 1.0 References: <20240322163430.444bed0c@hermes.local> In-Reply-To: <20240322163430.444bed0c@hermes.local> From: Patrick Robb Date: Mon, 1 Apr 2024 18:26:44 -0400 Message-ID: Subject: Re: pcapng_autotest unit test false positive To: Stephen Hemminger Cc: David Marchand , dev , Aaron Conole , ci@dpdk.org, Cody Cheng Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org On Fri, Mar 22, 2024 at 7:34=E2=80=AFPM Stephen Hemminger wrote: > > > Could you build a simple test to see if TSC every runs backwards on > this machine. Or there could be yet another math error. > Or maybe container TSC is huge an wrapping around? > > The point of the test is to make sure that there wasn't wraparound errors= . Sorry about the wait on this one, but we did write that simple C program to check for whether TSC ever runs backwards on this system. It gets TSC using __rdtsc() because that's the same approach from the x86 rte_cycles.c. And it just loops for 10 seconds or so and compares n TSC to n-1 TSC, and if n's TSC is ever less than n-1's TSC it prints a message saying so. Otherwise at the end it prints that TSC is working normally. From running this the first time, it showed TSC as never running backwards. Another thing I can do is trigger a full set of testing (so that the system is under normal load) and then run the tsc checking program concurrently. Another idea - maybe multiple timestamps are gathered from different CPU registers during the same test, and they are misaligned for that reason. Maybe we can try reducing the cores for each unit test to 1 and checking whether the issue persists. Or there could be another math error as you say. And I should mention that now that I'm looking at this more closely I did see that unfortunately all these fail results are coming from a new debian 12 x86 environment which was added a few weeks ago, but mistakenly labeled as debian 11 x86. So, the fact that fails started can be explained by the fact that we added this new debian 12 container recently. So, I'll try a few more things and keep yall updated.