* Re: cfg80211 / libertas: an unusual race
From: Johannes Berg @ 2009-10-27 10:15 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <1256201277.12174.17.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
On Thu, 2009-10-22 at 10:47 +0200, Johannes Berg wrote:
> On Fri, 2009-10-16 at 14:03 +0200, Holger Schurig wrote:
> > > I don't see this happening that way -- how are you even getting
> > to
> > > __cfg80211_disconnected() if not through _send_deauth()?
> >
> > See step 7a in the second table. We got there via
> > _send_deauth().
> >
> > But later, step 3b in the second table (I kept the original
> > numbers, so 3b happens after 7a time-wise!) we got into
> > WARN_ON().
>
> Still not making sense to me, since cfg80211_mlme_deauth() never does
> anything after calling you.
Ok, so I can see that this might happen as a result of a call to
__cfg80211_disconnect(), and I think the patch is correct.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* AW: [PATCH] mac80211: fix for incorrect sequence number on hostapd injected frames
From: Joerg Pommnitz @ 2009-10-27 11:09 UTC (permalink / raw)
To: Björn Smedman, linville
Cc: linux-wireless, Johannes Berg, Jouni Malinen, Will Dyson
In-Reply-To: <133e8d7e0910241155x4496b156p3c5d03450a71936a@mail.gmail.com>
I just applied the patch. So far, everything looks fine.
Thanks
Joerg
----- Ursprüngliche Mail ----
> Von: Björn Smedman <bjorn.smedman@venatech.se>
> An: linville@tuxdriver.com
> CC: linux-wireless@vger.kernel.org; Johannes Berg <johannes@sipsolutions.net>; Jouni Malinen <j@w1.fi>; Joerg Pommnitz <pommnitz@yahoo.com>; Will Dyson <will.dyson@gmail.com>
> Gesendet: Samstag, den 24. Oktober 2009, 20:55:09 Uhr
> Betreff: [PATCH] mac80211: fix for incorrect sequence number on hostapd injected frames
>
> When hostapd injects a frame, e.g. an authentication or association
> response, mac80211 looks for a suitable access point virtual interface
> to associate the frame with based on its source address. This makes it
> possible e.g. to correctly assign sequence numbers to the frames.
>
> A small typo in the ethernet address comparison statement caused a
> failure to find a suitable ap interface. Sequence numbers on such
> frames where therefore left unassigned causing some clients
> (especially windows-based 11b/g clients) to reject them and fail to
> authenticate or associate with the access point. This patch fixes the
> typo in the address comparison statement.
>
> Signed-off-by: Björn Smedman
Tested-by: Joerg Pommnitz <pommnitz@yahoo.com>
> ---
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index db4bda6..eaa4118 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1445,7 +1445,7 @@ static void ieee80211_xmit(struct
> ieee80211_sub_if_data *sdata,
> if (tmp_sdata->vif.type != NL80211_IFTYPE_AP)
> continue;
> if (compare_ether_addr(tmp_sdata->dev->dev_addr,
> - hdr->addr2)) {
> + hdr->addr2) == 0) {
> dev_hold(tmp_sdata->dev);
> dev_put(sdata->dev);
> sdata = tmp_sdata;
^ permalink raw reply
* Re: ath5k phy0: no further txbuf available, dropping packet
From: Michael Buesch @ 2009-10-27 10:29 UTC (permalink / raw)
To: Bob Copeland
Cc: dsrbecky, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
linux-wireless
In-Reply-To: <20091027100926.GA13391@hash.localnet>
On Tuesday 27 October 2009 11:09:26 Bob Copeland wrote:
> On Mon, Oct 26, 2009 at 10:30:55PM +0100, Michael Buesch wrote:
> > /* No frame has been send or error */
> > if (unlikely(!(tx_status->tx_status_1 & AR5K_DESC_TX_STATUS1_DONE)))
> > return -EINPROGRESS;
> > ...
> > }
>
> > Notice the comment and how it says "or error".
>
> Hmm, that does sound problematic. But looking at the various bitfields:
>
> #define AR5K_DESC_TX_STATUS1_DONE 0x00000001
> #define AR5K_DESC_TX_STATUS1_SEQ_NUM 0x00001ffe
> #define AR5K_DESC_TX_STATUS1_ACK_SIG_STRENGTH 0x001fe000
> #define AR5K_DESC_TX_STATUS1_FINAL_TS_INDEX 0x00600000
> #define AR5K_DESC_TX_STATUS1_COMP_SUCCESS 0x00800000
> #define AR5K_DESC_TX_STATUS1_XMIT_ANTENNA 0x01000000
>
> I would be led to believe that 'done' means 'completed or error' and
> the comment is similarly ambiguous. The status0 word contains things
> like 'really did succeed, number of retries, timestamp' etc.
Hm, I looked through the whole status processing code and this is the only
place I can see that could trigger stalling of the buffer head queue.
If the lowlevel status handler is able to distinguish between "done", "error" and "not done yet",
the return codes should probably changed:
0 => Packet was properly processed.
The upper status handler will free it
-INPROGRESS => Packet was not processed, yet.
The upper status handler should bail out and wait.
ERROR => Packet failed.
The upper status handler should drop the packet
and go on processing the other frames.
If that's not the case, I don't really know what's happening.
--
Greetings, Michael.
^ permalink raw reply
* Re: ath5k phy0: no further txbuf available, dropping packet
From: Bob Copeland @ 2009-10-27 10:09 UTC (permalink / raw)
To: Michael Buesch
Cc: dsrbecky, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
linux-wireless
In-Reply-To: <200910262230.57957.mb@bu3sch.de>
On Mon, Oct 26, 2009 at 10:30:55PM +0100, Michael Buesch wrote:
> /* No frame has been send or error */
> if (unlikely(!(tx_status->tx_status_1 & AR5K_DESC_TX_STATUS1_DONE)))
> return -EINPROGRESS;
> ...
> }
> Notice the comment and how it says "or error".
Hmm, that does sound problematic. But looking at the various bitfields:
#define AR5K_DESC_TX_STATUS1_DONE 0x00000001
#define AR5K_DESC_TX_STATUS1_SEQ_NUM 0x00001ffe
#define AR5K_DESC_TX_STATUS1_ACK_SIG_STRENGTH 0x001fe000
#define AR5K_DESC_TX_STATUS1_FINAL_TS_INDEX 0x00600000
#define AR5K_DESC_TX_STATUS1_COMP_SUCCESS 0x00800000
#define AR5K_DESC_TX_STATUS1_XMIT_ANTENNA 0x01000000
I would be led to believe that 'done' means 'completed or error' and
the comment is similarly ambiguous. The status0 word contains things
like 'really did succeed, number of retries, timestamp' etc.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: RECAP: indication of channel noise
From: Johannes Berg @ 2009-10-27 7:03 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Holger Schurig, linux-wireless, Felix Fietkau
In-Reply-To: <20091027034514.GA20995@jm.kir.nu>
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
On Mon, 2009-10-26 at 20:45 -0700, Jouni Malinen wrote:
> On Mon, Oct 26, 2009 at 02:42:44PM +0100, Holger Schurig wrote:
>
> > The idea is to have one API call "do site survey", where you tell
> > the driver to scan on specified/all channels to determine those
> > values.
>
> What would this command be? Just the existing scan trigger command with
> a new attribute indicating that site survey is requested? In my first
> use case (select best channel for an AP), I would like to combine the
> normal scan (get all BSSes) and site survey (get tx/rx/idle hw counters
> for each channel). Fetching the site survey data with a new command
> would be fine, but trigger command should be shared.
That was my thinking (shared trigger) as well. Fetching the data cannot
be done with the same command anyway.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Johannes Berg @ 2009-10-27 7:01 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Jarek Poplawski, David Miller, hidave.darkstar, linux-kernel,
tglx, linux-wireless, linux-ppp, netdev, paulus, Michael Buesch,
Oliver Hartkopp
In-Reply-To: <4AE64441.7060008@imap.cc>
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
On Tue, 2009-10-27 at 01:52 +0100, Tilman Schmidt wrote:
> > Any code (say ISDN code) that calls netif_rx() is clearly assuming to
> > always be running in (soft)irq context, otherwise it couldn't call
> > netif_rx() unconditionally. Agree so far?
>
> Well, in fact I'm not sure. :-) All I know is that in the ISDN case, no
> such assumption is explicitly stated anywhere. (The code in question is
> called from the rcvcallb_skb() callback method which the hardware driver
> calls when data has been received, and the description of that method in
> Documentation/isdn/INTERFACE does not say anything about the context in
> which it may be called.) The relevant code in drivers/isdn/i4l/isdn_ppp.c
> is rather old, perhaps even older than softirqs and the netif_rx() /
> netif_rx_ni() split. (Bear in mind that we are talking about the old
> ISDN4Linux subsystem which initially didn't even make it into the 2.6
> series because it was considered obsolete.) It seems quite possible to me
> that just no one ever thought about that question.
Heh :)
> > So now if you change the ISDN code to call netif_rx_ni(), you've changed
> > the assumption that the ISDN code makes -- that it is running in
> > (soft)irq context. Therefore, you need to verify that this is actually a
> > correct change, which is what I tried to say.
>
> Understood. However, the fact that the local_softirq_pending message is
> appearing would seem to indicate that this assumption was wrong to
> begin with, wouldn't it?
I thought it only recently started appearing with a new driver or
something, but I may have misunderstood you. Anyway, I think that sums
up the issue from my POV.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] ath: Updates for regulatory and country codes.
From: Vivek Natarajan @ 2009-10-27 6:02 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Add a few new country codes and update the regulatory domain for some
countries.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/regd.h | 8 ++++++++
drivers/net/wireless/ath/regd_common.h | 32 ++++++++++++++++++++------------
2 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index c1dd857..a1c3952 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -65,10 +65,13 @@ enum CountryCode {
CTRY_ALGERIA = 12,
CTRY_ARGENTINA = 32,
CTRY_ARMENIA = 51,
+ CTRY_ARUBA = 533,
CTRY_AUSTRALIA = 36,
CTRY_AUSTRIA = 40,
CTRY_AZERBAIJAN = 31,
CTRY_BAHRAIN = 48,
+ CTRY_BANGLADESH = 50,
+ CTRY_BARBADOS = 52,
CTRY_BELARUS = 112,
CTRY_BELGIUM = 56,
CTRY_BELIZE = 84,
@@ -77,6 +80,7 @@ enum CountryCode {
CTRY_BRAZIL = 76,
CTRY_BRUNEI_DARUSSALAM = 96,
CTRY_BULGARIA = 100,
+ CTRY_CAMBODIA = 116,
CTRY_CANADA = 124,
CTRY_CHILE = 152,
CTRY_CHINA = 156,
@@ -97,7 +101,11 @@ enum CountryCode {
CTRY_GEORGIA = 268,
CTRY_GERMANY = 276,
CTRY_GREECE = 300,
+ CTRY_GREENLAND = 304,
+ CTRY_GRENEDA = 308,
+ CTRY_GUAM = 316,
CTRY_GUATEMALA = 320,
+ CTRY_HAITI = 332,
CTRY_HONDURAS = 340,
CTRY_HONG_KONG = 344,
CTRY_HUNGARY = 348,
diff --git a/drivers/net/wireless/ath/regd_common.h b/drivers/net/wireless/ath/regd_common.h
index 9847af7..248c670 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -288,13 +288,16 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_DEFAULT, FCC1_FCCA, "CO"},
{CTRY_ALBANIA, NULL1_WORLD, "AL"},
{CTRY_ALGERIA, NULL1_WORLD, "DZ"},
- {CTRY_ARGENTINA, APL3_WORLD, "AR"},
+ {CTRY_ARGENTINA, FCC3_WORLD, "AR"},
{CTRY_ARMENIA, ETSI4_WORLD, "AM"},
+ {CTRY_ARUBA, ETSI1_WORLD, "AW"},
{CTRY_AUSTRALIA, FCC2_WORLD, "AU"},
{CTRY_AUSTRALIA2, FCC6_WORLD, "AU"},
{CTRY_AUSTRIA, ETSI1_WORLD, "AT"},
{CTRY_AZERBAIJAN, ETSI4_WORLD, "AZ"},
{CTRY_BAHRAIN, APL6_WORLD, "BH"},
+ {CTRY_BANGLADESH, NULL1_WORLD, "BD"},
+ {CTRY_BARBADOS, FCC2_WORLD, "BB"},
{CTRY_BELARUS, ETSI1_WORLD, "BY"},
{CTRY_BELGIUM, ETSI1_WORLD, "BE"},
{CTRY_BELGIUM2, ETSI4_WORLD, "BL"},
@@ -304,13 +307,14 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_BRAZIL, FCC3_WORLD, "BR"},
{CTRY_BRUNEI_DARUSSALAM, APL1_WORLD, "BN"},
{CTRY_BULGARIA, ETSI6_WORLD, "BG"},
- {CTRY_CANADA, FCC2_FCCA, "CA"},
+ {CTRY_CAMBODIA, ETSI1_WORLD, "KH"},
+ {CTRY_CANADA, FCC3_FCCA, "CA"},
{CTRY_CANADA2, FCC6_FCCA, "CA"},
{CTRY_CHILE, APL6_WORLD, "CL"},
{CTRY_CHINA, APL1_WORLD, "CN"},
{CTRY_COLOMBIA, FCC1_FCCA, "CO"},
{CTRY_COSTA_RICA, FCC1_WORLD, "CR"},
- {CTRY_CROATIA, ETSI3_WORLD, "HR"},
+ {CTRY_CROATIA, ETSI1_WORLD, "HR"},
{CTRY_CYPRUS, ETSI1_WORLD, "CY"},
{CTRY_CZECH, ETSI3_WORLD, "CZ"},
{CTRY_DENMARK, ETSI1_WORLD, "DK"},
@@ -324,18 +328,22 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_GEORGIA, ETSI4_WORLD, "GE"},
{CTRY_GERMANY, ETSI1_WORLD, "DE"},
{CTRY_GREECE, ETSI1_WORLD, "GR"},
+ {CTRY_GREENLAND, ETSI1_WORLD, "GL"},
+ {CTRY_GRENEDA, FCC3_FCCA, "GD"},
+ {CTRY_GUAM, FCC1_FCCA, "GU"},
{CTRY_GUATEMALA, FCC1_FCCA, "GT"},
+ {CTRY_HAITI, ETSI1_WORLD, "HT"},
{CTRY_HONDURAS, NULL1_WORLD, "HN"},
- {CTRY_HONG_KONG, FCC2_WORLD, "HK"},
+ {CTRY_HONG_KONG, FCC3_WORLD, "HK"},
{CTRY_HUNGARY, ETSI1_WORLD, "HU"},
{CTRY_ICELAND, ETSI1_WORLD, "IS"},
{CTRY_INDIA, APL6_WORLD, "IN"},
- {CTRY_INDONESIA, APL1_WORLD, "ID"},
+ {CTRY_INDONESIA, NULL1_WORLD, "ID"},
{CTRY_IRAN, APL1_WORLD, "IR"},
{CTRY_IRELAND, ETSI1_WORLD, "IE"},
{CTRY_ISRAEL, NULL1_WORLD, "IL"},
{CTRY_ITALY, ETSI1_WORLD, "IT"},
- {CTRY_JAMAICA, ETSI1_WORLD, "JM"},
+ {CTRY_JAMAICA, FCC3_WORLD, "JM"},
{CTRY_JAPAN, MKK1_MKKA, "JP"},
{CTRY_JAPAN1, MKK1_MKKB, "JP"},
@@ -402,7 +410,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_KOREA_ROC, APL9_WORLD, "KR"},
{CTRY_KOREA_ROC2, APL2_WORLD, "K2"},
{CTRY_KOREA_ROC3, APL9_WORLD, "K3"},
- {CTRY_KUWAIT, NULL1_WORLD, "KW"},
+ {CTRY_KUWAIT, ETSI3_WORLD, "KW"},
{CTRY_LATVIA, ETSI1_WORLD, "LV"},
{CTRY_LEBANON, NULL1_WORLD, "LB"},
{CTRY_LIECHTENSTEIN, ETSI1_WORLD, "LI"},
@@ -414,13 +422,13 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_MALTA, ETSI1_WORLD, "MT"},
{CTRY_MEXICO, FCC1_FCCA, "MX"},
{CTRY_MONACO, ETSI4_WORLD, "MC"},
- {CTRY_MOROCCO, NULL1_WORLD, "MA"},
+ {CTRY_MOROCCO, APL4_WORLD, "MA"},
{CTRY_NEPAL, APL1_WORLD, "NP"},
{CTRY_NETHERLANDS, ETSI1_WORLD, "NL"},
{CTRY_NETHERLANDS_ANTILLES, ETSI1_WORLD, "AN"},
{CTRY_NEW_ZEALAND, FCC2_ETSIC, "NZ"},
{CTRY_NORWAY, ETSI1_WORLD, "NO"},
- {CTRY_OMAN, APL6_WORLD, "OM"},
+ {CTRY_OMAN, FCC3_WORLD, "OM"},
{CTRY_PAKISTAN, NULL1_WORLD, "PK"},
{CTRY_PANAMA, FCC1_FCCA, "PA"},
{CTRY_PAPUA_NEW_GUINEA, FCC1_WORLD, "PG"},
@@ -429,7 +437,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_POLAND, ETSI1_WORLD, "PL"},
{CTRY_PORTUGAL, ETSI1_WORLD, "PT"},
{CTRY_PUERTO_RICO, FCC1_FCCA, "PR"},
- {CTRY_QATAR, NULL1_WORLD, "QA"},
+ {CTRY_QATAR, APL1_WORLD, "QA"},
{CTRY_ROMANIA, NULL1_WORLD, "RO"},
{CTRY_RUSSIA, NULL1_WORLD, "RU"},
{CTRY_SAUDI_ARABIA, NULL1_WORLD, "SA"},
@@ -445,7 +453,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_SYRIA, NULL1_WORLD, "SY"},
{CTRY_TAIWAN, APL3_FCCA, "TW"},
{CTRY_THAILAND, FCC3_WORLD, "TH"},
- {CTRY_TRINIDAD_Y_TOBAGO, ETSI4_WORLD, "TT"},
+ {CTRY_TRINIDAD_Y_TOBAGO, FCC3_WORLD, "TT"},
{CTRY_TUNISIA, ETSI3_WORLD, "TN"},
{CTRY_TURKEY, ETSI3_WORLD, "TR"},
{CTRY_UKRAINE, NULL1_WORLD, "UA"},
@@ -456,7 +464,7 @@ static struct country_code_to_enum_rd allCountries[] = {
* would need to assign new special alpha2 to CRDA db as with the world
* regdomain and use another alpha2 */
{CTRY_UNITED_STATES_FCC49, FCC4_FCCA, "PS"},
- {CTRY_URUGUAY, APL2_WORLD, "UY"},
+ {CTRY_URUGUAY, FCC3_WORLD, "UY"},
{CTRY_UZBEKISTAN, FCC3_FCCA, "UZ"},
{CTRY_VENEZUELA, APL2_ETSIC, "VE"},
{CTRY_VIET_NAM, NULL1_WORLD, "VN"},
--
1.6.5.1
^ permalink raw reply related
* Re: [PATCH] ath9k: Updates for regulatory and country codes.
From: Vivek Natarajan @ 2009-10-27 6:02 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <20091027055731.GA6153@vivek-laptop>
On Tue, Oct 27, 2009 at 11:27 AM, Vivek Natarajan
<vivek.natraj@gmail.com> wrote:
> Add a few new country codes and update the regulatory domain for some
> countries.
>
> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
I will change the subject line to ath instead of ath9k and send it once again.
Thanks
Vivek.
^ permalink raw reply
* [PATCH] ath9k: Updates for regulatory and country codes.
From: Vivek Natarajan @ 2009-10-27 5:57 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Add a few new country codes and update the regulatory domain for some
countries.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/regd.h | 8 ++++++++
drivers/net/wireless/ath/regd_common.h | 32 ++++++++++++++++++++------------
2 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index c1dd857..a1c3952 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -65,10 +65,13 @@ enum CountryCode {
CTRY_ALGERIA = 12,
CTRY_ARGENTINA = 32,
CTRY_ARMENIA = 51,
+ CTRY_ARUBA = 533,
CTRY_AUSTRALIA = 36,
CTRY_AUSTRIA = 40,
CTRY_AZERBAIJAN = 31,
CTRY_BAHRAIN = 48,
+ CTRY_BANGLADESH = 50,
+ CTRY_BARBADOS = 52,
CTRY_BELARUS = 112,
CTRY_BELGIUM = 56,
CTRY_BELIZE = 84,
@@ -77,6 +80,7 @@ enum CountryCode {
CTRY_BRAZIL = 76,
CTRY_BRUNEI_DARUSSALAM = 96,
CTRY_BULGARIA = 100,
+ CTRY_CAMBODIA = 116,
CTRY_CANADA = 124,
CTRY_CHILE = 152,
CTRY_CHINA = 156,
@@ -97,7 +101,11 @@ enum CountryCode {
CTRY_GEORGIA = 268,
CTRY_GERMANY = 276,
CTRY_GREECE = 300,
+ CTRY_GREENLAND = 304,
+ CTRY_GRENEDA = 308,
+ CTRY_GUAM = 316,
CTRY_GUATEMALA = 320,
+ CTRY_HAITI = 332,
CTRY_HONDURAS = 340,
CTRY_HONG_KONG = 344,
CTRY_HUNGARY = 348,
diff --git a/drivers/net/wireless/ath/regd_common.h b/drivers/net/wireless/ath/regd_common.h
index 9847af7..248c670 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -288,13 +288,16 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_DEFAULT, FCC1_FCCA, "CO"},
{CTRY_ALBANIA, NULL1_WORLD, "AL"},
{CTRY_ALGERIA, NULL1_WORLD, "DZ"},
- {CTRY_ARGENTINA, APL3_WORLD, "AR"},
+ {CTRY_ARGENTINA, FCC3_WORLD, "AR"},
{CTRY_ARMENIA, ETSI4_WORLD, "AM"},
+ {CTRY_ARUBA, ETSI1_WORLD, "AW"},
{CTRY_AUSTRALIA, FCC2_WORLD, "AU"},
{CTRY_AUSTRALIA2, FCC6_WORLD, "AU"},
{CTRY_AUSTRIA, ETSI1_WORLD, "AT"},
{CTRY_AZERBAIJAN, ETSI4_WORLD, "AZ"},
{CTRY_BAHRAIN, APL6_WORLD, "BH"},
+ {CTRY_BANGLADESH, NULL1_WORLD, "BD"},
+ {CTRY_BARBADOS, FCC2_WORLD, "BB"},
{CTRY_BELARUS, ETSI1_WORLD, "BY"},
{CTRY_BELGIUM, ETSI1_WORLD, "BE"},
{CTRY_BELGIUM2, ETSI4_WORLD, "BL"},
@@ -304,13 +307,14 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_BRAZIL, FCC3_WORLD, "BR"},
{CTRY_BRUNEI_DARUSSALAM, APL1_WORLD, "BN"},
{CTRY_BULGARIA, ETSI6_WORLD, "BG"},
- {CTRY_CANADA, FCC2_FCCA, "CA"},
+ {CTRY_CAMBODIA, ETSI1_WORLD, "KH"},
+ {CTRY_CANADA, FCC3_FCCA, "CA"},
{CTRY_CANADA2, FCC6_FCCA, "CA"},
{CTRY_CHILE, APL6_WORLD, "CL"},
{CTRY_CHINA, APL1_WORLD, "CN"},
{CTRY_COLOMBIA, FCC1_FCCA, "CO"},
{CTRY_COSTA_RICA, FCC1_WORLD, "CR"},
- {CTRY_CROATIA, ETSI3_WORLD, "HR"},
+ {CTRY_CROATIA, ETSI1_WORLD, "HR"},
{CTRY_CYPRUS, ETSI1_WORLD, "CY"},
{CTRY_CZECH, ETSI3_WORLD, "CZ"},
{CTRY_DENMARK, ETSI1_WORLD, "DK"},
@@ -324,18 +328,22 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_GEORGIA, ETSI4_WORLD, "GE"},
{CTRY_GERMANY, ETSI1_WORLD, "DE"},
{CTRY_GREECE, ETSI1_WORLD, "GR"},
+ {CTRY_GREENLAND, ETSI1_WORLD, "GL"},
+ {CTRY_GRENEDA, FCC3_FCCA, "GD"},
+ {CTRY_GUAM, FCC1_FCCA, "GU"},
{CTRY_GUATEMALA, FCC1_FCCA, "GT"},
+ {CTRY_HAITI, ETSI1_WORLD, "HT"},
{CTRY_HONDURAS, NULL1_WORLD, "HN"},
- {CTRY_HONG_KONG, FCC2_WORLD, "HK"},
+ {CTRY_HONG_KONG, FCC3_WORLD, "HK"},
{CTRY_HUNGARY, ETSI1_WORLD, "HU"},
{CTRY_ICELAND, ETSI1_WORLD, "IS"},
{CTRY_INDIA, APL6_WORLD, "IN"},
- {CTRY_INDONESIA, APL1_WORLD, "ID"},
+ {CTRY_INDONESIA, NULL1_WORLD, "ID"},
{CTRY_IRAN, APL1_WORLD, "IR"},
{CTRY_IRELAND, ETSI1_WORLD, "IE"},
{CTRY_ISRAEL, NULL1_WORLD, "IL"},
{CTRY_ITALY, ETSI1_WORLD, "IT"},
- {CTRY_JAMAICA, ETSI1_WORLD, "JM"},
+ {CTRY_JAMAICA, FCC3_WORLD, "JM"},
{CTRY_JAPAN, MKK1_MKKA, "JP"},
{CTRY_JAPAN1, MKK1_MKKB, "JP"},
@@ -402,7 +410,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_KOREA_ROC, APL9_WORLD, "KR"},
{CTRY_KOREA_ROC2, APL2_WORLD, "K2"},
{CTRY_KOREA_ROC3, APL9_WORLD, "K3"},
- {CTRY_KUWAIT, NULL1_WORLD, "KW"},
+ {CTRY_KUWAIT, ETSI3_WORLD, "KW"},
{CTRY_LATVIA, ETSI1_WORLD, "LV"},
{CTRY_LEBANON, NULL1_WORLD, "LB"},
{CTRY_LIECHTENSTEIN, ETSI1_WORLD, "LI"},
@@ -414,13 +422,13 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_MALTA, ETSI1_WORLD, "MT"},
{CTRY_MEXICO, FCC1_FCCA, "MX"},
{CTRY_MONACO, ETSI4_WORLD, "MC"},
- {CTRY_MOROCCO, NULL1_WORLD, "MA"},
+ {CTRY_MOROCCO, APL4_WORLD, "MA"},
{CTRY_NEPAL, APL1_WORLD, "NP"},
{CTRY_NETHERLANDS, ETSI1_WORLD, "NL"},
{CTRY_NETHERLANDS_ANTILLES, ETSI1_WORLD, "AN"},
{CTRY_NEW_ZEALAND, FCC2_ETSIC, "NZ"},
{CTRY_NORWAY, ETSI1_WORLD, "NO"},
- {CTRY_OMAN, APL6_WORLD, "OM"},
+ {CTRY_OMAN, FCC3_WORLD, "OM"},
{CTRY_PAKISTAN, NULL1_WORLD, "PK"},
{CTRY_PANAMA, FCC1_FCCA, "PA"},
{CTRY_PAPUA_NEW_GUINEA, FCC1_WORLD, "PG"},
@@ -429,7 +437,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_POLAND, ETSI1_WORLD, "PL"},
{CTRY_PORTUGAL, ETSI1_WORLD, "PT"},
{CTRY_PUERTO_RICO, FCC1_FCCA, "PR"},
- {CTRY_QATAR, NULL1_WORLD, "QA"},
+ {CTRY_QATAR, APL1_WORLD, "QA"},
{CTRY_ROMANIA, NULL1_WORLD, "RO"},
{CTRY_RUSSIA, NULL1_WORLD, "RU"},
{CTRY_SAUDI_ARABIA, NULL1_WORLD, "SA"},
@@ -445,7 +453,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_SYRIA, NULL1_WORLD, "SY"},
{CTRY_TAIWAN, APL3_FCCA, "TW"},
{CTRY_THAILAND, FCC3_WORLD, "TH"},
- {CTRY_TRINIDAD_Y_TOBAGO, ETSI4_WORLD, "TT"},
+ {CTRY_TRINIDAD_Y_TOBAGO, FCC3_WORLD, "TT"},
{CTRY_TUNISIA, ETSI3_WORLD, "TN"},
{CTRY_TURKEY, ETSI3_WORLD, "TR"},
{CTRY_UKRAINE, NULL1_WORLD, "UA"},
@@ -456,7 +464,7 @@ static struct country_code_to_enum_rd allCountries[] = {
* would need to assign new special alpha2 to CRDA db as with the world
* regdomain and use another alpha2 */
{CTRY_UNITED_STATES_FCC49, FCC4_FCCA, "PS"},
- {CTRY_URUGUAY, APL2_WORLD, "UY"},
+ {CTRY_URUGUAY, FCC3_WORLD, "UY"},
{CTRY_UZBEKISTAN, FCC3_FCCA, "UZ"},
{CTRY_VENEZUELA, APL2_ETSIC, "VE"},
{CTRY_VIET_NAM, NULL1_WORLD, "VN"},
--
1.6.5.1
^ permalink raw reply related
* Re: ath5k, too high output power?
From: Denys Fedoryschenko @ 2009-10-27 3:47 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <43e72e890910262025me2acd0ekacd9ac4224ba9386@mail.gmail.com>
On Tuesday 27 October 2009 05:25:44 Luis R. Rodriguez wrote:
>
> How do we do this for windows then?
>
You are right. I search in registry and .inf files, there is nothing vendor
specific. Most probably what is exist now - enough for laptops.
^ permalink raw reply
* Re: RECAP: indication of channel noise
From: Jouni Malinen @ 2009-10-27 3:45 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, Johannes Berg, Felix Fietkau
In-Reply-To: <200910261442.44774.h.schurig@mn-solutions.de>
On Mon, Oct 26, 2009 at 02:42:44PM +0100, Holger Schurig wrote:
> The idea is to have one API call "do site survey", where you tell
> the driver to scan on specified/all channels to determine those
> values.
What would this command be? Just the existing scan trigger command with
a new attribute indicating that site survey is requested? In my first
use case (select best channel for an AP), I would like to combine the
normal scan (get all BSSes) and site survey (get tx/rx/idle hw counters
for each channel). Fetching the site survey data with a new command
would be fine, but trigger command should be shared.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: ath5k, too high output power?
From: Luis R. Rodriguez @ 2009-10-27 3:25 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <200910270518.18181.denys@visp.net.lb>
On Mon, Oct 26, 2009 at 8:18 PM, Denys Fedoryschenko <denys@visp.net.lb> wrote:
> On Tuesday 27 October 2009 05:14:27 Luis R. Rodriguez wrote:
>> ath5k and madwifi are very different.
> I know, but as i know there no way to know to which connector vendor plugged
> antenna cable.
How do we do this for windows then?
Luis
^ permalink raw reply
* Re: ath5k, too high output power?
From: Denys Fedoryschenko @ 2009-10-27 3:18 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <43e72e890910262014y77ef048do965a76ab423c2db6@mail.gmail.com>
On Tuesday 27 October 2009 05:14:27 Luis R. Rodriguez wrote:
> ath5k and madwifi are very different.
I know, but as i know there no way to know to which connector vendor plugged
antenna cable.
^ permalink raw reply
* Re: ath5k, too high output power?
From: Luis R. Rodriguez @ 2009-10-27 3:14 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <200910270508.29029.denys@visp.net.lb>
On Mon, Oct 26, 2009 at 8:08 PM, Denys Fedoryschenko <denys@visp.net.lb> wrote:
> On Tuesday 27 October 2009 04:59:20 Luis R. Rodriguez wrote:
>> You mean can you do antenna diversity and select this manually ? I am
>> not sure, but I doubt it, should be easy to add though.
>
> Yes, on some laptops wireless card connected really weird way. And while on
> Windows everything worked fine, on Linux signal was too weak, and some people
> thinking it is driver issue.
> I had this issue with madwifi before, and choosing antenna manually helped.
> But it was long time ago, no idea if it's useful now in ath5k. But in custom
> boards like Routerboard it is very useful.
ath5k and madwifi are very different.
Luis
^ permalink raw reply
* Re: ath5k, too high output power?
From: Denys Fedoryschenko @ 2009-10-27 3:08 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <43e72e890910261959s6490b900xebb365d288c03f@mail.gmail.com>
On Tuesday 27 October 2009 04:59:20 Luis R. Rodriguez wrote:
> You mean can you do antenna diversity and select this manually ? I am
> not sure, but I doubt it, should be easy to add though.
Yes, on some laptops wireless card connected really weird way. And while on
Windows everything worked fine, on Linux signal was too weak, and some people
thinking it is driver issue.
I had this issue with madwifi before, and choosing antenna manually helped.
But it was long time ago, no idea if it's useful now in ath5k. But in custom
boards like Routerboard it is very useful.
^ permalink raw reply
* Re: ath5k, too high output power?
From: Luis R. Rodriguez @ 2009-10-27 2:59 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <200910270410.24274.denys@visp.net.lb>
On Mon, Oct 26, 2009 at 7:10 PM, Denys Fedoryschenko <denys@visp.net.lb> wrote:
> On Tuesday 27 October 2009 03:38:02 Luis R. Rodriguez wrote:
>> You obviously can change the antenna on a lot of devices, sometimes
>> that is difficult due to the connectors used but you are likely to
>> find them online somewhere.
>
> I mean A or B :-) AUX or MAIN :-)
> Sorry for my ugly English.
> In madwifi, as i remember i was possible to do that or over sysctl or over
> module parameter, i dont remember exactly where.
You mean can you do antenna diversity and select this manually ? I am
not sure, but I doubt it, should be easy to add though.
Luis
^ permalink raw reply
* Re: ath5k, too high output power?
From: Denys Fedoryschenko @ 2009-10-27 2:10 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <43e72e890910261838k7986048dg4cc38634d828e98c@mail.gmail.com>
On Tuesday 27 October 2009 03:38:02 Luis R. Rodriguez wrote:
> You obviously can change the antenna on a lot of devices, sometimes
> that is difficult due to the connectors used but you are likely to
> find them online somewhere.
I mean A or B :-) AUX or MAIN :-)
Sorry for my ugly English.
In madwifi, as i remember i was possible to do that or over sysctl or over
module parameter, i dont remember exactly where.
^ permalink raw reply
* Re: ath5k, too high output power?
From: Luis R. Rodriguez @ 2009-10-27 1:38 UTC (permalink / raw)
To: Denys Fedoryschenko; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <200910270259.09787.denys@visp.net.lb>
On Mon, Oct 26, 2009 at 5:59 PM, Denys Fedoryschenko <denys@visp.net.lb> wrote:
> I have laptop with ath5k card, and just tried to run it with ath5k driver.
> I notice strange thing:
>
> lappi ~ # iw phy phy0 info
> Wiphy phy0
> Band 1:
> Frequencies:
> * 2412 MHz [1] (20.0 dBm)
> * 2417 MHz [2] (20.0 dBm)
> * 2422 MHz [3] (20.0 dBm)
>
> I guess it is too high. I am not sure it is actual value, but if it is right
> and actual value, then i am exceeding local regulations.
That value is the maximum value allowed, not your actual eirp. By
default the EEPROM's card is read and that is used for regulatory
purposes, users can however be good citizens and help regulatory
compliance further by indicating their country and if the max eirp of
the programmed EEPROM is higher than your current country it will be
lowered.
Please have a good read at:
http://wireless.kernel.org/en/developers/Regulatory
http://wireless.kernel.org/en/users/Drivers/ath
> Another thing, is it possible to change antenna output?
You obviously can change the antenna on a lot of devices, sometimes
that is difficult due to the connectors used but you are likely to
find them online somewhere.
Luis
^ permalink raw reply
* ath5k, too high output power?
From: Denys Fedoryschenko @ 2009-10-27 0:59 UTC (permalink / raw)
To: linux-wireless, ath5k-devel
I have laptop with ath5k card, and just tried to run it with ath5k driver.
I notice strange thing:
lappi ~ # iw phy phy0 info
Wiphy phy0
Band 1:
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
I guess it is too high. I am not sure it is actual value, but if it is right
and actual value, then i am exceeding local regulations.
I have simple spectrum analyzer (spectran), and i can try to test actual
output power if required.
Another thing, is it possible to change antenna output?
Hardware:
01:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg
Wireless PCI Express Adapter (rev 01)
Subsystem: Hewlett-Packard Company Device 137a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 128 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d1300000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit-
Count=1/1 Enable-
Address: 00000000 Data: 0000
Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns,
L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency
L0 <512ns, L1 <64us
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain-
CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [90] MSI-X: Enable- Mask- TabSize=1
Vector table: BAR=0 offset=00000000
PBA: BAR=0 offset=00000000
Capabilities: [100] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
AERCap: First Error Pointer: 0e, GenCap+ CGenEn- ChkCap+
ChkEn-
Capabilities: [140] Virtual Channel <?>
Kernel driver in use: ath5k
Kernel modules: ath5k
^ permalink raw reply
* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Tilman Schmidt @ 2009-10-27 0:52 UTC (permalink / raw)
To: Johannes Berg
Cc: Jarek Poplawski, David Miller, hidave.darkstar, linux-kernel,
tglx, linux-wireless, linux-ppp, netdev, paulus, Michael Buesch,
Oliver Hartkopp
In-Reply-To: <1256547380.28230.17.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]
Am 26.10.2009 09:56 schrieb Johannes Berg:
> On Mon, 2009-10-26 at 10:47 +0200, Tilman Schmidt wrote:
>
>>> Basically it boils down to using netif_rx() when in (soft)irq, and
>>> netif_rx_ni() when in process context. That could just be an
>>> optimisation, but it's a very valid one.
>> Hmmm. That seems to contradict your earlier statement to me that
>> simply replacing a call to netif_rx() by one to netif_rx_ni()
>> when not in interrupt context isn't a valid solution either.
>> What am I missing?
>
> Well, I think you misunderstood me. It would be correct to do this, if
> and only if the code that calls it doesn't need the extra guarantee.
I see. Thanks for the clarification.
> Any code (say ISDN code) that calls netif_rx() is clearly assuming to
> always be running in (soft)irq context, otherwise it couldn't call
> netif_rx() unconditionally. Agree so far?
Well, in fact I'm not sure. :-) All I know is that in the ISDN case, no
such assumption is explicitly stated anywhere. (The code in question is
called from the rcvcallb_skb() callback method which the hardware driver
calls when data has been received, and the description of that method in
Documentation/isdn/INTERFACE does not say anything about the context in
which it may be called.) The relevant code in drivers/isdn/i4l/isdn_ppp.c
is rather old, perhaps even older than softirqs and the netif_rx() /
netif_rx_ni() split. (Bear in mind that we are talking about the old
ISDN4Linux subsystem which initially didn't even make it into the 2.6
series because it was considered obsolete.) It seems quite possible to me
that just no one ever thought about that question.
> So now if you change the ISDN code to call netif_rx_ni(), you've changed
> the assumption that the ISDN code makes -- that it is running in
> (soft)irq context. Therefore, you need to verify that this is actually a
> correct change, which is what I tried to say.
Understood. However, the fact that the local_softirq_pending message is
appearing would seem to indicate that this assumption was wrong to
begin with, wouldn't it?
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: ath5k phy0: no further txbuf available, dropping packet
From: Michael Buesch @ 2009-10-26 21:34 UTC (permalink / raw)
To: Bob Copeland
Cc: dsrbecky, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
linux-wireless
In-Reply-To: <200910262230.57957.mb@bu3sch.de>
On Monday 26 October 2009 22:30:55 Michael Buesch wrote:
> On Monday 26 October 2009 21:52:39 David Srbecky wrote:
> > I am getting this error as well.
>
> Ok, I looked at the code a bit and this looks strange to me.
> There's the TX status handler in base.c which basically looks like this:
>
>
> loop_over_queued_packets() {
> ret = sc->ah->ah_proc_rx_desc(sc->ah, ds, &rs);
Typo. I meant ah_proc_tx_desc()
> if (unlikely(ret == -EINPROGRESS))
> break;
> free_packet_and_return_bufferhead_to_pool();
> }
>
> So the ah_proc_rx_desc callback looks like this:
>
> ah_proc_rx_..._desc()
same here
> {
> ...
> /* No frame has been send or error */
> if (unlikely(!(tx_status->tx_status_1 & AR5K_DESC_TX_STATUS1_DONE)))
> return -EINPROGRESS;
> ...
> }
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH v2 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Luis R. Rodriguez @ 2009-10-26 21:32 UTC (permalink / raw)
To: Kalle Valo
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <878wexhn6m.fsf@purkki.valot.fi>
On Mon, Oct 26, 2009 at 02:15:13PM -0700, Kalle Valo wrote:
> "Luis R. Rodriguez" <lrodriguez@Atheros.com> writes:
>
> >> I think you should provide the size of hw_name to this function and
> >> use snprintf() to avoid writing out of bounds.
> >
> > I was going to do this but since I know the users of it and control
> > it seemed to not matter. I'll respin with this added, better to be careful.
>
> Yeah, you never know if someone (for example a crazy Finn just after a
> refreshing sauna) comes along, changes the function a bit "to clean it
> up" and creates a subtle bug ;)
Ah yes, forgot about the crazy sauna fins, must fix now for sure.
Luis
^ permalink raw reply
* Re: ath5k phy0: no further txbuf available, dropping packet
From: Michael Buesch @ 2009-10-26 21:30 UTC (permalink / raw)
To: Bob Copeland
Cc: dsrbecky, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
linux-wireless
In-Reply-To: <87f9e23c0910261352x60e17ef8ud859f91f36c43898@mail.gmail.com>
On Monday 26 October 2009 21:52:39 David Srbecky wrote:
> I am getting this error as well.
Ok, I looked at the code a bit and this looks strange to me.
There's the TX status handler in base.c which basically looks like this:
loop_over_queued_packets() {
ret = sc->ah->ah_proc_rx_desc(sc->ah, ds, &rs);
if (unlikely(ret == -EINPROGRESS))
break;
free_packet_and_return_bufferhead_to_pool();
}
So the ah_proc_rx_desc callback looks like this:
ah_proc_rx_..._desc()
{
...
/* No frame has been send or error */
if (unlikely(!(tx_status->tx_status_1 & AR5K_DESC_TX_STATUS1_DONE)))
return -EINPROGRESS;
...
}
Notice the comment and how it says "or error". So does that mean that if the
hardware produces some kind of error on one frame, the driver will stop processing any TX status
reports (because the loop always breaks early)? This would result in a buffer queue underrun,
which is reported by the printk.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH v2 2/4] ath9k_hw: distinguish single-chip solutions on initial probe print
From: Kalle Valo @ 2009-10-26 21:15 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org
In-Reply-To: <20091026204447.GA5713@tux>
"Luis R. Rodriguez" <lrodriguez@Atheros.com> writes:
>> I think you should provide the size of hw_name to this function and
>> use snprintf() to avoid writing out of bounds.
>
> I was going to do this but since I know the users of it and control
> it seemed to not matter. I'll respin with this added, better to be careful.
Yeah, you never know if someone (for example a crazy Finn just after a
refreshing sauna) comes along, changes the function a bit "to clean it
up" and creates a subtle bug ;)
--
Kalle Valo
^ permalink raw reply
* Re: ath5k: no further txbuf available, dropping packet
From: Fabio Rossi @ 2009-10-26 20:57 UTC (permalink / raw)
To: linux-wireless
Cc: Michael Buesch, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
Bob Copeland
In-Reply-To: <200910231608.18676.mb@bu3sch.de>
On Friday 23 October 2009 16:08:16 Michael Buesch wrote:
> ath5k breaks in AP mode after some operation time and keeps throwing
> this message:
>
> [2096249.446071] ath5k phy0: no further txbuf available, dropping packet
>
> Driver is yesterday's compat-wireless on 2.6.31.1
I got the same message but in managed mode with the latest git wireless
testing (v2.6.32-rc5-40584-g9b469da)
^ 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