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.deb...@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 -- Beautiful Sunny Winfield
