On Wed, Dec 18, 2013 at 08:45:46PM +0100, Sander Eikelenboom wrote:

Wednesday, December 18, 2013, 8:43:28 PM, you wrote:

quoted

On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote:

quoted

Wednesday, December 18, 2013, 10:26:25 AM, you wrote:

quoted

Hi all,

quoted

We really should be asking Luis to look at this who hasn't yet chimed
in, presumably because he's between jobs (and travelling IIRC)

quoted

On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote:

quoted

On 12/17/2013 11:06 PM, Linus Torvalds wrote:

quoted

We have literally had this *exact* same issue with firmware loading.
Network drivers shouldn't try to load firmware at module load time.
Same deal.

It is kind of a chicken and egg problem for (wireless) networking
drivers. To get IFF_UP from the network layer you have to register a
netdevice. For wireless drivers this means you have to register a wiphy
device with cfg80211 which flags capabilities and optionally are custom
regulatory domain. That information depends on the device and firmware
used. And there we have a full circle.

quoted

This is all really beside the point.

quoted

For this CRDA information, the kernel never actually *waits* for it, so
in the case that there's no reply, it uses the built-in world domain. So
it's not like request_firmware(), which will block boot forever, but
it's also not like request_firmware_nowait() which will eventually time
out and come back with an error if userspace isn't handling it (though
now that firmware loading is built in ...)

quoted

The issue is that it uses the built-in data *forever*, and what Sander
said was "or it will block forever" but just meant that it never was
able to do any further updates.

quoted

It *doesn't* actually block the boot process or such. Everything Linus
said is true but seems to have been written in understanding "blocks" as
"blocking the boot process", rather than "blocking further updates".

quoted

Regardless of this, even blocking further updates is a really bad idea.
There are a few ways to handle this, but I'll let Luis poke at that.

Your description is correct, sorry if I was not clear.

quoted

We have a timeout handler for this, I'll check to see what's going on
by trying to reproduce on my end. Are you using wireless-testing ?

Originally 3.13-rc4, after that i tried with 3.13-rc4 with wireless-next pulled on top of it
(since there were major changes to reg.c) but the problem occurs with both.

OK I can reproduce and am working on the cleanest solution. Thanks for
your report, I'll Cc ya when I have something reasonable baked up,
hopefully rather soon!

  Luis