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=-2.2 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 DC203C43381 for ; Tue, 5 Mar 2019 11:20:17 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 9B6AE2082C for ; Tue, 5 Mar 2019 11:20:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Bf+k78Ts"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HhYU38pF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9B6AE2082C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=yeeDAZQdOJlA6OOLjJws3vqkkT9ktTT20UsVxP2KHak=; b=Bf+k78TsCbtmUsH2j5e1y0J2O eRh9UkSOTnVbgsohayeVo3LVvaUn0FoQd53DqfgjOavwNv+paC2z++5IjNjt4avuZ4jKgm/aB1qHJ uZC3spptZv0zktJyhzu9eSqIQI7MizoD/RumG5ESaRqzlHKAJW7vbszXXg9YVAmwBHdRpqTtLpiPo YiaKS+o6hcZ+nwsG6Yhtx3ZD1ns+YvMtsbfBpuPryWBrEMC3z60QnfhS74YHgIaNQyDzojmmmeSYG c4xSc4yYEZAO+O2o1VishKOpMvX0scm6JY/3FT5/mEZSnhfVdh0K1OugNEyKgjbVFiPR3s6+FYXpT m1itESoRQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h187J-00068H-5G; Tue, 05 Mar 2019 11:20:13 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h187F-00065M-HZ for linux-arm-kernel@lists.infradead.org; Tue, 05 Mar 2019 11:20:11 +0000 Received: by mail-wm1-x330.google.com with SMTP id y15so2184134wma.0 for ; Tue, 05 Mar 2019 03:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=nhN4yqqRaCL86t4zvd41CcSun+CwjWHohZT4ksDk2lQ=; b=HhYU38pFZH3LjivDiAKrZPBLvu4ztA7TkWS8IHj3e3jIix+g9Pp6WpbiMaI6WHd3Wq J+uRK5qgW+INRwgpZxF4U4K8Net+2Wq6y1r/R828h9+dBLbmsy++qcfxTsZZBZUblNXg UQMK1ifPAjykg6HTuelN9Wn1CCPkv5fBnUmu4f8Pozhu/xmw0Y7taI9jaR5Ps8PzEc7c DG/xi/O9Gmb35QeVael2mXh6K9A6/GMdMM0bFYLq/d3tMDvvAZeo0USkOq39gH3qbLkn 5SFiFSQkoAnXHO5l+bwIyEgND22avM9F34pL6X1OjwhSRIcBlGCc4H/1E+JyMooanv+j R00A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=nhN4yqqRaCL86t4zvd41CcSun+CwjWHohZT4ksDk2lQ=; b=ClIkGOIbrXrw+qIZ4sZuoL/4VBRiSW/J9lC1geNlbbxTGA/QbY/0tK6RAOO3bGgSno 1JMgoC9+WTl2y8BuqlVL7ahbxq3OlVlrbBsnAOn9MjCx90KT5KmWP5V1XIpCBhjvWn1u lkv5uVFxAdgkuTSYDTIcL/Q2yQdw0sBQ9oevveArx52lZobnV2PTUCxIGSXTul98sIYS ny7iSgoLthictr7FS9Oyra1w188VHN2t4rRzYNRKfzd0VA5eSUSadd9CnNrZ510XKx2j 5RJFY20jwv5NkPnO8kRRuP6u/G+fgUnj92mmGiy3QgMqpEB+ME/NtjeZ+PS0N9mUMnEm rAvg== X-Gm-Message-State: APjAAAWQcJ/aFy9lQPxdmV44XzZAhUoh5mtVrmWBd9gYkMZRV9BX0yWk WeamoHU1cRPc+2Gu+Dkwe7g= X-Google-Smtp-Source: APXvYqxKzsQ9ZSebObv52qyGNOoMyvL/VXudLrgU+C1M2AIOTvIcg63WOopS6hxKc2x7OeerLw/VSQ== X-Received: by 2002:a1c:7dd7:: with SMTP id y206mr2269309wmc.123.1551784807241; Tue, 05 Mar 2019 03:20:07 -0800 (PST) Received: from localhost (pD9E51D2D.dip0.t-ipconnect.de. [217.229.29.45]) by smtp.gmail.com with ESMTPSA id x17sm27038324wrd.95.2019.03.05.03.20.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Mar 2019 03:20:06 -0800 (PST) Date: Tue, 5 Mar 2019 12:20:05 +0100 From: Thierry Reding To: Embedded Engineer Subject: Re: Unstable Kernel behavior on an ARM based board Message-ID: <20190305112005.GC26369@ulmo> References: <20190302123907.qoe46qs6qmx7qnjs@shell.armlinux.org.uk> <453072a9-52e2-7591-750f-624ca27e0bbf@gmx.net> <20190304142546.GB24676@ulmo> <20190305100731.uz6tleu3fkaruwb6@shell.armlinux.org.uk> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190305_032009_610554_2C74D168 X-CRM114-Status: GOOD ( 19.38 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Vladimir Murzin , Russell King - ARM Linux admin , Jon Hunter , linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============4190940215306915157==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============4190940215306915157== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JgQwtEuHJzHdouWu" Content-Disposition: inline --JgQwtEuHJzHdouWu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 05, 2019 at 03:29:26PM +0500, Embedded Engineer wrote: > On Tue, Mar 5, 2019 at 3:07 PM Russell King - ARM Linux admin > wrote: > > > > Please apply this patch so we can see the (ptrval) values. Thanks. >=20 > Please find below logs after applying patch: >=20 > https://pastebin.com/6TaBxPX5 Hm... so looks like what you're getting here is the error spew from the DMA pool debug code in mm/dmax_pool.c. The way I understand it is that that will initialize the memory for each page allocated from the pool with the POOL_POISON_FREED (0xa7) (see pool_alloc_page()) and then upon adding the page to the pool list, it'll store the offset to page->offset field and check the contents of the page. The contents of the page then don't match the expected poison. The dump of the corrupted memory is somewhat confusing because the values that don't match the poison are actually expected, at least partially. From my reading of the DMA pool code, the first four bytes store the offset of the DMA block into the physical memory page. However, given the size of the hexdump, it looks like the pool was allocated with a block size of 64 bytes, which matches the code in drivers/usb/chipidea/udc.c that allocates the "ci_hw_qh" pool. What's strange here, though, is that the offset that's stored to the first four bytes of a block seems to actually be stored twice per block. The first offset seems to be correct, since it's apparently used to find the offset of the next block to allocate. If you look at the first corrupted hexdump: [ 1.327553] tegra-udc 7d000000.usb: dma_pool_alloc ci_hw_qh, ec056080 = (corrupted) [ 1.335058] 00000000: c0 00 00 00 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = ................ [ 1.343077] 00000010: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = ................ [ 1.351095] 00000020: 80 00 00 00 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = ................ [ 1.359113] 00000030: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = ................ This is the entry for the block at offset 0x00000080 and the offset for the next block is 0x000000c0, which is exactly 64 bytes after the current block. However, if you then look at the second offset that's stored at offset 0x00000020 in the block, it's 0x00000080, which does match the offset of the current block, but I think that may just be coincidence. The same coincidence happens for the second corrupted block: [ 1.367210] tegra-udc 7d000000.usb: dma_pool_alloc ci_hw_qh, ec056140 = (corrupted) [ 1.374709] 00000000: 80 01 00 00 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = ................ [ 1.382727] 00000010: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = ................ [ 1.390744] 00000020: 40 01 00 00 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = @............... [ 1.398760] 00000030: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = ................ But not for the third: [ 1.406965] tegra-udc 7d000000.usb: dma_pool_alloc ci_hw_qh, ec0561c0 = (corrupted) [ 1.414466] 00000000: 00 02 00 00 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = ................ [ 1.422483] 00000010: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = ................ [ 1.430502] 00000020: 40 03 00 00 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = @............... [ 1.438519] 00000030: a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 a7 = ................ The fact that we see the offset stored at offset 0x20 in each block makes me think there's perhaps some sort of aliasing happening here. But I'm not sure how the system would even boot this far if aliasing was really the problem. Things should be falling apart much sooner if that's really what's going on here. However, this sort of aliasing is not something that your typical memory test will catch, so it could explain why they aren't reporting any errors. Thierry --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlx+W2EACgkQ3SOs138+ s6ENmBAAli+Ly5mpCVxcVpwoNYpLKAAdOGEnhCijyBatcfhfCqG+i/Gm+uLFhOjN z7a7OGtf7hOcJatAayDplAXWb1+G4Rv0WpUxpCI/5UoqN+Gzx8MNtkb8ZfC2kZDB /1/Is6sObVJJf+1ZMUl8yIOWKBon6JTWmrg3UghnvXzPoy/QgDwxYk4deXHYbGOM 1qIYVBxgblGSCZ3W0CdJIvMobTuzmA7GqqhZ/NkjY0gzBEwnPdl6xaUO6sCRjS/w jJ9qpLoYIr0UfY3nC69ytzApndILHPycWDH45y4qJAkl/RWF9PXXw6LXb6Wh68xV lszf6x4DOXc7p2qpdognzBZs7bXO2X24NcDnjdWDX4fVY+Vw6vfJPCHckeAsTgcx WWFlzGegcOKfK7CrYh5vo2HbaSJp/Ax+Xj9N7n2CwbV2vdfRnRj8Si3UkmpC+iuW mA81iB1rpesNyQ6xYh3+emjML5NKzk2R983KTagfQPGGI0mN0R8vPnL1C7wEGHfd q9f100kdm5AByOjIFEXqiGDIZBmhynabv8GkV3881iBeCG0n+4GRFAwRJ6b9LQDe rywfetJE+tgLJxc2XCc46qqj/ZduuDsQQN1n8OpHOCUMEVKECEKl0woOxL6t2dEg ahB918hbOSAFzhbLfLmT+JmbVgOxeNEYuK7pJD3fdo5+hefTK6Q= =L4bR -----END PGP SIGNATURE----- --JgQwtEuHJzHdouWu-- --===============4190940215306915157== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============4190940215306915157==--