[bug] uboot 2022.07 hangs on rpi 2 with attached usb storage
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 takahiro.akashi@linaro.org 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 takahiro.akashi@linaro.org Reviewed-by: Simon Glass sjg@chromium.org
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.
Hi Jan,
On Mon, 18 Jul 2022 at 11:48, Jan Palus jpalus@fastmail.com 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 takahiro.akashi@linaro.org 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 <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>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?
Regards, Simon
On 22.07.2022 02:59, Simon Glass wrote:
Hi Jan,
On Mon, 18 Jul 2022 at 11:48, Jan Palus jpalus@fastmail.com 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 takahiro.akashi@linaro.org 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 <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>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?
It hangs very early on during USB start, log from USB initialization with debug enabled:
starting USB... Bus usb@7e980000: OF: translating address: 0000987e OF: parent translation for: 0000003f OF: one level translation: 0000983f 0 - 0 'gpio@7e200000' - found dwc2_usb usb@7e980000: set_state_simple op missing dwc2_usb usb@7e980000: Can't get reset: -524 dwc2_usb usb@7e980000: Core Release: 2.80a USB DWC2 Sending event 4/(unknown) to spy 'efi_disk add' scanning bus usb@7e980000 for devices... bind node usb1@1 - attempt to match compatible string 'usb424,9514' No match for node 'usb1@1' 0 - 0 'gpio@7e200000' - found usb_hub usb_hub: set_state_simple op missing bind node usbether@1 - attempt to match compatible string 'usb424,ec00' No match for node 'usbether@1' 0 - 0 'gpio@7e200000' - found usb_hub usb_hub: set_state_simple op missing Sending event 4/(unknown) to spy 'efi_disk add' - seq=0 0 - 0 'gpio@7e200000' - found smsc95xx_eth smsc95xx_eth: set_state_simple op missing Sending event 4/(unknown) to spy 'efi_disk add' Device NOT ready Request Sense returned 02 04 01
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.
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 jpalus@fastmail.com 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 takahiro.akashi@linaro.org 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 <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>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)
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 jpalus@fastmail.com 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 takahiro.akashi@linaro.org 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 <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>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.
Hi Jan,
On Sat, 23 Jul 2022 at 09:03, Jan Palus jpalus@fastmail.com 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 jpalus@fastmail.com 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 takahiro.akashi@linaro.org 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 <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>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.
Are you able to post the full console log? It should start with the 'U-Boot' banner and end with the hang
Takahiro-san, so you have any ideas?
Regards, Simon
On 23.07.2022 10:42, Simon Glass wrote:
Hi Jan,
On Sat, 23 Jul 2022 at 09:03, Jan Palus jpalus@fastmail.com 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 jpalus@fastmail.com 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 takahiro.akashi@linaro.org 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 <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>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.
Are you able to post the full console log? It should start with the 'U-Boot' banner and end with the hang
Sure. Full log without debug logging:
U-Boot 2022.07 (Jul 23 2022 - 20:53:41 +0200)
DRAM: 832 MiB RPI 2 Model B (0xa01041) Core: 64 devices, 14 uclasses, devicetree: embed MMC: mmc@7e202000: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... Bus usb@7e980000: USB DWC2 scanning bus usb@7e980000 for devices... Device NOT ready Request Sense returned 02 04 01
And with debug logging:
U-Boot 2022.07 (Jul 23 2022 - 20:58:39 +0200)
DRAM: size=18, ptr=388, limit=400: 7fffe50 size=4, ptr=38c, limit=400: 7fffe68 832 MiB bind node aliases Device 'aliases' has no compatible string bind node chosen Device 'chosen' has no compatible string bind node reserved-memory Device 'reserved-memory' has no compatible string bind node thermal-zones Device 'thermal-zones' has no compatible string bind node soc - attempt to match compatible string 'simple-bus' - found match at 'simple_bus': 'simple-bus' matches 'simple-bus' bind node timer@7e003000 - attempt to match compatible string 'brcm,bcm2835-system-timer' No match for node 'timer@7e003000' bind node txp@7e004000 - attempt to match compatible string 'brcm,bcm2835-txp' No match for node 'txp@7e004000' bind node cprman@7e101000 - attempt to match compatible string 'brcm,bcm2835-cprman' No match for node 'cprman@7e101000' bind node mailbox@7e00b880 - attempt to match compatible string 'brcm,bcm2835-mbox' No match for node 'mailbox@7e00b880' bind node gpio@7e200000 - attempt to match compatible string 'brcm,bcm2835-gpio' - found match at 'bcm283x_pinctrl': 'brcm,bcm2835-gpio' matches 'brcm,bcm2835-gpio' bind node serial@7e201000 - attempt to match compatible string 'arm,pl011' - found match at 'serial_pl01x': 'arm,pl011' matches 'arm,pl011' - seq=0 bind node mmc@7e202000 - attempt to match compatible string 'brcm,bcm2835-sdhost' - found match at 'bcm2835-sdhost': 'brcm,bcm2835-sdhost' matches 'brcm,bcm2835-sdhost' bind node i2c@7e205000 - attempt to match compatible string 'brcm,bcm2835-i2c' No match for node 'i2c@7e205000' bind node aux@7e215000 - attempt to match compatible string 'brcm,bcm2835-aux' No match for node 'aux@7e215000' bind node pwm@7e20c000 - attempt to match compatible string 'brcm,bcm2835-pwm' No match for node 'pwm@7e20c000' bind node hvs@7e400000 - attempt to match compatible string 'brcm,bcm2835-hvs' No match for node 'hvs@7e400000' bind node i2c@7e804000 - attempt to match compatible string 'brcm,bcm2835-i2c' No match for node 'i2c@7e804000' bind node usb@7e980000 - attempt to match compatible string 'brcm,bcm2835-usb' - found match at 'dwc2_usb': 'brcm,bcm2835-usb' matches 'brcm,bcm2835-usb' bind node usb1@1 - attempt to match compatible string 'usb424,9514' No match for node 'usb1@1' bind node dma@7e007000 - attempt to match compatible string 'brcm,bcm2835-dma' No match for node 'dma@7e007000' bind node interrupt-controller@7e00b200 - attempt to match compatible string 'brcm,bcm2836-armctrl-ic' No match for node 'interrupt-controller@7e00b200' bind node watchdog@7e100000 - attempt to match compatible string 'brcm,bcm2835-pm' - attempt to match compatible string 'brcm,bcm2835-pm-wdt' No match for node 'watchdog@7e100000' bind node rng@7e104000 - attempt to match compatible string 'brcm,bcm2835-rng' No match for node 'rng@7e104000' bind node pixelvalve@7e206000 - attempt to match compatible string 'brcm,bcm2835-pixelvalve0' No match for node 'pixelvalve@7e206000' bind node pixelvalve@7e207000 - attempt to match compatible string 'brcm,bcm2835-pixelvalve1' No match for node 'pixelvalve@7e207000' bind node thermal@7e212000 - attempt to match compatible string 'brcm,bcm2836-thermal' No match for node 'thermal@7e212000' bind node i2c@7e805000 - attempt to match compatible string 'brcm,bcm2835-i2c' No match for node 'i2c@7e805000' bind node vec@7e806000 - attempt to match compatible string 'brcm,bcm2835-vec' No match for node 'vec@7e806000' bind node pixelvalve@7e807000 - attempt to match compatible string 'brcm,bcm2835-pixelvalve2' No match for node 'pixelvalve@7e807000' bind node hdmi@7e902000 - attempt to match compatible string 'brcm,bcm2835-hdmi' - found match at 'bcm2835_video': 'brcm,bcm2835-hdmi' matches 'brcm,bcm2835-hdmi' bind node v3d@7ec00000 - attempt to match compatible string 'brcm,bcm2835-v3d' No match for node 'v3d@7ec00000' bind node gpu - attempt to match compatible string 'brcm,bcm2835-vc4' No match for node 'gpu' bind node local_intc@40000000 - attempt to match compatible string 'brcm,bcm2836-l1-intc' No match for node 'local_intc@40000000' bind node firmware - attempt to match compatible string 'raspberrypi,bcm2835-firmware' - attempt to match compatible string 'simple-mfd' - found match at 'simple_bus': 'simple-bus' matches 'simple-mfd' bind node power - attempt to match compatible string 'raspberrypi,bcm2835-power' No match for node 'power' bind node mailbox@7e00b840 - attempt to match compatible string 'brcm,bcm2836-vchiq' - attempt to match compatible string 'brcm,bcm2835-vchiq' No match for node 'mailbox@7e00b840' bind node clocks Device 'clocks' has no compatible string bind node phy - attempt to match compatible string 'usb-nop-xceiv' No match for node 'phy' bind node arm-pmu - attempt to match compatible string 'arm,cortex-a7-pmu' No match for node 'arm-pmu' bind node timer - attempt to match compatible string 'arm,armv7-timer' No match for node 'timer' bind node cpus Device 'cpus' has no compatible string bind node leds - attempt to match compatible string 'gpio-leds' No match for node 'leds' bind node memory@0 Device 'memory@0' has no compatible string bind node smbios - attempt to match compatible string 'u-boot,sysinfo-smbios' - found match at 'sysinfo_smbios': 'u-boot,sysinfo-smbios' matches 'u-boot,sysinfo-smbios' bind node smbios Device 'smbios' has no compatible string bind node __symbols__ Device '__symbols__' has no compatible string bind node clk-osc - attempt to match compatible string 'fixed-clock' No match for node 'clk-osc' bind node clk-usb - attempt to match compatible string 'fixed-clock' No match for node 'clk-usb' 0 - 0 'gpio@7e200000' - found 0 - 0 'gpio@7e200000' - found pinconfig gpioout: set_state_simple op missing 0 - 0 'gpio@7e200000' - found pinconfig alt0: set_state_simple op missing 0 - 0 'gpio@7e200000' - found pinconfig i2s_alt0: set_state_simple op missing simple_bus soc: set_state_simple op missing RPI 2 Model B (0xa01041) 0 - 0 'gpio@7e200000' - found pinconfig uart0_gpio14: set_state_simple op missing Core: 64 devices, 14 uclasses, devicetree: embed MMC: 0 - 0 'mmc@7e202000' - found 0 - 0 'gpio@7e200000' - found pinconfig sdhost_gpio48: set_state_simple op missing Sending event 4/(unknown) to spy 'efi_disk add' bcm2835-sdhost mmc@7e202000: f_max 250000000, f_min 122129 bcm2835-sdhost mmc@7e202000: bcm2835_probe -> OK Sending event 4/(unknown) to spy 'efi_disk add' 1 - 0 'mmc@7e202000' - not found mmc@7e202000: 0 Loading Environment from FAT... Sending event 4/(unknown) to spy 'efi_disk add' Sending event 4/(unknown) to spy 'efi_disk add' Sending event 4/(unknown) to spy 'efi_disk add' <2, 0, 1024> <8, 0, 64> <8488, 256, 128> FAT read(sect=8098), clust_size=1, read_size=1 FAT read(sect=94922), clust_size=1, read_size=1 FAT read(sect=152022), clust_size=1, read_size=1 FAT read(sect=170944), clust_size=1, read_size=1 FAT read(sect=8108), clust_size=1, read_size=1 FAT read(sect=81128), clust_size=1, read_size=1 FAT read(sect=54597), clust_size=1, read_size=1 FAT read(sect=28307), clust_size=1, read_size=1 FAT read(sect=173533), clust_size=1, read_size=1 FAT read(sect=235690), clust_size=1, read_size=1 FAT read(sect=156342), clust_size=1, read_size=1 Unable to read "uboot.env" from mmc0:1... 0 - 0 'hdmi@7e902000' - found 0 - 0 'gpio@7e200000' - found bcm2835_video hdmi@7e902000: set_state_simple op missing Sending event 4/(unknown) to spy 'efi_disk add' Sending event 4/(unknown) to spy 'efi_disk add' In: serial Out: vidconsole Err: vidconsole 0 - not found Net: No ethernet found. starting USB... Bus usb@7e980000: 0 - 0 'gpio@7e200000' - found dwc2_usb usb@7e980000: set_state_simple op missing dwc2_usb usb@7e980000: Can't get reset: -524 dwc2_usb usb@7e980000: Core Release: 2.80a USB DWC2 Sending event 4/(unknown) to spy 'efi_disk add' scanning bus usb@7e980000 for devices... bind node usb1@1 - attempt to match compatible string 'usb424,9514' No match for node 'usb1@1' 0 - 0 'gpio@7e200000' - found usb_hub usb_hub: set_state_simple op missing bind node usbether@1 - attempt to match compatible string 'usb424,ec00' No match for node 'usbether@1' 0 - 0 'gpio@7e200000' - found usb_hub usb_hub: set_state_simple op missing Sending event 4/(unknown) to spy 'efi_disk add' - seq=0 0 - 0 'gpio@7e200000' - found smsc95xx_eth smsc95xx_eth: set_state_simple op missing Sending event 4/(unknown) to spy 'efi_disk add' Device NOT ready Request Sense returned 02 04 01
Takahiro-san, so you have any ideas?
Regards, Simon
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 jpalus@fastmail.com 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 takahiro.akashi@linaro.org 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 <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>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
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 jpalus@fastmail.com 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 takahiro.akashi@linaro.org 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 <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>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.
participants (3)
-
AKASHI Takahiro -
Jan Palus -
Simon Glass