From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Nocera Subject: Re: Why hid-sensor-hub's IIO doesn't work properly in >= 4.3 (possibly badly bisected) Date: Thu, 02 Feb 2017 11:35:05 +0100 Message-ID: <1486031705.16399.1.camel@hadess.net> References: <1484927552.21721.17.camel@hadess.net> <1485869863.5845.54.camel@hadess.net> <4663686.yGs8knaWTY@aspire.rjw.lan> <1485993472.18380.73.camel@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <1485993472.18380.73.camel@linux.intel.com> Sender: linux-acpi-owner@vger.kernel.org To: Srinivas Pandruvada , "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , ACPI Devel Maling List , linux-iio@vger.kernel.org, linux-input@vger.kernel.org, Benjamin Tissoires , "Rafael J. Wysocki" , Richard Hughes List-Id: linux-input@vger.kernel.org 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 > > > 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.