Issue with boot order probe after reboot

[nandorpal]

Describe the bug

Randomly after rebooting the rpi5, I can't access the pio.
I use it to control some leds, but randomly the the pi locks the driver out.
I noticed that if I check cat /sys/module/ws2812_pio_rp1/refcnt and gives me 1, for sure the leds and not even reboot or system update will work.
I tried with 6.12.75+rpt-rpi-2712, 6.18.29+rpt-rpi-2712

My firmware config

[all]
dtoverlay=ws2812-pio,gpio=10,num_leds=100
dtoverlay=dwc2,dr_mode=peripheral

Steps to reproduce the behaviour

Reboot, check cat /sys/module/ws2812_pio_rp1/refcnt
If it is 1 nothing will work, not even reboot.

Device (s)

Raspberry Pi 5

System

Raspberry Pi reference 2026-04-21
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 4ad56cc850fa60adcc7f07dc15879bc95cc1d281, stage2

2026/01/21 13:38:47
Copyright (c) 2012 Broadcom
version ab8a9dde (release) (embedded)

6.12.75+rpt-rpi-2712, 6.18.29+rpt-rpi-2712

Logs

No response

Additional context

No response

[pelwell]

Randomly after rebooting the rpi5, I can't access the pio.

There have been initialisation races around PIO and the RP1 mailbox driver, but I thought they were resolved in January (#7211 if you are curious). How frequently does this occur?

I noticed that if I check cat /sys/module/ws2812_pio_rp1/refcnt and gives me 1, for sure the leds and not even reboot or system update will work.

I don't understand what you are trying to say here.

[nandorpal]

There have been initialisation races around PIO and the RP1 mailbox driver, but I thought they were resolved in January
(#7211 if you are curious). How frequently does this occur?

About 30-40% of the time

I don't understand what you are trying to say here.

I tried to create a watchdog to monitor this behaviour, and noticed that whenever this output of is cat /sys/module/ws2812_pio_rp1/refcnt 1, nothing will work.

[nandorpal]

There have been initialisation races around PIO and the RP1 mailbox driver, but I thought they were resolved in January
(#7211 if you are curious). How frequently does this occur?

I read through that thread and tried that build, however it couldn't install it.

sudo rpi-update pulls/7215
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
FW_REV:
BOOTLOADER_REV:bf19070528db9ce435d4fbdcdc626807c38e6d3d
 *** We're running for the first time
 *** Backing up files (this will take a few minutes)
 *** Remove old firmware backup
 *** Backing up firmware
 *** Remove old modules backup
 *** Backing up modules 6.12.75+rpt-rpi-2712
WANT_32BIT:0 WANT_64BIT:1 WANT_64BIT_RT:0 WANT_PI4:1 WANT_PI5:1

Updating a system with initramfs configured is not supported by rpi-update.
If your system relies on drivers provided by the initramfs (e.g. custom filesystem options)
it may not boot without regenerating the initramfs.
If you are unsure, test if your system boots with initramfs options disabled from config.txt

Would you like to proceed? (y/N)

Downloading bootloader tools
Downloading bootloader images
 *** Downloading specific artifact revision (this will take a few minutes)
curl  -L https://builds.raspberrypi.com/github/linux/e75696024c791359ee4e5cc25844556e0c9d3ad9/bcmrpi | zcat | tar xf - -C //root/.rpi-firmware --strip-components=2
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:04 --:--:--     0

gzip: stdin: unexpected end of file
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:03 --:--:--     0
Invalid artifact specified. Response: 404.

[pelwell]

I'm not expecting you to try it - anything learnt from that will have been applied to the kernels you've tested. I'm just saying that you've found something new.

[nandorpal]

Ah okay, I thought it was a regression. Sorry for my babbling, and incoherency, I've been trying to find a solution for this for the last 12 hours, I have a client deadline tomorrow and I'm exhausted.

[pelwell]

Why have you not submitted any logs for the failure cases? dmesg -l err,warn would probably be sufficient.

[nandorpal]

Here's dmseg -l err,warn when I encountered the issue

[    0.413681] dwc2 1000480000.usb: supply vusb_d not found, using dummy regulator
[    0.413713] dwc2 1000480000.usb: supply vusb_a not found, using dummy regulator
[    3.748085] hci_uart_bcm serial0-0: supply vbat not found, using dummy regulator
[    3.748144] hci_uart_bcm serial0-0: supply vddio not found, using dummy regulator
[    6.086275] rp1-pio 1f00178000.pio: DMA wait timed out
[    7.110282] rp1-pio 1f00178000.pio: DMA wait timed out

[pelwell]

That is not the sort of error I was expecting - I don't think this is about probe order.

Am I right in thinking that you have an application attempting to use the LEDs immediately after boot? If so:

1. Try disabling the automatic start and running it manually, to see if that makes a difference. This is just for diagnostic purposes.
2. Can I see the source code to get a feel for what it is doing?

[nandorpal]

So what I have is the following:

1. For technical reasons I recieved an rpi5 that is not powered through USB c, but rather through PIN 2 & 6
2. The LEDs are the simplest ones for technical reasons and I am using GPIO 17 to deliver a high voltage. As far as I noticed the issue start when I'm trying to claim GPIO17 and set it to high:

[Unit]
Description=Claim GPIO 17 and hold HIGH
After=local-fs.target sysinit.target

[Service]
Type=simple
ExecStart=/usr/bin/gpioset -c 4 17=1
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

I tried other methods too, like building a C code snippet or a python script doing the same, but the end result is the same. The service either managed to claim GPIO17 and the LEDs start to work, or it fails and the system is locked, and I can't even reboot it.
3. I'm using another daemon service to run a GO binary which controls the LEDs using using /dev/leds0 to write 4 bit values.

Hope this helps, let me know if you need additional information.

[pelwell]

This sounds like an unusual configuration - the more information you can give me (such as the purpose of GPIO17), the quicker this might be resolved.

To hold a particular GPIO high (or low) for the lifetime of the kernel, it would be simpler to use a GPIO hog:

$ dtoverlay -h gpio-hog
Name:   gpio-hog

Info:   Activate a "hog" for a GPIO - request that the kernel configures it as
        an output, driven low or high as indicated by the presence or absence
        of the active_low parameter. Note that a hogged GPIO is not available
        to other drivers or for gpioset/gpioget.

Usage:  dtoverlay=gpio-hog,<param>=<val>

Params: gpio                    GPIO pin to hog (default 26)
        active_low              If set, the hog drives the GPIO low (defaults
                                to off - the GPIO is driven high)

In your case this would mean adding dtoverlay=gpio-hog,gpio=17 to config.txt.

The only reason this might not be such a good idea is if the timing of when the GPIO goes high matters, e.g. if you need to guarantee that some other setup has been performed. In this case, you could use the same overlay but apply it at runtime:

$ sudo dtoverlay gpio-hog gpio=17
$ gpioinfo | grep GPIO17
        line  17:       "GPIO17"                output consumer="hog"

[nandorpal]

I tried adding to the boot config,

 cat /boot/firmware/config.txt | grep hog
dtoverlay=gpio-hog,gpio=17

 gpioinfo | grep GPIO17
        line  17:       "GPIO17"                output consumer="hog"

it worked the same as before unfortunately.
GPIO17 is used to power a circuit board that powers the LEDs. I will try to use a low powered pin to see if that helps.

[pelwell]

There's a definite possibility that your external circuit is drawing too much power and upsetting RP1, leading to the DMA failures. Why can't you power it some other way?

[nandorpal]

So we are just currently sending a signal to the circuit board, it barely draws any power from the RPI, and I tried using pin 1, and removed any GPIO claims I had previously and I still get this DMA failure randomly.