Re: Why hid-sensor-hub's IIO doesn't work properly in >= 4.3 (possibly badly bisected)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 2, 2017 at 1:42 PM, Bastien Nocera <hadess@xxxxxxxxxx> wrote:
> On Thu, 2017-02-02 at 12:33 +0100, Rafael J. Wysocki wrote:
>> On Thursday, February 02, 2017 11:35:05 AM Bastien Nocera wrote:
>> > On Wed, 2017-02-01 at 15:57 -0800, Srinivas Pandruvada wrote:
>> > > On Thu, 2017-02-02 at 00:38 +0100, Rafael J. Wysocki wrote:
>> > > > + Srinivas
>> > > >
>> > > > On Tuesday, January 31, 2017 02:37:43 PM Bastien Nocera wrote:
>> > > > >
>> > > > > Hey Rafael,
>> > > > >
>> > > > > On Fri, 2017-01-27 at 00:07 +0100, Rafael J. Wysocki wrote:
>> > > > > >
>> > > > > > On Thu, Jan 26, 2017 at 4:15 PM, Bastien Nocera <hadess@had
>> > > > > > ess.
>> > > > > > ne
>> > > > > > t>
>> > > > > > wrote:
>> > > > > > >
>> > > > > > > On Fri, 2017-01-20 at 16:52 +0100, Bastien Nocera wrote:
>> > > > > > > >
>> > > > > > > > Hey,
>> > > > > > > >
>> > > > > > > > TLDR:
>> > > > > > > > # first bad commit:
>> > > > > > > > [50ba22479c324c0d9dc8134d519dcba92d83a8a7]
>> > > > > > > > Merge
>> > > > > > > > back earlier ACPI PM material for v4.3.
>> > > > > > > >
>> > > > > > > > hid-sensor-hub devices only start sending events
>> > > > > > > > through
>> > > > > > > > the
>> > > > > > > > IIO
>> > > > > > > > trigger after a suspend/resume cycle.
>> > >
>> > >
>> > > > Srinivas, does it sound like anything familiar to you?
>> > >
>> > > I guess this is related to
>> > > https://github.com/hadess/iio-sensor-proxy/issues/82
>> > >
>> > > There is some race between user space and iio. So the driver
>> > > powerup
>> > > never gets called back to power a hub during system boot. So the
>> > > workaround was to add to systemd unit file for iio-sensor-proxy
>> > > [Unit]
>> > > After=multi-user.target
>> > >
>> > > Something changed timings in the kernel, which triggered this
>> > > issue.
>> >
>> > I don't think it's simply "timings", or at least it's a big enough
>> > window of opportunity that I can reproduce the bug 100% of the time
>> > when not adding timeouts to iio-sensor-proxy's timeout.
>> >
>> > Putting the machine on suspend and resuming it also fixes the
>> > problem
>> > (for a machine I've been testing that can be suspended, it's not an
>> > option for all of them).
>> >
>> > > I never got chance to root cause this.
>> >
>> > Well, at least the root cause is limited to a single commit, shame
>> > it's
>> > a merge one.
>>
>> In fact this is a merge that doesn't change any code by itself (I
>> thought it
>> did, but that was not correct), so if that had been more than
>> timings, you'd
>> have seen breakage on at least one of the merged branches.
>>
>> Moreover, it merges the commits under 3431e490b503 back on top of
>> material
>> that went into 4.2, so if you only see the problem in 4.3 and later,
>> this has to
>> be the 3431e490b503 branch.
>>
>> Can you double check 3431e490b503 alone, please?
>
> I don't understand what you're asking of me. I'm not a git master, and
> I've never had to deal with merge commits.
>
> Did you want me to run "git reset --hard 3431e490b503" and test the
> resulting kernel? I'm pretty sure that's equivalent what my 3 runs of
> bisection have done, and it failed.

I must have misunderstood you, sorry.

This means that the error is present in 3431e490b503, though, so
something on this branch had introduced it, most likely.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux