* Re: [PATCH] ath9k: preserve DFS flags in calcrxfilter
From: Felix Fietkau @ 2011-11-02 13:19 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, ath9k-devel, rodrigue, linville
In-Reply-To: <1320235803-12190-1-git-send-email-zefir.kurtisi@neratec.com>
On 2011-11-02 1:10 PM, Zefir Kurtisi wrote:
> RX filter flags previously set for DFS radar detection were not
> preserved after "ath9k: disable unnecessary PHY error reporting".
>
> This patch ensures that the flags required for DFS support are
> kept set.
>
> Signed-off-by: Zefir Kurtisi<zefir.kurtisi@neratec.com>
I think preserving the existing register values is a bit fragile wrt.
hardware resets, register clobbering, etc.
How about just adding an internal flag or bool in the softc?
- Felix
^ permalink raw reply
* [PATCH] ath9k: preserve DFS flags in calcrxfilter
From: Zefir Kurtisi @ 2011-11-02 12:10 UTC (permalink / raw)
To: linux-wireless, ath9k-devel; +Cc: rodrigue, nbd, linville, Zefir Kurtisi
RX filter flags previously set for DFS radar detection were not
preserved after "ath9k: disable unnecessary PHY error reporting".
This patch ensures that the flags required for DFS support are
kept set.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 592ae5b..02c8dc3 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -417,6 +417,7 @@ void ath_rx_cleanup(struct ath_softc *sc)
* Calculate the receive filter according to the
* operating mode and state:
*
+ * o preserve DFS (phyerror, phyradar)
* o always accept unicast, broadcast, and multicast traffic
* o maintain current state of phy error reception (the hal
* may enable phy error frames for noise immunity work)
@@ -434,10 +435,15 @@ void ath_rx_cleanup(struct ath_softc *sc)
u32 ath_calcrxfilter(struct ath_softc *sc)
{
+ const u32 rx_filter_preserve =
+ (ATH9K_RX_FILTER_PHYERR | ATH9K_RX_FILTER_PHYRADAR);
+ const u32 rx_filter_accept =
+ (ATH9K_RX_FILTER_UCAST | ATH9K_RX_FILTER_BCAST
+ | ATH9K_RX_FILTER_MCAST);
u32 rfilt;
- rfilt = ATH9K_RX_FILTER_UCAST | ATH9K_RX_FILTER_BCAST
- | ATH9K_RX_FILTER_MCAST;
+ rfilt = (ath9k_hw_getrxfilter(sc->sc_ah) & rx_filter_preserve);
+ rfilt |= rx_filter_accept;
if (sc->rx.rxfilter & FIF_PROBE_REQ)
rfilt |= ATH9K_RX_FILTER_PROBEREQ;
@@ -475,8 +481,6 @@ u32 ath_calcrxfilter(struct ath_softc *sc)
}
return rfilt;
-
-#undef RX_FILTER_PRESERVE
}
int ath_startrecv(struct ath_softc *sc)
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v2 1/3] nl80211: Add probe response offload attribute
From: Luciano Coelho @ 2011-11-02 11:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: Guy Eilam, linux-wireless
In-Reply-To: <1320228817.3950.38.camel@jlt3.sipsolutions.net>
On Wed, 2011-11-02 at 11:13 +0100, Johannes Berg wrote:
> On Mon, 2011-10-31 at 12:04 +0200, Luciano Coelho wrote:
>
> > > + * @NL80211_ATTR_PROBE_RESP_OFFLOAD_SUPPORT: Indicates the support
> > > + * of probe response offloading by the driver/firmware.
> > > + * In addition this attribute holds a bitmap of the supported protocols
> > > + * for offloading using &enum nl80211_probe_resp_offload_support_attr.
> > > + *
>
> > I'm not sure I understand why we need this. Why aren't the flags
> > themselves enough?
>
> Not sure I understand the question?
It was what I meant (and you answered) below. :)
> > Johannes wrote, on a separate thread:
> > > Oh, and probably a regular WIPHY flag that indicates whether the
> > > attribute should be added at all so that it can also be 0 but present
> > > (presence with 0 value indicates something other than not present).
> >
> > What would be the meaning when the WIPHY flag is set but the attributes
> > are all 0? Wouldn't it mean that we don't support probe_resp offload at
> > all? Or would it mean that we support probe_resp offloading in normal
> > cases (ie. not WCS nor P2P)? If the latter is the case, why not add a
> > bit in the attributes to indicate that "normal" probe_resp offloading is
> > supported? I think this would be cleaner because there wouldn't be any
> > implicit semantics.
>
> It would mean we don't support probe response offload at all, and as a
> consequence would be more or less equivalent to having 0xfffffff as the
> flags mask (everything is "supported").
>
> Adding a flag for "normal" doesn't make sense: you can only ever reply
> to "normal" probe requests, you need to send any "special" ones up to
> the host. So each bit in this bitfield essentially says "I support this
> by passing it to the host" -- a bit for "normal" doesn't make sense in
> that context.
Okay, I get it now. So the flags are actually telling which types of
probe responses the hardware can pass up to the host when probe_resp
offload is in use.
My confusion was because I thought the flags were actually telling which
type of probe_resps the HW could offload.
Thanks for clarifying.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] compat: add pm_runtime_enabled() for kver < 2.6.38
From: Ozan Çağlayan @ 2011-11-02 11:35 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1316670659-4785-1-git-send-email-ozan@pardus.org.tr>
22-09-2011 08:50 tarihinde, Ozan Çağlayan yazdı:
> Without this, the build of wl12xx/sdio.c fails.
>
> Signed-off-by: Ozan Çağlayan<ozan@pardus.org.tr>
> ---
> include/linux/compat-2.6.38.h | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/compat-2.6.38.h b/include/linux/compat-2.6.38.h
> index 1f9ab52..d6da16e 100644
> --- a/include/linux/compat-2.6.38.h
> +++ b/include/linux/compat-2.6.38.h
> @@ -11,6 +11,10 @@
> /* rename member in struct mmc_host in include/linux/mmc/host.h */
> #define max_segs max_hw_segs
>
> +static inline bool pm_runtime_enabled(struct device *dev)
> +{
> + return !dev->power.disable_depth;
> +}
>
> /* Exponentially weighted moving average (EWMA) */
>
Any comments?
^ permalink raw reply
* Re: [PATCH] mac80211: disable powersave for broken APs
From: Johannes Berg @ 2011-11-02 10:46 UTC (permalink / raw)
To: John Linville; +Cc: Bill C Riemers, linux-wireless
In-Reply-To: <1319795987.8931.7.camel@jlt3.sipsolutions.net>
On Fri, 2011-10-28 at 11:59 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Only AID values 1-2007 are valid, but some APs have been
> found to send random bogus values, in the reported case an
> AP that was sending the AID field value 0xffff, an AID of
> 0x3fff (16383).
>
> There isn't much we can do but disable powersave since
> there's no way it can work properly in this case.
>
> Cc: stable@vger.kernel.org
> Reported-by: Bill C Riemers <briemers@redhat.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> Bill, please test this patch and see if you still see the
> warnings, or you can revert your iwlwifi changes and test
> then, it should work.
>
> John, please wait for Bill to test before you apply, just
> to confirm it fixes the issue.
https://bugzilla.redhat.com/show_bug.cgi?id=748548
Bill tested it, thanks!
johannes
^ permalink raw reply
* Re: [PATCH 3/4] mac80211: check if frame is really part of this BA
From: Johannes Berg @ 2011-11-02 10:19 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, devel, linville
In-Reply-To: <1319864732-11286-3-git-send-email-thomas@cozybit.com>
On Fri, 2011-10-28 at 22:05 -0700, Thomas Pedersen wrote:
> There was an an implicit assumption that any QoS data frame received
> from a STA/TID with an active BA session was sent to this vif as part of
> a BA. This is not true if IFF_PROMISC is enabled and the frame was
> destined for a different peer, for example. Don't treat these frames as
> part of a BA from the sending STA.
>
> Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
> ---
> net/mac80211/rx.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index ee9e71b..ad39216 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -776,6 +776,10 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
> (ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)))
> goto dont_reorder;
>
> + /* not actually part of this BA session */
> + if (compare_ether_addr(hdr->addr1, rx->sdata->vif.addr) != 0)
> + goto dont_reorder;
Huh that seems strange. Shouldn't that rather check
IEEE80211_RX_RA_MATCH?
johannes
^ permalink raw reply
* Re: [PATCH 1/4] mac80211: Avoid filling up mesh preq queue with redundant requests
From: Johannes Berg @ 2011-11-02 10:18 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, devel, Javier Cardona, linville
In-Reply-To: <1319864732-11286-1-git-send-email-thomas@cozybit.com>
On Fri, 2011-10-28 at 22:05 -0700, Thomas Pedersen wrote:
> @@ -1062,6 +1072,7 @@ void mesh_path_timer(unsigned long data)
> ++mpath->discovery_retries;
> mpath->discovery_timeout *= 2;
> spin_unlock_bh(&mpath->state_lock);
> + mpath->flags &= ~MESH_PATH_REQ_QUEUED;
locking spot-check -- is that really correct?
johannes
^ permalink raw reply
* Re: [PATCH 2/4] mac80211: QoS multicast frames have No Ack policy
From: Johannes Berg @ 2011-11-02 10:17 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, devel, linville
In-Reply-To: <1319864732-11286-2-git-send-email-thomas@cozybit.com>
On Fri, 2011-10-28 at 22:05 -0700, Thomas Pedersen wrote:
> Previously QoS multicast frames had the Normal Acknowledgment QoS
> control bits set. This would cause broadcast frames to be discarded by
> peers with which we have a BA session, since their sequence number would
> fall outside the allowed range. Set No Ack QoS control bits on multicast
> QoS frames and filter these in de-aggregation code.
I'm not sure why you would attempt to deaggregate broadcast frames but I
guess mesh is a bit special.
> @@ -770,6 +771,11 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
> if (unlikely(hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_NULLFUNC)))
> goto dont_reorder;
>
> + /* not part of a BA session */
> + if (!((ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK) ||
> + (ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)))
> + goto dont_reorder;
Maybe ack_policy != BA && ack_policy != NORMAl would be easier to read?
> --- a/net/mac80211/wme.c
> +++ b/net/mac80211/wme.c
> @@ -147,7 +147,8 @@ void ieee80211_set_qos_hdr(struct ieee80211_sub_if_data *sdata,
>
> tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
>
> - if (unlikely(sdata->local->wifi_wme_noack_test))
> + if (unlikely(sdata->local->wifi_wme_noack_test) ||
> + is_multicast_ether_addr(hdr->addr1))
> ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
Interestingly, this seems to have been a bug for a long time --
7.1.3.5.3 indicates this is supposed to be done.
johannes
^ permalink raw reply
* Re: [PATCH v2 1/3] nl80211: Add probe response offload attribute
From: Johannes Berg @ 2011-11-02 10:13 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Guy Eilam, linux-wireless
In-Reply-To: <1320055498.2672.10.camel@cumari>
On Mon, 2011-10-31 at 12:04 +0200, Luciano Coelho wrote:
> > + * @NL80211_ATTR_PROBE_RESP_OFFLOAD_SUPPORT: Indicates the support
> > + * of probe response offloading by the driver/firmware.
> > + * In addition this attribute holds a bitmap of the supported protocols
> > + * for offloading using &enum nl80211_probe_resp_offload_support_attr.
> > + *
> I'm not sure I understand why we need this. Why aren't the flags
> themselves enough?
Not sure I understand the question?
> Johannes wrote, on a separate thread:
> > Oh, and probably a regular WIPHY flag that indicates whether the
> > attribute should be added at all so that it can also be 0 but present
> > (presence with 0 value indicates something other than not present).
>
> What would be the meaning when the WIPHY flag is set but the attributes
> are all 0? Wouldn't it mean that we don't support probe_resp offload at
> all? Or would it mean that we support probe_resp offloading in normal
> cases (ie. not WCS nor P2P)? If the latter is the case, why not add a
> bit in the attributes to indicate that "normal" probe_resp offloading is
> supported? I think this would be cleaner because there wouldn't be any
> implicit semantics.
It would mean we don't support probe response offload at all, and as a
consequence would be more or less equivalent to having 0xfffffff as the
flags mask (everything is "supported").
Adding a flag for "normal" doesn't make sense: you can only ever reply
to "normal" probe requests, you need to send any "special" ones up to
the host. So each bit in this bitfield essentially says "I support this
by passing it to the host" -- a bit for "normal" doesn't make sense in
that context.
johannes
^ permalink raw reply
* Re: [wireless-next PATCH 3/5] wifi: Allow overriding some HT information.
From: Johannes Berg @ 2011-11-02 8:13 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EAAD95E.1030001@candelatech.com>
On Fri, 2011-10-28 at 09:33 -0700, Ben Greear wrote:
> >> * Allow configuring the mcs (/n) rates available.
> >> * Allow configuration of MAX-A-MSDU
> >> * Allow configuration of A-MPDU factor& density.
> >>
> >> Users can only remove existing rates. The MSDU and MPDU
> >> values can be set to any value allowed by the 802.11n
> >> specification.
> >
> > That can't work -- the device might not support it.
>
> The device would always support removing rates, right?
No. As I pointed out in another email, you need to think beyond
mac80211.
> As for the MSDU and MPDU stuff, I would need to add capabilities
> flags and then enable each driver as they are tested?
No. Neither of these can ever be increased so it's not that simple. And
making it smaller is always possible since it's just advertising.
Presumably you do understand the reasons for this advertising/these
restrictions?
> > I also don't really like the way you pass in some binary "mask" when
> > it's not really a binary masking operation.
>
> I found the mask to work very well. It's easy enough to
> deal with in user-space, and easily allows us to add override features
> (the additional bits to support the MPDU stuff once the
> HT rates logic was in is a very small bit of code).
>
> Otherwise, I'll need to add new netlink commands for each new
> feature. That is going to bloat hostapd as well as the
> kernel.
I'm not sure it'll bloat it, but I can live with the binary struct. It
seems a bit ugly to me but I think it's acceptable. However, you should
document more clearly what struct it is and how it is defined to work.
You're also relying on userspace to not do stupid things (otherwise your
code reads memory out of bounds), this would help:
> /* add attributes here, update the policy in nl80211.c */
Anyway, I'm out of breath. I think this is simply bad implementation &
execution of your ideas. These are somewhat interesting features and I'm
willing to accommodate even some of the more esoteric features that most
people will never use, but I'm quite annoyed by how much of your patches
I end up doing myself through review.
Please focus more on the quality of your patches in "details" like
security, API issues, non-mac80211 drivers and even simply logic like
the A-MSDU thing I just pointed out. I'm spending a disproportionate
amount of time reviewing your patches over and over again with every
patchset and am no longer willing to do that.
Obviously we'll still have to discuss things like whether it should be a
connection or interface parameter -- but I shouldn't have to point out
trivial security issues -- you should be focusing more on these things
while writing the code, not after the fact where it's much harder. E.g.
never ever use nla_data() without validating nla_len() in some way, it
seems to me that should be completely obvious.
> >> @@ -114,6 +115,19 @@ static void ieee80211_add_ht_ie(struct sk_buff *skb, const u8 *ht_info_ie,
> >> if (ht_info_ie[1]< sizeof(struct ieee80211_ht_info))
> >> return;
> >>
> >> + memcpy(&ht_cap,&sband->ht_cap, sizeof(ht_cap));
> >> + /*
> >> + * This is for an association attempt, and we must
> >> + * advert at least the first 8 rates, even if we
> >> + * will later force the rate control to a lower rate.
> >> + */
> >> + ieee80211_apply_htcap_overrides(sdata,&ht_cap, 8);
> >
> > Yuck, why, why hard-code 8, etc.
>
> I can make a define that involves MCS7.
I don't think I understand then why MCSs 0-7 must be supported?
johannes
^ permalink raw reply
* Re: [wireless-next PATCH v2 1/4] mac80211: Support forcing station to disable 11n.
From: Johannes Berg @ 2011-11-02 7:57 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1319840474-2618-1-git-send-email-greearb@candelatech.com>
On Fri, 2011-10-28 at 15:21 -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This allows a user to configure a wifi station interface
> to disable 802.11n, even if the AP and NIC supports it.
You really should've waited for the review on v1 to finish -- this v2 is
worthless. That makes John think that you addressed all review feedback,
when really we didn't even finish discussing some points; eventually
that'll just force me to have my own tree so John isn't confused all the
time.
johannes
^ permalink raw reply
* Re: [wireless-next PATCH 1/5] mac80211: Support forcing station to disable 11n.
From: Johannes Berg @ 2011-11-02 7:56 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EAAD734.10501@candelatech.com>
On Fri, 2011-10-28 at 09:24 -0700, Ben Greear wrote:
> >> +++ b/net/mac80211/cfg.c
> >> @@ -57,6 +57,9 @@ static int ieee80211_change_iface(struct wiphy *wiphy,
> >> struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> >> int ret;
> >>
> >> + if (params->disable_11n != -1)
> >> + sdata->cfg_disable_11n = params->disable_11n;
> >
> > This doesn't seem right -- why change the iface for it? It's a per
> > connection parameter.
>
> I wanted it to be an interface parameter, or at least I think
> that is what I want.
Why? I'm thinking that it's better as a connection parameter as then
it's more temporal. I know we have interface parameters like RTS/CTS
settings etc, but I like connection parameters better as they go away
with each new connection, so the behaviour is less surprising to most
users. Imagine your wpa_supplicant crashes, and then the user who was
restricting it to no-HT starts the regular wpa_supplicant; now his
interface will be in no-HT until he reboots or figures out the right
magic to change it. I think that kind of situation is undesirable.
> I would like eventually to support this same feature for AP
> interfaces, and probably other types. Would it still be in
> the u.mgd struct in that case?
No, but again there I'd argue that it should be a "connection" parameter
as well.
johannes
^ permalink raw reply
* Re: [wireless-next PATCH 1/5] mac80211: Support forcing station to disable 11n.
From: Johannes Berg @ 2011-11-02 7:53 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4EAAFAA7.8090403@candelatech.com>
On Fri, 2011-10-28 at 11:55 -0700, Ben Greear wrote:
> > This should be a parameter to connect() and assoc(), not a generic
> > netdev parameter, since it applies to the connection.
> >
> > Also, it would be good to have a capability check for it etc. since a
> > lot of fullmac drivers will likely never implement this.
>
> The existing code always sets the IEEE80211_STA_DISABLE_11N flag in u.mgd if
> WEP or TKIP is configured, without any capability checks, and my patch
> sets that flag in the same location.
>
> So, maybe it is OK as is?
>
> If not, I will add a new capability bit and just enable
> it in ath9k (and let others enable it in their drivers as they wish).
You misunderstood -- I said fullmac drivers, not differences between
ath9k, iwlwifi etc. Other cfg80211 drivers, not other mac80211 drivers.
johannes
^ permalink raw reply
* Re: problem clearing bit-rates with 'iw'
From: Johannes Berg @ 2011-11-02 7:52 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4EAF228F.6030104@candelatech.com>
On Mon, 2011-10-31 at 15:34 -0700, Ben Greear wrote:
> According to the help, it seems I should be able to pass no rates and
> have it clear the mask. But, it seems that is not actually working:
>
> [root@lec2010-ath9k-1 lanforge]# ./local/sbin/iw dev sta4 set bitrates legacy-2.4
> command failed: Invalid argument (-22)
remove the "legacy-2.4" thing.
johannes
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Guy, Wey-Yi @ 2011-11-02 3:21 UTC (permalink / raw)
To: Norbert Preining
Cc: David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <20111102031345.GA10851@gamma.logic.tuwien.ac.at>
Hi Norbert,
On Tue, 2011-11-01 at 20:13 -0700, Norbert Preining wrote:
> Hi all,
>
> On Mi, 26 Okt 2011, Norbert Preining wrote:
> > On Di, 25 Okt 2011, wwguy wrote:
> > > so this is different problem, right? it looks different compare to what
> > > you described before which is cause by queue stopped.
> >
> > I assume that this is a different regression concerning 3.1.0 released.
>
> Is there any progress on that? Currently linux git status is unusable
> with respect to iwlwifi?
>
> Are there any changes planned before rc1?
>
after the firmware reloaded, is the traffic resume? or it is continuous
without traffic?
Looks like the different "queue stuck" problem you are seeing. you
mention you only seeing this at university but not home. So what the
differences are?
what Band/channel you are using, also, if you disable 11n, are you still
seeing the problem?
you also mention it is might related to suspend/resume, could you please
give a better description why you think it might be related
Thanks
Wey
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Norbert Preining @ 2011-11-02 3:13 UTC (permalink / raw)
To: wwguy
Cc: David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <20111026040332.GF24956@gamma.logic.tuwien.ac.at>
Hi all,
On Mi, 26 Okt 2011, Norbert Preining wrote:
> On Di, 25 Okt 2011, wwguy wrote:
> > so this is different problem, right? it looks different compare to what
> > you described before which is cause by queue stopped.
>
> I assume that this is a different regression concerning 3.1.0 released.
Is there any progress on that? Currently linux git status is unusable
with respect to iwlwifi?
Are there any changes planned before rc1?
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
BOSEMAN
One who spends all day loafing about near pedestrian crossing looking
as if he's about to cross.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: 3.1+ iwlwifi lockup
From: Dave Jones @ 2011-11-01 22:08 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: Linux Kernel, ilw@linux.intel.com, linux-wireless@vger.kernel.org
In-Reply-To: <1320179254.31823.130.camel@wwguy-huron>
On Tue, Nov 01, 2011 at 01:27:34PM -0700, Guy, Wey-Yi wrote:
> Dave,
>
> On Mon, 2011-10-31 at 07:34 -0700, Dave Jones wrote:
> > I just got this trace, and a driver lockup that caused me to have to
> > unload & reload the iwlwifi module to get networking back.
> > hardware is..
> > 04:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300
> >
> > This is new as of 3.1+ (This kernel was Linus' tree as of last night)
> >
> >
>
> Any more information to help us understand how to re-produce the issue?
> without more data, it is really hard to root cause and fix it.
>
> Thanks
> Wey
Wasn't doing anything special. ssh, firefox, git clones.
Dave
^ permalink raw reply
* Re: 3.1+ iwlwifi lockup
From: Guy, Wey-Yi @ 2011-11-01 20:27 UTC (permalink / raw)
To: Dave Jones
Cc: Linux Kernel, ilw@linux.intel.com, linux-wireless@vger.kernel.org
In-Reply-To: <20111031143408.GA17152@redhat.com>
Dave,
On Mon, 2011-10-31 at 07:34 -0700, Dave Jones wrote:
> I just got this trace, and a driver lockup that caused me to have to
> unload & reload the iwlwifi module to get networking back.
> hardware is..
> 04:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300
>
> This is new as of 3.1+ (This kernel was Linus' tree as of last night)
>
>
Any more information to help us understand how to re-produce the issue?
without more data, it is really hard to root cause and fix it.
Thanks
Wey
>
> 9.712377] WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c:927 iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]()
> [ 2669.712381] Hardware name: Adamo 13
> [ 2669.712384] wrong command queue 0 (should be 4), sequence 0x0 readp=54 writep=54
> [ 2669.712386] Modules linked in: nfs fscache auth_rpcgss nfs_acl ppdev parport_pc lp parport fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle tun bridge stp llc lockd bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables arc4 dell_wmi sparse_keymap uvcvideo videodev snd_usb_audio v4l2_compat_ioctl32 snd_usbmidi_lib cdc_ether snd_rawmidi cdc_wdm usbnet cdc_acm mii snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device dell_laptop iwlwifi dcdbas microcode snd_pcm mac80211 joydev i2c_i801 pcspkr snd_timer iTCO_wdt iTCO_vendor_support snd soundcore cfg80211 snd_page_alloc tg3 rfkill wmi virtio_net kvm_intel kvm uinput sunrpc ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
> [ 2669.712493] Pid: 2332, comm: firefox Not tainted 3.1.0+ #9
> [ 2669.712495] Call Trace:
> [ 2669.712497] <IRQ> [<ffffffff8107d16f>] warn_slowpath_common+0x7f/0xc0
> [ 2669.712509] [<ffffffff8107d266>] warn_slowpath_fmt+0x46/0x50
> [ 2669.712519] [<ffffffffa038090e>] iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]
> [ 2669.712529] [<ffffffffa037e280>] iwl_irq_tasklet+0x210/0x8e0 [iwlwifi]
> [ 2669.712535] [<ffffffff810851fd>] tasklet_action+0x9d/0x240
> [ 2669.712539] [<ffffffff81085e28>] __do_softirq+0xc8/0x3d0
> [ 2669.712544] [<ffffffff81657f3c>] call_softirq+0x1c/0x30
> [ 2669.712549] [<ffffffff8101c735>] do_softirq+0xa5/0xe0
> [ 2669.712553] [<ffffffff810864a6>] irq_exit+0xa6/0xf0
> [ 2669.712557] [<ffffffff81658813>] do_IRQ+0x63/0xd0
> [ 2669.712561] [<ffffffff8164e5f3>] common_interrupt+0x73/0x73
> [ 2669.712563] <EOI> [<ffffffff81655c7a>] ? sysret_check+0x2e/0x69
> [ 2669.712570] ---[ end trace e86fa0935f9dc7a5 ]---
> [ 2669.712573] iwl data: 00000000: 00 00 55 55 00 00 00 00 08 53 e0 00 00 00 00 00 ..UU.....S......
> [ 2669.712577] iwl data: 00000010: 00 00 00 00 7e 04 19 00 05 00 04 00 94 07 02 00 ....~...........
> [ 2669.712619] ------------[ cut here ]------------
> [ 2669.712628] WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c:927 iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]()
> [ 2669.712631] Hardware name: Adamo 13
> [ 2669.712634] wrong command queue 11 (should be 4), sequence 0x6B6B readp=54 writep=54
> [ 2669.712636] Modules linked in: nfs fscache auth_rpcgss nfs_acl ppdev parport_pc lp parport fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle tun bridge stp llc lockd bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables arc4 dell_wmi sparse_keymap uvcvideo videodev snd_usb_audio v4l2_compat_ioctl32 snd_usbmidi_lib cdc_ether snd_rawmidi cdc_wdm usbnet cdc_acm mii snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device dell_laptop iwlwifi dcdbas microcode snd_pcm mac80211 joydev i2c_i801 pcspkr snd_timer iTCO_wdt iTCO_vendor_support snd soundcore cfg80211 snd_page_alloc tg3 rfkill wmi virtio_net kvm_intel kvm uinput sunrpc ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
> [ 2669.712729] Pid: 2332, comm: firefox Tainted: G W 3.1.0+ #9
> [ 2669.712731] Call Trace:
> [ 2669.712733] <IRQ> [<ffffffff8107d16f>] warn_slowpath_common+0x7f/0xc0
> [ 2669.712743] [<ffffffff8164de90>] ? _raw_spin_unlock_irqrestore+0x40/0x90
> [ 2669.712747] [<ffffffff8107d266>] warn_slowpath_fmt+0x46/0x50
> [ 2669.712753] [<ffffffff810c189f>] ? trace_hardirqs_on_caller+0x1f/0x1b0
> [ 2669.712762] [<ffffffffa038090e>] iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]
> [ 2669.712772] [<ffffffffa037e280>] iwl_irq_tasklet+0x210/0x8e0 [iwlwifi]
> [ 2669.712777] [<ffffffff810851fd>] tasklet_action+0x9d/0x240
> [ 2669.712781] [<ffffffff81085e28>] __do_softirq+0xc8/0x3d0
> [ 2669.712785] [<ffffffff81657f3c>] call_softirq+0x1c/0x30
> [ 2669.712789] [<ffffffff8101c735>] do_softirq+0xa5/0xe0
> [ 2669.712792] [<ffffffff810864a6>] irq_exit+0xa6/0xf0
> [ 2669.712796] [<ffffffff81658813>] do_IRQ+0x63/0xd0
> [ 2669.712800] [<ffffffff8164e5f3>] common_interrupt+0x73/0x73
> [ 2669.712802] <EOI> [<ffffffff81655c7a>] ? sysret_check+0x2e/0x69
> [ 2669.712808] ---[ end trace e86fa0935f9dc7a6 ]---
> [ 2669.712811] iwl data: 00000000: 00 00 55 55 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ..UUkkkkkkkkkkkk
> [ 2669.712815] iwl data: 00000010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> [ 2669.712818] ------------[ cut here ]------------
> [ 2669.712826] WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c:927 iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]()
> [ 2669.712829] Hardware name: Adamo 13
> [ 2669.712832] wrong command queue 11 (should be 4), sequence 0x6B6B readp=54 writep=54
> [ 2669.712834] Modules linked in: nfs fscache auth_rpcgss nfs_acl ppdev parport_pc lp parport fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle tun bridge stp llc lockd bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables arc4 dell_wmi sparse_keymap uvcvideo videodev snd_usb_audio v4l2_compat_ioctl32 snd_usbmidi_lib cdc_ether snd_rawmidi cdc_wdm usbnet cdc_acm mii snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device dell_laptop iwlwifi dcdbas microcode snd_pcm mac80211 joydev i2c_i801 pcspkr snd_timer iTCO_wdt iTCO_vendor_support snd soundcore cfg80211 snd_page_alloc tg3 rfkill wmi virtio_net kvm_intel kvm uinput sunrpc ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
> [ 2669.712925] Pid: 2332, comm: firefox Tainted: G W 3.1.0+ #9
> [ 2669.712928] Call Trace:
> [ 2669.712930] <IRQ> [<ffffffff8107d16f>] warn_slowpath_common+0x7f/0xc0
> [ 2669.712938] [<ffffffff8107d266>] warn_slowpath_fmt+0x46/0x50
> [ 2669.712948] [<ffffffffa038090e>] iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]
> [ 2669.712958] [<ffffffffa037e280>] iwl_irq_tasklet+0x210/0x8e0 [iwlwifi]
> [ 2669.712963] [<ffffffff810851fd>] tasklet_action+0x9d/0x240
> [ 2669.712967] [<ffffffff81085e28>] __do_softirq+0xc8/0x3d0
> [ 2669.712971] [<ffffffff81657f3c>] call_softirq+0x1c/0x30
> [ 2669.712975] [<ffffffff8101c735>] do_softirq+0xa5/0xe0
> [ 2669.712979] [<ffffffff810864a6>] irq_exit+0xa6/0xf0
> [ 2669.712982] [<ffffffff81658813>] do_IRQ+0x63/0xd0
> [ 2669.712986] [<ffffffff8164e5f3>] common_interrupt+0x73/0x73
> [ 2669.712988] <EOI> [<ffffffff81655c7a>] ? sysret_check+0x2e/0x69
> [ 2669.712994] ---[ end trace e86fa0935f9dc7a7 ]---
> [ 2669.712997] iwl data: 00000000: 00 00 55 55 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ..UUkkkkkkkkkkkk
> [ 2669.713018] iwl data: 00000010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> [ 2669.713136] ------------[ cut here ]------------
> [ 2669.713146] WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c:927 iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]()
> [ 2669.713150] Hardware name: Adamo 13
> [ 2669.713153] wrong command queue 11 (should be 4), sequence 0x6B6B readp=54 writep=54
> [ 2669.713157] Modules linked in: nfs fscache auth_rpcgss nfs_acl ppdev parport_pc lp parport fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle tun bridge stp llc lockd bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables arc4 dell_wmi sparse_keymap uvcvideo videodev snd_usb_audio v4l2_compat_ioctl32 snd_usbmidi_lib cdc_ether snd_rawmidi cdc_wdm usbnet cdc_acm mii snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device dell_laptop iwlwifi dcdbas microcode snd_pcm mac80211 joydev i2c_i801 pcspkr snd_timer iTCO_wdt iTCO_vendor_support snd soundcore cfg80211 snd_page_alloc tg3 rfkill wmi virtio_net kvm_intel kvm uinput sunrpc ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
> [ 2669.713292] Pid: 2332, comm: firefox Tainted: G W 3.1.0+ #9
> [ 2669.713295] Call Trace:
> [ 2669.713297] <IRQ> [<ffffffff8107d16f>] warn_slowpath_common+0x7f/0xc0
> [ 2669.713308] [<ffffffff8107d266>] warn_slowpath_fmt+0x46/0x50
> [ 2669.713319] [<ffffffffa038090e>] iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]
> [ 2669.713331] [<ffffffffa037e280>] iwl_irq_tasklet+0x210/0x8e0 [iwlwifi]
> [ 2669.713337] [<ffffffff810851fd>] tasklet_action+0x9d/0x240
> [ 2669.713342] [<ffffffff81085e28>] __do_softirq+0xc8/0x3d0
> [ 2669.713347] [<ffffffff81657f3c>] call_softirq+0x1c/0x30
> [ 2669.713353] [<ffffffff8101c735>] do_softirq+0xa5/0xe0
> [ 2669.713357] [<ffffffff810864a6>] irq_exit+0xa6/0xf0
> [ 2669.713362] [<ffffffff81658813>] do_IRQ+0x63/0xd0
> [ 2669.713367] [<ffffffff8164e5f3>] common_interrupt+0x73/0x73
> [ 2669.713369] <EOI> [<ffffffff81655c7a>] ? sysret_check+0x2e/0x69
> [ 2669.713377] ---[ end trace e86fa0935f9dc7a8 ]---
> [ 2669.713380] iwl data: 00000000: 00 00 55 55 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ..UUkkkkkkkkkkkk
> [ 2669.713385] iwl data: 00000010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> [ 2670.784424] iwlwifi 0000:04:00.0: Microcode SW error detected. Restarting 0x2000000.
> [ 2670.784431] iwlwifi 0000:04:00.0: Loaded firmware version: 8.83.5.1 build 33692
> [ 2670.784556] iwlwifi 0000:04:00.0: Start IWL Error Log Dump:
> [ 2670.784559] iwlwifi 0000:04:00.0: Status: 0x000412E4, count: 5
> [ 2670.784562] iwlwifi 0000:04:00.0: 0x00000005 | SYSASSERT
> [ 2670.784565] iwlwifi 0000:04:00.0: 0x000024EC | uPc
> [ 2670.784568] iwlwifi 0000:04:00.0: 0x000024C8 | branchlink1
> [ 2670.784570] iwlwifi 0000:04:00.0: 0x000024C8 | branchlink2
> [ 2670.784573] iwlwifi 0000:04:00.0: 0x00000916 | interruptlink1
> [ 2670.784576] iwlwifi 0000:04:00.0: 0x00000000 | interruptlink2
> [ 2670.784578] iwlwifi 0000:04:00.0: 0x000000FF | data1
> [ 2670.784580] iwlwifi 0000:04:00.0: 0x00000489 | data2
> [ 2670.784583] iwlwifi 0000:04:00.0: 0x00000489 | line
> [ 2670.784585] iwlwifi 0000:04:00.0: 0x1A41414C | beacon time
> [ 2670.784588] iwlwifi 0000:04:00.0: 0x54956EB4 | tsf low
> [ 2670.784591] iwlwifi 0000:04:00.0: 0x000004FB | tsf hi
> [ 2670.784593] iwlwifi 0000:04:00.0: 0x00000000 | time gp1
> [ 2670.784596] iwlwifi 0000:04:00.0: 0x9D4D53F1 | time gp2
> [ 2670.784598] iwlwifi 0000:04:00.0: 0x00000000 | time gp3
> [ 2670.784601] iwlwifi 0000:04:00.0: 0x00010853 | uCode version
> [ 2670.784603] iwlwifi 0000:04:00.0: 0x00000024 | hw version
> [ 2670.784606] iwlwifi 0000:04:00.0: 0x00480302 | board version
> [ 2670.784609] iwlwifi 0000:04:00.0: 0x0B15001C | hcmd
> [ 2670.784611] iwlwifi 0000:04:00.0: CSR values:
> [ 2670.784614] iwlwifi 0000:04:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
> [ 2670.784641] iwlwifi 0000:04:00.0: CSR_HW_IF_CONFIG_REG: 0X00480302
> [ 2670.784666] iwlwifi 0000:04:00.0: CSR_INT_COALESCING: 0X00000040
> [ 2670.784691] iwlwifi 0000:04:00.0: CSR_INT: 0X00000000
> [ 2670.784715] iwlwifi 0000:04:00.0: CSR_INT_MASK: 0X00000000
> [ 2670.784740] iwlwifi 0000:04:00.0: CSR_FH_INT_STATUS: 0X00000000
> [ 2670.784765] iwlwifi 0000:04:00.0: CSR_GPIO_IN: 0X00000000
> [ 2670.784790] iwlwifi 0000:04:00.0: CSR_RESET: 0X00000000
> [ 2670.784814] iwlwifi 0000:04:00.0: CSR_GP_CNTRL: 0X080403c5
> [ 2670.784839] iwlwifi 0000:04:00.0: CSR_HW_REV: 0X00000024
> [ 2670.784864] iwlwifi 0000:04:00.0: CSR_EEPROM_REG: 0X00000000
> [ 2670.784889] iwlwifi 0000:04:00.0: CSR_EEPROM_GP: 0X90000004
> [ 2670.784914] iwlwifi 0000:04:00.0: CSR_OTP_GP_REG: 0X00060000
> [ 2670.784938] iwlwifi 0000:04:00.0: CSR_GIO_REG: 0X00080042
> [ 2670.784963] iwlwifi 0000:04:00.0: CSR_GP_UCODE_REG: 0X00007c71
> [ 2670.784988] iwlwifi 0000:04:00.0: CSR_GP_DRIVER_REG: 0X00000000
> [ 2670.785012] iwlwifi 0000:04:00.0: CSR_UCODE_DRV_GP1: 0X00000000
> [ 2670.785037] iwlwifi 0000:04:00.0: CSR_UCODE_DRV_GP2: 0X00000000
> [ 2670.785062] iwlwifi 0000:04:00.0: CSR_LED_REG: 0X00000058
> [ 2670.785086] iwlwifi 0000:04:00.0: CSR_DRAM_INT_TBL_REG: 0X8811a5a0
> [ 2670.785111] iwlwifi 0000:04:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
> [ 2670.785136] iwlwifi 0000:04:00.0: CSR_ANA_PLL_CFG: 0X00880300
> [ 2670.785161] iwlwifi 0000:04:00.0: CSR_HW_REV_WA_REG: 0X0001001a
> [ 2670.785186] iwlwifi 0000:04:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0000
> [ 2670.785188] iwlwifi 0000:04:00.0: FH register values:
> [ 2670.785224] iwlwifi 0000:04:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X1174de00
> [ 2670.785243] iwlwifi 0000:04:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X012abbb0
> [ 2670.785261] iwlwifi 0000:04:00.0: FH_RSCSR_CHNL0_WPTR: 0X00000048
> [ 2670.785280] iwlwifi 0000:04:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
> [ 2670.785300] iwlwifi 0000:04:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
> [ 2670.785343] iwlwifi 0000:04:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X02630000
> [ 2670.785362] iwlwifi 0000:04:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
> [ 2670.785380] iwlwifi 0000:04:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001
> [ 2670.785389] iwlwifi 0000:04:00.0: FH_TSSR_TX_ERROR_REG: 0X00000000
> [ 2670.785389] iwlwifi 0000:04:00.0: Start IWL Event Log Dump: display last 20 entries
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638087993:0x00000000:0355
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088265:0x00000113:0106
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088266:0x00000000:0302
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088289:0x00000000:0355
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088453:0x00000113:0106
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088455:0x00000000:0302
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088478:0x00000000:0355
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088750:0x0b15001c:0206
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088752:0x00000001:0204
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088755:0x00000001:0214
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088756:0x01002111:0209
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638089055:0x00000000:0210
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638089065:0x00000000:0207
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638089067:0x01002111:0211
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638089072:0x00000000:0212
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638090106:0x00000000:0215
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638090108:0x00000008:0220
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638090127:0x00000000:0301
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638090315:0x00000000:0355
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2639090696:0x00000000:0125
> [ 2670.795643] ieee80211 phy0: Hardware restart was requested
> [ 2670.795729] iwlwifi 0000:04:00.0: L1 Enabled; Disabling L0S
> [ 2670.798779] iwlwifi 0000:04:00.0: Radio type=0x0-0x2-0x0
>
^ permalink raw reply
* AP mode support for ralink rt2070 vs rt2571W vs rt2573
From: twebb @ 2011-11-01 20:50 UTC (permalink / raw)
To: linux-wireless
Could someone comment on the current level of AP support for USB-based
drivers: rt2070/2571W/2573 and ath9k_htc? I'm confused because I
see/read that rt73usb supports AP mode for rt2771W, but I only see USB
DevID for rt2573 (0x2573) listed in rt73usb.c. What is rt2571W vs
rt2573?
I'm experimenting with USB-based AP functionality and trying to
determine which device(s) to start with.
Thanks,
twebb
^ permalink raw reply
* Re: spamm of cfg80211: Calling CRDA to update world regulatory domain
From: Thomas Backlund @ 2011-11-01 18:44 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-kernel, netdev, linux-wireless
In-Reply-To: <4EB00DD3.7090701@gmail.com>
Justin P. Mattock skrev 1.11.2011 17:18:
> is there a way to get rid of this annoying spamming of the regulatory?
>
>
> [ 338.519037] cfg80211: Calling CRDA to update world regulatory domain
> [ 338.523266] cfg80211: World regulatory domain updated:
> [ 338.523269] cfg80211: (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [ 338.523272] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300
> mBi, 2000 mBm)
> [ 338.523276] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300
> mBi, 2000 mBm)
> [ 338.523279] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300
> mBi, 2000 mBm)
> [ 338.523281] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300
> mBi, 2000 mBm)
> [ 338.523284] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300
> mBi, 2000 mBm)
> [ 340.948738] wlan1: authenticate with 00:1d:a2:d8:7e:70 (try 1)
> [ 340.950479] wlan1: authenticated
> [ 340.950707] wlan1: associate with 00:1d:a2:d8:7e:70 (try 1)
> [ 340.953611] wlan1: RX ReassocResp from 00:1d:a2:d8:7e:70 (capab=0x401
> status=0 aid=79)
> [ 340.953614] wlan1: associated
> [ 458.646604] wlan1: deauthenticated from 00:1d:a2:d8:7e:70 (Reason: 2)
>
>
> my entire syslog is filled with the above.
>
Are you using networkmanager or systemd or even both ?
Atleast at some point networkmanager have had problems when trying to
activate wireless faster than the hw like, so you get into
auth/deauth loop, and for every time interface restart gets detected,
setting crda gets triggered.
For me systemd also has had the same problems for me from time to time,
and the only way to get wireless up then is to disable it for a
~5+ seconds with the hw killswitch, and when I re-enable it, network
comes up as intended.
This happends for me with atleast 3.0 and 3.1 kernels and Intel 4965AGN
wireless connecting to a 11N 5GHz AP.
--
Thomas
^ permalink raw reply
* Compat-wireless release for 2011-11-01 is baked
From: Compat-wireless cronjob account @ 2011-11-01 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
814862 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3523 - % of code consists of backport work
^ permalink raw reply
* pull request: bluetooth 2011-11-01
From: Gustavo Padovan @ 2011-11-01 17:23 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
Hi John,
Some fixes for the 3.2 release, there are four fixes in our drivers code
by David Hermann. Szymon Janc fixed a bug that was making some dongles not
work well and a sleep in invalid context. And finally a bug fix in the mgmt
code by Johan Hedberg.
Please pull, thanks!
Gustavo
The following changes since commit ba54238552625aad2d75f455a4d3db18ea7dec68:
ath9k: Fix a dma warning/memory leak (2011-09-26 14:55:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth.git master
David Herrmann (4):
Bluetooth: ath3k: Use GFP_KERNEL instead of GFP_ATOMIC
Bluetooth: bcm203x: Fix race condition on disconnect
Bluetooth: bcm203x: Use GFP_KERNEL in workqueue
Bluetooth: bfusb: Fix error path on firmware load
Johan Hedberg (1):
Bluetooth: Set HCI_MGMT flag only in read_controller_info
Szymon Janc (2):
Bluetooth: rfcomm: Fix sleep in invalid context in rfcomm_security_cfm
Bluetooth: Increase HCI reset timeout in hci_dev_do_close
drivers/bluetooth/ath3k.c | 4 ++--
drivers/bluetooth/bcm203x.c | 12 +++++++++++-
drivers/bluetooth/bfusb.c | 13 +++++++------
include/net/bluetooth/rfcomm.h | 1 +
net/bluetooth/hci_core.c | 2 +-
net/bluetooth/mgmt.c | 2 --
net/bluetooth/rfcomm/core.c | 9 +++++++--
7 files changed, 29 insertions(+), 14 deletions(-)
^ permalink raw reply
* RE: [PATCH v2] NFC: update to NCI spec 1.0 draft 18
From: Elias, Ilan @ 2011-11-01 16:25 UTC (permalink / raw)
To: Gustavo Padovan
Cc: aloisio.almeida@openbossa.org, lauro.venancio@openbossa.org,
samuel@sortiz.org, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <20111101151209.GA2580@joana>
Hi Gustavo,
> > > > -static void nci_rf_activate_ntf_packet(struct nci_dev *ndev,
> > > > - struct sk_buff *skb)
> > > > +static void nci_rf_intf_activated_ntf_packet(struct
> nci_dev *ndev,
> > > > + struct
> sk_buff *skb)
> > > > {
> > > > - struct nci_rf_activate_ntf ntf;
> > > > + struct nci_rf_intf_activated_ntf ntf;
> > > > __u8 *data = skb->data;
> > > > - int rc = -1;
> > > > + int err = 0;
> > > >
> > > > clear_bit(NCI_DISCOVERY, &ndev->flags);
> > > > set_bit(NCI_POLL_ACTIVE, &ndev->flags);
> > > >
> > > > - ntf.target_handle = *data++;
> > > > + ntf.rf_discovery_id = *data++;
> > > > + ntf.rf_interface_type = *data++;
> > > > ntf.rf_protocol = *data++;
> > > > - ntf.rf_tech_and_mode = *data++;
> > > > + ntf.activation_rf_tech_and_mode = *data++;
> > > > ntf.rf_tech_specific_params_len = *data++;
> > > >
> > > > - nfc_dbg("target_handle %d, rf_protocol 0x%x,
> > > rf_tech_and_mode 0x%x, rf_tech_specific_params_len %d",
> > > > - ntf.target_handle,
> > > > - ntf.rf_protocol,
> > > > - ntf.rf_tech_and_mode,
> > > > + nfc_dbg("rf_discovery_id %d", ntf.rf_discovery_id);
> > > > + nfc_dbg("rf_interface_type 0x%x",
> ntf.rf_interface_type);
> > > > + nfc_dbg("rf_protocol 0x%x", ntf.rf_protocol);
> > > > + nfc_dbg("activation_rf_tech_and_mode 0x%x",
> > > > + ntf.activation_rf_tech_and_mode);
> > > > + nfc_dbg("rf_tech_specific_params_len %d",
> > > > ntf.rf_tech_specific_params_len);
> > > >
> > > > - switch (ntf.rf_tech_and_mode) {
> > > > - case NCI_NFC_A_PASSIVE_POLL_MODE:
> > > > - rc =
> nci_rf_activate_nfca_passive_poll(ndev, &ntf,
> > > > - data);
> > > > - break;
> > > > + if (ntf.rf_tech_specific_params_len > 0) {
> > > > + switch (ntf.activation_rf_tech_and_mode) {
> > > > + case NCI_NFC_A_PASSIVE_POLL_MODE:
> > > > + data =
> > > nci_extract_rf_params_nfca_passive_poll(ndev,
> > > > + &ntf, data);
> > > > + break;
> > > > +
> > > > + default:
> > > > + nfc_err("unsupported
> > > activation_rf_tech_and_mode 0x%x",
> > > > +
> ntf.activation_rf_tech_and_mode);
> > > > + return;
> > > > + }
> > > > + }
> > > >
> > > > - default:
> > > > - nfc_err("unsupported rf_tech_and_mode 0x%x",
> > > > - ntf.rf_tech_and_mode);
> > > > - return;
> > > > + ntf.data_exchange_rf_tech_and_mode = *data++;
> > > > + ntf.data_exchange_tx_bit_rate = *data++;
> > > > + ntf.data_exchange_rx_bit_rate = *data++;
> > > > + ntf.activation_params_len = *data++;
> > > > +
> > > > + nfc_dbg("data_exchange_rf_tech_and_mode 0x%x",
> > > > + ntf.data_exchange_rf_tech_and_mode);
> > > > + nfc_dbg("data_exchange_tx_bit_rate 0x%x",
> > > > + ntf.data_exchange_tx_bit_rate);
> > > > + nfc_dbg("data_exchange_rx_bit_rate 0x%x",
> > > > + ntf.data_exchange_rx_bit_rate);
> > > > + nfc_dbg("activation_params_len %d",
> > > > + ntf.activation_params_len);
> > > > +
> > > > + if (ntf.activation_params_len > 0) {
> > >
> > > Seems to me that ntf.activation_params_len > 0 can be a check
> > > in the beginning
> > > of this function.
> > Actually, each param is read in order (as you can see the
> pointer data is advanced on each param read).
> > The order is important, since it's clearer and some
> parameters are depend on the previous ones (e.g. we must read
> activation_rf_tech_and_mode before we read the activation params).
> > So, activation_params_len is read when we arrive to its
> location in the data stream.
> > In any case, I don't see the benefit in checking the
> condition in the beginning of the function (since I still
> need to read the other params).
>
> Sure, I didn't realize this in my quick look to this code.
> But this remind me
> another thing. Why are you reading your data like this, each
> member at a time?
> Can't you do something like this:
>
> struct ntf *ntf = skb->data;
>
> Then if you need to copy them to another places, or do memcpy
> or pick the ones
> you want by assign them to other variables.
Wherever I can read them into a pointer like you suggest, I do it (as you can see with all other packets).
In this case, the packet is complicated, since it includes lots of different sub-structs depending on the previous fields.
Also, some fields have variable length (so I need to keep track of the current position all the time).
In addition, some fields are bigger than 1 byte and need to be converted from little-endian to local CPU.
The reason for the complication lies in the nature of NFC, where we're expected to support multiple technologies and protocols (represented in 1 single packet).
For example, we can receive activation from tech A tags or B, F etc...each of them have different representation.
For simplicity of the code and the parsing, we represent all the information of a activation ntf in a single struct.
Of course, this struct does not represent the true protocol format (as explained above).
>
> Gustavo
>
Thanks & BR,
Ilan
^ permalink raw reply
* [PATCH] compat-wireless: add driver-select for mac80211_hwsim
From: Janusz Dziedzic @ 2011-11-01 16:05 UTC (permalink / raw)
To: linux-wireless
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
---
scripts/driver-select | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/scripts/driver-select b/scripts/driver-select
index 3619541..6f7f103 100755
--- a/scripts/driver-select
+++ b/scripts/driver-select
@@ -33,7 +33,7 @@ PURPLE="\033[35m"
CYAN="\033[36m"
UNDERLINE="\033[02m"
-SUPPORTED_80211_DRIVERS="ath5k ath9k ath9k_htc carl9170 ath6kl b43
zd1211rw rt2x00 wl1251 wl12xx brcmsmac brcmfmac"
+SUPPORTED_80211_DRIVERS="ath5k ath9k ath9k_htc carl9170 ath6kl b43
zd1211rw rt2x00 wl1251 wl12xx brcmsmac brcmfmac mac80211_hwsim"
# b43 needs some more work for driver-select, the SSB stuff, plus
# what if you update b44 but not b43? It will bust.
@@ -424,6 +424,11 @@ case $1 in
disable_staging
disable_var_01
;;
+ mac80211_hwsim)
+ disable_staging
+ disable_bt_usb_ethernet
+ select_driver CONFIG_MAC80211_HWSIM
+ ;;
# Ethernet and Bluetooth drivers
atl1)
enable_only_ethernet
--
1.7.4.1
^ permalink raw reply related
* spamm of cfg80211: Calling CRDA to update world regulatory domain
From: Justin P. Mattock @ 2011-11-01 15:18 UTC (permalink / raw)
To: linux-kernel, netdev, linux-wireless
is there a way to get rid of this annoying spamming of the regulatory?
[ 338.519037] cfg80211: Calling CRDA to update world regulatory domain
[ 338.523266] cfg80211: World regulatory domain updated:
[ 338.523269] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 338.523272] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 338.523276] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
[ 338.523279] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz),
(300 mBi, 2000 mBm)
[ 338.523281] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 338.523284] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz),
(300 mBi, 2000 mBm)
[ 340.948738] wlan1: authenticate with 00:1d:a2:d8:7e:70 (try 1)
[ 340.950479] wlan1: authenticated
[ 340.950707] wlan1: associate with 00:1d:a2:d8:7e:70 (try 1)
[ 340.953611] wlan1: RX ReassocResp from 00:1d:a2:d8:7e:70 (capab=0x401
status=0 aid=79)
[ 340.953614] wlan1: associated
[ 458.646604] wlan1: deauthenticated from 00:1d:a2:d8:7e:70 (Reason: 2)
my entire syslog is filled with the above.
Note: I am not on the list so Cc me!
Justin P. Mattock
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox