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
