[Letux-kernel] accelerometer bridge madness

[H. Nikolaus Schaller]

> Am 27.07.2018 um 19:42 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Fri, 27 Jul 2018 19:08:37 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> 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.
> 
> Ok, retested with 0 and xxd, cpu usage is still ok.
> 
> I had even one boot where the accel was at event3 and not 5 or 6 and
> then it worked. Again these nasty initialization order things.

Yes...They are confusing. I am not sure if there is a CONFIG which makes
the deferred probing run in a well defined order (i.e. without parallelism).

But there can still be fluctuations since deferred probing may be triggered
by the time some external chip needs to ramp up power and/or clocks or
initialize itself.

> So
> automated testing is probably needed to have clearer results.
> 
>> 
>> 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...
>> 
>> 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.
>> 
> Probably not, every command I tested just hangs, it gets no data, so it
> will never be closed. Ok, checked where it hangs:
> open("/dev/input/event5", O_RDONLY)     = 3
> fstat64(3, {st_mode=S_IFCHR|0660, st_rdev=makedev(13, 69), ...}) = 0
> ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0xbe936a7c) = -1 EINVAL (Invalid argument) <-- well, it is no tty.
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f40000
> read(3,

could you copy the full strace incl. command?
Then I can try on my device and we can compare.

> 
> And again I have renamed /lib/udev/accelerometer.
> 
>> Another question: which rule makes /lib/udev/accelerometer run? 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()...
>> 
> root at gta04:/lib/udev# grep -R accelerometer *
> Binary file accelerometer-no matches
> rules.d/61-accelerometer.rules:SUBSYSTEM=="input", ACTION!="remove", ENV{ID_INPUT_ACCELEROMETER}=="1", IMPORT{program}="accelerometer %p"
> 
> 
>> AFAIK only uevents trigger udevd - but does /dev/input/event have an uevent?
>> 
> I have never seen anything like that.
> 
> Regards,
> Andreas
> 
> _______________________________________________
> 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/e28e5913/attachment.asc>