Skip to content

ALS sensor dead after resume #73

Open
Open
ALS sensor dead after resume#73

Description

@agx
agx
opened on Oct 30, 2025

On a Intel 13" (Intel(R) Core(TM) Ultra 7 155H) the ALS sensor is dead after the first/suspend resume making it pretty much unusable:

$ sudo linux/tools/iio/iio_generic_buffer -a --device-name als   
iio device number being used is 0
iio trigger number being used is 0
Enabling all channels
Enabling: in_intensity_both_en
Enabling: in_illuminance_en
Enabling: in_timestamp_en
/sys/bus/iio/devices/iio:device0 als-dev0
339.000000 339.000000 1761832980102457343 
339.000000 339.000000 1761832980903336181 
Disabling: in_intensity_both_en
Disabling: in_illuminance_en
Disabling: in_timestamp_en

Suspend and resume device:

$ sudo linux/tools/iio/iio_generic_buffer -a --device-name als  
iio device number being used is 0
iio trigger number being used is 0
Enabling all channels
Enabling: in_intensity_both_en
Enabling: in_illuminance_en
Enabling: in_timestamp_en
/sys/bus/iio/devices/iio:device0 als-dev0
^^^^ hangs here until CTRL-C is hit

Disabling: in_intensity_both_en
Disabling: in_illuminance_en
Disabling: in_timestamp_en

The same is reproducible with iio-sensor-proxy (I picked iio_generic_buffer as it requires less indirection)

dmidecode reports the Bios as Release Date: 08/08/2025 and fwupdmgr doesn't report any updates to install.

ectool says

$ sudo build/hx30/util/ectool version
RO version:    marigold-3.0.5-a5f07f8
RW version:    marigold-3.0.5-a5f07f8
Firmware copy: RO
Build info:    marigold-3.0.5-a5f07f8 2025-08-06 07:01:52 marigold1@ip-172-26-3-226
Tool version:  v0.0.1-f6620a8 2025-05-28 11:32:28 agx@quark

Activity

  1. JohnAZoidberg commented on Oct 30, 2025

    @JohnAZoidberg
    JohnAZoidberg
    on Oct 30, 2025
    Member

    What's your kernel and iio-sensor-proxy version?

    Does it work if you directly access it with framework_tool?
    https://github.com/FrameworkComputer/framework-system/blob/main/EXAMPLES.md#check-sensors

  2. agx commented on Oct 30, 2025

    @agx
    agx
    on Oct 30, 2025
    Author

    What's your kernel and iio-sensor-proxy version?

    iio-sensor-proxy 3.8 (but see the above reproducer with iio_generic_buffer). Kernel is 6.16.12.

    Going via /dev/cros seems to work:

    $ sudo target/debug/framework_tool --sensors
[sudo] password for agx: 
ALS:    6 Lux

    would be good to have the framework_tool in Debian (and thus its downstreams).

  3. JohnAZoidberg commented on Oct 31, 2025

    @JohnAZoidberg
    JohnAZoidberg
    on Oct 31, 2025
    Member

    Are there any related error messages in dmesg?

    The ALS Sensor works by the EC exposing an I2C HID interface.

    This is the first time I've seen this issue happen. It's been pretty solid so far

  4. agx commented on Oct 31, 2025

    @agx
    agx
    on Oct 31, 2025
    Author

    This is the dmesg from a suspend/resume cycle:

    [ 6072.081177] lockdown_is_locked_down: 2 callbacks suppressed
