* Regression in v4.15 due to GPIO .get_multiple changes
@ 2018-01-15 15:35 Clemens Gruber
2018-01-15 16:51 ` Lukas Wunner
0 siblings, 1 reply; 3+ messages in thread
From: Clemens Gruber @ 2018-01-15 15:35 UTC (permalink / raw)
To: linux-gpio; +Cc: Linus Walleij, Lukas Wunner, Bartosz Golaszewski
Hi,
I noticed a regression when testing the GPIOs on an i.MX6 with the
current v4.15-rc8 kernel.
When reading the input value of an internal GPIO, for example with
libgpiod's gpiod_line_get_value, strace shows that userspace blocks
indefinitely at:
ioctl(45, GPIOHANDLE_GET_LINE_VALUES_IOCTL
(The process consumes 100% CPU afterwards and can't be killed)
I looked at changes between v4.14 (working) and v4.15-rc8 (broken),
especially in drivers/gpio/gpio-{mxc,mmio}.c and identified the
following two commits to be responsible:
eec1d566cdf9 ("gpio: Introduce ->get_multiple callback")
80057cb417b2 ("gpio-mmio: Use the new .get_multiple() callback")
Reverting both of them (they are interdependent) fixed the problem.
I don't have a patch to fix it yet, but as it is rather late in the
development cycle of 4.15, I thought it better to report it now. The
author can probably cook up a fix way quicker or decide if you want to
revert.
If you can't reproduce it, let me know and I can send you ftrace
records, test your patches or try to come up with a solution myself.
Cheers,
Clemens
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Regression in v4.15 due to GPIO .get_multiple changes
2018-01-15 15:35 Regression in v4.15 due to GPIO .get_multiple changes Clemens Gruber
@ 2018-01-15 16:51 ` Lukas Wunner
2018-01-15 21:49 ` Clemens Gruber
0 siblings, 1 reply; 3+ messages in thread
From: Lukas Wunner @ 2018-01-15 16:51 UTC (permalink / raw)
To: Clemens Gruber; +Cc: linux-gpio, Linus Walleij, Bartosz Golaszewski
Hi Clemens,
thanks for reporting this and sorry for the breakage.
On Mon, Jan 15, 2018 at 04:35:48PM +0100, Clemens Gruber wrote:
> I noticed a regression when testing the GPIOs on an i.MX6 with the
> current v4.15-rc8 kernel.
>
> When reading the input value of an internal GPIO, for example with
> libgpiod's gpiod_line_get_value, strace shows that userspace blocks
> indefinitely at:
> ioctl(45, GPIOHANDLE_GET_LINE_VALUES_IOCTL
>
> (The process consumes 100% CPU afterwards and can't be killed)
>
> I looked at changes between v4.14 (working) and v4.15-rc8 (broken),
> especially in drivers/gpio/gpio-{mxc,mmio}.c and identified the
> following two commits to be responsible:
> eec1d566cdf9 ("gpio: Introduce ->get_multiple callback")
> 80057cb417b2 ("gpio-mmio: Use the new .get_multiple() callback")
>
> Reverting both of them (they are interdependent) fixed the problem.
They're not interdependent, the latter depends on the former but not
vice-versa. Hence, reverting only the latter should be sufficient.
Can you confirm this?
Looking at 80057cb417b2, the only possible cause I can imagine is that
the following somehow becomes an infinite loop. Can you insert a printk
to confirm this?
+ while ((bit = find_next_bit(mask, gc->ngpio, bit)) != gc->ngpio) {
+ if (gc->bgpio_dir & BIT(bit))
+ set_mask |= BIT(bit);
+ else
+ get_mask |= BIT(bit);
+ }
Is you platform big or little endian?
Thanks,
Lukas
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Regression in v4.15 due to GPIO .get_multiple changes
2018-01-15 16:51 ` Lukas Wunner
@ 2018-01-15 21:49 ` Clemens Gruber
0 siblings, 0 replies; 3+ messages in thread
From: Clemens Gruber @ 2018-01-15 21:49 UTC (permalink / raw)
To: Lukas Wunner; +Cc: linux-gpio, Linus Walleij
Hi Lukas,
On Mon, Jan 15, 2018 at 05:51:55PM +0100, Lukas Wunner wrote:
> Hi Clemens,
>
> thanks for reporting this and sorry for the breakage.
>
> On Mon, Jan 15, 2018 at 04:35:48PM +0100, Clemens Gruber wrote:
> > I noticed a regression when testing the GPIOs on an i.MX6 with the
> > current v4.15-rc8 kernel.
> >
> > When reading the input value of an internal GPIO, for example with
> > libgpiod's gpiod_line_get_value, strace shows that userspace blocks
> > indefinitely at:
> > ioctl(45, GPIOHANDLE_GET_LINE_VALUES_IOCTL
> >
> > (The process consumes 100% CPU afterwards and can't be killed)
> >
> > I looked at changes between v4.14 (working) and v4.15-rc8 (broken),
> > especially in drivers/gpio/gpio-{mxc,mmio}.c and identified the
> > following two commits to be responsible:
> > eec1d566cdf9 ("gpio: Introduce ->get_multiple callback")
> > 80057cb417b2 ("gpio-mmio: Use the new .get_multiple() callback")
> >
> > Reverting both of them (they are interdependent) fixed the problem.
>
> They're not interdependent, the latter depends on the former but not
> vice-versa. Hence, reverting only the latter should be sufficient.
> Can you confirm this?
Yes, that's right.
>
> Looking at 80057cb417b2, the only possible cause I can imagine is that
> the following somehow becomes an infinite loop. Can you insert a printk
> to confirm this?
Yes, this loop is the cause. I tried to initialize bit = -1; and pass
bit + 1 to find_next_bit but I see you already suggested a much better
solution in the meantime and discovered more bugs. Thanks for your help!
>
> + while ((bit = find_next_bit(mask, gc->ngpio, bit)) != gc->ngpio) {
> + if (gc->bgpio_dir & BIT(bit))
> + set_mask |= BIT(bit);
> + else
> + get_mask |= BIT(bit);
> + }
>
> Is you platform big or little endian?
Little endian.
Cheers,
Clemens
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-01-15 21:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-15 15:35 Regression in v4.15 due to GPIO .get_multiple changes Clemens Gruber
2018-01-15 16:51 ` Lukas Wunner
2018-01-15 21:49 ` Clemens Gruber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).