Closed chernetsov0 closed 4 years ago
@hadess and I want to note, that staying in D
for a few millis is normal for reading sensors, but not for hours. :wink: It never responded to my SIGKILL
, so it never left D
in those few hours.
I'm pretty sure that this is caused by the driver, though I wouldn't know, as I don't have that hardware at hand.
@hadess, any info I can provide to help? Also, is it possible to timeout such a call in any way or abort it? Or if the kernel blocks due to bad driver there is not much you can do?
I can't do anything about this, please contact the kernel driver developers about this. The iio-sensor-proxy is trivial usage of the input API they provide.
This bug is closely related to the #231, but I couldn't care less about the load average - I just want my suspend to work. :smiley:
The machine in question is HP Envy 4-1257sr and it happens to have the same ST LIS3LV02DL accelerometer as in the ProBooks from #231.
When I try to suspend, look what happens to the
/var/log/syslog
To add insult to injury, I'm unable to
kill -9
theiio-sensor-proxy
or to uninstall it via package manager, so it looks like it's in the uninterruptible sleep indefinitely. It has been a few hours since I issuedSIGKILL
and it's still there with the same PID.This accelerometer is probably only used to park the HDD heads during drops and is pretty pointless on my machine (I did the SSD swap). But it is pretty generic, so it may be used in other HP notebooks for screen rotation as well.
I guess it's a hardware fault, so the accelerometer won't respond to
is3lv02d_acpi_read
forever, a situation whichiio-sensor-proxy
handles in a manner Hachikō would be proud of. In this case it would probably be more graceful to timeout quite quickly or maybe blacklist the sensor for a while if it times out too many times in a row. Better loose autorotation in case of sensor failure then suspend/hibernate. And load average stays 2.0 while process is sleeping so maybe #231 had merit after all.