On Tue, Feb 17, 2009 at 11:06:46AM -0800, Luis Rodriguez wrote: > On Tue, Feb 17, 2009 at 10:42:30AM -0800, Luis Rodriguez wrote: > > On Mon, Feb 16, 2009 at 07:47:33AM -0800, John W. Linville wrote: > > > On Mon, Feb 16, 2009 at 12:08:44PM +0000, Tony Vroon wrote: > > > > Just to confirm, if I use my early-boot hook that I used for your iw > > > > list to set the regulatory domain manually (iw reg set GB) all is well. > > > > If I allow the driver stack to get to the association stage without > > > > setting a regulatory domain, I can never get my 802.11A spectrum back > > > > after the fact. > > > > Would you still see this as a bug or rather a specific requirement of > > > > the new interface that hasn't yet been documented? > > > > > > Seems like a bug, or at least an unintended consequence of intersection...? > > Sorry for the blank e-mail. > > You are reporting you are disabling OLD_REG and your 5 GHz on iwlagn is disabled > upon bootup. You also reported from your log: > > cfg80211: Calling CRDA to update world regulatory domain > cfg80211: calling CRDA failed - unable to update world regulatory domain, using static definition > > This indicates to me your regulatory domain was simply never updated by CRDA. So what > would have happened is that iwlagn registers its device to mac80211 via ieee80211_register_hw() > then mac80211 registers it with cfg80211 via wiphy_register(). Upon that call cfg80211 will update > the device's regulatory ifnromation by calling > > wiphy_update_regulatory(wiphy, REGDOM_SET_BY_CORE); > > This in turn will check to see if it should ignore the request, and in your case > the check is: > > if (!last_request) > return true; > if (setby == REGDOM_SET_BY_CORE && > wiphy->custom_regulatory) > return true > > Since iwlagn sets wiphy->custom_regulatory to true and since upon registration setby is > REGDOM_SET_BY_CORE the device will be ignored to change the regulatory domain. I see I > currently see no reason why your 5 GHz channels will be disabled unless I'm missing > something or the card's EEPROM disables them. > > To debug this further we need more information. So please provide the output of both > the kernel *and*, 'iw list' _prior_ to associating to your AP. Before you do so please > recompile wireless-testing with these options enabled: > > # Intel debug > CONFIG_IWL_DEBUG_INFO=y > > # Cfg80211 regulatory debug > CONFIG_CFG80211_REG_DEBUG=y > > So to re-iterate: I want both your kernel log _and_ 'iw list' output prior to association. To help isolate that orthogonal issue about having the udev rule not being created you can also test the new patch series I just posted and enable REG_DEBUG, this will give us a trace and hopefully we can see if call_usermodehelper() was the one that failed during early boot. http://marc.info/?l=linux-wireless&m=123510990625914&w=2 Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
