[Letux-kernel] accelerometer bridge madness

H. Nikolaus Schaller hns at goldelico.com
Fri Jul 27 19:49:43 CEST 2018 

> Am 27.07.2018 um 19:19 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 27.07.2018 um 19:08 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> Hi,
>> 
>>> Am 27.07.2018 um 18:49 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> 
>>> Hi,
>>> 
>>> On Fri, 27 Jul 2018 16:58:08 +0200
>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> 
>>>>> 
>>>>> But I will first check how often open() is called.
>>>> 
>>>> Yes, that is the important thing. And when it is called. You might add some
>>>> printk to the probe function to identify the sequence.
>>>> 
>>> only one time! I moved away that /lib/udev/accelerometer thing
>>> and did xxd /dev/input/eventX after the boot fully finished.
>>> No accel_open() caused by udev anymore!
>>> So this is definitively not a race condition regarding the work struct
>>> (but of course that should be fixed).
>>> 
>>> I tested
>>> diff --git a/drivers/iio/industrialio-inputbridge.c b/drivers/iio/industrialio-inputbridge.c
>>> index bd5807f31767..77bd9bb352f7 100644
>>> --- a/drivers/iio/industrialio-inputbridge.c
>>> +++ b/drivers/iio/industrialio-inputbridge.c
>>> @@ -89,7 +89,7 @@ static int accel_open(struct input_dev *input)
>>> {
>>>      struct iio_dev *iiodev = input_get_drvdata(input);
>>> 
>>> -#if 0
>>> +#if 1
>>> printk("accel_open()\n");
>>> #endif
>>> 
>>> @@ -98,7 +98,7 @@ printk("accel_open()\n");
>>> 
>>> #if POLLING
>>>      schedule_delayed_work(&input_work,
>>> -               msecs_to_jiffies(0));   // start now
>>> +               msecs_to_jiffies(100)); // start now
>>> #else
>>>      int iio_channel_start_all_cb(struct iio_cb_buffer *cb_buff);
>>> #endif
>>> 
>>> 
>>> having the 100 there at least causes at least the cpu usage to be sane.
>> 
>> Ah, that could be part of the problem.
>> 
>> I have studied https://github.com/lu-zero/udev/blob/master/src/accelerometer/accelerometer.c
>> again and it looks as if it can even be called from the command-line...
> 
> I tried to cross-check if that is the real source code. It is.
> 
> I have found it here:
> 
> 	https://packages.debian.org/wheezy/udev
> 
> => download the source from
> 
> 	http://http.debian.net/debian/pool/main/u/udev/udev_175.orig.tar.bz2
> 
> => and navigate to udev-175/extras/accelerometer)
> 
> Interestingly, /lib/udev/accelerometer only exists in Wheezy! Not in Jessie or Stretch. Or did I miss something?
> 
> That may explain why I don't see issues since my test roots is usually Jessie.
> But I also didn't notice it when running QtMoko on Wheezy with earlier kernels.

No, I have now checked and it is installed on my Jessie system:

root at letux:~# ls -l /lib/udev
total 6500
-rwxr-xr-x 1 root root   22036 Apr  8  2017 accelerometer
-rwxr-xr-x 1 root root   17936 Apr  8  2017 ata_id
-rwxr-xr-x 1 root root   26132 Apr  8  2017 cdrom_id
-rwxr-xr-x 1 root root   13832 Apr  8  2017 collect
-rwxr-xr-x 1 root root    2284 Apr  8  2017 dsl-modem.agent
-rwxr-xr-x 1 root root     583 Feb 24  2015 hdparm
-rwxr-xr-x 1 root root    9736 Sep 13  2017 hid2hci
-rw-r--r-- 1 root root    1175 Apr  8  2017 hotplug.functions
-rwxr-xr-x 1 root root     776 Mar 29  2015 hwclock-set
-r--r--r-- 1 root root 6449966 Jul 25  2017 hwdb.bin
drwxr-xr-x 2 root root    4096 Jul 25  2017 hwdb.d
-rwxr-xr-x 1 root root     614 Apr  8  2017 logger.agent
-rwxr-xr-x 1 root root    5532 Apr  8  2017 mtd_probe
-rwxr-xr-x 1 root root    2297 Apr  8  2017 net.agent
-rw-r--r-- 1 root root    2899 Apr  8  2017 rule_generator.functions
drwxr-xr-x 2 root root    4096 Jul 10 07:12 rules.d
-rwxr-xr-x 1 root root   22548 Apr  8  2017 scsi_id
-rwxr-xr-x 1 root root     230 Apr  8  2017 udev-finish
-rwxr-xr-x 1 root root    5584 Apr  8  2017 v4l_id
-rwxr-xr-x 1 root root    4411 Apr  8  2017 write_net_rules
root at letux:~# dpkg-query -S /lib/udev/accelerometer
udev: /lib/udev/accelerometer
root at letux:~# dmesg|fgrep iio
[    8.048717] input: accelerometer-iio-input-bridge as /devices/virtual/input/input5
[    8.569373] iio_charge:0
root at letux:~# uname -a
Linux letux 4.18.0-rc6-letux+ #2567 SMP PREEMPT Fri Jul 27 10:10:47 CEST 2018 armv7l GNU/Linux
root at letux:~#

