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 9F200C43334 for ; Mon, 25 Jul 2022 02:25:33 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1D4A283FAE; Mon, 25 Jul 2022 04:25:31 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="hpmBhruC"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 67FF983FAE; Mon, 25 Jul 2022 04:25:30 +0200 (CEST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 68A748036F for ; Mon, 25 Jul 2022 04:25:27 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pl1-x62d.google.com with SMTP id y24so9148546plh.7 for ; Sun, 24 Jul 2022 19:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc; bh=faGEMRXvx9doDr7/O8LXSEKnMt4v43aOsftQdoOChs0=; b=hpmBhruCmRzd/GZ+QrI+dNnEw3rDVAHpkOw/R0eR5ndTYA0aJzwhjtjNMN3nfXF71Q BdHfpCZZUXoLjLN2KdFd1hdZ/77I9pWscGXhgZiQS6fu5CDAucslKy9/SvYiOsN1S43O TjWhnI72iHMh+fqTgYAnISz3XWKiYaG1RODaOy8x1mCZDF/wjRf27x85YAdI3mC8jCev lF3XZn8PkkToq4q/0jgth7DmpGPTQnCuBxylTlcekkq8Z04wzi7T0tll1NLAdF6dBffT RNXv6guitD77gz+EfCInr1u8a3ylP0KHVV7VmInSyQjJ6Doo5T1WPXHb6DellZh5qbbu eLew== 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 :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc; bh=faGEMRXvx9doDr7/O8LXSEKnMt4v43aOsftQdoOChs0=; b=M1ukXXZdNhxtxL+3zireVxiorGqxvbBUT2KXCW4Logj/O4e8F7g6/BggLClfMRN987 78HFuUJcCUDHpmnRVa8MzhSYQ/vuD25f/ucmlgp+tKPWnuGvnfnhdVYzMdiDTjQzh/ke NHuu/4AOJZFEBye5lK4Z8LP6A9Sg24NgU2S2SyamaDsP1KsJ+mQvEzBTyum6GiZRHZVn P+yNgX6pC1XAS2kwhLxu0iudG/J0DNgYXzaFLnDDfYOf7l9bkPb4Gl+SN/h/35AONgpI c8yz5KtmYHFZx8CbgKlL+VPhFnnyWq3i3Snvl2TGhOLAoA6XpnyuXKtihg/QMrmsEPud /Wyg== X-Gm-Message-State: AJIora8yscRVcvRsBhajxoK0IChAXDdTQatk3u9bL89VKrEQO67gk3ab cL1uTRhJPRjc8jdE/mCEPP44fg== X-Google-Smtp-Source: AGRyM1txRBdSnIndWWYL5top97ogLB9RQRq0nHIHAAy15MJs5FZwqPEe8go4EuN00e/YeLnUdtQn4Q== X-Received: by 2002:a17:903:1103:b0:16c:9a6e:d54 with SMTP id n3-20020a170903110300b0016c9a6e0d54mr10169913plh.131.1658715925344; Sun, 24 Jul 2022 19:25:25 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:e46b:1dd3:dc44:d2ff]) by smtp.gmail.com with ESMTPSA id s16-20020a170902ea1000b00162529828aesm3765531plg.109.2022.07.24.19.25.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Jul 2022 19:25:24 -0700 (PDT) Date: Mon, 25 Jul 2022 11:25:20 +0900 From: AKASHI Takahiro To: Jan Palus Cc: Simon Glass , U-Boot Mailing List Subject: Re: [bug] uboot 2022.07 hangs on rpi 2 with attached usb storage Message-ID: <20220725022520.GA19532@laputa> Mail-Followup-To: AKASHI Takahiro , Jan Palus , Simon Glass , U-Boot Mailing List References: <20220718174849.ygiyqhg2qjks3o4i@kalarepa.grzadka> <20220723141913.qr62cd5wxd42e5x5@pine.grzadka> <20220723144318.b3r2n7vigm5glcpg@pine.grzadka> <20220723150339.ellrz7byusj6pwbb@pine.grzadka> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220723150339.ellrz7byusj6pwbb@pine.grzadka> 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 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). Thanks, -Takahiro Akashi