USB ports on Raspberry Pi are deactivated when connecting a Drobo unit

[ 85.177095] usb 1-1.1: new high-speed USB device number 3 using xhci_hcd
[ 92.733065] ------------[ cut here ]------------
[ 92.733076] Firmware transaction timeout
[ 92.733139] WARNING: CPU: 2 PID: 180 at drivers/firmware/raspberrypi.c:64 rpi_firmware_transaction+0xd8/0x108
[ 92.733143] Modules linked in: dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua btsdio bluetooth ecdh_generic ecc brcmfmac brcmutil bcm2835_v4l2(CE) cfg80211 bcm2835_mmal_vchiq(CE) videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev snd_bcm2835(CE) mc snd_pcm snd_timer vc_sm_cma(CE) snd raspberrypi_hwmon rpivid_mem uio_pdrv_genirq uio sch_fq_codel drm ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_ce spidev phy_generic aes_neon_bs aes_neon_blk crypto_simd cryptd
[ 92.733247] CPU: 2 PID: 180 Comm: kworker/2:2 Tainted: G C E 5.4.0-1008-raspi #8-Ubuntu
[ 92.733252] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
[ 92.733273] Workqueue: events get_values_poll [raspberrypi_hwmon]
[ 92.733282] pstate: 60400005 (nZCv daif +PAN -UAO)
[ 92.733291] pc : rpi_firmware_transaction+0xd8/0x108
[ 92.733299] lr : rpi_firmware_transaction+0xd8/0x108
[ 92.733303] sp : ffff8000102fbc90
[ 92.733308] x29: ffff8000102fbc90 x28: ffff000074909800
[ 92.733316] x27: 0000000000000000 x26: ffff800010159008
[ 92.733323] x25: 0000000000001000 x24: ffff00007b252700
[ 92.733330] x23: ffff00007ca79dc0 x22: ffffb708d82cbda0
[ 92.733336] x21: ffff00007ca79dc0 x20: ffff00007c8e4080
[ 92.733342] x19: 00000000ffffff92 x18: 0000000000000000
[ 92.733349] x17: 0000000000000000 x16: 0000000000000000
[ 92.733355] x15: 0000000000000000 x14: 0000000000000000
[ 92.733361] x13: 0000000000000000 x12: ffffb708d833e000
[ 92.733367] x11: ffffb708d822c000 x10: 0000000000000000
[ 92.733374] x9 : ffff8000102fbc90 x8 : 6d6974206e6f6974
[ 92.733380] x7 : 0000000000000000 x6 : 0000000000000000
[ 92.733386] x5 : ffffb708d820a000 x4 : ffff8000102fc000
[ 92.733392] x3 : ffffb708d820a140 x2 : ffff00007ca79dc0
[ 92.733399] x1 : b8bb2ee8a7f3bf00 x0 : 0000000000000000
[ 92.733405] Call trace:
[ 92.733414] rpi_firmware_transaction+0xd8/0x108
[ 92.733422] rpi_firmware_property_list+0xb8/0x170
[ 92.733430] rpi_firmware_property+0x74/0x108
[ 92.733439] get_values_poll+0x48/0x148 [raspberrypi_hwmon]
[ 92.733448] process_one_work+0x1d0/0x430
[ 92.733454] worker_thread+0x54/0x4a0
[ 92.733462] kthread+0xfc/0x128
[ 92.733471] ret_from_fork+0x10/0x1c
[ 92.733476] ---[ end trace 4071726612ef60c4 ]---
[ 92.733495] hwmon hwmon0: Failed to get throttled (-110)
[ 95.333107] xhci_hcd 0000:01:00.0: Abort failed to stop command ring: -110
[ 95.356131] xhci_hcd 0000:01:00.0: Host halt failed, -110
[ 95.356138] xhci_hcd 0000:01:00.0: xHCI host controller not responding, assume dead
[ 95.363937] xhci_hcd 0000:01:00.0: HC died; cleaning up
[ 95.369618] xhci_hcd 0000:01:00.0: Timeout while waiting for setup device command
[ 95.370446] usb 1-1: USB disconnect, devi...

Status changed to 'Confirmed' because the bug affects multiple users.

I have managed to work around this bug by doing the following:

1) Using James Chambers unofficial 64-bit build
Moving to 64 bit gets things moving, but after a several minutes the host controller would eventually hangup on me. I can't help but wonder if some 32bit ints are being blown somewhere because of the big reported sizes

2) Add the quirk 'usb-storage.quirks=[yourdrivesVID]:[yourdrivesPID]:u' to cmdline.txt
This limits DMA scatter-gather operations (new in Pi4) and seemes to help, but I've not been able to conclusively establish how

3) Connect the Drobo to the USB2 port rather than USB3
This (after the previous two steps) the finally kept the device mounted and working - kinda...

4) On another computer (I used a Mac with extFS added) repartition the drive to have a 16Tb partition (rather than the normal ~70Tb)
I found that if the OS tried to address data above some big value (never did manage to tie it down), perhaps while partitioning(!), formatting or fsck-ing, it would hang-up. In my case I happen to have 15Tb currently loaded in my Drobo and so I tried a 16Tb partition, and that worked.

5) In cmdline.txt change 'fsck.mode=auto' to 'fsck.mode=force'
I have found that the drive is always perceived as dirty and potentially corrupt (even though it isn't) on mount, so by forcing a fsck I ensure that the drive will be usable on boot (although this does mean that a reboot will make some functions unavailable for several hours.

6) Make sure that the mount options include 'nofail' and a good device-timeout, I use 'x-systemd.device-timeout=15'
The nofail ensures boot can proceed even though the fsck will take hours to complete (I have set the services that need the drive to wait for the mount), and the timeout caters for a corner case.
If it helps, my mount options in fstab are: 'rw,suid,dev,exec,auto,nouser,async,relatime,nofail,x-systemd.device-timeout=15'

And there it is. A big Drobo workaround, stuck on USB2 speeds, constrained to fraction of potential capacity, and that takes several hours to become usable... but I've got a NAS that works.

Obviously, this is far from ideal. I would love this to get fixed. Hopefully this has given some hints as to where to look, and helped others in the meantime.