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 5CE95C43334 for ; Mon, 25 Jul 2022 11:05:25 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8FA1F84072; Mon, 25 Jul 2022 13:05:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=fastmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=fastmail.com header.i=@fastmail.com header.b="isQrI4sN"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b="zj03C6Vp"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D99B58415E; Mon, 25 Jul 2022 09:44:40 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 0E2BE84159 for ; Mon, 25 Jul 2022 09:44:36 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=fastmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jpalus@fastmail.com Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8BC9C5C004F; Mon, 25 Jul 2022 03:44:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 25 Jul 2022 03:44:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1658735075; x=1658821475; bh=3FVLDraEO9 pXG4fvKpdj1EhwAFpvXBUl0pihU6ypLY0=; b=isQrI4sNmzQhcKjGqTdWKJLBly AiKBLUwUCFXJtP9MgehHR8gh9KhDAeujnXFZngchvR2+gSX16PadnVHITHPfXj5R qUlz6qbFTlQkiVirsCXyYweNIO4H3Yx0uEazPJAYMbEoXFhUaoRVO6xb5X68dGDY AGzbfesb8vD6NljbyZ06n0f1n+9qZKSLrjPOkgpGReo0OZkKsc31r2pU8j8ZTRht w16z7WYognqKuaLxbHMpjzt97CKxrApqWxD0D9+IkXy4s6tSEqLnvomrayPc1SEF 30UIHvLQ2RGoukhrpicwv/DNixFrPN4gYTlnMwG0OGSTwTwYj78U/847rydQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1658735075; x=1658821475; bh=3FVLDraEO9pXG4fvKpdj1EhwAFpv XBUl0pihU6ypLY0=; b=zj03C6Vp5imlBrJgjY8C+ghr1ArsrAZytIdlB10ew60L ML/IMPwur5jGlP0Xag6+gtxdoIANL/4qOrRI8A4pp8J/JCbrQeAV8FqEZD56NaLI xrVWl9A+05XEZyDQ5Ck5ES6xBDXieS+nyQP8WX+UQVvnM7P8/TG1bMJbalhD/gcd XshunELhLjhyD11bPmSDpa8KKBeH40EZmYpSqzfyKsDJlVwHIcvDpfrZcnTY913f VSNI4N/srrJGX6XZGwWakhwIejIFy844hrBIt7sxUThDe63ubd13TEHJ6eYn8POH aOFbWjKcpmSg3725O3ogd5n1kXxCoDfDPLVc75QIHg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvddtjedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujggfsehttdertddtreejnecuhfhrohhmpeflrghn ucfrrghluhhsuceojhhprghluhhssehfrghsthhmrghilhdrtghomheqnecuggftrfgrth htvghrnhepfeeghfffjeeigfetudelgfdvffduleetgfekhfeiffdtfeefledvhedtgefh vddtnecuffhomhgrihhnpeguvghngidruggvnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepjhhprghluhhssehfrghsthhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i01894241:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Jul 2022 03:44:34 -0400 (EDT) Date: Mon, 25 Jul 2022 09:44:32 +0200 From: Jan Palus To: AKASHI Takahiro , Simon Glass , U-Boot Mailing List Subject: Re: [bug] uboot 2022.07 hangs on rpi 2 with attached usb storage Message-ID: <20220725074432.tjzesqo7hhhfdgak@pine.grzadka> References: <20220718174849.ygiyqhg2qjks3o4i@kalarepa.grzadka> <20220723141913.qr62cd5wxd42e5x5@pine.grzadka> <20220723144318.b3r2n7vigm5glcpg@pine.grzadka> <20220723150339.ellrz7byusj6pwbb@pine.grzadka> <20220725022520.GA19532@laputa> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220725022520.GA19532@laputa> User-Agent: NeoMutt/20220429 X-Mailman-Approved-At: Mon, 25 Jul 2022 13:05:19 +0200 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 On 25.07.2022 11:25, AKASHI Takahiro wrote: > On Sat, Jul 23, 2022 at 05:03:39PM +0200, Jan Palus wrote: > > On 23.07.2022 16:43, Jan Palus wrote: > > > On 23.07.2022 16:19, Jan Palus wrote: > > > > On 22.07.2022 02:59, Simon Glass wrote: > > > > > Hi Jan, > > > > > > > > > > On Mon, 18 Jul 2022 at 11:48, Jan Palus wrote: > > > > > > > > > > > > u-boot 2022.07 boots fine without any USB devices attached to > > > > > > RaspberryPi 2 however it hangs early on if external USB drive is > > > > > > connected, right after: > > > > > > > > > > > > Request Sense returned 02 04 01 > > > > > > > > > > > > git bisect indicates first commit to cause regression is: > > > > > > > > > > > > 8c9812a5d557c4eacf164147d7380b3af1b222ec is the first bad commit > > > > > > commit 8c9812a5d557c4eacf164147d7380b3af1b222ec > > > > > > Author: AKASHI Takahiro > > > > > > Date: Tue Mar 8 20:36:40 2022 +0900 > > > > > > > > > > > > usb: storage: call device_probe() after scanning > > > > > > > > > > > > Every time a usb bus/port is scanned and a new device is detected, > > > > > > we want to call device_probe() as it will give us a chance to run > > > > > > additional post-processings for some purposes. > > > > > > > > > > > > In particular, support for creating partitions on a device will be added. > > > > > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > > > Reverting this commit fixes the issue. > > > > > > > > > > > > Note that USB drive is TOSHIBA MQ04UBD200 and it's not used for booting. > > > > > > Also note that without this change 0 storage devices are detected even > > > > > > when drive is attached. > > > > > > > > > > I am not sure what is going on here. Can you provide the full console > > > > > trace of the boot? Any idea where it is hanging? > > > > > > > ... > > > > > > > > Now the place where it hangs is: > > > > > > > > part_efi.c: > > > > > > > > static int part_test_efi(struct blk_desc *dev_desc) > > > > { > > > > ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, dev_desc->blksz); > > > > > > > > where dev_desc->blksz is 3782209548. > > > > > > > > > > So it appears block size is read incorrectly? Should be 512 but not sure > > > where this value 3782209548 is coming from, it's not block capacity > > > either. After plugging in Linux reports: > > > > > > sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB) > > > > Since this was logged: > > > > Device NOT ready > > Request Sense returned 02 04 01 > > > > then it seems capacity/block size were never determined (happens right > > after these log messages if they *don't* occur) so I guess they are > > random values and this usb storage should never have been probed? I'll > > stop here due to my cluelessness. > > The code looks like: > usb_stor_probe_device() > ... > blk_create_devicef(); > ret = usb_stor_get_info(udev, data, blkdev); > if (ret == 1) { > usb_max_devs++; > debug("%s: Found device %p\n", __func__, udev); > } else { > debug("usb_stor_get_info: Invalid device\n"); > ret = device_unbind(dev); > if (ret) > return ret; > <== (A) > } > > blk_probe_or_unbind(dev); > ... > > > usb_stor_get_info() returns 0 when it generates "Device NOT ready" message. > Then blk_probe_or_unbind(), hence part_test_efi(), is accidentally called > although blkdev is not fully initialised/populated. > > I think we should skip the subsequent processing by adding "continue" at (A). I see there is a change proposed in ml in the same place: https://lists.denx.de/pipermail/u-boot/2022-July/489531.html Though I'm also wondering "Request Sense returned 02 04 01" from a quick search appears to indeed mean "Device NOT ready", but "it's becoming ready" so in my case that's likely about spinning up HDD plates. I wonder if it shouldn't be treated like -EAGAIN with some timeout as in second or two the drive would likely report it is ready.