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 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0BAE2C433FE for ; Mon, 10 Oct 2022 17:40:48 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 918E084ECB; Mon, 10 Oct 2022 19:40:46 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="GpIGHKGA"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8ABE384EE5; Mon, 10 Oct 2022 19:40:45 +0200 (CEST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 60C6E84E35 for ; Mon, 10 Oct 2022 19:40:42 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf2f.google.com with SMTP id f14so7542312qvo.3 for ; Mon, 10 Oct 2022 10:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=NpsOSxcpVwoLj2E0xmpSTTFn4hvko2wxjvyczdzLJP4=; b=GpIGHKGADjxhWOC79dds+XEJf2oeJEk/t4X/6kkvwD0YMbGSDbYufnlAlxFqxk6W+T jGyL4jget9H2li6Lw8I/Awki+3GpnwymL6npWPk9DfdeL2r+pSht5E1LTJtDJu6mWvS2 UcrdedmK9DhNyUk9NSVdZvYltjc41UFWnuEao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NpsOSxcpVwoLj2E0xmpSTTFn4hvko2wxjvyczdzLJP4=; b=7PwYsILKYQ+4EtgY3lEBAeDkTk/011hJGglnCujrTntZcby1N+JBkZ8ojIqhMvSm7l uuGePe51NtpSbCSY9PmqVAHiZQeL9qNOMs5kjYNMC+jTcdmz1bdvrDLEDgRVUs8MsP3S 8nfY3WC05Wmu+XcA9i47pc3c1gf0uYrex9LeNk6m1mxFkkAfPSS5LeMTXOwkIRS1K5fW QKMpfjhVFnxN3d4A93rX9Ts0jIyCq3KYcJtFX2smc4RIkTjWJRR2dCWShjdhVfmdSAk+ guwJS60XjnMDHgLrtlNWOiXcmtjsIp4zc43eYHdoZF6Yr3hbTktHnKyV9pqLFbI2EmMU sNaQ== X-Gm-Message-State: ACrzQf17m1njeCI56jv3ny6tc6Hmm3972XTmZD9McZfKUt+q1KEo5cMV o88SjPCxf6DQPI6r5VP4fJk/vp2sMijHwA== X-Google-Smtp-Source: AMsMyM5qG9kKRR9a8xlo2FlQCCSGUemgnxNUjAciCrgsUPVB/ecT1wlCnlT9F3DGVg5mBsUn2N7Ojg== X-Received: by 2002:a05:6214:d0c:b0:4b3:36b4:c89a with SMTP id 12-20020a0562140d0c00b004b336b4c89amr13887053qvh.93.1665423641158; Mon, 10 Oct 2022 10:40:41 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b00-6400-9534-07b5-32fb-791d.res6.spectrum.com. [2603:6081:7b00:6400:9534:7b5:32fb:791d]) by smtp.gmail.com with ESMTPSA id n20-20020a05620a295400b006cede93c765sm10923192qkp.28.2022.10.10.10.40.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Oct 2022 10:40:40 -0700 (PDT) Date: Mon, 10 Oct 2022 13:40:38 -0400 From: Tom Rini To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Stefan Roese , u-boot@lists.denx.de Subject: Re: Broken watchdog in u-boot master branch Message-ID: <20221010174038.GP2020586@bill-the-cat> References: <20221009191225.65jwebefhqng3qbi@pali> <20221010162818.GM2020586@bill-the-cat> <20221010172256.jb4qwvgsbcucwejf@pali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sCNd3Ivk/oijKKf1" Content-Disposition: inline In-Reply-To: <20221010172256.jb4qwvgsbcucwejf@pali> X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean --sCNd3Ivk/oijKKf1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2022 at 07:22:56PM +0200, Pali Roh=E1r wrote: > On Monday 10 October 2022 12:28:18 Tom Rini wrote: > > On Sun, Oct 09, 2022 at 09:12:25PM +0200, Pali Roh=E1r wrote: > > > Hello! Watchdog code seems to be broken in u-boot master branch. > > > On Nokia N900 I'm getting following message in qemu: > > >=20 > > > cyclic function rx51_watchdog took too long: 10000us vs 1000us max, d= isabling > > >=20 > > > Seems that watchdog core code is not prepared for "slower" watchdogs > > > which communicate over slower i2c bus, like it is the case for N900. > > >=20 > > > Disabling slower watchdog is a bad idea as it would result in reboot > > > loop instead of slower - but working code. > >=20 > > So, looking at this in more detail, we have > > CONFIG_CYCLIC_MAX_CPU_TIME_US as a configuration option (which is where > > the too long comes from). And picking a random CI run: > > https://source.denx.de/u-boot/u-boot/-/jobs/511177 > > I do see we hit this in CI once, but not every time, QEMU runs here. Is > > that the max time is configurable enough to satisfy your concerns here? >=20 > It is needed to investigate, how to _properly_ fix this issue, not just > workarounded it. Probably other boards may be affected. So it's the cyclic watchdog code, which we merged as early as possible that's the reason here. And it was merged as early as we could to see if there's problems. Are there problems? We're seeing "system too slow, disabling" on QEMU, sometimes, and the value of too slow is configurable. I know you reported other problems with n900 HW, so we can't see if it's failing there, and I don't have any omap3 HW setup in my lab atm, just newer generation boards and don't see the problem there. Which is why I'm asking, is being able to configure the "too slow" value enough? Or is there something else that needs to be done? --=20 Tom --sCNd3Ivk/oijKKf1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmNEWRMACgkQFHw5/5Y0 tyyUzgv/b6mqG5LXfIZrv8uiCL2fQoFccNU+t39kng7VOFMZVsKLbWb6U3TQLQMK 9yu0gNP0Kt1aJJAKKyof/zPMh7ecMjWCoxsVoqeEigqByUBNY1IU36HomONF/9dZ QqAmV/Mn7rUhSOLeRs03So5fAe1RSHO1H1H+ac+ecRqQtZT/iWRIuJoZ1Axwtm0/ JJl4RaEvh3s8ksQMPvZSy2sPUEnknwJR8ALuPTrcre4daDn/KoU9q8s7rffkiEmi A5yEmxQ21K67f/wf9bg8VVt1ehgG0VyShosbvzXiUaXFJZhAbjc/TwBk7z8zBOX0 M+ZkSzHs50mPnhDl/bl83sBzXx5SrLsPGuEvMCkTsflcMThQ1vePKNEphgKqmvlU lFxdKaB9mU23C8DopjgGXjM0WAIh/UOrGutI1mTqdIPYJm8aPH1iBhsI8su8cSiL blC3p9oZnFngR1DK88Yt/HmoH3q0l08K36WZyBYHMqfBoWzLN3WgVcOXGEDpmVxA GbdUmFJs =Nwzi -----END PGP SIGNATURE----- --sCNd3Ivk/oijKKf1--