[Letux-kernel] accelerometer bridge madness

H. Nikolaus Schaller hns at goldelico.com
Fri Jul 27 21:40:10 CEST 2018


> Am 27.07.2018 um 19:49 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Fri, 27 Jul 2018 19:19:43 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>>> 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?
>> 
> wrong,
> udev is part of systemd on jessie.

Well, I have a jessie with no systemd. But still the tool exists.

> apt-get source udev will give you
> systemd-215/src/udev/accelerometer/accelerometer.c
> 
> But again, any program seems to be able to create trouble here.
> The only special thing here is that accelerometer.c does not use read()
> but ioctl() to read axis values:
> #define READ_AXIS(axis, var) { memzero(&abs_info, sizeof(abs_info)); r = ioctl(fd, EVIOCGABS(axis), &abs_info); if (r < 0) return; var = abs_info.value; }
> 
> So that may be the reason for 100%.
> 
>> That may explain why I don't see issues since my test roots is usually Jessie.
> 
> I am using jessie mostly, too.

But the fact that the strace is almost the same and a read() syscall hangs indicates
that it *is* a kernel issue and not a user-space problem.

BR,
Nikolaus


-------------- 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/e067924a/attachment.asc>


More information about the Letux-kernel mailing list