Re: IWL5300, 2.6.29-rc4, CRDA 1.0.1: Missing out 802.11A frequency ranges

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

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