Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.

Hi Diederik,

This may not be the same bug. The one you referenced was provoked when the SD card slot was empty and could be suppressed by putting a card in the slot. Also that bug was fixed and the work around was no longer necessary. The one I experienced could happen with the SD card in place and at various times, the SD card would be recognized or would not be recognized (when a card was in place and the timeout was reported.) Let me clarify the situations I encountered while testing. Again, I performed testing while booting from a USB connected SSD.

* Normal boot, no timeout reported and SD card recognized.

* Timeout reported following boot and SD card recognized and working.

* Timeout reported and SD card not recognized.

Repeating the boot process could result in any of the three conditions and it did not seem to matter if a warm or cold boot was involved.

I have updated my test install to the 6.0 kernel, identified as

hbarta@boson:~$ uname -a
Linux boson 6.0.0-5-arm64 #1 SMP Debian 6.0.10-1 (2022-11-26) aarch64 GNU/Linux
hbarta@boson:~$

I rebooted and power cycled several times and was ready to declare this fixed, but the most recent reboot is den=monstrating the issue - e.g. MMC timeouts and no SD card in /dev. I inserted an SD card in the slot and the timeout messages are continuing after the card is initialized.

[ 274.788978] mmc1: new ultra high speed DDR50 SDHC card at address aaaa
[ 274.805432] mmcblk1: mmc1:aaaa SL16G 14.8 GiB
[ 274.837154] mmcblk1: p1 p2
[ 281.828861] mmc0: Timeout waiting for hardware cmd interrupt.
[ 281.836160] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 281.844122] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00009902
[ 281.852082] mmc0: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
[ 281.860026] mmc0: sdhci: Argument: 0x00000c00 | Trn mode: 0x00000000
[ 281.867973] mmc0: sdhci: Present:   0x01ff0001 | Host ctl: 0x00000001
[ 281.875905] mmc0: sdhci: Power:     0x0000000f | Blk gap: 0x00000000
[ 281.883839] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00007187
[ 281.891779] mmc0: sdhci: Timeout:   0x00000000 | Int stat: 0x00018000
[ 281.899716] mmc0: sdhci: Int enab: 0x00ff0003 | Sig enab: 0x00ff0003
[ 281.907658] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
[ 281.915602] mmc0: sdhci: Caps:      0x00000000 | Caps_1:   0x00000000
[ 281.923543] mmc0: sdhci: Cmd:       0x0000341a | Max curr: 0x00000001
[ 281.931481] mmc0: sdhci: Resp[0]:   0x00000000 | Resp[1]: 0x00000000
[ 281.939414] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]: 0x00000000
[ 281.947338] mmc0: sdhci: Host ctl2: 0x00000000
[ 281.953232] mmc0: sdhci: ============================================

I'm not sure if this matters, but when the timeouts are reported, orderly shutdown takes several minutes longer than normal but eventually completes.

best,

On Tue, Dec 6, 2022 at 6:10 PM Diederik de Haas <didi.debian@cknow.org> wrote:

Control: tag -1 moreinfo

Hi Hank,

On Tuesday, 13 September 2022 17:48:22 CET Hank Barta wrote:
> Package: src:linux
> Version: 5.19.6-1
>
> * What led up to the situation?
>
> Apparent inability to initialize/connect to the SD card H/W. This leads to
> the message below that is repeated about every 10s. It can manifest three
> ways.
>
> 1. Failure to boot - continuous retries to read SD card.
> 2. If a USB SSD is connected, it can skip the SD card and boot from the SATA
> SSD. (That is the coneition as I prepare this report.)
> 3. Completes boot, message repeats and there are no /dev/mmc* entries and
> WiFi H/W is not recognozed.
> 4. Completes boot, messages are repeated but /dev/mmc entries are present
> and can mount/read an SD card. And WiFi appears to be working
> 5. Completes boot, no SD card timeout messages are reported and system
> operates normally.
>
> ** Kernel log:
> [ 723.735217] mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00018000
> [ 723.741743] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003
> [ 723.748270] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
> [ 723.754797] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525
> [ 723.761324] mmc0: sdhci: Cmd: 0x00000502 | Max curr: 0x00080008
> [ 723.767851] mmc0: sdhci: Resp[0]: 0x000001aa | Resp[1]: 0x00000000
> [ 723.774379] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
> [ 723.780905] mmc0: sdhci: Host ctl2: 0x00000000
> [ 723.785404] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
> [ 723.791930] mmc0: sdhci: ============================================
> [ 733.923993] mmc0: Timeout waiting for hardware cmd interrupt.
> [ 733.929837] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> [ 733.936364] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
> [ 733.942892] mmc0: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
> [ 733.949420] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
> [ 733.955946] mmc0: sdhci: Present: 0x1fff0000 | Host ctl: 0x00000001
> [ 733.962473] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080
> [ 733.969001] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000fa07
> [ 733.975528] mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00018000
> [ 733.982055] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003
> [ 733.988582] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000001
> [ 733.995109] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525
> [ 734.001636] mmc0: sdhci: Cmd: 0x00000502 | Max curr: 0x00080008
> [ 734.008163] mmc0: sdhci: Resp[0]: 0x000001aa | Resp[1]: 0x00000000
> [ 734.014689] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
> [ 734.021216] mmc0: sdhci: Host ctl2: 0x00000000
> [ 734.025716] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
> [ 734.032242] mmc0: sdhci: ============================================

The title of this bug and the above quoted part of the kernel log seems to be
the same as the problem reported in https://bugs.debian.org/985630.

Do you agree?
Does that make this bug the same as the other one (and should therefor be
merged)? The main reason I'm hesitant to merge them is that both bugs also
describe other issues.
While the repeated messages aren't 'nice', they itself are harmless AFAICT.
But what you further described is more then just harmless.

Can you clarify? And while you're at it, also tell us whether the issue is the
same or resolved or worse with f.e. a 6.0 kernel? It would be great if you
could also try it with the 6.1-rcX kernel from Experimental.

Cheers,
Diederik