[Letux-kernel] accelerometer bridge madness

Andreas Kemnade andreas at kemnade.info
Fri Jul 27 19:42:19 CEST 2018


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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180727/c6fd9763/attachment.asc>


More information about the Letux-kernel mailing list