RPI 4 4G ssd usb boot

[douxyeti]

I successfully updated bootloader to pieeprom-2020-05-26.bin and I am now able to boot from an ADATA SD
Q external SSD.

All is good except that I regularly get mmc0: Timeout waiting for hardware cmd interrupt. It does not seems to affect to much the PI operation other than slowing down some scripts.

Any help would be greatly appreciated



==> /var/log/kern.log <==
Jun 5 09:34:34 cnat kernel: [ 76.647516] mmc0: Timeout waiting for hardware cmd interrupt.
Jun 5 09:34:34 cnat kernel: [ 76.647521] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
Jun 5 09:34:34 cnat kernel: [ 76.647527] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
Jun 5 09:34:34 cnat kernel: [ 76.647531] mmc0: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
Jun 5 09:34:34 cnat kernel: [ 76.647535] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
Jun 5 09:34:34 cnat kernel: [ 76.647539] mmc0: sdhci: Present: 0x1fff0001 | Host ctl: 0x00000001
Jun 5 09:34:34 cnat kernel: [ 76.647543] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080
Jun 5 09:34:34 cnat kernel: [ 76.647547] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
Jun 5 09:34:34 cnat kernel: [ 76.647550] mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
Jun 5 09:34:34 cnat kernel: [ 76.647554] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003
Jun 5 09:34:34 cnat kernel: [ 76.647558] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
Jun 5 09:34:34 cnat kernel: [ 76.647562] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525
Jun 5 09:34:34 cnat kernel: [ 76.647566] mmc0: sdhci: Cmd: 0x0000371a | Max curr: 0x00080008
Jun 5 09:34:34 cnat kernel: [ 76.647569] mmc0: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000
Jun 5 09:34:34 cnat kernel: [ 76.647573] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
Jun 5 09:34:34 cnat kernel: [ 76.647576] mmc0: sdhci: Host ctl2: 0x00000000
Jun 5 09:34:34 cnat kernel: [ 76.647580] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
Jun 5 09:34:34 cnat kernel: [ 76.647583] mmc0: sdhci: ============================================
Jun 5 09:34:44 cnat kernel: [ 86.668230] mmc0: Timeout waiting for hardware cmd interrupt.
Jun 5 09:34:44 cnat kernel: [ 86.668235] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
Jun 5 09:34:44 cnat kernel: [ 86.668241] mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00001002
Jun 5 09:34:44 cnat kernel: [ 86.668245] mmc0: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000
Jun 5 09:34:44 cnat kernel: [ 86.668249] mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
Jun 5 09:34:44 cnat kernel: [ 86.668253] mmc0: sdhci: Present: 0x1fff0001 | Host ctl: 0x00000001
Jun 5 09:34:44 cnat kernel: [ 86.668257] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000080
Jun 5 09:34:44 cnat kernel: [ 86.668261] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x0000f447
Jun 5 09:34:44 cnat kernel: [ 86.668264] mmc0: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
Jun 5 09:34:44 cnat kernel: [ 86.668268] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003
Jun 5 09:34:44 cnat kernel: [ 86.668272] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
Jun 5 09:34:44 cnat kernel: [ 86.668276] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525
Jun 5 09:34:44 cnat kernel: [ 86.668280] mmc0: sdhci: Cmd: 0x0000371a | Max curr: 0x00080008
Jun 5 09:34:44 cnat kernel: [ 86.668283] mmc0: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000
Jun 5 09:34:44 cnat kernel: [ 86.668287] mmc0: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000
Jun 5 09:34:44 cnat kernel: [ 86.668290] mmc0: sdhci: Host ctl2: 0x00000000
Jun 5 09:34:44 cnat kernel: [ 86.668294] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000
Jun 5 09:34:44 cnat kernel: [ 86.668297] mmc0: sdhci: ============================================

[ygator]

Same with network boot for me with no sd card and get these messages every 10-12 seconds. I can only get it to stop by inserting an sd card, but it will return if it is later removed. It causes dmesg output to become saturated with these messages. From what I can tell I no longer reference the sd card as my cmdline.txt is
console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=1.2.3.4:/nfs/rpi4,vers=4.1,proto=tcp rw ip=dhcp rootwait elevator=deadline
and my /etc/fstab is
proc /proc proc defaults 0 0

This is running on an rpi 4 8gb.

