* [PATCH 03/13] ath9k_hw: fix typo in the AR9003 EEPROM data structure definition
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
index 5fe335e..d8c0318 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
@@ -265,7 +265,7 @@ struct cal_ctl_edge_pwr {
} __packed;
struct cal_ctl_data_2g {
- struct cal_ctl_edge_pwr ctlEdges[AR9300_NUM_BAND_EDGES_5G];
+ struct cal_ctl_edge_pwr ctlEdges[AR9300_NUM_BAND_EDGES_2G];
} __packed;
struct cal_ctl_data_5g {
--
1.6.3.3
^ permalink raw reply related
* [PATCH 04/13] ath9k_hw: disable TX IQ calibration for AR9003
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez, Paul Shaw, Thomas Hammel
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
Disable TX IQ calibration, it was prematurely enabled in
previous versions.
Cc: Paul Shaw <Paul.Shaw@Atheros.com>
Cc: Thomas Hammel <Thomas.Hammel@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 3 ++-
drivers/net/wireless/ath/ath9k/hw.c | 6 ++++++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index 5e20b48..5fcafb4 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -755,7 +755,8 @@ static bool ar9003_hw_init_cal(struct ath_hw *ah,
}
/* Do Tx IQ Calibration */
- ar9003_hw_tx_iq_cal(ah);
+ if (ah->config.tx_iq_calibration)
+ ar9003_hw_tx_iq_cal(ah);
/* Revert chainmasks to their original values before NF cal */
ar9003_hw_set_chain_masks(ah, ah->rxchainmask, ah->txchainmask);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 5a29048..9af83e5 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -387,6 +387,12 @@ static void ath9k_hw_init_config(struct ath_hw *ah)
ah->config.rx_intr_mitigation = true;
/*
+ * Tx IQ Calibration (ah->config.tx_iq_calibration) is only
+ * used by AR9003, but it is showing reliability issues.
+ * It will take a while to fix so this is currently disabled.
+ */
+
+ /*
* We need this for PCI devices only (Cardbus, PCI, miniPCI)
* _and_ if on non-uniprocessor systems (Multiprocessor/HT).
* This means we use it for all AR5416 devices, and the few
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index a78e09b..6c84d31 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -261,6 +261,7 @@ struct ath9k_ops_config {
#define AR_BASE_FREQ_5GHZ 4900
#define AR_SPUR_FEEQ_BOUND_HT40 19
#define AR_SPUR_FEEQ_BOUND_HT20 10
+ bool tx_iq_calibration; /* Only available for >= AR9003 */
int spurmode;
u16 spurchans[AR_EEPROM_MODAL_SPURS][2];
u8 max_txtrig_level;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 06/13] ath9k_hw: update EEPROM data structure for AR9280
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Adds read access for the 5 GHz fast clock flag
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/eeprom.h | 3 ++-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 2 ++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h
index fb9c8c9..21354c1 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -300,7 +300,8 @@ struct base_eep_header {
u32 binBuildNumber;
u8 deviceType;
u8 pwdclkind;
- u8 futureBase_1[2];
+ u8 fastClk5g;
+ u8 divChain;
u8 rxGainType;
u8 dacHiPwrMode_5G;
u8 openLoopPwrCntl;
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index cf59799..e591ad6 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -274,6 +274,8 @@ static u32 ath9k_hw_def_get_eeprom(struct ath_hw *ah,
return pBase->txMask;
case EEP_RX_MASK:
return pBase->rxMask;
+ case EEP_FSTCLK_5G:
+ return pBase->fastClk5g;
case EEP_RXGAIN_TYPE:
return pBase->rxGainType;
case EEP_TXGAIN_TYPE:
--
1.6.3.3
^ permalink raw reply related
* [PATCH 00/13] ath9k/ath9k_hw: AR9003 fixes for April
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
John, this series contains a few fixes we've made to AR9003 over
the last few weeks. We've tested them considerably. Also included
is a change for AR9280 2.0 to enable fast PLL clock.
Happy Monday.
Felix Fietkau (10):
ath9k_hw: update initvals for AR9003
ath9k_hw: fix pll clock setting for 5ghz on AR9003
ath9k_hw: fix typo in the AR9003 EEPROM data structure definition
ath9k_hw: update EEPROM data structure for AR9280
ath9k_hw: fix fast clock handling for 5GHz channels
ath9k: wake queue after processing edma rx frames
ath9k_hw: use the configured power limit for AR9003
ath9k_hw: Fix typos in tx rate power level parsing for AR9003
ath9k_hw: Fix endian bug in an AR9003 EEPROM field
ath9k_hw: fix noisefloor timeout handling on AR9003
Luis R. Rodriguez (2):
ath9k_hw: disable TX IQ calibration for AR9003
ath9k_hw: Fix TX interrupt mitigation settings
Vasanthakumar Thiagarajan (1):
ath9k_hw: Fix usec to hw clock conversion in 5Ghz for ar9003
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 5 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 16 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 3 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 8 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_initvals.h | 265 +++++++++++-----------
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 3 +
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 16 +-
drivers/net/wireless/ath/ath9k/eeprom.h | 3 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 24 ++-
drivers/net/wireless/ath/ath9k/hw.h | 8 +-
drivers/net/wireless/ath/ath9k/mac.c | 10 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +
14 files changed, 189 insertions(+), 178 deletions(-)
^ permalink raw reply
* [PATCH 08/13] ath9k: wake queue after processing edma rx frames
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index b0d345a..3db1917 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2290,6 +2290,8 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
ath_tx_complete_buf(sc, bf, txq, &bf_head,
&txs, txok, 0);
+ ath_wake_mac80211_queue(sc, txq);
+
spin_lock_bh(&txq->axq_lock);
if (!list_empty(&txq->txq_fifo_pending)) {
INIT_LIST_HEAD(&bf_head);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 09/13] ath9k_hw: use the configured power limit for AR9003
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Since the new AR9003 EEPROM code does tune the card for the configured
tx power level, we need to fill in the correct power limits in the TPC
part of the DMA descriptor.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 1 +
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 3 +++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 5d92be4..79b0e28 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -1817,6 +1817,7 @@ static void ath9k_hw_ar9300_set_txpower(struct ath_hw *ah,
u8 twiceMaxRegulatoryPower,
u8 powerLimit)
{
+ ah->txpower_limit = powerLimit;
ar9003_hw_set_target_power_eeprom(ah, chan->channel);
ar9003_hw_calibration_apply(ah, chan->channel);
}
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 7d111fb..37ba374 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -311,6 +311,9 @@ static void ar9003_hw_set11n_txdesc(struct ath_hw *ah, void *ds,
{
struct ar9003_txc *ads = (struct ar9003_txc *) ds;
+ if (txpower > ah->txpower_limit)
+ txpower = ah->txpower_limit;
+
txpower += ah->txpower_indexoffset;
if (txpower > 63)
txpower = 63;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index bc682da..77245df 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -719,6 +719,7 @@ struct ath_hw {
u32 *addac5416_21;
u32 *bank6Temp;
+ u8 txpower_limit;
int16_t txpower_indexoffset;
int coverage_class;
u32 beacon_interval;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 02/13] ath9k_hw: fix pll clock setting for 5ghz on AR9003
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 11 +----------
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 137543b..bf8ec68 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -375,16 +375,7 @@ static u32 ar9003_hw_compute_pll_control(struct ath_hw *ah,
else if (chan && IS_CHAN_QUARTER_RATE(chan))
pll |= SM(0x2, AR_RTC_9300_PLL_CLKSEL);
- if (chan && IS_CHAN_5GHZ(chan)) {
- pll |= SM(0x28, AR_RTC_9300_PLL_DIV);
-
- /*
- * When doing fast clock, set PLL to 0x142c
- */
- if (IS_CHAN_A_5MHZ_SPACED(chan))
- pll = 0x142c;
- } else
- pll |= SM(0x2c, AR_RTC_9300_PLL_DIV);
+ pll |= SM(0x2c, AR_RTC_9300_PLL_DIV);
return pll;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 05/13] ath9k_hw: Fix usec to hw clock conversion in 5Ghz for ar9003
From: Luis R. Rodriguez @ 2010-04-26 19:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Vasanthakumar Thiagarajan
In-Reply-To: <1272308681-32396-1-git-send-email-lrodriguez@atheros.com>
From: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Fast clock operation (44Mhz) is enabled for 5Ghz in ar9003, so
take care of the conversion from usec to hw clock.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 10 ++++++++--
drivers/net/wireless/ath/ath9k/hw.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 9af83e5..ca676cd 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -26,6 +26,7 @@
#define ATH9K_CLOCK_RATE_CCK 22
#define ATH9K_CLOCK_RATE_5GHZ_OFDM 40
#define ATH9K_CLOCK_RATE_2GHZ_OFDM 44
+#define ATH9K_CLOCK_FAST_RATE_5GHZ_OFDM 44
static bool ath9k_hw_set_reset_reg(struct ath_hw *ah, u32 type);
@@ -91,7 +92,11 @@ static u32 ath9k_hw_mac_clks(struct ath_hw *ah, u32 usecs)
return usecs *ATH9K_CLOCK_RATE_CCK;
if (conf->channel->band == IEEE80211_BAND_2GHZ)
return usecs *ATH9K_CLOCK_RATE_2GHZ_OFDM;
- return usecs *ATH9K_CLOCK_RATE_5GHZ_OFDM;
+
+ if (ah->caps.hw_caps & ATH9K_HW_CAP_FASTCLOCK)
+ return usecs * ATH9K_CLOCK_FAST_RATE_5GHZ_OFDM;
+ else
+ return usecs * ATH9K_CLOCK_RATE_5GHZ_OFDM;
}
static u32 ath9k_hw_mac_to_clks(struct ath_hw *ah, u32 usecs)
@@ -2192,7 +2197,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
}
if (AR_SREV_9300_20_OR_LATER(ah)) {
- pCap->hw_caps |= ATH9K_HW_CAP_EDMA | ATH9K_HW_CAP_LDPC;
+ pCap->hw_caps |= ATH9K_HW_CAP_EDMA | ATH9K_HW_CAP_LDPC |
+ ATH9K_HW_CAP_FASTCLOCK;
pCap->rx_hp_qdepth = ATH9K_HW_RX_HP_QDEPTH;
pCap->rx_lp_qdepth = ATH9K_HW_RX_LP_QDEPTH;
pCap->rx_status_len = sizeof(struct ar9003_rxs);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 6c84d31..7a1347b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -198,6 +198,7 @@ enum ath9k_hw_caps {
ATH9K_HW_CAP_EDMA = BIT(17),
ATH9K_HW_CAP_RAC_SUPPORTED = BIT(18),
ATH9K_HW_CAP_LDPC = BIT(19),
+ ATH9K_HW_CAP_FASTCLOCK = BIT(20),
};
enum ath9k_capability_type {
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH PING] ssb patches for SPROM location
From: Larry Finger @ 2010-04-26 19:04 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: John W. Linville, linux-wireless
In-Reply-To: <y2nb170af451004261133qe1e0dfaand43c190b6f7f8d3@mail.gmail.com>
On 04/26/2010 01:33 PM, Rafał Miłecki wrote:
> 2010/4/26 John W. Linville <linville@tuxdriver.com>:
>> On Fri, Apr 16, 2010 at 11:22:28AM -0500, Larry Finger wrote:
>>> On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
>>>> W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
>>>> <linville@tuxdriver.com> napisał:
>>>>> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>>>>>> John, I posted some time ago following patches:
>>>>>>
>>>>>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>>>>>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>>>>>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>>>>>>
>>>>>> while Michael has some doubts about "ssb: Look for SPROM at different
>>>>>> offset on higher rev CC" I explained to him that what he does not like
>>>>>> was fixed in next 2 posted patches.
>>>>>>
>>>>>> AFAIR you got some device with this recently-discovered location of
>>>>>> SPROM. Could you test my set if it makes your card working? If so,
>>>>>> could you take that patches to your tree?
>>>>>
>>>>> Sorry, been busy w/ other things. FWIW, my implementation based on
>>>>> the RE work from Larry did not work on the box in question, and my
>>>>> implementation wasn't substantially different from yours. Anyway,
>>>>> I'll try to confirm this soon w/ your patches and to collect more
>>>>> information for Larry.
>>>>
>>>> Ah, I didn't know you got own implementation. Had to miss it.
>>>>
>>>> Larry do you have any ideas what else may we do incorrectly?
>>>
>>> No. AFAICT, we have implemented it correctly. Any additional info would
>>> be welcome.
>>
>> FWIW, this patch series also still results in a hang on my problematic
>> netbook. I'm going to merge them anyway, in hopes that they make
>> things better for someone (or at least get us closer to it). I'll try
>> to pinpoint this hang as well.
>
> Did it actually pick another (newly discovered) offset for SPROM
> location in your case? Could you add some single printk to check this?
My suggestion is that for now we only implement John's patch for no
SPROM. I am hoping that we try to fix the failures for boxes with the
SPROM in a normal location. Once we do that, there will be a simpler fix
for testing at the alternate location. The patch will all be contained
in sprom_do_read().
Larry
^ permalink raw reply
* Re: [RFC/RFT] ssb: Avoid system hang when SPROM read fails
From: John W. Linville @ 2010-04-26 18:32 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, b43-dev, linux-wireless
In-Reply-To: <4BD5D5B1.6020906@lwfinger.net>
On Mon, Apr 26, 2010 at 01:04:33PM -0500, Larry Finger wrote:
> On 04/26/2010 12:15 PM, John W. Linville wrote:
> >
> > Well, the "good" news is that I hit the "Unable to read SPROM" case.
> > The bad news is that the box still hangs after the -ENODEV. I have
> > not yet tracked-down the exact location of the current hang.
> >
> > John
> >
> > P.S. Sorry about the 'radio silence' -- I've been distracted with
> > some other things. Also, the box in question originally belonged
> > to someone else who had configured it in a way that was less than
> > friendly to kernel development. I finally reinstalled it...
>
> That box is certainly resistant!
>
> I certainly understand your distractions. That has to be a major
> understatement.
>
> As the patch makes some improvement in both your system and the one in
> Bug #15825, I'll push it as a real patch.
>
> Would your box be available to me as a loaner? I have considered buying
> a netbook for debugging purposes, but I cannot quite justify the cost.
> In addition, Murphy's law would make whatever one I bought work without
> any problems.
I think that can be arranged...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: Rafał Miłecki @ 2010-04-26 18:33 UTC (permalink / raw)
To: John W. Linville; +Cc: Larry Finger, linux-wireless
In-Reply-To: <20100426182655.GE2387@tuxdriver.com>
2010/4/26 John W. Linville <linville@tuxdriver.com>:
> On Fri, Apr 16, 2010 at 11:22:28AM -0500, Larry Finger wrote:
>> On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
>> > W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
>> > <linville@tuxdriver.com> napisał:
>> >> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>> >>> John, I posted some time ago following patches:
>> >>>
>> >>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>> >>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>> >>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>> >>>
>> >>> while Michael has some doubts about "ssb: Look for SPROM at different
>> >>> offset on higher rev CC" I explained to him that what he does not like
>> >>> was fixed in next 2 posted patches.
>> >>>
>> >>> AFAIR you got some device with this recently-discovered location of
>> >>> SPROM. Could you test my set if it makes your card working? If so,
>> >>> could you take that patches to your tree?
>> >>
>> >> Sorry, been busy w/ other things. FWIW, my implementation based on
>> >> the RE work from Larry did not work on the box in question, and my
>> >> implementation wasn't substantially different from yours. Anyway,
>> >> I'll try to confirm this soon w/ your patches and to collect more
>> >> information for Larry.
>> >
>> > Ah, I didn't know you got own implementation. Had to miss it.
>> >
>> > Larry do you have any ideas what else may we do incorrectly?
>>
>> No. AFAICT, we have implemented it correctly. Any additional info would
>> be welcome.
>
> FWIW, this patch series also still results in a hang on my problematic
> netbook. I'm going to merge them anyway, in hopes that they make
> things better for someone (or at least get us closer to it). I'll try
> to pinpoint this hang as well.
Did it actually pick another (newly discovered) offset for SPROM
location in your case? Could you add some single printk to check this?
--
Rafał
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: John W. Linville @ 2010-04-26 18:26 UTC (permalink / raw)
To: Larry Finger; +Cc: Rafał Miłecki, linux-wireless
In-Reply-To: <4BC88EC4.5000606@lwfinger.net>
On Fri, Apr 16, 2010 at 11:22:28AM -0500, Larry Finger wrote:
> On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
> > W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
> > <linville@tuxdriver.com> napisał:
> >> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
> >>> John, I posted some time ago following patches:
> >>>
> >>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
> >>> [PATCH 1/2] ssb: Use relative offsets for SPROM
> >>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
> >>>
> >>> while Michael has some doubts about "ssb: Look for SPROM at different
> >>> offset on higher rev CC" I explained to him that what he does not like
> >>> was fixed in next 2 posted patches.
> >>>
> >>> AFAIR you got some device with this recently-discovered location of
> >>> SPROM. Could you test my set if it makes your card working? If so,
> >>> could you take that patches to your tree?
> >>
> >> Sorry, been busy w/ other things. FWIW, my implementation based on
> >> the RE work from Larry did not work on the box in question, and my
> >> implementation wasn't substantially different from yours. Anyway,
> >> I'll try to confirm this soon w/ your patches and to collect more
> >> information for Larry.
> >
> > Ah, I didn't know you got own implementation. Had to miss it.
> >
> > Larry do you have any ideas what else may we do incorrectly?
>
> No. AFAICT, we have implemented it correctly. Any additional info would
> be welcome.
FWIW, this patch series also still results in a hang on my problematic
netbook. I'm going to merge them anyway, in hopes that they make
things better for someone (or at least get us closer to it). I'll try
to pinpoint this hang as well.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH V4] ssb: Implement virtual SPROM
From: Larry Finger @ 2010-04-26 18:14 UTC (permalink / raw)
To: John W. Linville; +Cc: Michael Buesch, bcm43xx-dev, linux-wireless
In-Reply-To: <20100426175850.GD2387@tuxdriver.com>
On 04/26/2010 12:58 PM, John W. Linville wrote:
> On Fri, Mar 26, 2010 at 12:39:08AM -0500, Larry Finger wrote:
>> Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
>> from the SPROM could be included in the kernel; however, this presents
>> a problem in the generation of a unique, reproducible MAC address. The
>> solution is to initialize the address to a known, workable value. Thus,
>> the device will work without any further code. For an address that is
>> preserved across reloads or reboots, a set of udev routines has been
>> prepared that detect the special address and assign a random value that
>> is preserved in a second udev rule file. The random address should be
>> unique except for the case where a given box has more than one of these
>> cards. This case is handles by adding the DEVPATH to the recognition rules.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>
> Do we still want this patch? Or do we think all the cases of a
> "missing" SPROM were actually a "relocated" SPROM?
I would say to drop it for now. We may never even have found a relocated
SPROM, just some bug that keeps it from being read. I'll keep the patch
for the time when we actually find a device in the wild without an
SPROM. To help us find such a device, you should reinstate commit
fcb54b0bf7d3fe730c2. It didn't fix the problems that we have currently,
but the Broadcom driver does indicate that these tests are needed.
Perhaps the message at
+ if (!ssb_is_sprom_available(bus)) {
+ ssb_printk(KERN_ERR PFX "No SPROM available!\n");
+ return -ENODEV;
+ }
should be enhanced to tell the user to contact us on the ML so that we
know that it is time for the virtual SPROM patch.
Larry
^ permalink raw reply
* Re: [RFC/RFT] ssb: Avoid system hang when SPROM read fails
From: Larry Finger @ 2010-04-26 18:04 UTC (permalink / raw)
To: John W. Linville; +Cc: Michael Buesch, b43-dev, linux-wireless
In-Reply-To: <20100426171505.GC2387@tuxdriver.com>
On 04/26/2010 12:15 PM, John W. Linville wrote:
>
> Well, the "good" news is that I hit the "Unable to read SPROM" case.
> The bad news is that the box still hangs after the -ENODEV. I have
> not yet tracked-down the exact location of the current hang.
>
> John
>
> P.S. Sorry about the 'radio silence' -- I've been distracted with
> some other things. Also, the box in question originally belonged
> to someone else who had configured it in a way that was less than
> friendly to kernel development. I finally reinstalled it...
That box is certainly resistant!
I certainly understand your distractions. That has to be a major
understatement.
As the patch makes some improvement in both your system and the one in
Bug #15825, I'll push it as a real patch.
Would your box be available to me as a loaner? I have considered buying
a netbook for debugging purposes, but I cannot quite justify the cost.
In addition, Murphy's law would make whatever one I bought work without
any problems.
Larry
^ permalink raw reply
* [PATCH 2/3] ath9k_htc: Validate TX Endpoint ID
From: Sujith @ 2010-04-26 9:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Check for the endpoint IDs when processing
TX completions and drop the unsupported EPIDs.
We can add other endpoints (UAPSD,..) when support
is added.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 2c3c510..08bfe5d 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -244,16 +244,25 @@ void ath9k_htc_txep(void *drv_priv, struct sk_buff *skb,
enum htc_endpoint_id ep_id, bool txok)
{
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) drv_priv;
+ struct ath_common *common = ath9k_hw_common(priv->ah);
struct ieee80211_tx_info *tx_info;
if (!skb)
return;
- if (ep_id == priv->mgmt_ep)
+ if (ep_id == priv->mgmt_ep) {
skb_pull(skb, sizeof(struct tx_mgmt_hdr));
- else
- /* TODO: Check for cab/uapsd/data */
+ } else if ((ep_id == priv->data_bk_ep) ||
+ (ep_id == priv->data_be_ep) ||
+ (ep_id == priv->data_vi_ep) ||
+ (ep_id == priv->data_vo_ep)) {
skb_pull(skb, sizeof(struct tx_frame_hdr));
+ } else {
+ ath_print(common, ATH_DBG_FATAL,
+ "Unsupported TX EPID: %d\n", ep_id);
+ dev_kfree_skb_any(skb);
+ return;
+ }
tx_info = IEEE80211_SKB_CB(skb);
--
1.7.0.5
^ permalink raw reply related
* [PATCH 3/3] ath9k_htc: Simplify RX IRQ handler
From: Sujith @ 2010-04-26 9:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
A bunch of validation and processing in the RX IRQ handler
can be moved to the RX tasklet. The IRQ handler is
already heavy, with the memory allocation for handling
stream mode. Also, a memcpy of 40 bytes for every packet
can be avoided in the handler.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 44 ++++++++++++------------
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 08bfe5d..28abc7d 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -448,10 +448,32 @@ static bool ath9k_rx_prepare(struct ath9k_htc_priv *priv,
struct ieee80211_hw *hw = priv->hw;
struct sk_buff *skb = rxbuf->skb;
struct ath_common *common = ath9k_hw_common(priv->ah);
+ struct ath_htc_rx_status *rxstatus;
int hdrlen, padpos, padsize;
int last_rssi = ATH_RSSI_DUMMY_MARKER;
__le16 fc;
+ if (skb->len <= HTC_RX_FRAME_HEADER_SIZE) {
+ ath_print(common, ATH_DBG_FATAL,
+ "Corrupted RX frame, dropping\n");
+ goto rx_next;
+ }
+
+ rxstatus = (struct ath_htc_rx_status *)skb->data;
+
+ if (be16_to_cpu(rxstatus->rs_datalen) -
+ (skb->len - HTC_RX_FRAME_HEADER_SIZE) != 0) {
+ ath_print(common, ATH_DBG_FATAL,
+ "Corrupted RX data len, dropping "
+ "(dlen: %d, skblen: %d)\n",
+ rxstatus->rs_datalen, skb->len);
+ goto rx_next;
+ }
+
+ /* Get the RX status information */
+ memcpy(&rxbuf->rxstatus, rxstatus, HTC_RX_FRAME_HEADER_SIZE);
+ skb_pull(skb, HTC_RX_FRAME_HEADER_SIZE);
+
hdr = (struct ieee80211_hdr *)skb->data;
fc = hdr->frame_control;
hdrlen = ieee80211_get_hdrlen_from_skb(skb);
@@ -616,8 +638,6 @@ void ath9k_htc_rxep(void *drv_priv, struct sk_buff *skb,
struct ath_hw *ah = priv->ah;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_rxbuf *rxbuf = NULL, *tmp_buf = NULL;
- struct ath_htc_rx_status *rxstatus;
- u32 len = 0;
spin_lock(&priv->rx.rxbuflock);
list_for_each_entry(tmp_buf, &priv->rx.rxbuf, list) {
@@ -634,27 +654,7 @@ void ath9k_htc_rxep(void *drv_priv, struct sk_buff *skb,
goto err;
}
- len = skb->len;
- if (len <= HTC_RX_FRAME_HEADER_SIZE) {
- ath_print(common, ATH_DBG_FATAL,
- "Corrupted RX frame, dropping\n");
- goto err;
- }
-
- rxstatus = (struct ath_htc_rx_status *)skb->data;
-
- if (be16_to_cpu(rxstatus->rs_datalen) -
- (len - HTC_RX_FRAME_HEADER_SIZE) != 0) {
- ath_print(common, ATH_DBG_FATAL,
- "Corrupted RX data len, dropping "
- "(epid: %d, dlen: %d, skblen: %d)\n",
- ep_id, rxstatus->rs_datalen, len);
- goto err;
- }
-
spin_lock(&priv->rx.rxbuflock);
- memcpy(&rxbuf->rxstatus, rxstatus, HTC_RX_FRAME_HEADER_SIZE);
- skb_pull(skb, HTC_RX_FRAME_HEADER_SIZE);
rxbuf->skb = skb;
rxbuf->in_process = true;
spin_unlock(&priv->rx.rxbuflock);
--
1.7.0.5
^ permalink raw reply related
* [PATCH 1/3] ath9k_htc: Remove unnecessary powersave restore
From: Sujith @ 2010-04-26 9:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 9c9f3e0..644776a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -153,7 +153,6 @@ static int ath9k_htc_set_channel(struct ath9k_htc_priv *priv,
ath_print(common, ATH_DBG_FATAL,
"Unable to reset channel (%u Mhz) "
"reset status %d\n", channel->center_freq, ret);
- ath9k_htc_ps_restore(priv);
goto err;
}
--
1.7.0.5
^ permalink raw reply related
* Re: [PATCH V4] ssb: Implement virtual SPROM
From: John W. Linville @ 2010-04-26 17:58 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, bcm43xx-dev, linux-wireless
In-Reply-To: <4bac487c.j3EXBzCzHYNAd+Ky%Larry.Finger@lwfinger.net>
On Fri, Mar 26, 2010 at 12:39:08AM -0500, Larry Finger wrote:
> Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
> from the SPROM could be included in the kernel; however, this presents
> a problem in the generation of a unique, reproducible MAC address. The
> solution is to initialize the address to a known, workable value. Thus,
> the device will work without any further code. For an address that is
> preserved across reloads or reboots, a set of udev routines has been
> prepared that detect the special address and assign a random value that
> is preserved in a second udev rule file. The random address should be
> unique except for the case where a given box has more than one of these
> cards. This case is handles by adding the DEVPATH to the recognition rules.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Do we still want this patch? Or do we think all the cases of a
"missing" SPROM were actually a "relocated" SPROM?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] mac80211: fix handling of 4-address-mode in ieee80211_change_iface
From: Felix Fietkau @ 2010-04-26 17:54 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Johannes Berg
A misplaced interface type check bails out too early if the interface
is not in monitor mode. This patch moves it to the right place, so that
it only covers changes to the monitor flags.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
---
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -97,9 +97,6 @@ static int ieee80211_change_iface(struct
params->mesh_id_len,
params->mesh_id);
- if (sdata->vif.type != NL80211_IFTYPE_MONITOR || !flags)
- return 0;
-
if (type == NL80211_IFTYPE_AP_VLAN &&
params && params->use_4addr == 0)
rcu_assign_pointer(sdata->u.vlan.sta, NULL);
@@ -107,6 +104,9 @@ static int ieee80211_change_iface(struct
params && params->use_4addr >= 0)
sdata->u.mgd.use_4addr = params->use_4addr;
+ if (sdata->vif.type != NL80211_IFTYPE_MONITOR || !flags)
+ return 0;
+
sdata->u.mntr_flags = *flags;
return 0;
}
^ permalink raw reply
* Re: [RFC/RFT] ssb: Avoid system hang when SPROM read fails
From: John W. Linville @ 2010-04-26 17:15 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Buesch, b43-dev, linux-wireless
In-Reply-To: <4bd4c284.WBohOsmgdwRzw5JC%Larry.Finger@lwfinger.net>
On Sun, Apr 25, 2010 at 05:30:28PM -0500, Larry Finger wrote:
> In kernel Bugzilla #15825, the OP reports a case of intermittent reading
> of the SPROM. If such reads fail, the box hangs. Thanks to careful testing
> by bugzillakernelorg@lez.ath.cx has shown that the first read of the
> SPROM returns 0xFFFF with the hang happening on the next read.
>
> The source of the read failure is still under investigation; however,
> this patch does avoid the system hang.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
>
> John,
>
> Does this patch avoid the system hang on your box?
>
> Larry
> ---
>
> ===================================================================
> --- wireless-testing.orig/drivers/ssb/pci.c
> +++ wireless-testing/drivers/ssb/pci.c
> @@ -253,6 +253,11 @@ static int sprom_do_read(struct ssb_bus
> {
> int i;
>
> + /* Check if SPROM can be read */
> + if (ioread16(bus->mmio + SSB_SPROM_BASE) == 0xFFFF) {
> + ssb_printk(KERN_ERR PFX "Unable to read SPROM\n");
> + return -ENODEV;
> + }
> for (i = 0; i < bus->sprom_size; i++)
> sprom[i] = ioread16(bus->mmio + SSB_SPROM_BASE + (i * 2));
>
Well, the "good" news is that I hit the "Unable to read SPROM" case.
The bad news is that the box still hangs after the -ENODEV. I have
not yet tracked-down the exact location of the current hang.
John
P.S. Sorry about the 'radio silence' -- I've been distracted with
some other things. Also, the box in question originally belonged
to someone else who had configured it in a way that was less than
friendly to kernel development. I finally reinstalled it...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* 802.11n copper bag hack for MIMO
From: Luis R. Rodriguez @ 2010-04-26 17:10 UTC (permalink / raw)
To: linux-wireless
Figured you guys working with 802.11n on close range over the air
environments might enjoy this little hack to test performance with
MIMO:
http://www.youtube.com/watch?v=pCMjKJ7LK_U
Luis
^ permalink raw reply
* Re: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: Sedat Dilek @ 2010-04-26 17:04 UTC (permalink / raw)
To: reinette chatre; +Cc: wireless, John Linville, Berg, Johannes
In-Reply-To: <1272300138.4381.8815.camel@rchatre-DESK>
On Mon, Apr 26, 2010 at 6:42 PM, reinette chatre
<reinette.chatre@intel.com> wrote:
> On Mon, 2010-04-26 at 09:31 -0700, Sedat Dilek wrote:
>> I tested both .34-git4 kernels half a day and this was the only
>> problem I saw in the my system-logs.
>
> This may indicate a problem in your environment since it just says that
> the station cannot communicate with the AP anymore. This occurs very
> often in various environments. This does not indicate a bug.
>
>> BTW, the WLAN connection did not crash as described in the initial
>> bug-report (logs see [1]).
>> At that time, I had to coldstart my machine - this was not the case
>> last weekend while testing.
>
> Either this issue is very hard to reproduce or it has been addressed
> with a change introduced between the kernels you are testing. Can you
> reproduce the issue when going back to earlier kernels? If so, then this
> may be a candidate for a bisect for us to find out what fixed it.
>
The kernel (with patches) is identical to the one from 20100417, so
what shall I bisect?
With same kernel-config, etc.
But in the meantime I upgraded my system - it could be that some other
package(s) fixed the magic.
Other idea could be some temporarily occured disturbance in WLAN
connection and/or in streaming on the websites I visited.
- Sedat -
^ permalink raw reply
* Re: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: reinette chatre @ 2010-04-26 16:42 UTC (permalink / raw)
To: sedat.dilek@gmail.com; +Cc: wireless, John Linville, Berg, Johannes
In-Reply-To: <k2i2d0a357f1004260931l98ce66d2ia3422958779c64d7@mail.gmail.com>
On Mon, 2010-04-26 at 09:31 -0700, Sedat Dilek wrote:
> I tested both .34-git4 kernels half a day and this was the only
> problem I saw in the my system-logs.
This may indicate a problem in your environment since it just says that
the station cannot communicate with the AP anymore. This occurs very
often in various environments. This does not indicate a bug.
> BTW, the WLAN connection did not crash as described in the initial
> bug-report (logs see [1]).
> At that time, I had to coldstart my machine - this was not the case
> last weekend while testing.
Either this issue is very hard to reproduce or it has been addressed
with a change introduced between the kernels you are testing. Can you
reproduce the issue when going back to earlier kernels? If so, then this
may be a candidate for a bisect for us to find out what fixed it.
Reinette
^ permalink raw reply
* Changes to b43/ssb specs
From: Larry Finger @ 2010-04-26 16:40 UTC (permalink / raw)
To: Gábor Stefanik, Rafał Miłecki, Michael Buesch
Cc: b43-dev, wireless, John Linville
In Kernel Bugzilla #15825, a netbook with an LP PHY device had symptoms
similar to John's box. The main difference is that the freezes on ssb
load were intermittent. From the instances that it works, we learned
that this box does have a SPROM at the normal location (0x1000). With
the help of the OP, we also learned that when it failed, it read the
first word of the SPROM as 0xFFFF, and then froze upon trying the
second. This behavior is the basis for my submission of "[RFC/RFT] ssb:
Avoid system hang when SPROM read fails". On the box at Bug #15825, that
patch eliminates the hangs. Of course, when the load fails with the
appropriate log entries, the wireless doesn't work.
In auditing the path that is involved in ssb registration, I noted a
variable named fast_pwrup_delay in struct ssb_chipcommon that gets
written to MMIO offset 0x6A8. When I looked for some variable like this
in the Broadcom driver, I found that it should be set to 7000 for the
BCM4312 LP-PHY device, but a test print showed it to be 0 with b43/ssb.
Resolving the discrepancy led to modifications in the specs at
http://bcm-v4.sipsolutions.net/802.11/Init. In particular, line 11 was
added. There are now two new pages at
http://bcm-v4.sipsolutions.net/802.11/ClkctlFastPwrupDelay, and
http://bcm-v4.sipsolutions.net/802.11/PmuFastPwrupDelay.
I hand coded the driver to write 7000, rather than zero, to the MMIO
offset 0x6A8. For my device, which already works, it made no difference.
I have sent such a trial patch to the OP at Bug #15825, but have not
gotten feedback.
Larry
^ permalink raw reply
* Re: iwl3945: Error sending REPLY_{RXON|SCAN_CMD|TX_PWR_TABLE_CMD} time out after 500ms
From: Sedat Dilek @ 2010-04-26 16:31 UTC (permalink / raw)
To: reinette chatre; +Cc: wireless, John Linville, Berg, Johannes
In-Reply-To: <1272298097.4381.8765.camel@rchatre-DESK>
I tested both .34-git4 kernels half a day and this was the only
problem I saw in the my system-logs.
BTW, the WLAN connection did not crash as described in the initial
bug-report (logs see [1]).
At that time, I had to coldstart my machine - this was not the case
last weekend while testing.
- Sedat -
[1] http://files.iniza.org/BUG_iwl3945_20100417/logs/
On Mon, Apr 26, 2010 at 6:08 PM, reinette chatre
<reinette.chatre@intel.com> wrote:
> On Mon, 2010-04-26 at 01:20 -0700, Sedat Dilek wrote:
>> I had only one issue with
>> linux-image-2.6.34-rc4-115-gdc57da3_2.6.34-rc4-115-gdc57da3.20100424~iniza.1_i386.deb
>> kernel:
>>
>> ...
>> /var/log/syslog.1-Apr 25 13:33:11 seduxbox wpa_supplicant[1732]: WPA:
>> Group rekeying completed with 00:04:0e:e4:00:3d [GTK=CCMP]
>> /var/log/syslog.1:Apr 25 13:59:56 seduxbox kernel: [59184.500070] No
>> probe response from AP 00:04:0e:e4:00:3d after 500ms, disconnecting.
>> /var/log/syslog.1-Apr 25 13:59:56 seduxbox kernel: [59184.505044]
>> cfg80211: Calling CRDA to update world regulatory domain
>> /var/log/syslog.1-Apr 25 13:59:56 seduxbox wpa_supplicant[1732]:
>> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717331]
>> cfg80211: World regulatory domain updated:
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717337]
>> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717343]
>> (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717349]
>> (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717355]
>> (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717361]
>> (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> /var/log/syslog.1-Apr 25 13:59:57 seduxbox kernel: [59185.717367]
>> (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
>> Trying to associate with 00:04:0e:e4:00:3d
>> (SSID='g00gle-street-knows-my-SSID-and-where-I-live' freq=2442 MHz)
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.753888]
>> wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.755614]
>> wlan0: authenticated
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.755649]
>> wlan0: associate with 00:04:0e:e4:00:3d (try 1)
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.760216]
>> wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411 status=0
>> aid=1)
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox kernel: [59187.760221]
>> wlan0: associated
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
>> Associated with 00:04:0e:e4:00:3d
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]: WPA:
>> Key negotiation completed with 00:04:0e:e4:00:3d [PTK=CCMP GTK=CCMP]
>> /var/log/syslog.1-Apr 25 13:59:59 seduxbox wpa_supplicant[1732]:
>> CTRL-EVENT-CONNECTED - Connection to 00:04:0e:e4:00:3d completed
>> (reauth) [id=0 id_str=]
>> ...
>
> Sorry ... but could you please point out what the issue is above? I do
> see that at one point the station's testing of AP communication
> fails ... but that can happen for many reasons and does not indicate a
> bug. Was there some other logs that pointed out an issue during this
> time?
>
> Reinette
>
>
>
^ 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