regular warnings mmc1 timeout waiting for hardware cmd interrupt

[andrewufrank]

Is this the right place for my bug report?
Using a Debian installation from [https://raspi.debian.net/daily-images/] specifically [https://raspi.debian.net/daily/raspi_4_bullseye.img.xz] which uses the firmware from here, I hope the report is appropriate. I have not seen a similar error reported.

I have followed the advice to fix distributed images to boot from USB (thank you for the help!). I have to use the bullseye distribution, because the older ones do not allow dual monitor displays. bullseye does. once a desktop is installed, the warning is not visible and does not disturb; so far I have not seen a negative impact on the system.

Describe the bug
I get approximately every 10 seconds a warning: mmc1 warning timeout waiting for hardware cmd interrupt.
I have no SD card insterted (start on SSD with USB bridge).

Mar 28 13:40:39 romont kernel: [ 1481.461117] mmc1: Timeout waiting for hardware cmd interrupt.
Mar 28 13:40:39 romont kernel: [ 1481.463853] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
Mar 28 13:40:39 romont kernel: [ 1481.466906] mmc1: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
Mar 28 13:40:39 romont kernel: [ 1481.469956] mmc1: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
Mar 28 13:40:39 romont kernel: [ 1481.473005] mmc1: sdhci: Argument:  0x80000c08 | Trn mode: 0x00000000
Mar 28 13:40:39 romont kernel: [ 1481.476055] mmc1: sdhci: Present:   0x1fff0001 | Host ctl: 0x00000001
Mar 28 13:40:39 romont kernel: [ 1481.479104] mmc1: sdhci: Power:     0x0000000f | Blk gap:  0x00000080
Mar 28 13:40:39 romont kernel: [ 1481.482153] mmc1: sdhci: Wake-up:   0x00000000 | Clock:    0x0000f447
Mar 28 13:40:39 romont kernel: [ 1481.485202] mmc1: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
Mar 28 13:40:39 romont kernel: [ 1481.488251] mmc1: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
Mar 28 13:40:39 romont kernel: [ 1481.491300] mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
Mar 28 13:40:39 romont kernel: [ 1481.494350] mmc1: sdhci: Caps:      0x45ee6432 | Caps_1:   0x0000a525
Mar 28 13:40:39 romont kernel: [ 1481.497399] mmc1: sdhci: Cmd:       0x0000341a | Max curr: 0x00080008
Mar 28 13:40:39 romont kernel: [ 1481.500449] mmc1: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
Mar 28 13:40:39 romont kernel: [ 1481.503498] mmc1: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
Mar 28 13:40:39 romont kernel: [ 1481.506547] mmc1: sdhci: Host ctl2: 0x00000000
Mar 28 13:40:39 romont kernel: [ 1481.508650] mmc1: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
Mar 28 13:40:39 romont kernel: [ 1481.511699] mmc1: sdhci: ============================================

There shoul not be a warning (which interrupts using the system badly - is there a method to switch it off?)

To reproduce
I have added to the image downloaded the reset_raspberrypi module in the initramfs as per advice to achieve booting from an SSD.

Expected behaviour
boot without repeated warnings

Actual behaviour
regular warnings

System
Raspi 4,
Linux romont 5.10.0-5-arm64 #1 SMP Debian 5.10.24-1 (2021-03-19) aarch64 GNU/Linux
if you need more information, please indicate how to obtain it.

[pelwell]

Adding dtparam=sd_poll_once to config.txt will cause it to only scan once at boot time, with the obvious side effect that it will be necessary to reboot in order to use an SD card.

[andrewufrank]

I have added dtparam=sd_poll_once to /boot/firmware/config.txt and rebooted. I still have an entry in the syslog every 12 sec. (approx)
mmc1: Timeout waiting for hardware cmd interrupt.
what have I done wrong?
my system is: uname -a Linux romont 5.10.0-5-arm64 #1 SMP Debian 5.10.24-1 (2021-03-19) aarch64 GNU/Linux
thank you for advice!

[domolys]

Same for me, leaving the sd card slot empty is causing same entry

[trejan]

You're using a Debian image that is built with the upstream kernel instead of the RPT maintained kernel. It doesn't have any of the optional DT overlays like sd_poll_once so adding that config.txt line does nothing.

[andrewufrank]

thank you for the explanation of why the warning does not disappear. where can I find an image with the RPT maintained kernel? I downloaded the image from "Debian Tested Images".

[lurch]

where can I find an image with the RPT maintained kernel?

https://www.raspberrypi.org/software/operating-systems/#raspberry-pi-os-32-bit 😉

If you want to use Debian, then that's something you'll need to ask the Debian maintainers about. The source for the RPT maintained kernel is at https://github.com/raspberrypi/linux

[pelwell]

FYI there is a patch being upstreamed that provides a workaround to a hitherto unknown (to us) feature of the BCM2711 SDHCI controller. The size of an internal counter limits the ratio between the source clock and the SD bus clock that can be used safely. A 100kHz SD clock is apparently too slow with a 500MHz source clock, and a clock that slow is used if the card doesn't respond at 400kHz, which would be the case if no card is present.

[andrewufrank]

@pelwell - I guess the comment above is not for this bug?
any help with the repeated mmc1: Timeout waiting for hardware cmd interrupt.
where the dtparam=sd_poll_once parameter does not help. Is there a module I can add to the kernel?

[pelwell]

I guess the comment above is not for this bug?

Not exactly since it is for the EMMC2/SD controller, but it might be related since they are both Arasan cores.

[lurch]

I dunno much about DeviceTree, but maybe you can replicate whatever https://github.com/raspberrypi/linux/blob/rpi-5.10.y/arch/arm/boot/dts/bcm2711-rpi-4-b.dts#L627 is doing if you build your own kernel and/or dtb? 🤷 Or maybe you just need to wait for Debian to update their images with a kernel that supports this setting?

[vianpl]

We're trying to fix this issue in upstream Linux. Here's the explanation on what's happening: http://archive.lwn.net:8080/linux-kernel/CAOGqxeWzjn70A_gP4Eh_ZLW0H3KkE_wA7QzeGRqU1u7xtJr-+Q@mail.gmail.com/

There will hopefully be a fix available soon.

[andrewufrank]

i have the impression that the bug that sd_poll_once is not related to this timing issue. @pelwell fixed it for the bmc283x and the bmc2711. i cannot see if the package I have includes this patch; how could I check?

[pelwell]

@vianpl The upstream email thread is interesting, but it neglects the fact that the EMMC2 block has its own clock, independent of the core, that is set to 100MHz.

[andrewufrank]

I with to return to the original issue, the repeated mmc1 warning:
I have observed that the patch to insert the sd_poll_once dtparam is not in the raspi-firmware bmc2711-rpi-4-b.dtb for bullseye and threrfore it is not surprising that the dtparam does not have an effect. I tried to copy the new version from the linux project to the firmware project, but do not understand about the necessary conversion etc. What are the correct procedures to have this change arrive in the firmware used for bullseye? I pose this question in both, the firmware and the linux project, not knowing who should act. Thank you for help and clarification!

[lurch]

@andrewufrank As I mentioned before, if you're using an OS which isn't Raspberry Pi OS (available at https://www.raspberrypi.org/software/ ) then you'll need to ask whoever develops that distro to pull in whatever patches / fixes you're interested in.

[andrewufrank]

@lurch I understood your information, but I had the impression the project here is exactly to build OS which are not Raspberry Pi OS. The OS I use is, as much as I understand, built using the software from this page, thus asking the question here seems approriate. It is build with debootstrap and loads raspberry-firmware to go on to build a vanilla debian.

[bsmith76s]

has this issue been addressed? I am getting same message repeated.

[puccaso]

I can confirm. Currently seeing the same thing.
Mind you, i'm on the testing repo.

[  228.062011] mmc1: Timeout waiting for hardware cmd interrupt.
[  228.066605] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
[  228.071464] mmc1: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
[  228.076335] mmc1: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
[  228.081203] mmc1: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
[  228.086058] mmc1: sdhci: Present:   0x1fff0001 | Host ctl: 0x00000001
[  228.090904] mmc1: sdhci: Power:     0x0000000f | Blk gap:  0x00000080
[  228.095751] mmc1: sdhci: Wake-up:   0x00000000 | Clock:    0x0000f447
[  228.100596] mmc1: sdhci: Timeout:   0x00000000 | Int stat: 0x00000000
[  228.105456] mmc1: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
[  228.110311] mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[  228.115163] mmc1: sdhci: Caps:      0x45ee6432 | Caps_1:   0x0000a525
[  228.120006] mmc1: sdhci: Cmd:       0x00000502 | Max curr: 0x00080008
[  228.124835] mmc1: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
[  228.129643] mmc1: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
[  228.134417] mmc1: sdhci: Host ctl2: 0x00000000
[  228.138374] mmc1: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000
[  228.143160] mmc1: sdhci: ============================================

Puc

[pelwell]

A patch appeared in Linux 5.10.61 that may resolve this problem: raspberrypi/linux@2566c1d
It's included in the latest kernel releases, including the stable branch (sudo BRANCH=stable rpi-update). I think it just missed the most recent update to raspberrypi-kernel, but it shouldn't be long before that gets bumped too.

[puccaso]

Hello pelwell,

good stuff!

This is how I resolved the issue,

dtparam=sd_poll_once

puc.

[bsmith76s]

Hello pelwell,

good stuff!

This is how I resolved the issue,

dtparam=sd_poll_once

puc.

I tried this, did not resolve issue for me.

[Robbot]

The most simple method I could get rid of those annoying messages was to put an SD card into a slot after booting from the USB drive.

[agkirsanov]

Привет, Пелуэлл,

хорошая вещь!

Вот как я решил проблему,

dtparam = sd_poll_once

пак.
In which file did you write this parameter?

[pelwell]

Put it in config.txt, but without spaces (dtparam=sd_poll_once).