[Letux-kernel] accelerometer bridge madness
andreas at kemnade.info
Fri Jul 27 07:21:50 CEST 2018
On Wed, 25 Jul 2018 07:00:48 +0200
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> > Am 24.07.2018 um 22:26 schrieb Andreas Kemnade
> > <andreas at kemnade.info>:
> > Hi,
> >> BTW: did you see the kernel hickups also with evtest on the
> >> accelerometer?
> > [ 60.439422] ------------[ cut here ]------------
> > [ 60.444305] WARNING: CPU: 0 PID: 3140 at kernel/workqueue.c:1513
> > __queue_delayed_work+0xd8/0x13c
> So some list is not empty which should be. No idea why that happens...
> INIT_DELAYED_WORK(&input_work, inputbridge_work);
> should have initialized work->entry through
well, it is called *after* the device registration. So a there is a
condition. Not sure if that can be exploited.
> >> Maybe /lib/udev/accelerometer is slightly incompatible with kernel
> >> API and the iio-bridge doesn't catch such situations properly?
I also tried with my stretched partition, then I have a process named
systemd-udevd running. So there is no single binary to remove/rename.
Booting is again slowed down horribly, and also the time between kernel
switching off unused regulators (and therefore stops automatic
charging) and usb enumeration (when charging starts again). So this is
critical. Somehow I do not like a system where failed accelerometer
reads lead to boot problems. That is too fragile.
> > also plain reads are enough to get it, like a simple
> > xxd /dev/input/eventX.
> > Are you testing with A4 or A5?
> I have also looked into the code of the stack trace and could you
> please try to change accel_open() in
> #if POLLING
> msecs_to_jiffies(0)); // start now
> #if POLLING
> msecs_to_jiffies(1)); // start now
> Maybe immediately scheduling a delayed work ins't allowed in open()
> in some situations?
I even tried 100 and it did not help.
But what helps:
moving the initialisation of the workqueue to accel_open().
Then evtest works. But that can be dangerous if the device is opened
multiple times. Is the current code safe for that anyways? I guess not,
canceling the work should only happen at last close() and scheduling it
at the first open()
But somehow if initializing input_work earlier causes trouble then it
means it is damaged somehow. That all feels like memory corruption by a
random driver. So now what is the right printk to enable to
fix the problem ;-)
Well, nightmare ahead...
Maybe I should give the letux 3704 a torture night again so maybe we
know whether the problem is in common code or not.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Letux-kernel