Bug 2283978

Proposed as a Blocker for 41-final by Fedora user lbrabec using the blocker tracking app because:

 Although we don't have a criterion for suspend, I'm proposing this as a blocker bug. I cannot login every time I keep Raspberry Pi idling for 15 minutes and I have to restart it, this could also lead to loss of data. This is something different compared to x86_64 situation since we support only handful of ARM boards. Also, suspend on Raspberry Pi OS is disabled.

Removing block, we don't block on HW features out of our control on x86, why we see the need to do this on arm is beyond me. PS you should probably also add the maintainer to these sorts of bugs so they're at least aware!

Hi Peter, I was the one who asked Lukas to file this and propose it, so I'll take the liberty of switching it back to the proposed state. There's a blocker discussion ticket here [1], can you please go there and voice your opinion, including your possible vote? Either there or here, I'd particularly like to know why you see this as a hw feature out of our control, when RaspPiOS is able to disable suspend for the device completely (on kernel level?), and there's also still an option to at least disable autosuspend in GNOME (e.g. Server does this). So, to me, it looks like there are some options available, and the current state, where out of the box you lose all your unsaved data and the device freezes every 15 minutes without user interaction, seems like extremely bad user experience. Thanks a lot.

[1] https://pagure.io/fedora-qa/blocker-review/issue/1607

Proper suspend (to s2idle) seems to be in the works:
https://www.phoronix.com/news/Suspend-To-Idle-Raspberry-Pi

But at least according to the article, the resume (and maybe even suspend) might need to be done through UART, so a common resume event by a USB device might not be available.