[RonR]

Do you have a UART enabled in /boot/config.txt (enable_uart=1)?

If so, disabling it may eliminate this behavior (it does here).

[W. H. Heydt]

The system is polling the SD card interface to see if one is there. If you want stop that, add the following to /boot/config.txt:

Code: Select all

# Stop polling SD card that isn't there.
dtparam=sd_poll_once

[RonR]

The system is polling the SD card interface to see if one is there. If you want stop that, add the following to /boot/config.txt:

Code: Select all

# Stop polling SD card that isn't there.
dtparam=sd_poll_once

Wrong answer.

[dickon]

Other than filling dmesg with junk (which is annoying), it's harmless. It'll add ~1 to your load average, but that's due to a kernel process stuck in D state, which is normal for stuck IO tasks, and it isn't actually using any CPU:

Code: Select all

root@pi4:~# ps -auxwww | grep '\sD '
root     20170  0.0  0.0      0     0 ?        D    09:02   0:00 [kworker/0:0+events_freezable]

and top's top lines:

Code: Select all

top - 09:23:04 up  9:31,  1 user,  load average: 1.00, 0.81, 0.45
Tasks: 110 total,   1 running, 109 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.3 us,  0.4 sy,  0.0 ni, 99.1 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :   1673.5 total,    268.1 free,     76.2 used,   1329.1 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   1520.5 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND   
  231 root      20   0   33644   5620   4752 S   0.3   0.3   0:04.48 systemd-j+
20170 root      20   0       0      0      0 D   0.3   0.0   0:00.72 kworker/0+
20649 root      20   0   10100   2812   2460 R   0.3   0.2   0:00.15 top       
20650 root      20   0    9380   2088   1772 S   0.3   0.1   0:00.01 cron      
    1 root      20   0   32640   6664   5096 S   0.0   0.4   0:07.67 systemd   
    2 root      20   0       0      0      0 S   0.0   0.0   0:00.08 kthreadd  
    3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp    
    4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par_gp
    6 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/0+

[ygator]

Do you have a UART enabled in /boot/config.txt (enable_uart=1)?

I sure did.

If so, disabling it may eliminate this behavior (it does here).

It does so here as well. Last line printed is: [ 36.314670] vcc-sd: disabling
and then no more sd card messages every 10-12 seconds. Inserting an sd card functions as normal still and after removing the messages do not return.

Thank you very much.

[ygator]

and then no more sd card messages every 10-12 seconds. Inserting an sd card functions as normal still and after removing the messages do not return.

I spoke too soon. It does come back, but just not as often.
[ 495.839405] mmc0: Timeout waiting for hardware cmd interrupt.
[ 570.080815] mmc0: Timeout waiting for hardware cmd interrupt.
[ 627.041634] mmc0: Timeout waiting for hardware cmd interrupt.
[ 637.281750] mmc0: Timeout waiting for hardware cmd interrupt.
[ 647.521877] mmc0: Timeout waiting for hardware cmd interrupt.
After that it appears to repeat every ~10-15 seconds or longer.

I guess the only way to stop it completely is to insert an sd card.

[Fedebolo]

it happens to me too, some news?

[RonR]

it happens to me too, some news?

Any 'news' will most likely have to come in the form of a software update of some sort.

[ygator]

I network boot and have no sd card in a Rpi3B and do not get the messages.

Could they have left something enabled in the bootloader on the Rpi4 causing this?

[dpeltola]

The system is polling the SD card interface to see if one is there. If you want stop that, add the following to /boot/config.txt:

Code: Select all

# Stop polling SD card that isn't there.
dtparam=sd_poll_once

Wrong answer.

Why is this wrong answer? It seems to work brilliantly.

[RonR]

The system is polling the SD card interface to see if one is there. If you want stop that, add the following to /boot/config.txt:

Code: Select all

# Stop polling SD card that isn't there.
dtparam=sd_poll_once

Wrong answer.

Why is this wrong answer? It seems to work brilliantly.

Because it simply masks (hides) the problem instead of fixing it, leaving the SD card slot unusable in the process.

[gegeweb]

Hi,

Because it simply masks (hides) the problem instead of fixing it, leaving the SD card slot unusable in the process.

Is there a solution to solve this problem without keeping the SD card in the slot?

The solutions found on this forum or elsewhere apply for Pi3 but not for Pi4.