But not making trouble (neither on GT04 nor Pyra) with patched 4.18-rc6 kernel.

> 
>> 
>> What it does is to open the event device, read one value and close, then do its
>> calculations and return a value.
>> 
>> This means if this /lib/udev/accelerometer is called quickly we have a (very)
>> quick succession of calls to accel_open() and access_close(). Also with many
>> schedule_delayed_work() and cancels.
>> 
>> Another question: which rule makes /lib/udev/accelerometer run?

This one

root at letux:~# cat /lib/udev/rules.d/61-accelerometer.rules
# do not edit this file, it will be overwritten on update

SUBSYSTEM=="input", ACTION!="remove", ENV{ID_INPUT_ACCELEROMETER}=="1", IMPORT{program}="accelerometer %p"
root at letux:~#

But I don't understand what it is doing...


>> Is it being
>> run by every change of accelerometer? Then, there should be some mechanism
>> that waits for accelerometer changes, notifies udevd which then call
>> /lib/udev/accelerometer which does an accel_open()+read+close. So access events
>> could indirectly end in accel_open()...
>> 
>> AFAIK only uevents trigger udevd - but does /dev/input/event have an event?

Answer: yes

root at letux:~# find /sys -name input5
/sys/devices/virtual/input/input5
/sys/class/input/input5
root at letux:~# ls -l /sys/class/input/input5/
total 0
drwxr-xr-x 2 root root    0 Jul 27 17:34 capabilities
drwxr-xr-x 3 root root    0 Jul 27 17:23 event5
drwxr-xr-x 2 root root    0 Jul 27 17:23 id
-r--r--r-- 1 root root 4096 Jul 27 17:35 modalias
-r--r--r-- 1 root root 4096 Jul 27 17:23 name
-r--r--r-- 1 root root 4096 Jul 27 17:35 phys
drwxr-xr-x 2 root root    0 Jul 27 17:34 power
-r--r--r-- 1 root root 4096 Jul 27 17:35 properties
lrwxrwxrwx 1 root root    0 Jul 27 17:23 subsystem -> ../../../../class/input
-rw-r--r-- 1 root root 4096 Jul 27 17:23 uevent
-r--r--r-- 1 root root 4096 Jul 27 17:35 uniq
root at letux:~# cat /sys/class/input/input5/uevent
PRODUCT=0/0/0/0
NAME="accelerometer-iio-input-bridge"
PHYS="accel/input0"
PROP=0
EV=9
ABS=7
MODALIAS=input:b0000v0000p0000e0000-e0,3,kra0,1,2,mlsfw
root at letux:~#

But this seems to be static.


>> 
>>> 
>>> head->scratch();
>> 
>> for(i=1; i<10; i++) head->scratch();
>> 
>>> 
>>> ok, next step probably is to monitor input_work.
>> 
>> BR,
>> Nikolaus
>> 
>> _______________________________________________
>> http://projects.goldelico.com/p/gta04-kernel/
>> Letux-kernel mailing list
>> Letux-kernel at openphoenux.org
>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180727/d01f2704/attachment-0001.asc>

More information about the Letux-kernel mailing list