Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Kalle Valo <kvalo@codeaurora.org>, Robert White <rwhite@pobox.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: long startup delay ath10k_pci known issue?
Date: Thu, 28 Feb 2019 22:23:54 +0100	[thread overview]
Message-ID: <5ec99b14c40a178b726313f5af7a166f4aed8e44.camel@sipsolutions.net> (raw)
In-Reply-To: <877edk1f6j.fsf@purkki.adurom.net> (sfid-20190228_093803_234305_61F241F7)

On Thu, 2019-02-28 at 10:37 +0200, Kalle Valo wrote:
> 
> > Is this long delay after module and firmware load some expected effect
> > that I need to code around or what?
> 
> Usually these 60 second (or it's multiply) delays are caused by kernel
> requesting a firmware image from user space but the corresponding user
> space component is not replying and kernel waits for the reply until it
> timeouts and continues. IIRC there's a kernel config option you can use
> to disable this feature, or you could also try to fix the user space.

Regardless though, fixing this will just make the race condition less
likely, not fix it.

Most wifi NICs these days will load firmware because they need to run
it, and they will typically have to load the firmware *before* they
register their wiphy/netdev. Due to technical considerations (built-in
drivers etc.) the firmware load pretty much has to happen
asynchronously.

As a result, modprobe will return before the netdev exists. Now, in your
case you likely have some sort of firmware problem like Kalle says,
which causes it to take an excessive amount of time, perhaps by calling
out to a userspace helper that doesn't work and thus doesn't answer
negatively?

However, the fact remains that you shouldn't assume that modprobe
returning means anything - the netdev will exists when that happens, and
you should trigger your networking startup on the event that says it
exists now.

johannes


  reply	other threads:[~2019-02-28 21:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-28  7:33 long startup delay ath10k_pci known issue? Robert White
2019-02-28  8:37 ` Kalle Valo
2019-02-28 21:23   ` Johannes Berg [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-02-28  7:26 Robert White

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ec99b14c40a178b726313f5af7a166f4aed8e44.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rwhite@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox