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@hadess. > > > > > 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? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
