linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: reinette chatre <reinette.chatre@intel.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: "ipw3945-devel@lists.sourceforge.net"
	<ipw3945-devel@lists.sourceforge.net>,
	"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] iwlagn: default to MAX_UCODE_BEACON_INTERVAL in iwl_adjust_beacon_interval
Date: Sat, 21 Feb 2009 09:31:33 -0800	[thread overview]
Message-ID: <1235237493.5860.122.camel@rc-desk> (raw)
In-Reply-To: <20090221003133.GB3890@tuxdriver.com>

On Fri, 2009-02-20 at 16:31 -0800, John W. Linville wrote:
> From: John W. Linville <linville@tuxdriver.com>
> 
> Default to MAX_UCODE_BEACON_INTERVAL if the output of
> iwl_adjust_beacon_interval would otherwise be zero.  This prevents a
> division by zero on my iwl5300-equipped Lenovo T400 with kernels that
> include "mac80211: use cfg80211s BSS infrastructure".
> 
> This patch is a bit of a hack -- I'm not sure why iwl_setup_rxon_timing
> is giving iwl_adjust_beacon_interval a zero input (which is the only way
> it would output zero).  I would be happy to have a better fix.  But for
> now, this makes my box boot...
> 
> Signed-off-by: John W. Linville <linville@tuxdriver.com>

Unfortunately I do not have a better fix, but I could shed some light
onto what may be going on and hope we can together figure out what is
the problem.

First, it appears that your problem occurs during association. The
driver obtains the value of beacon interval from mac80211 at the time it
is asked to associate (specifically, mac80211 calls bss_info_changed
with BSS_CHANGED_ASSOC and ieee80211_bss_conf->assoc is true). The
driver obtains beacon interval from iee80211_bss_conf structure at this
time. As you indicate - the driver gets a zero and this causes an oops
later.

Now, the patch you pointed out ("mac80211: use cfg80211s BSS
infrastructure") changes the way in which the beacon interval value is
obtained and stored ... but yet I cannot see how it can be different
from before and cause zero to be returned. Here I hope that Johannes can
shed some light.

Before this patch we used mac80211's BSS infrastructure and placed the
beacon interval from the beacon frame in that. Now we use cfg80211's BSS
infrastructure and place the beacon interval from the probe response in
that. Now, the function that does this (ieee80211_bss_info_update) does
not currently distinguish between beacon and probe resp when it updates
the BSS information and uses the probe resp fields (in
cfg80211_inform_bss_frame). This should not matter because the beacon
and probe resp fields are the same in this regard.

So ... if the information is obtained in the same way there could maybe
be an issue in how it is stored now? This has also changed significantly
with the move to the rbtree. I don't know.

Johannes, do you perhaps know how beacon interval was ok with the
mac80211 BSS infrastructure, but now we get zero after moving to
cfg80211 BSS infrastructure?

Thank you

Reinette



  reply	other threads:[~2009-02-21 17:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <154E55ADF9629D4E8D13F08BF92ABEB629C9D28B8D@PDSMSX501.ccr.corp.intel.com>
     [not found] ` <20090220145223.GA15006@tuxdriver.com>
     [not found]   ` <1235155966.5860.44.camel@rc-desk>
     [not found]     ` <20090220194306.GA4051@tuxdriver.com>
     [not found]       ` <20090221003013.GA3890@tuxdriver.com>
2009-02-21  0:31         ` [PATCH] iwlagn: default to MAX_UCODE_BEACON_INTERVAL in iwl_adjust_beacon_interval John W. Linville
2009-02-21 17:31           ` reinette chatre [this message]
2009-02-21 22:59             ` John W. Linville
2009-02-24  2:38           ` Johannes Berg
2009-02-25  1:44             ` John W. Linville
2009-03-14 15:59               ` Johannes Berg
2009-03-14 16:01                 ` Johannes Berg
2009-03-14 17:08                 ` Kalle Valo
2009-03-14 17:14                   ` Johannes Berg
2009-03-14 17:33                     ` Kalle Valo

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=1235237493.5860.122.camel@rc-desk \
    --to=reinette.chatre@intel.com \
    --cc=ipw3945-devel@lists.sourceforge.net \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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;
as well as URLs for NNTP newsgroup(s).