(In reply to Kamil Páral from comment #4)
> Proper suspend (to s2idle) seems to be in the works:
> https://www.phoronix.com/news/Suspend-To-Idle-Raspberry-Pi
> 
> But at least according to the article, the resume (and maybe even suspend)
> might need to be done through UART, so a common resume event by a USB device
> might not be available.

I was actually planning on updating the bug with details of that. I am cc:ed on the series, ATM it's only for RPi3/Zero2W and not yet RPi4. The older devices don't have PCIe and a bunch of other things that also need work.

The pieces through the UART are for the testing, eg there's still issues with USB.

I have a kernel I have built that I will be testing this. I don't think this will land in time for F-41, and then it won't be for the RPi4. So while this is a start of the work, we don't know how much is left to go.

Discussed during the 2024-08-19 blocker review meeting: [1]

The decision to classify this bug as a AcceptedBlocker (Beta) was made:

"This is accepted as a violation of 'All known bugs that can cause corruption of user data must be fixed or documented at Common Issues'. We note that fixing it may not be straightforward and it may have to be waived as hard to fix or documented and considered 'resolved' in that way."

[1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-08-19/f41-blocker-review.2024-08-19-15.59.log.html

To be clear, there's no expectation here that suspend on Pis is going to magically start working. The 'best practical' fix we envisioned was some kind of selective way to disable suspend entirely for Pis at the kernel level (so GNOME won't be able to try and suspend on them), or to disable autosuspend in GNOME for Pis. If that's not possible, documenting this as a common issue would resolve the blocker status.

I see the chances of upstream taking a "disable suspend for Pi" patch for kernel as very unlikely.

It actually occurs to me to wonder - can we do it with a udev rule? Carrying one custom udev rule downstream wouldn't be *too* onerous, if we remember to remove it if/when this ever actually works.

(In reply to Adam Williamson from comment #9)
> It actually occurs to me to wonder - can we do it with a udev rule? Carrying
> one custom udev rule downstream wouldn't be *too* onerous, if we remember to
> remove it if/when this ever actually works.

I think the fix would be to just not suspend when plugged into the power like we used to do.

The same issue occurs with the KDE spin on a Raspberry Pi 4.

We discussed this at the blocker meeting today, and some ideas came up:

fzatlouk: maybe something in arm-image-installer? it knows the board
conan kudo: technically udev rules can know too. I think at least with dt mode there's a procfs thing. not sure about tianocore/uefi mode
janne grunau: Systemd has platform integration for units and would know as well

> fzatlouk: maybe something in arm-image-installer? it knows the board

Well the RPi is all setup for boot and can be deployed with Fedora Media Writer, etcher, dd and a bunch of other tools so that would fix it for some users but would mean it's patchy.

> conan kudo: technically udev rules can know too. I think at least with dt
> mode there's a procfs thing. not sure about tianocore/uefi mode

Can know what? Can they provide some details here?

> janne grunau: Systemd has platform integration for units and would know as
> well

I think that's basically the same as udev above.

(In reply to Peter Robinson from comment #13)
> > fzatlouk: maybe something in arm-image-installer? it knows the board
> 
> Well the RPi is all setup for boot and can be deployed with Fedora Media
> Writer, etcher, dd and a bunch of other tools so that would fix it for some
> users but would mean it's patchy.

Yeah, I know it's surely not "the perfect" solution, but it'd resolve the blocker status here as (if I am not mistaken(!)) we block on raw images only when deployed via arm-image-installer.

> Yeah, I know it's surely not "the perfect" solution, but it'd resolve the
> blocker status here as (if I am not mistaken(!)) we block on raw images only
> when deployed via arm-image-installer.

We don't specify the deployment mechanism, it should ultimately make no difference.

It will also make support hell like because you end up in situations where the machine will act differently depending on how it's deployed which is not something is a good experience for users overall.

>> janne grunau: Systemd has platform integration for units and would know as
>> well

> I think that's basically the same as udev above.

It matches against compatible values from the devicetree top-level compatible string which would be an option to match against in udev as well. If disabling suspend in systemd directly would be more convenient it is possible to match Raspberry Pi 4s.

For matching `ConditionFirmware=device-tree-compatible("raspberrypi,4-model-b")' could be used (and "raspberrypi,400") for the Raspberry Pi 400. The compute module would be "raspberrypi,4-compute-module". It's possible that some compute module setup are capable of waking from suspend but I doubt it is the majority. 

https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#ConditionFirmware=

> when RaspPiOS is able to disable suspend for the device completely
> (on kernel level?), and there's also still an option to at least disable

Well RPiOS can disable it completely in the kernel as they support only their own devices. We obviously can't do that as it impacts aarch64 devices where suspend does work (eg a bunch of Allwinner, qcom devices etc).

> "This is accepted as a violation of 'All known bugs that can cause
> corruption of user data must be fixed or documented at Common Issues'. We
> note that fixing it may not be straightforward and it may have to be waived
> as hard to fix or documented and considered 'resolved' in that way."

So for Beta I would like to deal with this in common bugs documentation.

So I am (slowly, I have a LOT going on ATM) going through a bunch of suspend/resume stuff at the moment across aarch64 devices. There's a minor improvement in the RPi firmware [1] which fixes a bug in the SET_POWER_STATE interface which will allow the kernel to actually interface with the RPi firmware for suspend, but this needs upstream patches so it's not something we can likely land for F-41 as upstream is focusing on RPi3 and older ATM as rpi4 has other complexities like pcie, non USB NIC etc.

I am still looking for options how can stop the rpi4 advertising suspend.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-dbf55dbc52

Discussed during the 2024-09-12 Go/No-Go meeting: [1]

The decision to classify this bug as a RejectedBlocker (Beta) and AcceptedBlocker (Final) was made:

"This is waived under "Difficult to fix blocker bugs" at https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases , on the advice of the maintainers involved (see the bug for details)."

[1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-09-12/f41-beta-go-no-go.2024-09-12-17.03.log.html

As this is now documented as a common issue, its release blocker status under the criterion is resolved, since the criterion says "All known bugs that can cause corruption of user data must be fixed or documented at Common Issues". Unmarking as a blocker.