On Thu, 29 Jun 2017 16:00:32 -0700, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 3:53 PM, Jakub Kicinski > <jakub.kicinski@xxxxxxxxxxxxx> wrote: > > On Fri, 30 Jun 2017 00:50:03 +0200, Luis R. Rodriguez wrote: > >> On Thu, Jun 29, 2017 at 01:58:22PM -0700, Jakub Kicinski wrote: > >> > On Thu, 29 Jun 2017 21:44:55 +0200, Luis R. Rodriguez wrote: > >> > > > Since this swake_up() --> swake_up_all() reportedly *fixed* the one wake up > >> > > > issue it would seem this does queue [0]. That said, I don't see any simple tests > >> > > > tools/testing/selftests/swait but then again we don't have test for regular > >> > > > waits either... > >> > > > > >> > > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=195477 > >> > > > >> > > I should also note that the swake_up_all() should have only helped in cases where > >> > > 3 cards were used, as if only 2 were used that should have been covered by just > >> > > the swake_up(). Unless of course I hear otherwise by the reporter, Nicolas or > >> > > from Jakub. > >> > > >> > I was hitting this with 2 cards. > >> > >> Thanks! > >> > >> Thing is I'm not convinced the issue with 2 cards was the swake_up() Vs > >> swake_up_all() in this case though. Let's recall also the missing wake up on > >> errors! And the fact that netronome has optional firmware, which naturally can > >> fail. > >> > >> So could the issue with 2 cards instead of the miss of a wake up on error due > >> to batched requests ? If so then that still would not put blame on the > >> swake_up()! > > > > Sorry, that was during manual tests. I had the driver request the > > firmware with _nowait() without an uevent, > > Can you provide the output of > > grep CONFIG_FW_LOADER_USER_HELPER .config > > I'd like to see if CONFIG_FW_LOADER_USER_HELPER_FALLBACK was disabled. > Not to be confused with the CONFIG_FW_LOADER_USER_HELPER. > > When the uevent is not set its also known as "a custom fallback > mechanism" and by default that has set a timeout of > MAX_SCHEDULE_TIMEOUT, which means that even if the direct filesystem > lookup failed the fallback mechanism would be used and just sit and > wait for what seems to be forever until user input was provided. FWIW CONFIG_FW_LOADER=y CONFIG_FW_LOADER_USER_HELPER=y CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y # CONFIG_FW_CFG_SYSFS is not set > > and then after I manually > > wrote -1 to loading only one would get woken up. > > Great, this helps, so for those not familiar with the firmware sysfs > fallback mechanism: > > The relevant values one could use are: > > 1: Start a load, discarding any previous partial load. > 0: Conclude the load and hand the data to the driver code. > -1: Conclude the load with an error and discard any written data. > > So you are triggering a failure. And indeed I expect the patch I just > provided to be the one to fix your issue with 2 cards. Cool, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
