Cannot schedule installation on Gazelle with ArchLinux: failed to map sideband memory

[Phundrak]

Distribution (run cat /etc/os-release):

NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux-logo

Related Application and/or Package Version:

• aur/system76-firmware 1.0.32-1
• aur/system76-firmware-daemon 1.0.32-1

Issue/Bug Description:
When I try to schedule an installation of a firmware, be it the open or the proprietary firmware, I get the following error message:

$ sudo system76-firmware-cli schedule --open
system76-firmware: failed to download: failed to map sideband memory: Operation not permitted (os error 1)

This happens whether the argument --open or --proprietary are passed, even when only executing sudo system76-firmware-cli schedule.

Steps to reproduce (if you know):

Expected behavior:
I assume system76-firmware-cli should return a positive message about successfully scheduling the firmware upgrade.

Other Notes:
The System76 packages that are installed on my Gazelle are the two packages mentioned above, as well as aur/system76-dkms. The service system76-firmware-daemon.service is enabled and running:

$ systemctl status system76-firmware-daemon.service
● system76-firmware-daemon.service - System76 Firmware Daemon
     Loaded: loaded (/usr/lib/systemd/system/system76-firmware-daemon.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2022-04-13 03:18:54 CEST; 16min ago
   Main PID: 71145 (system76-firmwa)
      Tasks: 1 (limit: 38135)
     Memory: 880.0K
        CPU: 34ms
     CGroup: /system.slice/system76-firmware-daemon.service
             └─71145 /usr/lib/system76-firmware/system76-firmware-daemon

avril 13 03:18:54 leon systemd[1]: Started System76 Firmware Daemon.

The precise model is a 17″ gaze15 with an Nvidia 1650 Ti.

[GerardoGR]

@Phundrak thank you for raising this detailed issue. I had the same issue with my archlinux install with my gaze15 with Nvidia 1650. I found a workaround that worked for me based on this stackoverflow answer: https://stackoverflow.com/a/49138256

I worked around the problem by setting the iomem Kernelparameter to relaxed via Grub:

I have systemd-boot instead of grub so what I did in my /boot/loader/entries/Arch.conf was add the iomem=relaxed in my options, e.g

title Arch
linux /vmlinuz-linux
options root=/dev/vg-main/root iomem=relaxed ...
...

AFAIU the culprit is the mmap done to /dev/mem as done here: https://github.com/pop-os/system76-firmware/blob/master/src/sideband.rs#L28. I don't have the low-level expertise to know what exactly is done here, but maybe there is a different way to achieve the same without this iomem=relaxed option but that would be worthy to have it's own issue.

My only question here, and maybe @ahoneybun (from System76 support-team) can chip-in here, why is the latest available firmware version of the gaze15 is 2021-07-20_93c2809, I can see that there are more recent versions here like 2022-02-15.

[ahoneybun]

@GerardoGR the firmware version on that page does not reflect the latest for any model. The latest version will be shown in the Settings -> Firmware or the CLI tool.

[GerardoGR]

@ahoneybun thank you for the clarification!

[Phundrak]

@Phundrak thank you for raising this detailed issue. I had the same issue with my archlinux install with my gaze15 with Nvidia 1650. I found a workaround that worked for me based on this stackoverflow answer: stackoverflow.com/a/49138256

I worked around the problem by setting the iomem Kernelparameter to relaxed via Grub:

I have systemd-boot instead of grub so what I did in my /boot/loader/entries/Arch.conf was add the iomem=relaxed in my options, e.g

title Arch
linux /vmlinuz-linux
options root=/dev/vg-main/root iomem=relaxed ...
...

It seems this was the reason for the error I was getting when running system76-firmware-cli, this time it did schedule the firmware update, and it appeared to have updated the firmware successfully, but I’m still stuck with the proprietary firmware.

Should I make a separate issue, or should I post relevant logs here? (In any case, is there any log file I should look for or are screen photos alright?)