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 5CF5843DAD; 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 E4EAC4025D; Tue, 2 Apr 2024 00:26:57 +0200 (CEST) Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) by mails.dpdk.org (Postfix) with ESMTP id B98E740151 for ; Tue, 2 Apr 2024 00:26:55 +0200 (CEST) Received: by mail-oo1-f50.google.com with SMTP id 006d021491bc7-5a46abf093cso3148739eaf.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=JxKgs79gcJo+xTnH9uX1oWCmwkiB8VeQt9/40U3Qm19fFFnszXrzWQvBSab893oAI3 mUqYYn6FXCn7CJ/kZYm1ZAagNkzrsXfi40AHqc+6rcsgPb61z4BUDsumqgQbI2q3ub7D HbK+fl5cX3mrBoXFhATPs5wxff+XuB2X9vPdLsn7sW9gy1EOAgdVEE+bb2SnJ6/7k+PW bLHpNQ/a6kfUg/Z/iDilPyxMB/JFHidGSWUnMK6/X0hSZUUm+rp3ay0y/80V2kjemtZc YI15TINFRhpO0oychheXv7K0VfnHGiAxv7PFJWs8qSjwE0INyyIoQSxSSiDZBhSeA1Vt 49kQ== X-Forwarded-Encrypted: i=1; AJvYcCVtZgiJr/ZLKKpOXVDSlZ81DgXX/7JkoP0blkmyHuKcYCQK5YVnGJnWayM2HUUrvA0EFcZX1qxRQnyJbcY= X-Gm-Message-State: AOJu0YxCnLa6SMzgyS9I7kqtdZ617SH+cw4POTFWO7OnywkZbV834dLG lBzsJ6Wqa2eGdST9vg4M5Hhtzr8MJAvV98299E+3/5syVqq9zV0jxmi5IkmfEN6HesFyL1c4DEW /Kq3aX33XhR5pZF1LG1fls8eD2sgm7e4slBM2aQ== 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: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-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.