So I changed the boot order and keep original SD Card in the slot:

Code: Select all

sudo -E rpi-eeprom-config --edit

Change

Code: Select all

BOOT_ORDER=0xf41

to

Code: Select all

BOOT_ORDER=0xf14

which means boot usb first and boot SD card if the USB boot fails and try again in this order otherwise.

Save the file.

Code: Select all

$ rpi-eeprom-config 

[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
TFTP_IP=
TFTP_PREFIX=0
BOOT_ORDER=0xf14
[none]
FREEZE_VERSION=0

and reboot

Code: Select all

$ sudo reboot

That will boot on the USB device event if there is the SD card in the slot.
So no need to disable the slot.

If there is enough space on the SD card it can be used to make regular backups of the system with rpi-clone.

[RonR]

Hi,

Because it simply masks (hides) the problem instead of fixing it, leaving the SD card slot unusable in the process.

Is there a solution to solve this problem without keeping the SD card in the slot?

The solutions found on this forum or elsewhere apply for Pi3 but not for Pi4.

So I changed the boot order and keep original SD Card in the slot:

Code: Select all

sudo -E rpi-eeprom-config --edit

Change

Code: Select all

BOOT_ORDER=0xf41

to

Code: Select all

BOOT_ORDER=0xf14

which means boot usb first and boot SD card if the USB boot fails and try again in this order otherwise.

Save the file.

Code: Select all

$ rpi-eeprom-config 

[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
TFTP_IP=
TFTP_PREFIX=0
BOOT_ORDER=0xf14
[none]
FREEZE_VERSION=0

and reboot

Code: Select all

$ sudo reboot

That will boot on the USB device event if there is the SD card in the slot.
So no need to disable the slot.

If there is enough space on the SD card it can be used to make regular backups of the system with rpi-clone.

I also use BOOT_ORDER=0xf14. I keep a fully operational SD card inserted which I can boot to in an emergency should there be a problem booting the USB device.

[HawaiianPi]

Because it simply masks (hides) the problem instead of fixing it, leaving the SD card slot unusable in the process.

Your answer is also wrong (or perhaps incomplete and misleading would be more accurate).

With dtparam=sd_poll_once the SD card slot is polled (once) and if no card is present the slot is disabled, but if a card IS present, it's mounted as non-removable storage. So the SD card slot is usable for storage (just not hot-swappable). I often (but not always) leave a card in the slot of my USB booted systems as storage for backing up scripts, configuration files and other data.

In addition, use of dtparam=sd_poll_once does not prohibit changing the boot order and leaving a boot SD card in the slot (that still works as intended). It just means that leaving a card in the system is optional (with the understanding that without the card there is no failover boot).

That will boot on the USB device event if there is the SD card in the slot.
So no need to disable the slot.

Except that without a card, you're back to that annoying polling.

As I said above, dtparam=sd_poll_once only disables the slot if it's empty at boot time. If there is a card in the system, it is usable for system backups, but you don't need a card in the system to avoid unnecessary polling.

[RonR]

Because it simply masks (hides) the problem instead of fixing it, leaving the SD card slot unusable in the process.

Your answer is also wrong (or perhaps incomplete and misleading would be more accurate).

Only if you quote a single sentence out of context more than four months later.

With dtparam=sd_poll_once the SD card slot is polled (once) and if no card is present the slot is disabled

Very true. That's the condition that relates to "leaving the SD card slot unusable in the process."

but if a card IS present, it's mounted as non-removable storage. So the SD card slot is usable for storage (just not hot-swappable).

Auto-mounting occurs only with Desktop (not Lite) versions of RaspiOS and the SD card is recognized as a removable device that can be ejected and changed. The auto-mounting is a function of File Manager (which can be turned off) and is unrelated to dtparam=sd_poll_once.

In addition, use of dtparam=sd_poll_once does not prohibit changing the boot order and leaving a boot SD card in the slot (that still works as intended). It just means that leaving a card in the system is optional (with the understanding that without the card there is no failover boot).

Was this ever in doubt?

[soundcheck]

Just stepped over this thread while looking for how to turn off mmc0/SD-card while booted
from USB ssd.

dtparam=sd_poll_once

This seems to work nicely. And most important to me. The mmc0 related IRQ flooding stops.

Thx for the hints.