| Message ID | 19210260274.20131216135644@eikelenboom.it (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Hi Sander, On Mon, Dec 16, 2013 at 11:56 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > > Monday, December 16, 2013, 12:37:47 PM, you wrote: > >> On 12/16/2013 12:22 PM, Sander Eikelenboom wrote: >>> >>> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: >>> >>>> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >>>> <linux@eikelenboom.it> wrote: >>>>> >>>>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >>>>> >>>>>> The best way to address all this is by automatic region awareness and >>>>>> doing the right thing on devices, this however requires good >>>>>> architecture / calibration data / etc and all that needs to be >>>>>> verified by the system integrators, and finally they need to be >>>>>> certified. If you want to hack your firmware and software go at it, >>>>>> just be aware there are reasons for things. >>>>> >>>>> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >>>>> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >>> >>>> Its simply stupid to have the user be involved, period, the fact that >>>> a user would be involved should only be for testing or helping >>>> compliance for a busted device, development, research and obviously >>>> hacking. Linux allows all these but by default a device with firmware >>>> and a custom regdomain that will barf if you try to use a channel that >>>> is not allowed is a restriction in firmware. Feel free to reverse >>>> engineer that if you don't like it but it just won't be supported or >>>> go upstream. Now, the common denominator is generally optimized for >>>> best performance as well so you shouldn't have to do anything, and for >>>> APs -- this is typically carefully crafted for a region, also highly >>>> optimized. >>> >>>>>>>> It doesn't seem like you are getting your original requests getting >>>>>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>>>>> from CRDA code: >>>>>>> >>>>>>> They don't get processed unless i remove the return from the code as i indicated. >>>>>>> If i remove that return it processes the request. >>>>>>> >>>>>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>>>>> >>>>>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>>>>> the dump seems fine. >>>>> >>>>>> OK thanks. Can you send a patch of what exact change you made, it was >>>>>> unclear from the paste you made. >>>>> >>>>>> diff -u file.c.orig file.c >>>>> >>>>> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >>>>> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >>>>> >>>>> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >>>>> probably due to those firmware restrictions. >>> >>>> Its unclear what results you got, and yeah if the device is restricted >>>> then its just the fw telling the driver its channels and you can't use >>>> them. That's it. You won't be able to override information then unless >>>> you hack the firmware >>> >>> Ping ? >>> >>> Is there anymore information you need to *fix* the problem ? > >> Maybe you did not get the essence of the response from Luis: There is >> *no* problem to be fixed. > > *sigh* .. > > Let's start from scratch then ... > > > a) Isn't the point of the whole regulatory domain system that i can select (and restrict) the channels/frequencies my devices transmits on, so i can abide the law ? > b) If so, does it set a regulatory domain from firmware ? > c) If so, should it let me *restrict* the available channels even more by setting the regulatory domain to the region in which de device is currently being used ? > d) If so, why am i not able to do so with my intel driver for a long time (for over a month now). > # iw reg get > country 00: > (2402 - 2472 @ 40), (6, 20) > (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN > (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN > (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN > (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN > (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN > # iw reg set US > # iw reg get > country 00: > (2402 - 2472 @ 40), (6, 20) > (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN > (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN > (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN > (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN > (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN > > Dmesg only spits out: > [ 383.849977] cfg80211: Pending regulatory request, waiting for it to be processed... > As has been explained previously, this indicates that, somehow, CRDA is not answering the kernel's requests as it should. Looking at the dmesg you posted before, we have: [ 3.862108] cfg80211: Calling CRDA to update world regulatory domain which never gets a reply. Are you using your distro's official CRDA package or have you compiled your own? It might not be installed properly as it looks like it's not responding to the kernel's call to update the world regulatory domain. There's more to installing CRDA than just sticking the executable and database in the right places. On my system here, I have: [ 16.981114] cfg80211: Calling CRDA to update world regulatory domain ... [ 17.300582] cfg80211: World regulatory domain updated: [ 17.300592] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 17.300594] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 17.300597] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 17.300598] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 17.300600] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 17.300602] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Your dmesg doesn't have the response listed, therefore CRDA is not responding to the kernel's requests. The kernel will not make additional requests until the previous one is answered. > e) So why doesn't this whole regulatory mumbojumbo and the Linux implementation in particular let me abide the law ?!? Wasn't that it's *sole* point of existence ? It _is_ doing this. The world regulatory domain is the intersection of all the regulatory domains we know of. This is the _most_ restricted version which _ensures_ that you're obeying the law _everywhere_. > f) Why doesn't seem anyone to be seriously looking at it (for over a month now, while everyone from wireless/80211 to intel driver maintainers were CC'ed) ? Because there is no bug in the kernel, the bug is in your system's setup. > g) Saying it has got to do with reg db's not being found or all kinds of other arguments while > the report clearly stated the way it can be circumvented by 2 simple patches that don't seem to involve any changes to > how it finds the reg db (apart from that i tested that a few times on request and indicated it didn't matter) > in current 3.13 code (and 3.12 and perhaps even earlier) (case 1) > or > with current wireless-next pulled (which has quite some changes to reg.c but none fixes this) onto 3.13 (case 2) > Neither of these patches might be correct codewise, but at least it let's me set the regulatory domain, and the current state the code is in is neither correct. These patches _break_ the functionality of the kernel, not fix it. They allow the kernel to issue requests before the previous one is answered. This is a bug. There are good reasons why this is not allowed. Thanks,
Tuesday, December 17, 2013, 3:17:50 AM, you wrote: > Hi Sander, > On Mon, Dec 16, 2013 at 11:56 PM, Sander Eikelenboom > <linux@eikelenboom.it> wrote: >> >> Monday, December 16, 2013, 12:37:47 PM, you wrote: >> >>> On 12/16/2013 12:22 PM, Sander Eikelenboom wrote: >>>> >>>> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: >>>> >>>>> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >>>>> <linux@eikelenboom.it> wrote: >>>>>> >>>>>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >>>>>> >>>>>>> The best way to address all this is by automatic region awareness and >>>>>>> doing the right thing on devices, this however requires good >>>>>>> architecture / calibration data / etc and all that needs to be >>>>>>> verified by the system integrators, and finally they need to be >>>>>>> certified. If you want to hack your firmware and software go at it, >>>>>>> just be aware there are reasons for things. >>>>>> >>>>>> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >>>>>> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >>>> >>>>> Its simply stupid to have the user be involved, period, the fact that >>>>> a user would be involved should only be for testing or helping >>>>> compliance for a busted device, development, research and obviously >>>>> hacking. Linux allows all these but by default a device with firmware >>>>> and a custom regdomain that will barf if you try to use a channel that >>>>> is not allowed is a restriction in firmware. Feel free to reverse >>>>> engineer that if you don't like it but it just won't be supported or >>>>> go upstream. Now, the common denominator is generally optimized for >>>>> best performance as well so you shouldn't have to do anything, and for >>>>> APs -- this is typically carefully crafted for a region, also highly >>>>> optimized. >>>> >>>>>>>>> It doesn't seem like you are getting your original requests getting >>>>>>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>>>>>> from CRDA code: >>>>>>>> >>>>>>>> They don't get processed unless i remove the return from the code as i indicated. >>>>>>>> If i remove that return it processes the request. >>>>>>>> >>>>>>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>>>>>> >>>>>>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>>>>>> the dump seems fine. >>>>>> >>>>>>> OK thanks. Can you send a patch of what exact change you made, it was >>>>>>> unclear from the paste you made. >>>>>> >>>>>>> diff -u file.c.orig file.c >>>>>> >>>>>> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >>>>>> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >>>>>> >>>>>> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >>>>>> probably due to those firmware restrictions. >>>> >>>>> Its unclear what results you got, and yeah if the device is restricted >>>>> then its just the fw telling the driver its channels and you can't use >>>>> them. That's it. You won't be able to override information then unless >>>>> you hack the firmware >>>> >>>> Ping ? >>>> >>>> Is there anymore information you need to *fix* the problem ? >> >>> Maybe you did not get the essence of the response from Luis: There is >>> *no* problem to be fixed. >> >> *sigh* .. >> >> Let's start from scratch then ... >> >> >> a) Isn't the point of the whole regulatory domain system that i can select (and restrict) the channels/frequencies my devices transmits on, so i can abide the law ? >> b) If so, does it set a regulatory domain from firmware ? >> c) If so, should it let me *restrict* the available channels even more by setting the regulatory domain to the region in which de device is currently being used ? >> d) If so, why am i not able to do so with my intel driver for a long time (for over a month now). >> # iw reg get >> country 00: >> (2402 - 2472 @ 40), (6, 20) >> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN >> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN >> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN >> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN >> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN >> # iw reg set US >> # iw reg get >> country 00: >> (2402 - 2472 @ 40), (6, 20) >> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN >> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN >> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN >> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN >> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN >> >> Dmesg only spits out: >> [ 383.849977] cfg80211: Pending regulatory request, waiting for it to be processed... >> > As has been explained previously, this indicates that, somehow, CRDA > is not answering the kernel's requests as it should. Looking at the > dmesg you posted before, we have: > [ 3.862108] cfg80211: Calling CRDA to update world regulatory domain > which never gets a reply. > Are you using your distro's official CRDA package or have you compiled > your own? It might not be installed properly as it looks like it's not > responding to the kernel's call to update the world regulatory domain. > There's more to installing CRDA than just sticking the executable and > database in the right places. It's the official Debian package. But i have tried to compile the db.txt into the kernel as is mentioned and use the internalregdb kernel config option. Could it be that since i compile all modules in the kernel and use --initrd .. that the CRDA is just not available at *that* earlier moment in boot when that module gets activated ? If so, wouldn't it be feasible to have a) timeout with error message b) clearing the request so a subsequent request can be made ? The way the patches that where posted then circumvent the problem is by just plain ignoring the blocked request. I could see if compiling them as loadable modules helps, another thing would be shoveling the whole CRDA stuff into initrd. > On my system here, I have: > [ 16.981114] cfg80211: Calling CRDA to update world regulatory domain > ... > [ 17.300582] cfg80211: World regulatory domain updated: > [ 17.300592] cfg80211: (start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp) > [ 17.300594] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > [ 17.300597] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > [ 17.300598] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), > (300 mBi, 2000 mBm) > [ 17.300600] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > [ 17.300602] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > Your dmesg doesn't have the response listed, therefore CRDA is not > responding to the kernel's requests. The kernel will not make > additional requests until the previous one is answered. >> e) So why doesn't this whole regulatory mumbojumbo and the Linux implementation in particular let me abide the law ?!? Wasn't that it's *sole* point of existence ? > It _is_ doing this. > The world regulatory domain is the intersection of all the regulatory > domains we know of. This is the _most_ restricted version which > _ensures_ that you're obeying the law _everywhere_. >> f) Why doesn't seem anyone to be seriously looking at it (for over a month now, while everyone from wireless/80211 to intel driver maintainers were CC'ed) ? > Because there is no bug in the kernel, the bug is in your system's setup. I will leave this one in the clear for the moment ... (nope i will not .. see below ;-) ) >> g) Saying it has got to do with reg db's not being found or all kinds of other arguments while >> the report clearly stated the way it can be circumvented by 2 simple patches that don't seem to involve any changes to >> how it finds the reg db (apart from that i tested that a few times on request and indicated it didn't matter) >> in current 3.13 code (and 3.12 and perhaps even earlier) (case 1) >> or >> with current wireless-next pulled (which has quite some changes to reg.c but none fixes this) onto 3.13 (case 2) >> Neither of these patches might be correct codewise, but at least it let's me set the regulatory domain, and the current state the code is in is neither correct. > These patches _break_ the functionality of the kernel, not fix it. > They allow the kernel to issue requests before the previous one is > answered. This is a bug. There are good reasons why this is not > allowed. Yes because for some reason it's allowed for requests to block for ever ... which could be considered a bug. So yes it's the wrong fix ... but it at least identifies a problem .. infinite blocking requests. I will report back when i have tested converting the wireless stuff to loadable modules / seeing if i can put the CRDA stuff in initrd. > Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Sander, Tuesday, December 17, 2013, 10:45:48 AM, you wrote: > Tuesday, December 17, 2013, 3:17:50 AM, you wrote: >> Hi Sander, >> On Mon, Dec 16, 2013 at 11:56 PM, Sander Eikelenboom >> <linux@eikelenboom.it> wrote: >>> >>> Monday, December 16, 2013, 12:37:47 PM, you wrote: >>> >>>> On 12/16/2013 12:22 PM, Sander Eikelenboom wrote: >>>>> >>>>> Wednesday, December 11, 2013, 7:38:50 PM, you wrote: >>>>> >>>>>> On Wed, Dec 11, 2013 at 7:11 PM, Sander Eikelenboom >>>>>> <linux@eikelenboom.it> wrote: >>>>>>> >>>>>>> Wednesday, December 11, 2013, 6:53:07 PM, you wrote: >>>>>>> >>>>>>>> The best way to address all this is by automatic region awareness and >>>>>>>> doing the right thing on devices, this however requires good >>>>>>>> architecture / calibration data / etc and all that needs to be >>>>>>>> verified by the system integrators, and finally they need to be >>>>>>>> certified. If you want to hack your firmware and software go at it, >>>>>>>> just be aware there are reasons for things. >>>>>>> >>>>>>> Well the general problem seems to be "we don't trust the user" so we FORCE him to the lowest >>>>>>> common denominator (without a way to overrule that) so he is forced to operate *well* within the law. >>>>> >>>>>> Its simply stupid to have the user be involved, period, the fact that >>>>>> a user would be involved should only be for testing or helping >>>>>> compliance for a busted device, development, research and obviously >>>>>> hacking. Linux allows all these but by default a device with firmware >>>>>> and a custom regdomain that will barf if you try to use a channel that >>>>>> is not allowed is a restriction in firmware. Feel free to reverse >>>>>> engineer that if you don't like it but it just won't be supported or >>>>>> go upstream. Now, the common denominator is generally optimized for >>>>>> best performance as well so you shouldn't have to do anything, and for >>>>>> APs -- this is typically carefully crafted for a region, also highly >>>>>> optimized. >>>>> >>>>>>>>>> It doesn't seem like you are getting your original requests getting >>>>>>>>>> processed, so I don't think CRDA is passing it. Can you verify running >>>>>>>>>> from CRDA code: >>>>>>>>> >>>>>>>>> They don't get processed unless i remove the return from the code as i indicated. >>>>>>>>> If i remove that return it processes the request. >>>>>>>>> >>>>>>>>>> ./regdbdump /usr/lib/crda/regulatory.bin >>>>>>>>> >>>>>>>>> Although it's in a different location on Debian, /lib/crda/regulatory.bin >>>>>>>>> the dump seems fine. >>>>>>> >>>>>>>> OK thanks. Can you send a patch of what exact change you made, it was >>>>>>>> unclear from the paste you made. >>>>>>> >>>>>>>> diff -u file.c.orig file.c >>>>>>> >>>>>>> Well i just did a pull from wireless-next, to try Avinash Patil's patch. >>>>>>> net/wireless/reg.c had already changed much so i couldn't apply his patch without. >>>>>>> >>>>>>> With his patch it sets the regulatory domain, although as now expected i still can not use channels 12 and 13 yet, >>>>>>> probably due to those firmware restrictions. >>>>> >>>>>> Its unclear what results you got, and yeah if the device is restricted >>>>>> then its just the fw telling the driver its channels and you can't use >>>>>> them. That's it. You won't be able to override information then unless >>>>>> you hack the firmware >>>>> >>>>> Ping ? >>>>> >>>>> Is there anymore information you need to *fix* the problem ? >>> >>>> Maybe you did not get the essence of the response from Luis: There is >>>> *no* problem to be fixed. >>> >>> *sigh* .. >>> >>> Let's start from scratch then ... >>> >>> >>> a) Isn't the point of the whole regulatory domain system that i can select (and restrict) the channels/frequencies my devices transmits on, so i can abide the law ? >>> b) If so, does it set a regulatory domain from firmware ? >>> c) If so, should it let me *restrict* the available channels even more by setting the regulatory domain to the region in which de device is currently being used ? >>> d) If so, why am i not able to do so with my intel driver for a long time (for over a month now). >>> # iw reg get >>> country 00: >>> (2402 - 2472 @ 40), (6, 20) >>> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN >>> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN >>> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN >>> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN >>> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN >>> # iw reg set US >>> # iw reg get >>> country 00: >>> (2402 - 2472 @ 40), (6, 20) >>> (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN >>> (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN >>> (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN >>> (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN >>> (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN >>> >>> Dmesg only spits out: >>> [ 383.849977] cfg80211: Pending regulatory request, waiting for it to be processed... >>> >> As has been explained previously, this indicates that, somehow, CRDA >> is not answering the kernel's requests as it should. Looking at the >> dmesg you posted before, we have: >> [ 3.862108] cfg80211: Calling CRDA to update world regulatory domain >> which never gets a reply. >> Are you using your distro's official CRDA package or have you compiled >> your own? It might not be installed properly as it looks like it's not >> responding to the kernel's call to update the world regulatory domain. >> There's more to installing CRDA than just sticking the executable and >> database in the right places. > It's the official Debian package. > But i have tried to compile the db.txt into the kernel as is mentioned and use the internalregdb kernel config option. > Could it be that since i compile all modules in the kernel and use --initrd .. that the CRDA is just not > available at *that* earlier moment in boot when that module gets activated ? > If so, wouldn't it be feasible to have > a) timeout with error message > b) clearing the request so a subsequent request can be made ? > The way the patches that where posted then circumvent the problem is by just plain ignoring the blocked request. > I could see if compiling them as loadable modules helps, another thing would be shoveling the whole CRDA stuff > into initrd. >> On my system here, I have: >> [ 16.981114] cfg80211: Calling CRDA to update world regulatory domain >> ... >> [ 17.300582] cfg80211: World regulatory domain updated: >> [ 17.300592] cfg80211: (start_freq - end_freq @ bandwidth), >> (max_antenna_gain, max_eirp) >> [ 17.300594] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), >> (300 mBi, 2000 mBm) >> [ 17.300597] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), >> (300 mBi, 2000 mBm) >> [ 17.300598] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), >> (300 mBi, 2000 mBm) >> [ 17.300600] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), >> (300 mBi, 2000 mBm) >> [ 17.300602] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), >> (300 mBi, 2000 mBm) >> Your dmesg doesn't have the response listed, therefore CRDA is not >> responding to the kernel's requests. The kernel will not make >> additional requests until the previous one is answered. >>> e) So why doesn't this whole regulatory mumbojumbo and the Linux implementation in particular let me abide the law ?!? Wasn't that it's *sole* point of existence ? >> It _is_ doing this. >> The world regulatory domain is the intersection of all the regulatory >> domains we know of. This is the _most_ restricted version which >> _ensures_ that you're obeying the law _everywhere_. >>> f) Why doesn't seem anyone to be seriously looking at it (for over a month now, while everyone from wireless/80211 to intel driver maintainers were CC'ed) ? >> Because there is no bug in the kernel, the bug is in your system's setup. > I will leave this one in the clear for the moment ... (nope i will not .. see below ;-) ) >>> g) Saying it has got to do with reg db's not being found or all kinds of other arguments while >>> the report clearly stated the way it can be circumvented by 2 simple patches that don't seem to involve any changes to >>> how it finds the reg db (apart from that i tested that a few times on request and indicated it didn't matter) >>> in current 3.13 code (and 3.12 and perhaps even earlier) (case 1) >>> or >>> with current wireless-next pulled (which has quite some changes to reg.c but none fixes this) onto 3.13 (case 2) >>> Neither of these patches might be correct codewise, but at least it let's me set the regulatory domain, and the current state the code is in is neither correct. >> These patches _break_ the functionality of the kernel, not fix it. >> They allow the kernel to issue requests before the previous one is >> answered. This is a bug. There are good reasons why this is not >> allowed. > Yes because for some reason it's allowed for requests to block for ever ... which could be considered a bug. > So yes it's the wrong fix ... but it at least identifies a problem .. infinite blocking requests. > I will report back when i have tested converting the wireless stuff to loadable modules / seeing if i can put the CRDA stuff in initrd. With all the wireless stuff switched to loadable modules it *does* work. So the problem is that: The current code blocks all future regulatory domain setting attempts forever (till the next reboot) when it can't find the CRDA. This can and does happen when the modules are compiled in and the CRDA is not in initrd. So from the question department: A) Why doesn't the code timeout the processing of a regulatory domain hint and remove the pending request when it aborts ? B) Why isn't the CRDA treated as firmware and placed in /lib/firmware, which has a much greater chance of automagically appearing in initrd ? C) Why as a bare minimum, doesn't it have a sane readable warning about not being able to read *which* exact file, without having to second guess to *why* the regulatory hint processing is taking *forever* ? >> Thanks,
On Tue, Dec 17, 2013 at 09:33:19PM +0100, Sander Eikelenboom wrote: [...] > > It's the official Debian package. [...] > > I will report back when i have tested converting the wireless stuff to loadable modules / seeing if i can put the CRDA stuff in initrd. > > With all the wireless stuff switched to loadable modules it *does* work. > > So the problem is that: > The current code blocks all future regulatory domain setting attempts forever (till the next reboot) > when it can't find the CRDA. This can and does happen when the modules are compiled in and the CRDA is not in initrd. > > So from the question department: > > A) Why doesn't the code timeout the processing of a regulatory domain hint and remove the pending request when it aborts ? > B) Why isn't the CRDA treated as firmware and placed in /lib/firmware, which has a much greater chance of automagically appearing in initrd ? [...] It doesn't make any logical sense to put a userland program in /lib/firmware, and it wouldn't have any effect on the initramfs builders I'm familiar with (which look at module metadata to work out which files to include from /lib/firmware). Debian official kernels use modular drivers, and neither initramfs-tools nor dracut includes wireless drivers in the initramfs. If you build a custom kernel with built-in drivers then you most likely don't need an initramfs at all. As maintainer of crda in Debian, I could add an initramfs hook that would include it in an initramfs. But I don't understand why it would be worth doing so. Why is it so useful to have wireless drivers built-in *and* an initramfs? If you think I should do this then open a bug (reportbug crda). Ben.
Tuesday, December 17, 2013, 10:27:09 PM, you wrote: > On Tue, Dec 17, 2013 at 09:33:19PM +0100, Sander Eikelenboom wrote: > [...] >> > It's the official Debian package. > [...] >> > I will report back when i have tested converting the wireless stuff to loadable modules / seeing if i can put the CRDA stuff in initrd. >> >> With all the wireless stuff switched to loadable modules it *does* work. >> >> So the problem is that: >> The current code blocks all future regulatory domain setting attempts forever (till the next reboot) >> when it can't find the CRDA. This can and does happen when the modules are compiled in and the CRDA is not in initrd. >> >> So from the question department: >> >> A) Why doesn't the code timeout the processing of a regulatory domain hint and remove the pending request when it aborts ? >> B) Why isn't the CRDA treated as firmware and placed in /lib/firmware, which has a much greater chance of automagically appearing in initrd ? > [...] > It doesn't make any logical sense to put a userland program in > /lib/firmware, and it wouldn't have any effect on the initramfs > builders I'm familiar with (which look at module metadata to work > out which files to include from /lib/firmware). Ah yes of course stupid, it's not just a blob of the regdb but a userland program. > Debian official kernels use modular drivers, and neither > initramfs-tools nor dracut includes wireless drivers in the initramfs. > If you build a custom kernel with built-in drivers then you most > likely don't need an initramfs at all. > As maintainer of crda in Debian, I could add an initramfs hook that > would include it in an initramfs. But I don't understand why it would > be worth doing so. Why is it so useful to have wireless drivers > built-in *and* an initramfs? If you think I should do this then open > a bug (reportbug crda). Indeed, I looked for a crda hook for initramfs-tools but didn't find it, so skipped that idea for the moment. So if i combine the two .. it's essentially just a very bad idea to compile the wireless stuff in. It needs a access to a userland program at module load time, or it will block forever. > Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 17, 2013 at 1:49 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > > So if i combine the two .. it's essentially just a very bad idea to compile the wireless stuff in. > It needs a access to a userland program at module load time, or it will block forever. No, it's a very stupid module if it does that. It should require the crda hook not at module load time, but at first ifconfig time. We've had bugs like this before. Doing user-mode callbacks at module loading time is a disaster exactly because it doesn't work well with built-in modules. The fact that those things apparently also don't time out or notice when they fail seems to then just exacerbate the bad decision. 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. What's the broken path? Is this driver-specific, or is it generic to the 802.11 code? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi All, On Wed, Dec 18, 2013 at 8:49 AM, Sander Eikelenboom <linux@eikelenboom.it> wrote: > > Tuesday, December 17, 2013, 10:27:09 PM, you wrote: > >> On Tue, Dec 17, 2013 at 09:33:19PM +0100, Sander Eikelenboom wrote: >> Debian official kernels use modular drivers, and neither >> initramfs-tools nor dracut includes wireless drivers in the initramfs. >> If you build a custom kernel with built-in drivers then you most >> likely don't need an initramfs at all. > >> As maintainer of crda in Debian, I could add an initramfs hook that >> would include it in an initramfs. But I don't understand why it would >> be worth doing so. Why is it so useful to have wireless drivers >> built-in *and* an initramfs? If you think I should do this then open >> a bug (reportbug crda). > > Indeed, I looked for a crda hook for initramfs-tools but didn't find it, so skipped that idea > for the moment. > > So if i combine the two .. it's essentially just a very bad idea to compile the wireless stuff in. > It needs a access to a userland program at module load time, or it will block forever. From looking at the code and files in the Debian package, the CRDA "calls" are actually events which are then handled by udev. So what happens to events passed to udev which aren't handled by any of it's (current) rules? Thanks,
On 2013-12-17 22:49, Sander Eikelenboom wrote: > > Indeed, I looked for a crda hook for initramfs-tools but didn't find it, so skipped that idea > for the moment. > > So if i combine the two .. it's essentially just a very bad idea to compile the wireless stuff in. > It needs a access to a userland program at module load time, or it will block forever. The canonical trick to have cfg80211 built in is to execute crda manually in your boot scripts. This will satisfy the initial request and resolve the block. Cheers, Pontus -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/18/2013 08:50 AM, Pontus Fuchs wrote: > On 2013-12-17 22:49, Sander Eikelenboom wrote: >> >> Indeed, I looked for a crda hook for initramfs-tools but didn't find >> it, so skipped that idea >> for the moment. >> >> So if i combine the two .. it's essentially just a very bad idea to >> compile the wireless stuff in. >> It needs a access to a userland program at module load time, or it >> will block forever. > > The canonical trick to have cfg80211 built in is to execute crda > manually in your boot scripts. This will satisfy the initial request and > resolve the block. There is a Kconfig option to have the regulatory data built-in the kernel as well. Obviously that makes a regulatory update more difficult. net/wireless/Kconfig: config CFG80211_INTERNAL_REGDB bool "use statically compiled regulatory rules database" if EXPERT Regards, AvS -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/17/2013 11:06 PM, Linus Torvalds wrote: > 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. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > On 12/17/2013 11:06 PM, Linus Torvalds wrote: > > 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. > To solve this - iwlwifi uses request_firmware_nowait. Its doc reads: "Asynchronous variant of request_firmware for user contexts: - sleep for as small periods as possible since it may increase kernel boot time of built-in device drivers requesting firmware in their ->probe methods, if gfp is GFP_KERNEL."
Wednesday, December 18, 2013, 10:16:38 AM, you wrote: > On 12/17/2013 11:06 PM, Linus Torvalds wrote: >> 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. Very well, but: If it can't access the CRDA and it is setting the world domain, why on earth is it blocking any subsequent requests to setting the regulatory domain from userspace when the CRDA *is* accessible ? I mean, i could see the need to do something *temporary* at boot when accessing the CRDA fails and to take the most safe default for the time being .. The BUG is that it is NOT temporary, but blocking until next reboot because the first request wasn't completely processed. My hostapd will try to set the domain when it starts and at that point the CRDA is accessible, so it would set it from the temporary domain to the one specified, as long as it isn't blocking. > Regards, > Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi all, 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) On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: > On 12/17/2013 11:06 PM, Linus Torvalds wrote: > > 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. This is all really beside the point. 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 ...) 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. 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". 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. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wednesday, December 18, 2013, 10:26:25 AM, you wrote: > Hi all, > 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) > On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: >> On 12/17/2013 11:06 PM, Linus Torvalds wrote: >> > 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. > This is all really beside the point. > 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 ...) > 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. > 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". > 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. -- Sander > johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 16, 2013 at 01:56:44PM +0100, Sander Eikelenboom wrote: > > Let's start from scratch then ... > > > a) Isn't the point of the whole regulatory domain system that i can > select (and restrict) the channels/frequencies my devices transmits > on, so i can abide the law ? The point is to support all forms of vendor desired architecture. Letting userspace help regulatory with its own picked ISO3166-alpha2 is one feature and we support allowing userspace to distinguish the input source if its from userspace -- today we support a source from userspace to come from the user or a cellular base station. What is done for each of these will depend on the vendor and their own preference, and the specific device's own architecture By default Linux will trust the user, but if the driver wants, it will only use the user input to enhance regulatory, never to allow more. The matrix of possibilities varies depending on the architecture of the driver and firmware. So its best then to describe the issue specifically keeping in mind what device driver and firmware you are using, rather than assuming general things for the different scenerios. > b) If so, does it set a regulatory domain from firmware ? It depends on the device. In your case the driver reads channels that are allowed from EEPROM, then uses that information to set the channel data structures before wiphy registration to cfg80211. cfg80211 then will use this as the 'base set' of channels that are allowed, no further input can enable new channels unless regulatory_hint() is used by the driver. In your case you cannot do anything other than 'restrict' the device further and I don't think you want to do that -- given that the vendor already assumed testing / compliance with what it hand and they are OK with that! > c) If so, should it let me *restrict* the available channels even more > by setting the regulatory domain to the region in which de device is > currently being used ? Yeap. > d) If so, why am i not able to do so with my intel driver for a long time > (for over a month now). > # iw reg get > country 00: > (2402 - 2472 @ 40), (6, 20) > (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN > (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN > (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN > (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN > (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN > # iw reg set US > # iw reg get > country 00: > (2402 - 2472 @ 40), (6, 20) > (2457 - 2482 @ 40), (6, 20), PASSIVE-SCAN > (2474 - 2494 @ 20), (6, 20), NO-OFDM, PASSIVE-SCAN > (5170 - 5250 @ 160), (6, 20), PASSIVE-SCAN > (5250 - 5330 @ 160), (6, 20), DFS, PASSIVE-SCAN > (5490 - 5730 @ 160), (6, 20), DFS, PASSIVE-SCAN You originally seemed to believe that using this will let you use channels that the EEPROM and firmware does not allow, this is not the case. The expectation that this will help you *restrict* the device is correct thoug and the fact that its not going through is an issue and I'm happy to review that case and fix it, as that should work. My initial review from your kernel log though was that CRDA was not installed or if it was installed it was not sending the information to the kernel, which could have been an issue with the signature of the reguatory database -- the kernel log you showed so far reflects no updates being sent by CRDA. You have two options to help troubleshoot this, which I had indicated before. One is to use CONFIG_CFG80211_INTERNAL_REGDB and throw the regulatory database file into the kernel upon build on net/wireless/db.txt. The other is to troubleshoot the regulatory domain not getting to the kernel via udev and CRDA. > Dmesg only spits out: > [ 383.849977] cfg80211: Pending regulatory request, waiting for it to be processed... This indicates to us that there is an original regulatory request that was issued and has not been processed by userspace. There is a timeout for this, 3.14 seconds, and if 3.14 seconds go by without this being processed we clear it and new regulatory requests should be allowed after that. > e) So why doesn't this whole regulatory mumbojumbo and the Linux > implementation in particular let me abide the law ?!? Wasn't that it's > *sole* point of existence ? You are abiding by the law. The issue you are describing seems to be an issue likely fixed in older kernels, the timeout on pending requests was fixed long ago so I'd like to get more information on the kernel version you are using to see if I can see what's going on. > f) Why doesn't seem anyone to be seriously looking at it (for over a > month now, while everyone from wireless/80211 to intel driver > maintainers were CC'ed) ? No one except myself is looking into this, and I have been busy as I quit my job and have been traveling and juggling other things. You were also confusing things, despite my clarifications on things, and the issue you repoted is not something I was able to reproduce. > g) Saying it has got to do with reg db's not being found or all kinds > of other arguments while the report clearly stated the way it can be > circumvented by 2 simple patches that don't seem to involve any > changes to how it finds the reg db (apart from that i tested that a > few times on request and indicated it didn't matter) in current 3.13 > code (and 3.12 and perhaps even earlier) (case 1) or > with current wireless-next pulled (which has quite some changes to > reg.c but none fixes this) onto 3.13 (case 2) Neither of these > patches might be correct codewise, but at least it let's me set the > regulatory domain, and the current state the code is in is neither > correct. You are just jumbling things around for your own purpose. Stop that. The issue is either a timeout is not being cleared and/or CRDA is not getting the request to the kernel. Let's focus on that. > h) Added Linus to the CC, you never know if that automagically kicks > things in gear ... (hopefully not in reverse :-p) That won't help cure anything. > Case 1 - patch that makes it possible to set the regulatory domain > without silently ignoring it - applies to 3.13-rc4 > > diff --git a/net/wireless/reg.c b/net/wireless/reg.c > > index 7da67fd..e8ab82e 100644 > --- a/net/wireless/reg.c > +++ b/net/wireless/reg.c > @@ -1579,7 +1579,7 @@ static void reg_process_pending_hints(void) > /* When last_request->processed becomes true this will be rescheduled */ > if (lr && !lr->processed) { > REG_DBG_PRINT("Pending regulatory request, waiting for it to be processed...\n"); > - return; > + /* return; */ > } > > spin_lock(®_requests_lock); > Again that patch is not correct and breaks things given that we have a timeout that will clear that. The real issue is your original request was not processed and we want it processed. Otherwise after 3.14 seconds from the original request you should be able to issue new requests. > Case 2 - RFC patch by Avinash Patil that makes it possible to set the > regulatory domain without silently ignoring it - applies to 3.13-rc4 + > wireless-next pulled onto it That patch was incorrect as I noted earlier. What we need to do is get down to the exact case you have to reproduce and fix. The issue you reported should already be addressed as I noted and if its not I wonder if your kernel is old or its a corner case we had not looked into before. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote: > > Wednesday, December 18, 2013, 10:26:25 AM, you wrote: > > > Hi all, > > > 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) > > > On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: > >> On 12/17/2013 11:06 PM, Linus Torvalds wrote: > >> > 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. > > > This is all really beside the point. > > > 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 ...) > > > 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. > > > 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". > > > 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. 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 ? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wednesday, December 18, 2013, 8:43:28 PM, you wrote: > On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote: >> >> Wednesday, December 18, 2013, 10:26:25 AM, you wrote: >> >> > Hi all, >> >> > 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) >> >> > On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: >> >> On 12/17/2013 11:06 PM, Linus Torvalds wrote: >> >> > 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. >> >> > This is all really beside the point. >> >> > 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 ...) >> >> > 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. >> >> > 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". >> >> > 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. > 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. > Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 18, 2013 at 08:45:46PM +0100, Sander Eikelenboom wrote: > > Wednesday, December 18, 2013, 8:43:28 PM, you wrote: > > > On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote: > >> > >> Wednesday, December 18, 2013, 10:26:25 AM, you wrote: > >> > >> > Hi all, > >> > >> > 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) > >> > >> > On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: > >> >> On 12/17/2013 11:06 PM, Linus Torvalds wrote: > >> >> > 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. > >> > >> > This is all really beside the point. > >> > >> > 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 ...) > >> > >> > 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. > >> > >> > 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". > >> > >> > 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. > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 7da67fd..e8ab82e 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1579,7 +1579,7 @@ static void reg_process_pending_hints(void) /* When last_request->processed becomes true this will be rescheduled */ if (lr && !lr->processed) { REG_DBG_PRINT("Pending regulatory request, waiting for it to be processed...\n"); - return; + /* return; */ } spin_lock(®_requests_lock); Case 2 - RFC patch by Avinash Patil that makes it possible to set the regulatory domain without silently ignoring it - applies to 3.13-rc4 + wireless-next pulled onto it ---------- Forwarded message ---------- From: "Avinash Patil" <patila@marvell.com> Date: Dec 6, 2013 8:31 PM Subject: [RFC] cfg80211: set regulatory request processed for initiator core To: <johannes@sipsolutions.net>, <linux-wireless@vger.kernel.org> Cc: During cfg80211 init, cfg80211 initializes regulatory to set to world domain. Here we dont set last request processed flag. This results into further request set to pending indefinitely. This patch fixes this by setting last request to processed. Signed-off-by: Avinash Patil <patila@marvell.com> --- net/wireless/reg.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index ec54e1a..70a8f0a 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1670,6 +1670,8 @@ static void reg_process_hint(struct regulatory_request *reg_request) switch (reg_request->initiator) { case NL80211_REGDOM_SET_BY_CORE: reg_process_hint_core(reg_request); + nl80211_send_reg_change_event(reg_request); + reg_set_request_processed(); return; case NL80211_REGDOM_SET_BY_USER: