ALS sensor dead after resume

[agx]

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

[JohnAZoidberg]

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

[agx]

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).

[JohnAZoidberg]

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

[agx]

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).

[agx]

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)

[JohnAZoidberg]

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?

[agx]

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.

[agx]

#!/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.

[JohnAZoidberg]

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

[agx]

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).

[alecbcs]

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.

[JohnAZoidberg]

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.