* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Nick Bowler @ 2010-04-20 13:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <deuQKFRcc0B.A.3EG.BRSzLB@tosh>
On 05:15 Tue 20 Apr , Rafael J. Wysocki wrote:
> If you know of any other unresolved regressions from 2.6.33, please let us
> know either and we'll add them to the list. Also, please let us know
> if any of the entries below are invalid.
Please list these two similar regressions from 2.6.33 in the r600 DRM:
* r600 CS checker rejects GL_DEPTH_TEST w/o depth buffer:
https://bugs.freedesktop.org/show_bug.cgi?id=27571
* r600 CS checker rejects narrow FBO renderbuffers:
https://bugs.freedesktop.org/show_bug.cgi?id=27609
Thanks.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: Google Summer of Code 2010 - Please resolve duplicates
From: Grant Likely @ 2010-04-20 12:43 UTC (permalink / raw)
To: Till Kamppeter, Rik van Riel
Cc: Theodore Ts'o, Greg KH, Arnaldo Carvalho de Melo,
Luis R. Rodriguez, linux-kernel, linux-wireless, Witold Sowa,
Johannes Berg
In-Reply-To: <4BCCB176.3060206@gmail.com>
On Mon, Apr 19, 2010 at 1:39 PM, Till Kamppeter
<till.kamppeter@gmail.com> wrote:
> Please mail me if a mentor needs to be (re)assigned.
Nitin Gupta has 2 proposals on the table (one pending acceptance, and
one rejection). I'm assigned as mentor on both of them, but I'm
certainly not qualified. Rik van Riel has expressed a willingness to
mentor Nitin. Rik, are you willing to take on a second student, or
can you suggest somebody to mentor Nitin?
Alex Lorca's Locator/ID Separation Protocol project is pending
acceptance, but it has not been reviewed by anyone working in the area
of network routing. Again, I'm not qualified to mentor this project
and I do not know who to suggest.
g.
^ permalink raw reply
* Re: [ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted
From: Johan Hovold @ 2010-04-20 11:35 UTC (permalink / raw)
To: Ranga Rao Ravuri
Cc: Johan Hovold, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20100420110657.GH5288@lundinova.se>
On Tue, Apr 20, 2010 at 01:06:57PM +0200, Johan Hovold wrote:
> On Tue, Apr 20, 2010 at 02:40:51PM +0530, Ranga Rao Ravuri wrote:
> > Can you please set register 0x8120 bit 28 to 1 and test this again to
> > see that helps ?
>
> I'll try that.
I'm afraid it does not seem to have any effect on the corrupt frame
status.
Anything else I can try?
Thanks,
Johan
^ permalink raw reply
* Re: [ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted
From: Johan Hovold @ 2010-04-20 11:06 UTC (permalink / raw)
To: Ranga Rao Ravuri
Cc: Johan Hovold, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1271754651.14253.112.camel@ranga-desktop>
On Tue, Apr 20, 2010 at 02:40:51PM +0530, Ranga Rao Ravuri wrote:
> Can you please tell us more about your test,
> what exactly is your test is ?
> What kind of traffic are you running
> what is your AP ?.
I have a powerpc-based platform running AR9280 in AP mode. My STA is an
Intel 5300 (but I have been able to reproduce it also with an STA using
AR5008).
After connecting I run iperf in client mode on the STA thus sending data
to the STA. After a short while the AP stops receiving any data
(including TCP-acks) and the transfer stalls.
I've verified that frames that look ok in the air can still be corrupt
in ath9k. In particular, the status field is trashed so that frames are
incorrectly forwarded to mac80211 marked as decrypted which can trigger
countermeasures or update CCMP PN incorrectly (thereby dropping later,
correct frames).
Discarding frames which appear to have trashed status makes 802.11n
work.
> Are you testing with aggregated traffic or non-aggregate legacy
> traffic ?
Aggregated.
> Are you seeing only when CCMP is enabled or in WEP/TKIP also ?
Only with 802.11n (CCMP). Everything works perfectly with 802.11g and
WEP/TKIP/CCMP and I never see any corrupt frame status.
> Can you please set register 0x8120 bit 28 to 1 and test this again to
> see that helps ?
I'll try that.
Thanks,
Johan
^ permalink raw reply
* [PATCH] mac80211: Fix ieee80211_sta_conn_mon_timer with hw connection monitoring
From: Juuso Oikarinen @ 2010-04-20 10:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
When IEEE80211_HW_CONNECTION_MONITOR is configured by the driver, starting
of ieee80211_sta_conn_mon_timer should be prevented, as it is then not needed.
This is currently partially the case. As it seems, when a probe-response is
received from the AP the timer is still restarted, thus restarting the host
based connection keep-alive mechanism. These probe-responses happen at least
when scanning while associated.
Fix this by preventing starting of the ieee80211_sta_conn_mon_timer in the
ieee80211_rx_mgmt_probe_resp function.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
net/mac80211/mlme.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 3133681..425f66c 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1333,12 +1333,17 @@ static void ieee80211_rx_mgmt_probe_resp(struct ieee80211_sub_if_data *sdata,
mutex_lock(&sdata->local->iflist_mtx);
ieee80211_recalc_ps(sdata->local, -1);
mutex_unlock(&sdata->local->iflist_mtx);
+
+ if (sdata->local->hw.flags & IEEE80211_HW_CONNECTION_MONITOR)
+ return;
+
/*
* We've received a probe response, but are not sure whether
* we have or will be receiving any beacons or data, so let's
* schedule the timers again, just in case.
*/
mod_beacon_timer(sdata);
+
mod_timer(&ifmgd->conn_mon_timer,
round_jiffies_up(jiffies +
IEEE80211_CONNECTION_IDLE_TIME));
--
1.6.3.3
^ permalink raw reply related
* Re: p54pci does not work
From: Christian Lamparter @ 2010-04-20 9:32 UTC (permalink / raw)
To: Duarte Nuno Gomes; +Cc: linux-wireless
In-Reply-To: <i2u719bd8781004192319ge1e40479oa17f0f5036a6cee@mail.gmail.com>
On Tuesday 20 April 2010 08:19:11 Duarte Nuno Gomes wrote:
> On Tue, Apr 13, 2010 at 6:48 PM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> > On Tuesday 13 April 2010 07:47:42 Duarte Nuno Gomes wrote:
> >> it works all ok ... when i visit some websites ( www.rcmadeira.pt.vu is one
> >> of them ), my connection just disconnects and i cannot resume it . i need to
> >> shutdown and re lauch kernel in order to work with wireless again.
> >
> > hrmf, works here no matter how much i try.
> > But let's not get carry away, I guess the problem you are describing
> > has more to do with the amount of data which is transfered.
> > Ideally, you should be able to reproduce this _hang_ with any network
> > benchmarking tools (like iperf / nttcp / netperf (or whatever you prefer)).
> i would if u had a way of having a demon running on some shell and
> know what to check for
> >
> >> here is what dmesg outputs
> >>
> >> No probe response from AP 00:24:17:6c:a5:0e after 500ms, disconnecting.
> >> Phy0 : cannot boot firmware !
> >
> > are you getting these messages in this order? (some timestamps,
> > and maybe p54pci dmesg output while initializing would be jolly nice)
[...]
> >
> > * Wireless setup (Which band (2.4 or 5GHz) ? Do you use WPA/WPA2 with CCMP/TKIP,
> > (you can turn off the hw crypto accelerator by loading p54common with the module
> > parameter nohwcrypt=1 )
>
> 2.4 Ghz with WPA / TKIP
> IT WORKS WITH THAT NOHWCRYPT PARAMETER! ill test a little more !
> just need to figure out now , how to load it with parameter on boot !
> easy task !
echo "options p54common nohwcrypt=1" > /etc/modprobe/p54common.conf,
if you compiled p54common as a module (which I hope you did).
if p54common is built-in, then you'll have to add a p54common.nohwcrypt=1
kernel cmdline parameter.
The (most likely) reason why your AP drops you and does not allow you
to reconnect, is probably due to the "TKIP countermeasures".
What's your Accesspoint/Router and which firmware are you currently using?
Regards,
Chr
^ permalink raw reply
* Re: [ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted
From: Ranga Rao Ravuri @ 2010-04-20 9:10 UTC (permalink / raw)
To: Johan Hovold; +Cc: ath9k-devel@lists.ath9k.org, linux-wireless@vger.kernel.org
In-Reply-To: <20100420082519.GB5288@lundinova.se>
Hi
Can you please tell us more about your test,
what exactly is your test is ?
What kind of traffic are you running
what is your AP ?.
Are you testing with aggregated traffic or non-aggregate legacy
traffic ?
Are you seeing only when CCMP is enabled or in WEP/TKIP also ?
Can you please set register 0x8120 bit 28 to 1 and test this again to
see that helps ?
thanks
Ranga
On Tue, 2010-04-20 at 13:55 +0530, Johan Hovold wrote:
> Hi again,
>
> On Fri, Apr 16, 2010 at 12:48:50PM +0200, Johan Hovold wrote:
> > I now know why 802.11n receive stalls; ath9k is passing corrupt frames to
> > mac80211.
> [...]
> > An example of such a frame is:
> >
> > 00000000: 88 41 30 00 00 80 48 68 08 0f 00 21 6a 56 2c 36
> > 00000010: 00 22 02 00 0b 63 20 52 00 00 20 21 21 05 00 20
> > 00000020: 8a 39 7b 1f 0f 11 07 9e bd 53 80 33 3b 8c 98 00
> > 00000030: ef 5f da 7c 9a d6 3d d7 59 ac e0 21 44 88 63 d7
> > 00000040: 21 34 b7 9a 89 8e cf 9e 46 1c ee d6 81 56 25 59
> > 00000050: d2 ec ac 33 e6 12 3d c5 02 61 2d 80 8d 30 44 1e
> > 00000060: 79 74 79 79 62 25 ba ec 04 4d 54 dc
> >
> > with associated status
> >
> > rxstatus8 = 1e989103
> >
> > Here nothing in the frame status indicates an error; the frame has no error
> > flags set, the frame-ok flag is set, and so on. Still the frame is indeed
> > corrupt; the last four octets of the CCMP-header (bytes 0x20..0x23) should
> > be {00,00,00,00} rather than {8a,39,7b,1f} as the correct PN is 0x0521 (not
> > 0x1f7b398a0521).
> >
> > The corrupt frames all seem to have the upper half of the CCMP-header, data
> > and MIC corrupted, whereas the FCS (last four bytes) seem to be correct in the
> > sense that they match what I see in the air (and is verified by wireshark).
> >
> > One explanation for all of this could be that the corrupt packet is what the
> > hardware is expected to return should it's processing fail (e.g. due to
> > checksum error). Then the problem is merely that the status field sometimes
> > get corrupted (some frames with corrupt PN do indeed come with matching
> > rxstatus). Comments in the code concerning corrupt status fields also point in
> > this direction.
> >
> > Another explanation could be that the status is actually correct but for some
> > reason the returned frame is corrupted. Perhaps it's a combination of both
> > corrupt status and frame.
> >
> > Any ideas about what may be going on here?
>
> I'll answer my own question -- the status field is clearly corrupted.
> The bad frames all have status such as
>
> 19fdb637
> 9131f6d7
> 87b3f0c1
> 29de5e7b
> 10c68ff3
> 4c1a33c7
> 9abd470b
>
> where it should look something like 00030943. From inspection of
> returned frame status, I've come up with at way to catch these; I
> discard frames marked ok but with errors flags set or which have any of
> the reserved bits 19 through 28 (0x1ff80000) set.
>
> My question is: Is the latter assumption correct? Can I expect bits
> 19..28 to be zero?
>
> On my AR9820 hardware this seems to be case and I am able to catch all
> the corrupt frames and have 802.11n work perfectly. It also works fine
> with 802.11g/WEP/TKIP/CCMP.
>
> As a side note, I also seem able to confirm my observation above that
> frames returned with non-corrupt status and decrypt error flag set
> indeed do have corrupt CCMP header, data and MIC. That is, this seem to
> be what hw is expected to return on (such) errors.
>
> I'm responding to this mail with my fix (workaround).
>
> I have also seen non-decrypted frames with decrypt busy flag set but
> without decrypt crc err set (frame is marked not ok). I'm not sure
> whether this is due to a bug or bit error (decrypt crc somehow got
> cleared) but I also propose a change to remedy this.
>
> Thanks,
> Johan Hovold
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply
* Re: [RFC][PATCH 1/2] ath9k: fix corrupt frames being forwarded to mac80211
From: Johan Hovold @ 2010-04-20 8:38 UTC (permalink / raw)
To: Johan Hovold; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1271752088-13639-1-git-send-email-johan.hovold@lundinova.se>
On Tue, Apr 20, 2010 at 10:28:07AM +0200, Johan Hovold wrote:
> Verify frame status by making sure that no error flags are set if frame
> is marked ok and that reserved bits 19 through 28 (0x1ff80000) are all
> zero, otherwise discarded frame (as ATH9K_PHYERR_HT_CRC_ERROR).
I used ATH9K_PHYERR_HT_CRC_ERROR for now, but perhaps there is better
choice?
^ permalink raw reply
* Re: [ath9k-devel] [RFC][PATCH 2/6] ath9k: do not mark frames with RXKEY_IX_INVALID as decrypted
From: Johan Hovold @ 2010-04-20 8:35 UTC (permalink / raw)
To: Jouni Malinen
Cc: Johan Hovold, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1271417561.8066.4.camel@jm-desktop>
On Fri, Apr 16, 2010 at 02:32:41PM +0300, Jouni Malinen wrote:
> On Fri, 2010-04-16 at 03:52 -0700, Johan Hovold wrote:
> > Frames tagged by hardware with ATH9K_RXKEYIX_INVALID should not
> > incorrectly be marked decrypted (even if key index in frame is valid).
>
> Have you tested this with static WEP configuration? Or broadcast RX with
> WPA? There must be a reason for that odd looking code being there in the
> first place and I can now only think of it being needed when the default
> keys are used.
You are correct. That piece of code is indeed required for WEP
(KeyIdxValid is not set and sometimes also KeyMiss is set even though
frame has been decrypted).
I just posted a patch which seems to catch the corrupt frames without
messing anything else up. Perhaps you could take a quick look at it?
Thanks,
Johan
^ permalink raw reply
* [RFC][PATCH 2/2] ath9k: use also AR_DecryptBusyErr to determine decrypt errors
From: Johan Hovold @ 2010-04-20 8:28 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Johan Hovold
In-Reply-To: <20100420082519.GB5288@lundinova.se>
Prevent non-decrypted frames with DecryptBusyErr flag set to be marked
decrypted.
Have seen such a frame with status 0x40030bc1 (due to bit error?).
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
drivers/net/wireless/ath/ath9k/mac.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 2afe72f..780da87 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -930,7 +930,8 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_status |= ATH9K_RXERR_PHY;
phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
rs->rs_phyerr = phyerr;
- } else if (ads.ds_rxstatus8 & AR_DecryptCRCErr)
+ } else if (ads.ds_rxstatus8 & AR_DecryptCRCErr ||
+ ads.ds_rxstatus8 & AR_DecryptBusyErr)
rs->rs_status |= ATH9K_RXERR_DECRYPT;
else if (ads.ds_rxstatus8 & AR_MichaelErr)
rs->rs_status |= ATH9K_RXERR_MIC;
--
1.7.0.3
^ permalink raw reply related
* [RFC][PATCH 1/2] ath9k: fix corrupt frames being forwarded to mac80211
From: Johan Hovold @ 2010-04-20 8:28 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Johan Hovold
In-Reply-To: <20100420082519.GB5288@lundinova.se>
Frame status frequently gets corrupted in hardware with 802.11n which
can lead to corrupt frames being forwarded to mac80211. This in turn may
trigger countermeasures in reponse to false MIC-errors or cause receive
to stall when frames are dropped after processing a frame with corrupt PN.
Verify frame status by making sure that no error flags are set if frame
is marked ok and that reserved bits 19 through 28 (0x1ff80000) are all
zero, otherwise discarded frame (as ATH9K_PHYERR_HT_CRC_ERROR).
Tested with AR9280 (WEP, TKIP and CCMP).
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
drivers/net/wireless/ath/ath9k/mac.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 4a2060e..2afe72f 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -934,9 +934,22 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_status |= ATH9K_RXERR_DECRYPT;
else if (ads.ds_rxstatus8 & AR_MichaelErr)
rs->rs_status |= ATH9K_RXERR_MIC;
+ } else {
+ if (ads.ds_rxstatus8 & (AR_CRCErr |
+ AR_PHYErr |
+ AR_DecryptCRCErr |
+ AR_MichaelErr |
+ AR_DecryptBusyErr))
+ goto corrupt;
}
+ if (ads.ds_rxstatus8 & 0x1ff80000)
+ goto corrupt;
return 0;
+corrupt:
+ rs->rs_status |= ATH9K_RXERR_PHY;
+ rs->rs_phyerr = ATH9K_PHYERR_HT_CRC_ERROR;
+ return 0;
}
EXPORT_SYMBOL(ath9k_hw_rxprocdesc);
--
1.7.0.3
^ permalink raw reply related
* Re: [ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted
From: Johan Hovold @ 2010-04-20 8:25 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Johan Hovold, Tor Krill
In-Reply-To: <20100416104850.GA13329@lundinova.se>
Hi again,
On Fri, Apr 16, 2010 at 12:48:50PM +0200, Johan Hovold wrote:
> I now know why 802.11n receive stalls; ath9k is passing corrupt frames to
> mac80211.
[...]
> An example of such a frame is:
>
> 00000000: 88 41 30 00 00 80 48 68 08 0f 00 21 6a 56 2c 36
> 00000010: 00 22 02 00 0b 63 20 52 00 00 20 21 21 05 00 20
> 00000020: 8a 39 7b 1f 0f 11 07 9e bd 53 80 33 3b 8c 98 00
> 00000030: ef 5f da 7c 9a d6 3d d7 59 ac e0 21 44 88 63 d7
> 00000040: 21 34 b7 9a 89 8e cf 9e 46 1c ee d6 81 56 25 59
> 00000050: d2 ec ac 33 e6 12 3d c5 02 61 2d 80 8d 30 44 1e
> 00000060: 79 74 79 79 62 25 ba ec 04 4d 54 dc
>
> with associated status
>
> rxstatus8 = 1e989103
>
> Here nothing in the frame status indicates an error; the frame has no error
> flags set, the frame-ok flag is set, and so on. Still the frame is indeed
> corrupt; the last four octets of the CCMP-header (bytes 0x20..0x23) should
> be {00,00,00,00} rather than {8a,39,7b,1f} as the correct PN is 0x0521 (not
> 0x1f7b398a0521).
>
> The corrupt frames all seem to have the upper half of the CCMP-header, data
> and MIC corrupted, whereas the FCS (last four bytes) seem to be correct in the
> sense that they match what I see in the air (and is verified by wireshark).
>
> One explanation for all of this could be that the corrupt packet is what the
> hardware is expected to return should it's processing fail (e.g. due to
> checksum error). Then the problem is merely that the status field sometimes
> get corrupted (some frames with corrupt PN do indeed come with matching
> rxstatus). Comments in the code concerning corrupt status fields also point in
> this direction.
>
> Another explanation could be that the status is actually correct but for some
> reason the returned frame is corrupted. Perhaps it's a combination of both
> corrupt status and frame.
>
> Any ideas about what may be going on here?
I'll answer my own question -- the status field is clearly corrupted.
The bad frames all have status such as
19fdb637
9131f6d7
87b3f0c1
29de5e7b
10c68ff3
4c1a33c7
9abd470b
where it should look something like 00030943. From inspection of
returned frame status, I've come up with at way to catch these; I
discard frames marked ok but with errors flags set or which have any of
the reserved bits 19 through 28 (0x1ff80000) set.
My question is: Is the latter assumption correct? Can I expect bits
19..28 to be zero?
On my AR9820 hardware this seems to be case and I am able to catch all
the corrupt frames and have 802.11n work perfectly. It also works fine
with 802.11g/WEP/TKIP/CCMP.
As a side note, I also seem able to confirm my observation above that
frames returned with non-corrupt status and decrypt error flag set
indeed do have corrupt CCMP header, data and MIC. That is, this seem to
be what hw is expected to return on (such) errors.
I'm responding to this mail with my fix (workaround).
I have also seen non-decrypted frames with decrypt busy flag set but
without decrypt crc err set (frame is marked not ok). I'm not sure
whether this is due to a bug or bit error (decrypt crc somehow got
cleared) but I also propose a change to remedy this.
Thanks,
Johan Hovold
^ permalink raw reply
* Re: mac80211 and asymmetric 802.11n TX/RX
From: Johannes Berg @ 2010-04-20 8:22 UTC (permalink / raw)
To: Daniel Halperin; +Cc: linux-wireless
In-Reply-To: <48BAD814-F653-4CE3-85E0-A9D82EC31D53@cs.washington.edu>
Hi Dan,
> Does anyone know if the 11n standard says that the set of TX rates has
> to be a subset of the set of RX rates? This seems to be enforced now:
> when I set up one node to be 2x1, i.e. transmit 2 streams but only
> able to receive 1, then the mac80211 code only lets it transmit 1
> streams (even with a 2-stream-capable receiver at the other end).
I'm not sure. Reading 7.3.2.56.4 seems to imply that, but I'm not sure
about the "Rx Highest Supported Data Rate" field. Seems like maybe you
could set the "RX MCS bitmask" to more than is supported, limit it by
the highest supported data rate, and then use the bitmask for TX?
> A quick diff to net/mac80211/ht.c that fixes this for equal modulation
> streams is attached; the problem is still there for unequal modulation
> directly below. Before I send it up I wanted to make sure I'm not
> crazy.
Hmm, ok. I interpreted the standard differently here, but your
interpretation actually makes more sense I guess. Anyone who's more
familiar with the standard?
> A second question: my understanding is that if I am a 2x2 node and I
> associate to a 3x3 AP, the same code will mask out the fact that the
> AP can receive 3 streams since I can't transmit 3 streams. Is there a
> way to access this info from the driver if I want it?
Unfortunately not, at this point. We could keep track of it, what would
you need it for?
johannes
^ permalink raw reply
* Re: [PATCH] ath9k-htc: speedup disconnect handling
From: Ming Lei @ 2010-04-20 7:46 UTC (permalink / raw)
To: Sujith
Cc: Luis Rodriguez, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <19405.19620.199172.233574@gargle.gargle.HOWL>
2010/4/20 Sujith <Sujith.Manoharan@atheros.com>:
> Ming Lei wrote:
>> If ATH_DBG_RESET is enabled, you will find the debug messages
>> below[1] during disconnecting. From the messages, the short hang should
>> be caused by the 'RTC stuck in MAC reset'. Once the patch is applied,
>> no such issue will happen.
>
> I take it that you didn't have ATH_DBG_WMI in your debug mask.
> A simpler way to fix this issue is to deny all WMI commands once
> the target has been unplugged - something like the attached patch.
>
> Can you check if it fixes your issue ?
Yes, the patch does fix the issue.
Thanks,
--
Lei Ming
^ permalink raw reply
* Re: Google Summer of Code 2010 - Please resolve duplicates
From: Till Kamppeter @ 2010-04-20 7:19 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Ts'o, Arnaldo Carvalho de Melo, Luis R. Rodriguez,
linux-kernel, linux-wireless, Witold Sowa, Johannes Berg,
Grant Likely, Alexey Khoroshilov
In-Reply-To: <4BCCDFBC.4020907@gmail.com>
On 04/19/2010 03:57 PM, Till Kamppeter wrote:
> Sorry, here we go:
>
> http://socghop.appspot.com/gsoc/org/list_proposals/google/gsoc2010/lf
>
> Requires login as mentor.
>
> Till
On this page students which are accepted by 2 or more orgs are marked
with "Duplicate" in red. Click on this "Duplicate" to get info to
contact the other org.
Till
^ permalink raw reply
* mac80211 and asymmetric 802.11n TX/RX
From: Daniel Halperin @ 2010-04-20 7:07 UTC (permalink / raw)
To: linux-wireless
Hi all,
Does anyone know if the 11n standard says that the set of TX rates has to be a subset of the set of RX rates? This seems to be enforced now: when I set up one node to be 2x1, i.e. transmit 2 streams but only able to receive 1, then the mac80211 code only lets it transmit 1 streams (even with a 2-stream-capable receiver at the other end).
A quick diff to net/mac80211/ht.c that fixes this for equal modulation streams is attached; the problem is still there for unequal modulation directly below. Before I send it up I wanted to make sure I'm not crazy.
A second question: my understanding is that if I am a 2x2 node and I associate to a 3x3 AP, the same code will mask out the fact that the AP can receive 3 streams since I can't transmit 3 streams. Is there a way to access this info from the driver if I want it?
Thanks!
Dan
---
From: Daniel Halperin <dhalperi@cs.washington.edu>
Date: Tue, 20 Apr 2010 00:00:29 -0700
Subject: [PATCH] mac80211: support devices with more transmit than receive MCS supported
There is an implicit assumption built into mac80211 that an 11n NIC has a
receive MCS set that contains its TX MCS set, even when
IEEE80211_HT_MCS_TX_RX_DIFF is set. Then, a 2x1 node that can transmit 2
streams but only receive 1 will be unable to transmit 2 streams. Fix this for
equal modulation MCS sets by properly handling the IEEE80211_HT_MCS_TX_RX_DIFF
case.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
---
net/mac80211/ht.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index 2ab106a..249805b 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -24,6 +24,7 @@ void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
{
u8 ampdu_info, tx_mcs_set_cap;
int i, max_tx_streams;
+ bool use_rx_mask;
BUG_ON(!ht_cap);
@@ -71,12 +72,15 @@ void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
return;
/* Counting from 0, therefore +1 */
- if (tx_mcs_set_cap & IEEE80211_HT_MCS_TX_RX_DIFF)
+ if (tx_mcs_set_cap & IEEE80211_HT_MCS_TX_RX_DIFF) {
max_tx_streams =
((tx_mcs_set_cap & IEEE80211_HT_MCS_TX_MAX_STREAMS_MASK)
>> IEEE80211_HT_MCS_TX_MAX_STREAMS_SHIFT) + 1;
- else
+ use_rx_mask = 0;
+ } else {
max_tx_streams = IEEE80211_HT_MCS_TX_MAX_STREAMS;
+ use_rx_mask = 1;
+ }
/*
* 802.11n D5.0 20.3.5 / 20.6 says:
@@ -87,7 +91,8 @@ void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
*/
for (i = 0; i < max_tx_streams; i++)
ht_cap->mcs.rx_mask[i] =
- sband->ht_cap.mcs.rx_mask[i] & ht_cap_ie->mcs.rx_mask[i];
+ (use_rx_mask ? sband->ht_cap.mcs.rx_mask[i] : 0xFF) &
+ ht_cap_ie->mcs.rx_mask[i];
if (tx_mcs_set_cap & IEEE80211_HT_MCS_TX_UNEQUAL_MODULATION)
for (i = IEEE80211_HT_MCS_UNEQUAL_MODULATION_START_BYTE;
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] ath9k-htc: speedup disconnect handling
From: Sujith @ 2010-04-20 6:41 UTC (permalink / raw)
To: Ming Lei
Cc: Luis Rodriguez, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <y2ud82e647a1004192259nec8aad6dy836b76b2211b6a40@mail.gmail.com>
Ming Lei wrote:
> If ATH_DBG_RESET is enabled, you will find the debug messages
> below[1] during disconnecting. From the messages, the short hang should
> be caused by the 'RTC stuck in MAC reset'. Once the patch is applied,
> no such issue will happen.
I take it that you didn't have ATH_DBG_WMI in your debug mask.
A simpler way to fix this issue is to deny all WMI commands once
the target has been unplugged - something like the attached patch.
Can you check if it fixes your issue ?
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index c765ff4..b771e20 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -329,6 +329,7 @@ struct htc_beacon_config {
#define OP_ASSOCIATED BIT(8)
#define OP_ENABLE_BEACON BIT(9)
#define OP_LED_DEINIT BIT(10)
+#define OP_UNPLUGGED BIT(11)
struct ath9k_htc_priv {
struct device *dev;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a861896..701f2ef 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -744,6 +744,9 @@ int ath9k_htc_probe_device(struct htc_target *htc_handle, struct device *dev,
if (ret)
goto err_init;
+ /* The device may have been unplugged earlier. */
+ priv->op_flags &= ~OP_UNPLUGGED;
+
ret = ath9k_init_device(priv, devid);
if (ret)
goto err_init;
@@ -760,6 +763,11 @@ err_free:
void ath9k_htc_disconnect_device(struct htc_target *htc_handle, bool hotunplug)
{
if (htc_handle->drv_priv) {
+
+ /* Check if the device has been yanked out. */
+ if (hotunplug)
+ htc_handle->drv_priv->op_flags |= OP_UNPLUGGED;
+
ath9k_deinit_device(htc_handle->drv_priv);
ath9k_deinit_wmi(htc_handle->drv_priv);
ieee80211_free_hw(htc_handle->drv_priv->hw);
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index dc6c6fc..c688545 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -276,6 +276,9 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
int time_left, ret = 0;
unsigned long flags;
+ if (wmi->drv_priv->op_flags & OP_UNPLUGGED)
+ return 0;
+
if (!wmi)
return -EINVAL;
^ permalink raw reply related
* [PATCH v2] mac80211: document IEEE80211_CONF_CHANGE_QOS
From: Stanislaw Gruszka @ 2010-04-20 6:16 UTC (permalink / raw)
To: linux-wireless
Cc: Reinette Chatre, John W. Linville, wey-yi.w.guy, Johannes Berg,
Pavel Roskin
In-Reply-To: <1271692635.9026.17.camel@mj>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index dcf3c5f..97b2222 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -610,6 +610,7 @@ enum ieee80211_conf_flags {
* @IEEE80211_CONF_CHANGE_RETRY_LIMITS: retry limits changed
* @IEEE80211_CONF_CHANGE_IDLE: Idle flag changed
* @IEEE80211_CONF_CHANGE_SMPS: Spatial multiplexing powersave mode changed
+ * @IEEE80211_CONF_CHANGE_QOS: Quality of service was enabled or disabled
*/
enum ieee80211_conf_changed {
IEEE80211_CONF_CHANGE_SMPS = BIT(1),
^ permalink raw reply related
* Re: Google Summer of Code 2010 - Please resolve duplicates
From: Johannes Berg @ 2010-04-20 6:13 UTC (permalink / raw)
To: Till Kamppeter
Cc: Theodore Ts'o, Greg KH, Arnaldo Carvalho de Melo,
Luis R. Rodriguez, linux-kernel, linux-wireless, Witold Sowa,
Grant Likely
In-Reply-To: <4BCCB176.3060206@gmail.com>
On Mon, 2010-04-19 at 12:39 -0700, Till Kamppeter wrote:
> two students who applied for your projects have applied also for another
> organization's project and they got accepted by us and by the other
> organization.
I'm confused. How do I figure out which ones?
> Until Wednesday Google wants these situation to be resolved until
> Wednesday April 21, 17:00 UTC. Please contact the students and/or the
> organization to agree on one of the project for each student.
>
> In addition, the ranking of the students (to decide who actually gets
> our slots) and the mentor assignments have to be finalized by the same
> date and time.
>
> Duplicates not be resolved until then will be resolved on an IRC meeting
> on Wednesday April 21 at 19:00 UTC. The meeting takes place in the #gsoc
> channel on Freenode.
>
> Please mail me if a mentor needs to be (re)assigned.
Oh wow so I wasn't paying attention much after the initial ranking.
I'm certainly not qualified to mentor the ACL project, would somebody
else do that?
johannes
^ permalink raw reply
* Re: [PATCH] ath9k-htc: speedup disconnect handling
From: Ming Lei @ 2010-04-20 5:59 UTC (permalink / raw)
To: Sujith
Cc: Luis Rodriguez, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <19405.11838.119234.371361@gargle.gargle.HOWL>
2010/4/20 Sujith <Sujith.Manoharan@atheros.com>:
> tom.leiming@gmail.com wrote:
>> This patch detects the disconnect in wmi register write path,
>> then speedup the disconnect handling.
>
> What bug does this fix ? Submission of URBs in the REGOUT pipe
> should not really fail, and if it does, it is indicative of a deeper
> problem and recovery mechanisms are needed.
After the 9271 device is unplugged, you will find your machine hung for
several hundreds of milliseconds.
>
> If you do get WMI failures, can you post the relevant sections
> from the kernel log ?
If ATH_DBG_RESET is enabled, you will find the debug messages
below[1] during disconnecting. From the messages, the short hang should
be caused by the 'RTC stuck in MAC reset'. Once the patch is applied,
no such issue will happen.
[1], debug messages during 9287 disconnecting
[12873.291066] usb 2-1.3: USB disconnect, address 15
[12873.291800] device: 'ep_01': device_unregister
[12873.291809] PM: Removing info for No Bus:ep_01
[12873.292465] device: 'ep_82': device_unregister
[12873.292472] PM: Removing info for No Bus:ep_82
[12873.292654] device: 'ep_83': device_unregister
[12873.292661] PM: Removing info for No Bus:ep_83
[12873.292828] device: 'ep_04': device_unregister
[12873.292834] PM: Removing info for No Bus:ep_04
[12873.292999] device: 'ep_05': device_unregister
[12873.293431] PM: Removing info for No Bus:ep_05
[12873.293612] device: 'ep_06': device_unregister
[12873.293689] PM: Removing info for No Bus:ep_06
[12873.293868] PM: Removing info for usb:2-1.3:1.0
[12873.294338] bus: 'usb': remove device 2-1.3:1.0
[12873.294373] usb 2-1.3: __pm_runtime_resume()!
[12873.294380] usb 2-1.3: __pm_runtime_resume() returns 1!
[12873.294392] device: 'ath9k-phy12::assoc': device_unregister
[12873.294399] PM: Removing info for No Bus:ath9k-phy12::assoc
[12873.294732] device: 'ath9k-phy12::assoc': device_create_release
[12873.294771] device: 'ath9k-phy12::tx': device_unregister
[12873.294778] PM: Removing info for No Bus:ath9k-phy12::tx
[12873.295676] device: 'ath9k-phy12::tx': device_create_release
[12873.295718] device: 'ath9k-phy12::rx': device_unregister
[12873.295725] PM: Removing info for No Bus:ath9k-phy12::rx
[12873.296316] device: 'ath9k-phy12::rx': device_create_release
[12873.296351] device: 'ath9k-phy12::radio': device_unregister
[12873.296358] PM: Removing info for No Bus:ath9k-phy12::radio
[12873.296701] device: 'ath9k-phy12::radio': device_create_release
[12874.349767] ath: timeout (100000 us) on reg 0x7000: 0xfffffffb &
0x00000003 != 0x00000000
[12874.349774] ath: RTC stuck in MAC reset
[12874.349777] ath: Chip reset failed
[12874.349779] ath: Unable to reset channel (2437 Mhz) reset status -22
[12874.349784] ath: Unable to set channel
[12874.349939] ath: ah->misc_mode 0x4
[12874.350750] ath: Unable to remove station entry for: 00:03:7f:13:02:d3
[12874.352092] phy12: Removed STA 00:03:7f:13:02:d3
[12874.352224] phy12: Destroyed STA 00:03:7f:13:02:d3
[12874.352232] wlan14: deauthenticating from 00:03:7f:13:02:d3 by
local choice (reason=3)
[12874.352494] phy12: device now idle
[12875.177375] ath: timeout (100000 us) on reg 0x7000: 0xfffffffb &
0x00000003 != 0x00000000
[12875.177382] ath: RTC stuck in MAC reset
[12875.988627] ath: timeout (100000 us) on reg 0x7000: 0xfffffffb &
0x00000003 != 0x00000000
[12875.988633] ath: RTC stuck in MAC reset
[12875.988638] ath: AWAKE -> FULL-SLEEP
[12876.000157] PM: Removing info for No Bus:wlan14
[12876.005146] cfg80211: All devices are disconnected, going to
restore regulatory settings
[12876.005157] cfg80211: Restoring regulatory settings
[12876.005175] cfg80211: Calling CRDA to update world regulatory domain
[12876.006494] PM: Removing info for No Bus:rfkill13
[12876.013231] PM: Removing info for No Bus:phy12
[12876.026482] usb 2-1.3: ath9k_htc: USB layer deinitialized
[12876.027680] device: 'ep_00': device_unregister
[12876.027684] PM: Removing info for No Bus:ep_00
[12876.027781] PM: Removing info for usb:2-1.3
[12876.029678] bus: 'usb': remove device 2-1.3
[12876.045047] cfg80211: World regulatory domain updated:
[12876.045051] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[12876.045054] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[12876.045057] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[12876.045060] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[12876.045062] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[12876.045065] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[12876.144805] hub 2-1:1.0: __pm_runtime_suspend()!
[12876.144832] hub 2-1:1.0: __pm_runtime_suspend() returns 0!
[12878.705219] usb 2-1: __pm_runtime_suspend() from workqueue!
[12878.716694] usb 2-1: __pm_runtime_suspend() returns 0!
[12881.705105] usb usb2: __pm_runtime_suspend() from workqueue!
[12881.705175] usb usb2: __pm_runtime_suspend() returns 0!
--
Lei Ming
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Juuso Oikarinen @ 2010-04-20 5:08 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1271688177.23671.1.camel@jlt3.sipsolutions.net>
On Mon, 2010-04-19 at 16:42 +0200, ext Johannes Berg wrote:
> On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> > Determine the dynamic PS timeout based on the configured ps-qos network
> > latency. For backwards wext compatibility, allow the dynamic PS timeout
> > configured by the cfg80211 to overrule the automatically determined value.
>
> This seems OK, but I fear that you'll write applications setting the
> pm_qos network latency just to affect this parameter?
>
Well you have to see where I'm coming from - I must come up with a way
to tune the dynamic ps timeout value from user-space in a way that is
agreeable with others, and that is somewhat future-proof.
That said, obviously the network latency should be tuned as, well, the
expected network latency. In this phase though, there are no other
parameters affected by the network latency, so the result is quite
obvious - your fear will realise itself ;)
> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> > ---
> > include/net/mac80211.h | 5 ++++-
> > net/mac80211/cfg.c | 4 ++--
> > net/mac80211/main.c | 2 ++
> > net/mac80211/mlme.c | 14 ++++++++++++++
> > 4 files changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> > index dcf3c5f..243e4ab 100644
> > --- a/include/net/mac80211.h
> > +++ b/include/net/mac80211.h
> > @@ -661,6 +661,9 @@ enum ieee80211_smps_mode {
> > * @dynamic_ps_timeout: The dynamic powersave timeout (in ms), see the
> > * powersave documentation below. This variable is valid only when
> > * the CONF_PS flag is set.
> > + * @dynamic_ps_forced_timeout: The dynamic powersave timeout (in ms) configured
> > + * by cfg80211 (essentially, wext) If set, this value overrules the value
> > + * chosen by mac80211 based on ps qos network latency.
> > *
> > * @power_level: requested transmit power (in dBm)
> > *
> > @@ -680,7 +683,7 @@ enum ieee80211_smps_mode {
> > */
> > struct ieee80211_conf {
> > u32 flags;
> > - int power_level, dynamic_ps_timeout;
> > + int power_level, dynamic_ps_timeout, dynamic_ps_forced_timeout;
> > int max_sleep_period;
> >
> > u16 listen_interval;
> > diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> > index 7dd7cda..9a1a91c 100644
> > --- a/net/mac80211/cfg.c
> > +++ b/net/mac80211/cfg.c
> > @@ -1388,11 +1388,11 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
> > return -EOPNOTSUPP;
> >
> > if (enabled == sdata->u.mgd.powersave &&
> > - timeout == conf->dynamic_ps_timeout)
> > + timeout == conf->dynamic_ps_forced_timeout)
> > return 0;
> >
> > sdata->u.mgd.powersave = enabled;
> > - conf->dynamic_ps_timeout = timeout;
> > + conf->dynamic_ps_forced_timeout = timeout;
> >
> > /* no change, but if automatic follow powersave */
> > mutex_lock(&sdata->u.mgd.mtx);
> > diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> > index 4afe851..ebcca0e 100644
> > --- a/net/mac80211/main.c
> > +++ b/net/mac80211/main.c
> > @@ -569,6 +569,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> >
> > local->hw.conf.listen_interval = local->hw.max_listen_interval;
> >
> > + local->hw.conf.dynamic_ps_forced_timeout = -1;
> > +
> > result = sta_info_start(local);
> > if (result < 0)
> > goto fail_sta_info;
> > diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> > index 35d8502..6402997 100644
> > --- a/net/mac80211/mlme.c
> > +++ b/net/mac80211/mlme.c
> > @@ -476,6 +476,7 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
> > {
> > struct ieee80211_sub_if_data *sdata, *found = NULL;
> > int count = 0;
> > + int timeout;
> >
> > if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_PS)) {
> > local->ps_sdata = NULL;
> > @@ -509,6 +510,19 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
> > beaconint_us = ieee80211_tu_to_usec(
> > found->vif.bss_conf.beacon_int);
> >
> > + timeout = local->hw.conf.dynamic_ps_forced_timeout;
> > + if (timeout < 0) {
> > + if (latency <= 50000)
> > + timeout = 300;
> > + else if (latency <= 2000000000)
> > + timeout = 100;
> > + else if (latency <= 2100000000)
> > + timeout = 50;
> > + else
> > + timeout = 0;
>
> Is it even possible to set it larger than 2000 seconds?
Good question. I have not yet had the opportunity to test this, so I
can't tell. You could be right. ;)
-Juuso
> johannes
>
^ permalink raw reply
* Re: [RFC PATCHv3 2/2] cfg80211: Remove default dynamic PS timeout value
From: Juuso Oikarinen @ 2010-04-20 4:58 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1271688229.23671.2.camel@jlt3.sipsolutions.net>
On Mon, 2010-04-19 at 16:43 +0200, ext Johannes Berg wrote:
> On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> > Now that the mac80211 is choosing dynamic ps timeouts based on the ps-qos
> > network latency configuration, configure a default value of -1 as the dynamic
> > ps timeout in cfg80211. This value allows the mac80211 to determine the value
> > to be used.
> >
> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> > ---
> > net/wireless/core.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/wireless/core.c b/net/wireless/core.c
> > index 6ac70c1..37d0e0a 100644
> > --- a/net/wireless/core.c
> > +++ b/net/wireless/core.c
> > @@ -705,7 +705,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block * nb,
> > wdev->ps = true;
> > else
> > wdev->ps = false;
> > - wdev->ps_timeout = 100;
> > + /* allow mac80211 to determine the timeout */
> > + wdev->ps_timeout = -1;
> > if (rdev->ops->set_power_mgmt)
> > if (rdev->ops->set_power_mgmt(wdev->wiphy, dev,
> > wdev->ps,
>
> Does that need some API doc updates to indicate, as part of the cfg80211
> API, that -1 means some way of setting it by default?
>
> Or actually, wouldn't it make sense to move the pm_qos logic here (into
> cfg80211)?
I thought about that but then I realised that would contradict with one
of the arguments presented against the dynamic ps API I proposed
earlier. The argument specifically stated we don't want the API as in
the future there will be some uber-cool psm implementations in some
(full-mac?) chipsets that don't even use a value like this.
Therefore I opted to leave the implementation in mac80211, thinking that
the entire configuration option will be removed from the cfg80211 once
the wext is gone.
-Juuso
> johannes
>
^ permalink raw reply
* [PATCH] ath9k-htc: speedup disconnect handling
From: Sujith @ 2010-04-20 4:31 UTC (permalink / raw)
To: tom.leiming@gmail.com
Cc: Luis Rodriguez, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <1271691883-13133-1-git-send-email-tom.leiming@gmail.com>
tom.leiming@gmail.com wrote:
> This patch detects the disconnect in wmi register write path,
> then speedup the disconnect handling.
What bug does this fix ? Submission of URBs in the REGOUT pipe
should not really fail, and if it does, it is indicative of a deeper
problem and recovery mechanisms are needed.
If you do get WMI failures, can you post the relevant sections
from the kernel log ?
Sujith
^ permalink raw reply
* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Rafael J. Wysocki @ 2010-04-20 4:13 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Kernel Mailing List, Maciej Rutecki, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <20100419205723.8724338c.akpm@linux-foundation.org>
On Tuesday 20 April 2010, Andrew Morton wrote:
> On Tue, 20 Apr 2010 05:15:57 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15812
> > Subject : utsname.domainname not set in x86_32 processes (causing "YPBINDPROC_DOMAIN: domain not bound" errors)
> > Submitter : <adi@hexapodia.org>
> > Date : 2010-04-19 21:28 (1 days old)
>
> I merged hch's fix for this twelve seconds ago.
I updated the entry.
^ permalink raw reply
* Re: 2.6.34-rc5: Reported regressions from 2.6.33
From: Andrew Morton @ 2010-04-20 0:57 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Maciej Rutecki, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <deuQKFRcc0B.A.3EG.BRSzLB@tosh>
On Tue, 20 Apr 2010 05:15:57 +0200 (CEST) "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15812
> Subject : utsname.domainname not set in x86_32 processes (causing "YPBINDPROC_DOMAIN: domain not bound" errors)
> Submitter : <adi@hexapodia.org>
> Date : 2010-04-19 21:28 (1 days old)
I merged hch's fix for this twelve seconds ago.
^ 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