[ 6072.081180] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 6072.084399] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 6072.085802] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 6072.089682] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 6072.092818] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 6072.093774] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 6072.094705] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 6072.123452] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 6072.124401] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 6072.128275] wlp170s0: deauthenticating from 20:05:b6:ff:a3:27 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 6072.129615] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
[ 6072.656936] PM: suspend entry (s2idle)
[ 6072.660373] Filesystems sync: 0.003 seconds
[ 6072.768711] Freezing user space processes
[ 6072.770403] Freezing user space processes completed (elapsed 0.001 seconds)
[ 6072.770408] OOM killer disabled.
[ 6072.770410] Freezing remaining freezable tasks
[ 6072.771644] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 6072.771646] printk: Suspending console(s) (use no_console_suspend to debug)
[ 6072.845145] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 6072.941272] ACPI: EC: interrupt blocked
[ 6073.524096] ACPI: EC: interrupt unblocked
[ 6073.574871] pci 0000:00:08.0: Setting to D3hot
[ 6073.586947] pci 0000:00:0b.0: Setting to D3hot
[ 6073.607848] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/mtl_guc_70.bin version 70.44.1
[ 6073.621005] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
[ 6073.621007] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
[ 6073.621213] i915 0000:00:02.0: [drm] GT0: GUC: RC enabled
[ 6073.621661] i915 0000:00:02.0: [drm] GT1: GuC firmware i915/mtl_guc_70.bin version 70.44.1
[ 6073.621662] i915 0000:00:02.0: [drm] GT1: HuC firmware i915/mtl_huc_gsc.bin version 8.5.4
[ 6073.635461] i915 0000:00:02.0: [drm] GT1: GUC: submission enabled
[ 6073.635462] i915 0000:00:02.0: [drm] GT1: GUC: SLPC enabled
[ 6073.635579] i915 0000:00:02.0: [drm] GT1: GUC: RC enabled
[ 6073.644848] nvme nvme0: 22/0/0 default/read/poll queues
[ 6073.770028] mei_gsc_proxy 0000:00:16.0-0f73db04-97ab-4125-b893-e904ad0d5464: bound 0000:00:02.0 (ops i915_gsc_proxy_component_ops [i915])
[ 6073.771319] OOM killer enabled.
[ 6073.771321] Restarting tasks: Starting
[ 6073.772073] Restarting tasks: Done
[ 6073.772110] random: crng reseeded on system resumption
[ 6073.776090] PM: suspend exit
[ 6075.783856] wlp170s0: authenticate with 20:05:b6:ff:a3:27 (local address=dc:97:ba:b5:91:0e)
[ 6075.785409] wlp170s0: send auth to 20:05:b6:ff:a3:27 (try 1/3)
[ 6075.819285] wlp170s0: authenticated
[ 6075.819681] wlp170s0: associate with 20:05:b6:ff:a3:27 (try 1/3)
[ 6075.827116] wlp170s0: RX AssocResp from 20:05:b6:ff:a3:27 (capab=0x11 status=0 aid=2)
[ 6075.844053] wlp170s0: associated

    This is the first time I've seen this issue happen. It's been pretty solid so far

    Likely because most DEs don't unclaim the sensor. It seems stable if you keep the sensor claimed across suspend/resumed (e.g. have iio-sensor-proxy + monitor-sensor running). If the DE unclaims the sensor on e.g. screen blank (which we do in phosh) and don't have anything else claiming the sensor it seems to break (but works fine on e.g. the SDM845's sensor core on phones which suspends/resumes a ton more often).

  5. agx commented on Nov 2, 2025

    @agx
    agx
    on Nov 2, 2025
    Author

    The ALS Sensor works by the EC exposing an I2C HID interface.

    Interesting, reloading i2c_hid_acpi unbreaks after resume unbreaks things (until next suspend)

  6. JohnAZoidberg commented on Nov 2, 2025

    @JohnAZoidberg
    JohnAZoidberg
    on Nov 2, 2025
    Member

    Interesting findings!

    You're using phosh on the framework laptop?

    Why does it unclaim the sensor? Would that help with power consumption?

    Have you always seen this or could this be a regression with recent kernels?

  7. agx commented on Nov 2, 2025

    @agx
    agx
    on Nov 2, 2025
    Author

    You're using phosh on the framework laptop?

    Yes

    Why does it unclaim the sensor? Would that help with power consumption?

    Unclaiming the sensor when the screen is blanked saves battery by reducing wakeups

    Have you always seen this or could this be a regression with recent kernels?

    I only enabled it recently so I cannot tell.

  8. agx commented on Nov 2, 2025

    @agx
    agx
    on Nov 2, 2025
    Author
    #!/bin/sh

[ "$1" = "post" ] && [ "$2" = "suspend" ] || exit 0

echo "Working around broken ALS after resume on Framework 13"
rmmod i2c_hid_acpi 
modprobe i2c_hid_acpi

    in /usr/lib/systemd/system-sleep/framework13-als-workaround seems to reliably work around the issue.

  9. JohnAZoidberg commented on Nov 4, 2025

    @JohnAZoidberg
    JohnAZoidberg
    on Nov 4, 2025
    Member

    Can you try to downgrade to an earlier version of iOS sensor proxy?

    This seems like your issue
    https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/404#note_3099601

  10. agx commented on Nov 4, 2025

    @agx
    agx
    on Nov 4, 2025
    Author

    See how I wrote that the iio-buffer tools fail too. iio-sensor-proxy thus can't be at fault here as a suspend/resume must not break unrelated tools. It's a kernel problem (accidentally I'm one of iio-s-p upstreams).

  11. alecbcs commented on Nov 28, 2025

    @alecbcs
    alecbcs
    on Nov 28, 2025

    I'm also experiencing this issue on an AMD Framework 13 when using gnome-adaptive-brightness (issue linked above).

    @agx's workaround script works for me, but does cause a momentary dip in brightness as the extension reads a zero value a couple times before the module is reloaded. (Note to others: don't forget to make the script executable chmod ug+x <path> -- that caused me a couple minutes of debugging.)

    For reference I'm using Debian Unstable with kernel v6.17.9.

  12. JohnAZoidberg commented on Mar 2, 2026

    @JohnAZoidberg
    JohnAZoidberg
    on Mar 2, 2026
    Member

    Ok I can reproduce this issue, with iio_generic_buffer no, as well as FrameworkComputer/SoftwareFirmwareIssueTracker#179
    I found an issue in the EC firmware and I'm testing a patch.

  13. fain182 commented on May 1, 2026

    @fain182
    fain182
    on May 1, 2026

    Related report from a Framework 13 AMD (Ryzen 7040 series) running Fedora 44, kernel 6.19.14.

    On AMD, the issue manifests differently: the IIO buffer is silent from a fresh boot (not just after resume). The buffer driver in iio-sensor-proxy selects the buffer driver intermittently (sometimes is_buffer_usable() passes within 0.5s, sometimes not), but even when selected, the buffer produces data only once and then goes silent — causing LightLevel to freeze on the initial value under stable light conditions.

    Direct sysfs reads work correctly at all times:

    $ cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw
172   # updates correctly in real time

    But the IIO buffer (/dev/iio:device0) never produces continuous data, suggesting the EC firmware on AMD is not pushing buffer updates at regular intervals (only on the initial open, if at all).

    Workaround applied on our side: patched iio-sensor-proxy to skip the buffer driver for HID sensors and fall back to polling in_illuminance_raw directly. Details at https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/work_items/433

    Mentioned here by the iio-sensor-proxy maintainer. Happy to test a firmware patch if one becomes available for AMD.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions