RPI4 mmc device fails without WITNESS option ?

[Søren Schmidt]

On 26 Apr 2020, at 09.36, Mark Millard <marklmi at yahoo.com> wrote:
> 
> Søren Schmidt soren.schmidt at gmail.com wrote on
> Fri Apr 24 09:58:09 UTC 2020 :
> 
>> Just wanted to check perf on a 4G RPI€ here, and without WITNESS in the kernel config it hangs:
>> CPU  1: ARM Cortex-A72 r0p3 affinity:  1
>> CPU  2: ARM Cortex-A72 r0p3 affinity:  2
>> CPU  3: ARM Cortex-A72 r0p3 affinity:  3
>> regulator: shutting down unused regulators
>> sdhci_bcm0-slot0: Controller timeout
>> sdhci_bcm0-slot0: ============== REGISTER DUMP ==============
>> sdhci_bcm0-slot0: Sys addr: 0x000000c8 | Version:  0x00001002
>> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt:  0x00000004
>> sdhci_bcm0-slot0: Argument: 0x01cf7fc1 | Trn mode: 0x00000036
>> sdhci_bcm0-slot0: Present:  0x1fff0a06 | Host ctl: 0x00000007
>> sdhci_bcm0-slot0: Power:    0x0000000f | Blk gap:  0x00000080
>> sdhci_bcm0-slot0: Wake-up:  0x00000000 | Clock:    0x00000107
>> sdhci_bcm0-slot0: Timeout:  0x00000003 | Int stat: 0x00000000
>> sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff0009
>> sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
>> sdhci_bcm0-slot0: Caps:     0x45ee6432 | Caps2:    0x0000a525
>> sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000
>> sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
>> sdhci_bcm0-slot0: ===========================================
>> mmcsd0: Error indicated: 1 Timeout
>> mmcsd0: Error indicated: 1 Timeout
>> mmcsd0: Error indicated: 1 Timeout
>> mmcsd0: Error indicated: 1 Timeout
>> mmcsd0: Error indicated: 1 Timeout
>> mountroot: waiting for device /dev/mmcsd0s2a...
>> Mounting from ufs:/dev/mmcsd0s2a failed with error 19.
>> 
>> With WITNESS enabled it just chuck along and boots..
> 
> After updating from head -r359427 to -r360311 (non-debug
> kernel), including u-boot.bin and FreeBSD loader.efi updates,
> I fairly frequently see such controller-timeout based
> mountroot failures.
> 
> So far I've found that using boot -v seems to make booting
> more reliable. But sometimes it boots without doing anything
> special. It may be that even just stopping it to manually
> type boot is more reliable. (Seems to be a timing-relationships
> based problem? It will probably take a lot more use to
> conclude if there really is an improvement.)
> 
> I've not tried a debug kernel.

So I’m not alone at least :), for me it hangs every time if WITNESS is disabled, verbose or not.
Maybe it depends on the SD card used, they are certainly not created equally…

> Side note: So far the EtherNet seems to be working when it
> does boot.

Yes, works without issue here as well (with WITNESS that is :) )

-Søren