* Re: Initial work for ar9271
From: Joe Perches @ 2009-08-26 4:31 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, linux-kernel, Christian Lamparter, Johannes Berg,
John W. Linville, Greg KH, Stephen Chen, Zhifeng Cai,
Cliff Holden, Christoph Hellwig, Len Widra
In-Reply-To: <43e72e890908252103j2332d8eat9e18fecb20a1fe58@mail.gmail.com>
On Tue, 2009-08-25 at 21:03 -0700, Luis R. Rodriguez wrote:
> If you'd like to work on the
> driver I welcome patches:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/ar9271.git
I think this style ugly because it's non kernel standard.
int func(args)
{
do {
[ linear code ...]
if (err) {
errorcode = ;
break;
}
[ more linear code ...]
} while (0);
if (errorcode) {
handle()...
return some_err;
}
return 0;
}
It's a bit too much like a try/throw/catch block.
Are patches accepted to convert it to the more
commonly used kernel style using gotos?
^ permalink raw reply
* Re: Initial work for ar9271
From: Greg KH @ 2009-08-26 4:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, linux-kernel, Christian Lamparter, Johannes Berg,
John W. Linville, Stephen Chen, Zhifeng Cai, Cliff Holden,
Christoph Hellwig, Len Widra
In-Reply-To: <43e72e890908252103j2332d8eat9e18fecb20a1fe58@mail.gmail.com>
On Tue, Aug 25, 2009 at 09:03:08PM -0700, Luis R. Rodriguez wrote:
> I'm not yet sure if working with a separate repo or staging might be
> best here as the driver does not yet give STA functionality, the whole
> mac80211 driver part still remains to be developed. Lets play it by
> ear, I'll see if we can get a mailing list created in the meantime
> unless Greg doesn't mind me borrowing the driver project mailing list
> for that.
Not at all, feel free to use it for something like this.
thanks for asking,
greg k-h
^ permalink raw reply
* Initial work for ar9271
From: Luis R. Rodriguez @ 2009-08-26 4:03 UTC (permalink / raw)
To: linux-wireless, linux-kernel
Cc: Christian Lamparter, Johannes Berg, John W. Linville, Greg KH,
Stephen Chen, Zhifeng Cai, Cliff Holden, Christoph Hellwig,
Len Widra
Atheros ar9271 support work is underway with the initial hardware
revision support already added on ath9k [1]. This driver shares a lot
of the framework used by ar6k so there may be potential of sharing
there. The final step of course is to add mac80211 support. ar9271
will just be the first of a few generation of firmware based Atheros
11n devices as such a different driver core will need to be written to
support these devices, specifically for usb its important as we need
to sleep during reads/writes, re-using ath9k as is may not quite do
it. To help iron out the specifics we would like to work with the
community on the rest of the driver. For now I've stuffed what I have
with a clean history on a git repo. If you'd like to work on the
driver I welcome patches:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/ar9271.git
You can get the ar9271.fw firmware here:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/athfw2lnx.git
I encourage really interested developers to please send me a note as
we would like to allocate sample cards for you.
Bare with me on the progress of the driver, this code is so new I
haven't even tested if firmware loading works but I think it may. At
least it compiles now.
I'm not yet sure if working with a separate repo or staging might be
best here as the driver does not yet give STA functionality, the whole
mac80211 driver part still remains to be developed. Lets play it by
ear, I'll see if we can get a mailing list created in the meantime
unless Greg doesn't mind me borrowing the driver project mailing list
for that.
[1] http://marc.info/?l=linux-wireless&m=124935567308276&w=2
Luis
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Richard Farina @ 2009-08-26 3:46 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Herton Ronaldo Krzesinski, Hin-Tak Leung,
linux-wireless
In-Reply-To: <4a5cf0b4.F1C7R/E9sD5tpPd2%Larry.Finger@lwfinger.net>
Larry Finger wrote:
> When rtl8187 is unloaded and CONFIG_RTL8187_LEDS is set, the kernel
> may oops when the module is unloaded as the workqueue for led_on was
> not being cancelled.
>
> This patch fixes the problem reported in
> http://marc.info/?l=linux-wireless&m=124742957615781&w=2.
>
> Reported-by: Gábor Stefanik <netrolller.3d@gmail.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger>
> ---
>
> V2 - Do not create a new workqueue.
>
> John,
>
> This patch is 2.6.31 material. To the best of my knowledge, a formal bug
> report was never filed; however, it was reported in the reference given above.
>
>
Anyone know what happened here? This bug still seems very much alive in
compat-wireless-2.6.31-rc7. I know the window is closed and this really
isn't "earthshattering" but a kernel panick is kind of "a big deal". I
seems like it was tested doing a proper modprobe -r but not if you just
unplug the usb card.
When I unplug the usb I get instadeath, very uncool. If someone can
teach me how to get the kernel output from a non-functional system I am
happy to provide whatever.
thanks,
Rick Farina
> Larry
> ---
>
> Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_leds.c
> +++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
> @@ -208,11 +208,12 @@ void rtl8187_leds_exit(struct ieee80211_
> {
> struct rtl8187_priv *priv = dev->priv;
>
> - rtl8187_unregister_led(&priv->led_tx);
> /* turn the LED off before exiting */
> queue_delayed_work(dev->workqueue, &priv->led_off, 0);
> cancel_delayed_work_sync(&priv->led_off);
> + cancel_delayed_work_sync(&priv->led_on);
> rtl8187_unregister_led(&priv->led_rx);
> + rtl8187_unregister_led(&priv->led_tx);
> }
> #endif /* def CONFIG_RTL8187_LED */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [ANN] rfkill: v0.2
From: Richard Farina @ 2009-08-26 3:20 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <E1Mg8tl-0005Rh-8w@sipsolutions.net>
wireless@sipsolutions.net wrote:
> A new release of rfkill (v0.2) is available at:
>
> http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
>
> SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
>
> Here is the short log of the changes included in this
> release:
>
>
Again, a very short list...
-Rick
> Johannes Berg - version 0.2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [ANN] rfkill: v0.2
From: Julian Calaby @ 2009-08-26 3:17 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <E1Mg8tl-0005Rh-8w@sipsolutions.net>
On Wed, Aug 26, 2009 at 13:10, <wireless@sipsolutions.net> wrote:
>
> A new release of rfkill (v0.2) is available at:
>
> http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
>
> SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
>
> Here is the short log of the changes included in this
> release:
>
> Johannes Berg - version 0.2
Unless you're just bumping the version number, this is a rather slim release.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* [ANN] rfkill: v0.2
From: wireless @ 2009-08-26 3:10 UTC (permalink / raw)
To: linux-wireless
A new release of rfkill (v0.2) is available at:
http://wireless.kernel.org/download/rfkill/rfkill-0.2.tar.bz2
SHA1 sum: fc8f36efd4827219ca7169f8c55572a4c9e1c3b7
Here is the short log of the changes included in this
release:
Johannes Berg - version 0.2
^ permalink raw reply
* [PATCH 4/4] ath9k: Update INITVALs for AR9285
From: Sujith @ 2009-08-26 3:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/initvals.h | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/initvals.h b/drivers/net/wireless/ath/ath9k/initvals.h
index 27a86bb..8622265 100644
--- a/drivers/net/wireless/ath/ath9k/initvals.h
+++ b/drivers/net/wireless/ath/ath9k/initvals.h
@@ -4133,7 +4133,7 @@ static const u_int32_t ar9285Modes_9285_1_2[][6] = {
{ 0x00008318, 0x00003e80, 0x00007d00, 0x00006880, 0x00003440, 0x00006880 },
{ 0x00009804, 0x00000300, 0x000003c4, 0x000003c4, 0x00000300, 0x00000303 },
{ 0x00009820, 0x02020200, 0x02020200, 0x02020200, 0x02020200, 0x02020200 },
- { 0x00009824, 0x00000e0e, 0x00000e0e, 0x00000e0e, 0x00000e0e, 0x00000e0e },
+ { 0x00009824, 0x01000e0e, 0x01000e0e, 0x01000e0e, 0x01000e0e, 0x01000e0e },
{ 0x00009828, 0x0a020001, 0x0a020001, 0x0a020001, 0x0a020001, 0x0a020001 },
{ 0x00009834, 0x00000e0e, 0x00000e0e, 0x00000e0e, 0x00000e0e, 0x00000e0e },
{ 0x00009838, 0x00000007, 0x00000007, 0x00000007, 0x00000007, 0x00000007 },
@@ -4158,7 +4158,7 @@ static const u_int32_t ar9285Modes_9285_1_2[][6] = {
{ 0x000099bc, 0x00000600, 0x00000600, 0x00000c00, 0x00000c00, 0x00000c00 },
{ 0x000099c0, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4, 0x05eea6d4 },
{ 0x000099c4, 0x06336f77, 0x06336f77, 0x06336f77, 0x06336f77, 0x06336f77 },
- { 0x000099c8, 0x6af65329, 0x6af65329, 0x6af65329, 0x6af65329, 0x6af65329 },
+ { 0x000099c8, 0x6af6532f, 0x6af6532f, 0x6af6532f, 0x6af6532f, 0x6af6532f },
{ 0x000099cc, 0x08f186c8, 0x08f186c8, 0x08f186c8, 0x08f186c8, 0x08f186c8 },
{ 0x000099d0, 0x00046384, 0x00046384, 0x00046384, 0x00046384, 0x00046384 },
{ 0x000099d4, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000 },
@@ -4601,7 +4601,7 @@ static const u_int32_t ar9285Common_9285_1_2[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -4650,7 +4650,7 @@ static const u_int32_t ar9285Common_9285_1_2[][2] = {
{ 0x00009954, 0x5f3ca3de },
{ 0x00009958, 0x2108ecff },
{ 0x00009968, 0x000003ce },
- { 0x00009970, 0x192bb515 },
+ { 0x00009970, 0x192bb514 },
{ 0x00009974, 0x00000000 },
{ 0x00009978, 0x00000001 },
{ 0x0000997c, 0x00000000 },
@@ -4728,7 +4728,7 @@ static const u_int32_t ar9285Common_9285_1_2[][2] = {
{ 0x00007800, 0x00140000 },
{ 0x00007804, 0x0e4548d8 },
{ 0x00007808, 0x54214514 },
- { 0x0000780c, 0x02025820 },
+ { 0x0000780c, 0x02025830 },
{ 0x00007810, 0x71c0d388 },
{ 0x00007814, 0x924934a8 },
{ 0x0000781c, 0x00000000 },
--
1.6.4
^ permalink raw reply related
* [PATCH 3/4] ath9k: Handle PA cal usage properly
From: Sujith @ 2009-08-26 3:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
PA Calibration is not needed for high power solutions.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/calib.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index f9de16c..3234995 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -879,6 +879,11 @@ static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah, bool is_reset)
DPRINTF(ah->ah_sc, ATH_DBG_CALIBRATE, "Running PA Calibration\n");
+ /* PA CAL is not needed for high power solution */
+ if (ah->eep_ops->get_eeprom(ah, EEP_TXGAIN_TYPE) ==
+ AR5416_EEP_TXGAIN_HIGH_POWER)
+ return;
+
if (AR_SREV_9285_11(ah)) {
REG_WRITE(ah, AR9285_AN_TOP4, (AR9285_AN_TOP4_DEFAULT | 0x14));
udelay(10);
--
1.6.4
^ permalink raw reply related
* [PATCH 2/4] ath9k: Fix bugs in programming registers during PA CAL
From: Sujith @ 2009-08-26 3:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
* First PA driver (PDPADRV1) was not powered down properly.
* Compensation capacitor for dynamic PA was programmed incorrectly.
Also, remove a stray REG_READ.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/calib.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index 47a024d..f9de16c 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -901,13 +901,13 @@ static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah, bool is_reset)
REG_RMW_FIELD(ah, AR9285_AN_RF2G2, AR9285_AN_RF2G2_OFFCAL, 0);
REG_RMW_FIELD(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PWDDB, 0);
REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_ENPACAL, 0);
- REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV1, 1);
+ REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV1, 0);
REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPADRV2, 0);
REG_RMW_FIELD(ah, AR9285_AN_RF2G1, AR9285_AN_RF2G1_PDPAOUT, 0);
REG_RMW_FIELD(ah, AR9285_AN_RF2G8, AR9285_AN_RF2G8_PADRVGN2TAB0, 7);
REG_RMW_FIELD(ah, AR9285_AN_RF2G7, AR9285_AN_RF2G7_PADRVGN2TAB0, 0);
ccomp_org = MS(REG_READ(ah, AR9285_AN_RF2G6), AR9285_AN_RF2G6_CCOMP);
- REG_RMW_FIELD(ah, AR9285_AN_RF2G6, AR9285_AN_RF2G6_CCOMP, 7);
+ REG_RMW_FIELD(ah, AR9285_AN_RF2G6, AR9285_AN_RF2G6_CCOMP, 0xf);
REG_WRITE(ah, AR9285_AN_TOP2, 0xca0358a0);
udelay(30);
@@ -919,7 +919,6 @@ static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah, bool is_reset)
regVal |= (1 << (19 + i));
REG_WRITE(ah, 0x7834, regVal);
udelay(1);
- regVal = REG_READ(ah, 0x7834);
regVal &= (~(0x1 << (19 + i)));
reg_field = MS(REG_READ(ah, 0x7840), AR9285_AN_RXTXBB1_SPARE9);
regVal |= (reg_field << (19 + i));
--
1.6.4
^ permalink raw reply related
* [PATCH 1/4] ath9k: Reduce the frequency of PA offset calibration
From: Sujith @ 2009-08-26 3:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
PA calibration need not be done if the offset is not varying.
The current logic does PA calibration even if the offset is the
same.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/calib.c | 25 +++++++++++++++++++++----
drivers/net/wireless/ath/ath9k/calib.h | 7 +++++++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index 20f74b5..47a024d 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -861,7 +861,7 @@ static void ath9k_hw_9271_pa_cal(struct ath_hw *ah)
REG_WRITE(ah, regList[i][0], regList[i][1]);
}
-static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah)
+static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah, bool is_reset)
{
u32 regVal;
@@ -877,6 +877,8 @@ static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah)
{ 0x7838, 0 },
};
+ DPRINTF(ah->ah_sc, ATH_DBG_CALIBRATE, "Running PA Calibration\n");
+
if (AR_SREV_9285_11(ah)) {
REG_WRITE(ah, AR9285_AN_TOP4, (AR9285_AN_TOP4_DEFAULT | 0x14));
udelay(10);
@@ -936,6 +938,17 @@ static inline void ath9k_hw_9285_pa_cal(struct ath_hw *ah)
offs_6_1 = offset>>1;
offs_0 = offset & 1;
+ if ((!is_reset) && (ah->pacal_info.prev_offset == offset)) {
+ if (ah->pacal_info.max_skipcount < MAX_PACAL_SKIPCOUNT)
+ ah->pacal_info.max_skipcount =
+ 2 * ah->pacal_info.max_skipcount;
+ ah->pacal_info.skipcount = ah->pacal_info.max_skipcount;
+ } else {
+ ah->pacal_info.max_skipcount = 1;
+ ah->pacal_info.skipcount = 0;
+ ah->pacal_info.prev_offset = offset;
+ }
+
REG_RMW_FIELD(ah, AR9285_AN_RF2G6, AR9285_AN_RF2G6_OFFS, offs_6_1);
REG_RMW_FIELD(ah, AR9285_AN_RF2G3, AR9285_AN_RF2G3_PDVCCOMP, offs_0);
@@ -982,8 +995,12 @@ bool ath9k_hw_calibrate(struct ath_hw *ah, struct ath9k_channel *chan,
/* Do periodic PAOffset Cal */
if (AR_SREV_9271(ah))
ath9k_hw_9271_pa_cal(ah);
- else if (AR_SREV_9285_11_OR_LATER(ah))
- ath9k_hw_9285_pa_cal(ah);
+ else if (AR_SREV_9285_11_OR_LATER(ah)) {
+ if (!ah->pacal_info.skipcount)
+ ath9k_hw_9285_pa_cal(ah, false);
+ else
+ ah->pacal_info.skipcount--;
+ }
if (OLC_FOR_AR9280_20_LATER || OLC_FOR_AR9287_10_LATER)
ath9k_olc_temp_compensation(ah);
@@ -1081,7 +1098,7 @@ bool ath9k_hw_init_cal(struct ath_hw *ah, struct ath9k_channel *chan)
/* Do PA Calibration */
if (AR_SREV_9285_11_OR_LATER(ah))
- ath9k_hw_9285_pa_cal(ah);
+ ath9k_hw_9285_pa_cal(ah, true);
/* Do NF Calibration after DC offset and other calibrations */
REG_WRITE(ah, AR_PHY_AGC_CONTROL,
diff --git a/drivers/net/wireless/ath/ath9k/calib.h b/drivers/net/wireless/ath/ath9k/calib.h
index 547e697..019bcbb 100644
--- a/drivers/net/wireless/ath/ath9k/calib.h
+++ b/drivers/net/wireless/ath/ath9k/calib.h
@@ -110,6 +110,13 @@ struct ath9k_nfcal_hist {
u8 invalidNFcount;
};
+#define MAX_PACAL_SKIPCOUNT 8
+struct ath9k_pacal_info{
+ int32_t prev_offset; /* Previous value of PA offset value */
+ int8_t max_skipcount; /* Max No. of times PACAL can be skipped */
+ int8_t skipcount; /* No. of times the PACAL to be skipped */
+};
+
bool ath9k_hw_reset_calvalid(struct ath_hw *ah);
void ath9k_hw_start_nfcal(struct ath_hw *ah);
void ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel *chan);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 24b3063..b24150a 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -424,6 +424,7 @@ struct ath_hw {
enum ath9k_power_mode power_mode;
struct ath9k_nfcal_hist nfCalHist[NUM_NF_READINGS];
+ struct ath9k_pacal_info pacal_info;
struct ar5416Stats stats;
struct ath9k_tx_queue_info txq[ATH9K_NUM_TX_QUEUES];
--
1.6.4
^ permalink raw reply related
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Hin-Tak Leung @ 2009-08-26 2:43 UTC (permalink / raw)
To: Johannes Berg
Cc: htl10, Larry Finger, Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <1251192477.10667.3.camel@johannes.local>
On Tue, Aug 25, 2009 at 10:27 AM, Johannes
Berg<johannes@sipsolutions.net> wrote:
> On Tue, 2009-08-25 at 06:51 +0000, Hin-Tak Leung wrote:
>
>> dmesg and rfkill/state corresponds exactly to what the sliding switch
>> does (in the on position, dmesg says it is on, states says 2, in the
>> off position, dmesg says it is off, state says 1). NM basically
>> ignores rfkill/state, and just if'up the device whenever it notices
>> the device has gone down.
>
> NM can't ignore the state since cfg80211 enforces it.
>
> Can you please use rfkill (http://git.sipsolutions.net/rfkill.git) to
> see what's going on? Like print out events while you slide the button
> and use NM etc.
>
> One thing that would be possible -- does your poll callback work while
> the interface is down? Try to tell NM to turn off the wireless network,
> and see whether the state ever changes with your slider.
--------------------
[root@localhost rfkill]# ./rfkill list
0: (null): Wireless LAN
Soft blocked: no
Hard blocked: no
[root@localhost rfkill]# ./rfkill event
RFKILL event: idx 0 type 1 op 0 soft 0 hard 0
RFKILL event: idx 0 type 1 op 2 soft 0 hard 1
RFKILL event: idx 0 type 1 op 2 soft 0 hard 0
RFKILL event: idx 0 type 1 op 2 soft 0 hard 1
RFKILL event: idx 0 type 1 op 2 soft 0 hard 0
RFKILL event: idx 0 type 1 op 2 soft 0 hard 1
RFKILL event: idx 0 type 1 op 2 soft 0 hard 0
RFKILL event: idx 0 type 1 op 2 soft 0 hard 1
RFKILL event: idx 0 type 1 op 2 soft 0 hard 0
RFKILL event: idx 0 type 1 op 2 soft 0 hard 1
RFKILL event: idx 0 type 1 op 2 soft 0 hard 0
RFKILL event: idx 0 type 1 op 2 soft 0 hard 1
RFKILL event: idx 0 type 1 op 2 soft 0 hard 0
RFKILL event: idx 0 type 1 op 2 soft 0 hard 1
RFKILL event: idx 0 type 1 op 2 soft 0 hard 0
RFKILL event: idx 0 type 1 op 2 soft 0 hard 1
RFKILL event: idx 0 type 1 op 2 soft 0 hard 0
RFKILL event: idx 0 type 1 op 2 soft 0 hard 1
^C
[root@localhost rfkill]# ./rfkill list
0: (null): Wireless LAN
Soft blocked: no
Hard blocked: yes
[root@localhost rfkill]# ./rfkill list
0: (null): Wireless LAN
Soft blocked: no
Hard blocked: no
--------------
The rfkill event hard just goes 1 and 0 whenever I slide the switch,
regardless of what NM does . e.g. NM set to disable networking has no
effect on the 1/0 switch (it happens just depending on the slide
switch and nothing else), and nothing changes when NM noticed
rfkill'ed if down & decided to if'up and reassociate.
Basically the rfkill event state just depends on the slide switch,
regardless of NM (if it is set to enable wireless networking, it just
if up the device again; if it is set to disable, it just stayed
disable & the device stay down, but the event state continues to
respond to the slide switch).
^ permalink raw reply
* Re: Need rc6 posted to orbit-lab
From: Philip A. Prindeville @ 2009-08-26 0:03 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: wireless
In-Reply-To: <4A8AF05F.2020800@redfish-solutions.com>
Philip A. Prindeville wrote:
> Philip A. Prindeville wrote:
>
>> Can you please send out an announcement when rc6 hits orbit-lab?
>>
>> Thanks.
>>
>>
>
> Or maybe I'll just wait until rc7 comes out... :-O
>
Being the squeaky wheel here...
^ permalink raw reply
* Re: [PATCH] ath5k: fix print on warning on ath5k_hw_to_driver_rix()
From: Luis R. Rodriguez @ 2009-08-25 23:52 UTC (permalink / raw)
To: Bob Copeland
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <20090825233827.GA10998@mosca>
On Tue, Aug 25, 2009 at 4:38 PM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> On Tue, Aug 25, 2009 at 12:22:55PM -0700, Bob Copeland wrote:
>> On Tue, Aug 25, 2009 at 2:58 PM, Luis R.
>> Rodriguez<lrodriguez@atheros.com> wrote:
>> > OK how about the band info, think that's useful?
>>
>> Yeah, band is useful. We don't have to pretty print it though
>> (unless you really feel like it), %d would work just as well.
>>
>> Also WARN_ON_ONCE might be a good idea.
>
> Alright, first let me see if I can reproduce after cleaning
> curband crap a little.
>
>> >> which could indicate some
>> >> race condition with flushing the rx queue on channel changes.
>> >
>> > I'll see if I can reproduce somehow.
>> >
>> >> I haven't yet seen a hw rate we didn't know about.
>> >
>> > So you've seen this lately as well?
>>
>> I saw it some time ago, but then changed the order of how the
>> curchan/curband variables were set when we change channels and
>> haven't seen since. But kerneloops says a lot of other people
>> are still hitting it as well :(
>
> OK that's good to know too.
>
>> Hmm, ath5k_rx_stop probably wants an equivalent to txq_drainq in
>> there somewhere.
>
> True.
>
> First thing I saw upon a quick review was we were relying on our own
> curband for RX instead of the cfg80211 hw->conf band. Now granted
> that *may* be updated properly, and it seems that may be the case,
> but since do not tend to trust drivers here's a removal of all that
> crap first. I'll test this first to see if I run into the same warning.
> If this doesn't cure it then we are indeed processing old frames on RX
> and need to flush 'em out prior to a channel change first.
>
> Good thing is after a few hours I can reproduce at least.
Whah, the warn is still there.
[ 7281.492622] ------------[ cut here ]------------
[ 7281.492655] WARNING: at drivers/net/wireless/ath/ath5k/base.c:1133
ath5k_tasklet_rx+0x57b/0x720 [ath5k]()
[ 7281.492663] Hardware name: 7660A14
[ 7281.492668] invalid driver rate index mapped for hw_rix: 1b on freq: 5540
Luis
^ permalink raw reply
* Re: [PATCH] ath5k: fix print on warning on ath5k_hw_to_driver_rix()
From: Luis R. Rodriguez @ 2009-08-25 23:38 UTC (permalink / raw)
To: Bob Copeland
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <b6c5339f0908251222h5fb281c3vf3ecea8b27eb02ed@mail.gmail.com>
On Tue, Aug 25, 2009 at 12:22:55PM -0700, Bob Copeland wrote:
> On Tue, Aug 25, 2009 at 2:58 PM, Luis R.
> Rodriguez<lrodriguez@atheros.com> wrote:
> > OK how about the band info, think that's useful?
>
> Yeah, band is useful. We don't have to pretty print it though
> (unless you really feel like it), %d would work just as well.
>
> Also WARN_ON_ONCE might be a good idea.
Alright, first let me see if I can reproduce after cleaning
curband crap a little.
> >> which could indicate some
> >> race condition with flushing the rx queue on channel changes.
> >
> > I'll see if I can reproduce somehow.
> >
> >> I haven't yet seen a hw rate we didn't know about.
> >
> > So you've seen this lately as well?
>
> I saw it some time ago, but then changed the order of how the
> curchan/curband variables were set when we change channels and
> haven't seen since. But kerneloops says a lot of other people
> are still hitting it as well :(
OK that's good to know too.
> Hmm, ath5k_rx_stop probably wants an equivalent to txq_drainq in
> there somewhere.
True.
First thing I saw upon a quick review was we were relying on our own
curband for RX instead of the cfg80211 hw->conf band. Now granted
that *may* be updated properly, and it seems that may be the case,
but since do not tend to trust drivers here's a removal of all that
crap first. I'll test this first to see if I run into the same warning.
If this doesn't cure it then we are indeed processing old frames on RX
and need to flush 'em out prior to a channel change first.
Good thing is after a few hours I can reproduce at least.
Luis
From: Luis R. Rodriguez <lrodriguez@atheros.com>
Subject: [PATCH] ath5k: remove curband, curchan, curmode
It still possible for ath5k tasklet to trigger and the
curband to be off. There seems to be some race against it
somewhere. To help aid with this review we simplify the
notion of current band and current channel assumptions
ath5k and only rely on cfg80211's as it already does the
book keeping for us.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath5k/base.c | 87 +++++++++++++++------------------
drivers/net/wireless/ath/ath5k/base.h | 6 --
2 files changed, 39 insertions(+), 54 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 5056410..feffc92 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -220,7 +220,8 @@ static struct pci_driver ath5k_pci_driver = {
static int ath5k_tx(struct ieee80211_hw *hw, struct sk_buff *skb);
static int ath5k_tx_queue(struct ieee80211_hw *hw, struct sk_buff *skb,
struct ath5k_txq *txq);
-static int ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan);
+static int ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan,
+ bool chan_change);
static int ath5k_reset_wake(struct ath5k_softc *sc);
static int ath5k_start(struct ieee80211_hw *hw);
static void ath5k_stop(struct ieee80211_hw *hw);
@@ -293,8 +294,6 @@ static unsigned int ath5k_copy_channels(struct ath5k_hw *ah,
static int ath5k_setup_bands(struct ieee80211_hw *hw);
static int ath5k_chan_set(struct ath5k_softc *sc,
struct ieee80211_channel *chan);
-static void ath5k_setcurmode(struct ath5k_softc *sc,
- unsigned int mode);
static void ath5k_mode_setup(struct ath5k_softc *sc);
/* Descriptor setup */
@@ -759,12 +758,6 @@ ath5k_attach(struct pci_dev *pdev, struct ieee80211_hw *hw)
goto err;
}
- /* NB: setup here so ath5k_rate_update is happy */
- if (test_bit(AR5K_MODE_11A, ah->ah_modes))
- ath5k_setcurmode(sc, AR5K_MODE_11A);
- else
- ath5k_setcurmode(sc, AR5K_MODE_11B);
-
/*
* Allocate tx+rx descriptors and populate the lists.
*/
@@ -1084,7 +1077,7 @@ static int
ath5k_chan_set(struct ath5k_softc *sc, struct ieee80211_channel *chan)
{
ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "(%u MHz) -> (%u MHz)\n",
- sc->curchan->center_freq, chan->center_freq);
+ sc->hw->conf.channel->center_freq, chan->center_freq);
/*
* To switch channels clear any pending DMA operations;
@@ -1092,19 +1085,12 @@ ath5k_chan_set(struct ath5k_softc *sc, struct ieee80211_channel *chan)
* hardware at the new frequency, and then re-enable
* the relevant bits of the h/w.
*/
- return ath5k_reset(sc, chan);
-}
-static void
-ath5k_setcurmode(struct ath5k_softc *sc, unsigned int mode)
-{
- sc->curmode = mode;
+ ath5k_hw_set_imr(sc->ah, 0);
+ ath5k_txq_cleanup(sc);
+ ath5k_rx_stop(sc);
- if (mode == AR5K_MODE_11A) {
- sc->curband = &sc->sbands[IEEE80211_BAND_5GHZ];
- } else {
- sc->curband = &sc->sbands[IEEE80211_BAND_2GHZ];
- }
+ return ath5k_reset(sc, chan, true);
}
static void
@@ -1136,11 +1122,15 @@ ath5k_hw_to_driver_rix(struct ath5k_softc *sc, int hw_rix)
/* return base rate on errors */
if (WARN(hw_rix < 0 || hw_rix >= AR5K_MAX_RATES,
- "hw_rix out of bounds: %x\n", hw_rix))
+ "hardware rate index out of bounds: %x"
+ "on freq: %d\n", hw_rix,
+ sc->hw->conf.channel->center_freq))
return 0;
- rix = sc->rate_idx[sc->curband->band][hw_rix];
- if (WARN(rix < 0, "invalid hw_rix: %x\n", hw_rix))
+ rix = sc->rate_idx[sc->hw->conf.channel->band][hw_rix];
+ if (WARN(rix < 0, "invalid driver rate index mapped for "
+ "hw_rix: %x on freq: %d\n", hw_rix,
+ sc->hw->conf.channel->center_freq))
rix = 0;
return rix;
@@ -1742,6 +1732,8 @@ static void
ath5k_tasklet_rx(unsigned long data)
{
struct ieee80211_rx_status rxs = {};
+ struct ieee80211_rate *bitrate;
+ struct ieee80211_supported_band *sband;
struct ath5k_rx_status rs = {};
struct sk_buff *skb, *next_skb;
dma_addr_t next_skb_addr;
@@ -1751,6 +1743,7 @@ ath5k_tasklet_rx(unsigned long data)
int ret;
int hdrlen;
int padsize;
+ int cur_band;
spin_lock(&sc->rxbuflock);
if (list_empty(&sc->rxbuf)) {
@@ -1864,8 +1857,8 @@ accept:
rxs.mactime = ath5k_extend_tsf(sc->ah, rs.rs_tstamp);
rxs.flag |= RX_FLAG_TSFT;
- rxs.freq = sc->curchan->center_freq;
- rxs.band = sc->curband->band;
+ rxs.freq = sc->hw->conf.channel->center_freq;
+ rxs.band = sc->hw->conf.channel->band;
rxs.noise = sc->ah->ah_noise_floor;
rxs.signal = rxs.noise + rs.rs_rssi;
@@ -1885,8 +1878,11 @@ accept:
rxs.rate_idx = ath5k_hw_to_driver_rix(sc, rs.rs_rate);
rxs.flag |= ath5k_rx_decrypted(sc, ds, skb, &rs);
- if (rxs.rate_idx >= 0 && rs.rs_rate ==
- sc->curband->bitrates[rxs.rate_idx].hw_value_short)
+ cur_band = sc->hw->conf.channel->band;
+ sband = sc->hw->wiphy->bands[cur_band];
+ bitrate = &sband->bitrates[rxs.rate_idx];
+
+ if (rxs.rate_idx >= 0 && rs.rs_rate == bitrate->hw_value_short)
rxs.flag |= RX_FLAG_SHORTPRE;
ath5k_debug_dump_skb(sc, skb, "RX ", 0);
@@ -2328,6 +2324,11 @@ static void ath5k_tasklet_beacon(unsigned long data)
}
}
+static int
+ath5k_reset_init(struct ath5k_softc *sc)
+{
+ return ath5k_reset(sc, sc->hw->conf.channel, false);
+}
/********************\
* Interrupt handling *
@@ -2356,12 +2357,10 @@ ath5k_init(struct ath5k_softc *sc)
* be followed by initialization of the appropriate bits
* and then setup of the interrupt mask.
*/
- sc->curchan = sc->hw->conf.channel;
- sc->curband = &sc->sbands[sc->curchan->band];
sc->imask = AR5K_INT_RXOK | AR5K_INT_RXERR | AR5K_INT_RXEOL |
AR5K_INT_RXORN | AR5K_INT_TXDESC | AR5K_INT_TXEOL |
AR5K_INT_FATAL | AR5K_INT_GLOBAL | AR5K_INT_SWI;
- ret = ath5k_reset(sc, NULL);
+ ret = ath5k_reset_init(sc);
if (ret)
goto done;
@@ -2581,8 +2580,8 @@ ath5k_tasklet_calibrate(unsigned long data)
ieee80211_stop_queues(sc->hw);
ATH5K_DBG(sc, ATH5K_DEBUG_CALIBRATE, "channel %u/%x\n",
- ieee80211_frequency_to_channel(sc->curchan->center_freq),
- sc->curchan->hw_value);
+ ieee80211_frequency_to_channel(sc->hw->conf.channel->center_freq),
+ sc->hw->conf.channel->hw_value);
if (ath5k_hw_gainf_calibrate(ah) == AR5K_RFGAIN_NEED_CHANGE) {
/*
@@ -2592,10 +2591,10 @@ ath5k_tasklet_calibrate(unsigned long data)
ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "calibration, resetting\n");
ath5k_reset_wake(sc);
}
- if (ath5k_hw_phy_calibrate(ah, sc->curchan))
+ if (ath5k_hw_phy_calibrate(ah, sc->hw->conf.channel))
ATH5K_ERR(sc, "calibration of channel %u failed\n",
ieee80211_frequency_to_channel(
- sc->curchan->center_freq));
+ sc->hw->conf.channel->center_freq));
ah->ah_swi_mask = 0;
@@ -2680,26 +2679,18 @@ drop_packet:
}
/*
- * Reset the hardware. If chan is not NULL, then also pause rx/tx
- * and change to the given channel.
+ * Reset the hardware.
*/
static int
-ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
+ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan,
+ bool chan_change)
{
struct ath5k_hw *ah = sc->ah;
int ret;
ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "resetting\n");
- if (chan) {
- ath5k_hw_set_imr(ah, 0);
- ath5k_txq_cleanup(sc);
- ath5k_rx_stop(sc);
-
- sc->curchan = chan;
- sc->curband = &sc->sbands[chan->band];
- }
- ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, chan != NULL);
+ ret = ath5k_hw_reset(ah, sc->opmode, chan, chan_change);
if (ret) {
ATH5K_ERR(sc, "can't reset hardware (%d)\n", ret);
goto err;
@@ -2735,7 +2726,7 @@ ath5k_reset_wake(struct ath5k_softc *sc)
{
int ret;
- ret = ath5k_reset(sc, sc->curchan);
+ ret = ath5k_reset_init(sc);
if (!ret)
ieee80211_wake_queues(sc->hw);
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index a28c42f..1b88814 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -128,8 +128,6 @@ struct ath5k_softc {
enum nl80211_iftype opmode;
struct ath5k_hw *ah; /* Atheros HW */
- struct ieee80211_supported_band *curband;
-
#ifdef CONFIG_ATH5K_DEBUG
struct ath5k_dbg_info debug; /* debug info */
#endif /* CONFIG_ATH5K_DEBUG */
@@ -147,11 +145,7 @@ struct ath5k_softc {
#define ATH_STAT_STARTED 4 /* opened & irqs enabled */
unsigned int filter_flags; /* HW flags, AR5K_RX_FILTER_* */
- unsigned int curmode; /* current phy mode */
- struct ieee80211_channel *curchan; /* current h/w channel */
-
struct ieee80211_vif *vif;
-
enum ath5k_int imask; /* interrupt mask copy */
DECLARE_BITMAP(keymap, AR5K_KEYCACHE_SIZE); /* key use bit map */
--
1.6.3.3
^ permalink raw reply related
* 2.6.31-rc7-git2: Reported regressions 2.6.29 -> 2.6.30
From: Rafael J. Wysocki @ 2009-08-25 20:37 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.29 and
2.6.30, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.29
and 2.6.30, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-08-26 152 33 30
2009-08-20 150 35 32
2009-08-10 148 39 37
2009-08-02 145 44 39
2009-07-27 143 48 45
2009-07-07 138 50 46
2009-06-29 133 46 43
2009-06-07 110 35 31
2009-05-31 100 32 27
2009-05-24 92 34 27
2009-05-16 81 36 33
2009-04-25 55 36 26
2009-04-17 37 35 28
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14049
Subject : joydev: blacklist digitizers avoids recognition of Saitek X52 joysticks
Submitter : Janos Laube <janos.dev@gmail.com>
Date : 2009-08-24 14:18 (2 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d07a9cba6be5c0e947afc1014b5a62182a86f1f1
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13958
Subject : ath5k Atheros AR5001 low signal
Submitter : Marco Siviero <darker1985@slacky.it>
Date : 2009-08-10 15:03 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13949
Subject : XFS regression
Submitter : Justin Piszcz <jpiszcz@lucidpixels.com>
Date : 2009-08-08 8:39 (18 days old)
References : http://marc.info/?l=linux-kernel&m=124972079229959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898
Subject : Intel 3945ABG - problems on 2.6.30.X
Submitter : dienet <dienet@poczta.fm>
Date : 2009-07-31 15:17 (26 days old)
References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797
Subject : iBook G4 doesn't suspend since 2ed8d2b3a8
Submitter : Jörg Sommer <joerg@alea.gnuu.de>
Date : 2009-07-18 20:18 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795
Subject : abnormal boot and no suspend due to 'async' (fastboot)
Submitter : Rafal Kaczynski <fscnoboot@wp.pl>
Date : 2009-07-18 17:19 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780
Subject : NULL pointer dereference loading powernowk8
Submitter : Kurt Roeckx <kurt@roeckx.be>
Date : 2009-07-15 18:00 (42 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13770
Subject : System freeze on XFS filesystem recovery on an external disk
Submitter : Jean-Luc Coulon <jean.luc.coulon@gmail.com>
Date : 2009-07-14 10:31 (43 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739
Subject : 2.6.30 leaking keys on console switch
Submitter : Andi Kleen <andi@firstfloor.org>
Date : 2009-07-07 8:44 (50 days old)
References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4
Handled-By : Jiri Kosina <jkosina@suse.cz>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694
Subject : i915 phantom TV
Submitter : Maciek Józiewicz <mjoziew@gmail.com>
Date : 2009-07-02 12:26 (55 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682
Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30
Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com>
Date : 2009-06-30 13:34 (57 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646
Subject : warn_on tty_io.c, broken bluetooth
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-06-19 17:05 (68 days old)
References : http://lkml.org/lkml/2009/6/19/187
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583
Subject : pdflush uses 5% CPU on otherwise idle system
Submitter : Paul Martin <pm@debian.org>
Date : 2009-06-19 13:33 (68 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581
Subject : ath9k doesn't work with newer kernels
Submitter : Matteo <rootkit85@yahoo.it>
Date : 2009-06-19 12:04 (68 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564
Subject : random general protection fault at boot time caused by khubd.
Submitter : Pauli <suokkos@gmail.com>
Date : 2009-06-18 12:44 (69 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558
Subject : Tracelog during resume
Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date : 2009-06-17 11:32 (70 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514
Subject : acer_wmi causes stack corruption
Submitter : Rus <harbour@sfinx.od.ua>
Date : 2009-06-12 08:13 (75 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512
Subject : D43 on 2.6.30 doesn't suspend anymore
Submitter : Daniel Smolik <marvin@mydatex.cz>
Date : 2009-06-11 20:12 (76 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502
Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
Submitter : <sveina@gmail.com>
Date : 2009-06-10 20:04 (77 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408
Subject : Performance regression in 2.6.30-rc7
Submitter : Diego Calleja <diegocg@gmail.com>
Date : 2009-05-30 18:51 (88 days old)
References : http://lkml.org/lkml/2009/5/30/146
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407
Subject : adb trackpad disappears after suspend to ram
Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de>
Date : 2009-05-28 7:59 (90 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7
References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401
Subject : pktcdvd writing is really slow with CFQ scheduler (bisected)
Submitter : Laurent Riffard <laurent.riffard@free.fr>
Date : 2009-05-28 18:43 (90 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362
Subject : rt2x00: slow wifi with correct basic rate bitmap
Submitter : Alejandro Riveira <ariveira@gmail.com>
Date : 2009-05-22 13:32 (96 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351
Subject : 2.6.30 - 2.6.31 corrupts my system after suspend resume with readonly mounted hard disk
Submitter : <unggnu@googlemail.com>
Date : 2009-05-20 14:09 (98 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742
Handled-By : Yinghai Lu <yinghai@kernel.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject : Random Oops at boot at loading ip6tables rules
Submitter : <patrick@ostenberg.de>
Date : 2009-05-19 09:08 (99 days old)
Handled-By : Rusty Russell <rusty@rustcorp.com.au>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter : Francis Moreau <francis.moro@gmail.com>
Date : 2009-05-03 16:22 (115 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject : AGP doesn't work anymore on nforce2
Submitter : Karsten Mehrhoff <kawime@gmx.de>
Date : 2009-04-30 8:51 (118 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By : Shaohua Li <shaohua.li@intel.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject : hibernate slow on _second_ run
Submitter : Johannes Berg <johannes@sipsolutions.net>
Date : 2009-05-14 09:34 (104 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6
Submitter : David Hill <hilld@binarystorm.net>
Date : 2009-05-01 16:57 (117 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180
Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-04-21 21:35 (127 days old)
References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4
http://lkml.org/lkml/2009/4/27/290
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14059
Subject : DomU crashes during xenfb initialization
Submitter : Michal Schmidt <mschmidt@redhat.com>
Date : 2009-08-21 10:40 (5 days old)
References : http://marc.info/?l=linux-kernel&m=125085108431360&w=4
Handled-By : Michal Schmidt <mschmidt@redhat.com>
Patch : http://patchwork.kernel.org/patch/43107/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389
Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be
Submitter : Frans Pop <elendil@planet.nl>
Date : 2009-05-26 15:24 (92 days old)
Handled-By : Frans Pop <elendil@planet.nl>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671
http://bugzilla.kernel.org/attachment.cgi?id=21672
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319
Subject : Page allocation failures with b43 and p54usb
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2009-04-29 21:01 (119 days old)
References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
http://lkml.org/lkml/2009/6/7/136
http://lkml.org/lkml/2009/7/26/213
Handled-By : Johannes Berg <johannes@sipsolutions.net>
David Rientjes <rientjes@google.com>
Patch : http://patchwork.kernel.org/patch/37655/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.29 and 2.6.30, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=13070
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
* Re: 2.6.31-rc6-git5: Reported regressions from 2.6.30
From: Larry Finger @ 2009-08-25 23:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <200908220002.03707.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> On Friday 21 August 2009, Larry Finger wrote:
>> Rafael J. Wysocki wrote:
>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13960
>>> Subject : rtl8187 not connect to wifi
>>> Submitter : okias <d.okias@gmail.com>
>>> Date : 2009-08-10 19:16 (10 days old)
>> The patch for this one was sent from Linville to DaveM earlier today,
>> and should be sent to mainline in the near future.
>>
>> AFAIK, the OP has not yet tested the patch, but I think I was able to
>> reproduce the problem, and the patch did fit it for me.
>
> Thanks for the update.
>
> Can you please close the bug when the patch is merged?
The patch hit mainline as commit
1a9937b7f07ab6e35515e32a7625f0ba50ab7670. The bug has been closed.
Larry
^ permalink raw reply
* 2.6.31-rc7-git2: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-08-25 20:00 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.30, for which there
are no fixes in the mainline I know of. If any of them have been fixed already,
please let me know.
If you know of any other unresolved regressions from 2.6.30, please let me know
either and I'll add them to the list. Also, please let me know if any of the
entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-08-26 108 33 26
2009-08-20 102 32 29
2009-08-10 89 27 24
2009-08-02 76 36 28
2009-07-27 70 51 43
2009-07-07 35 25 21
2009-06-29 22 22 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14060
Subject : oops: sysfs_remove_link and i915
Submitter : Dominik Brodowski <linux@dominikbrodowski.net>
Date : 2009-08-22 5:48 (4 days old)
References : http://marc.info/?l=linux-kernel&m=125092139113955&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14058
Subject : Oops in fsnotify
Submitter : Grant Wilson <grant.wilson@zen.co.uk>
Date : 2009-08-20 15:48 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125078450923133&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14057
Subject : Strange network timeouts w/ e100
Submitter : Walt Holman <walt@holmansrus.com>
Date : 2009-08-20 0:21 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125072831831443&w=4
Handled-By : Krzysztof Halasa <khc@pm.waw.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14031
Subject : dvb_usb_af9015: Oops on hotplugging
Submitter : Stefan Lippers-Hollmann <s.L-H@gmx.de>
Date : 2009-08-05 20:32 (21 days old)
References : http://marc.info/?l=linux-kernel&m=124949716608828&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14018
Subject : kernel freezes, inotify problem
Submitter : Christoph Thielecke <christoph.thielecke@gmx.de>
Date : 2009-08-19 12:48 (7 days old)
References : http://marc.info/?l=linux-kernel&m=125068616818353&w=4
Handled-By : Eric Paris <eparis@parisplace.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14016
Subject : mm/ipw2200 regression
Submitter : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date : 2009-08-15 16:56 (11 days old)
References : http://marc.info/?l=linux-kernel&m=125036437221408&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14015
Subject : pty regressed again, breaking expect and gcc's testsuite
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2009-08-14 23:41 (12 days old)
References : http://marc.info/?l=linux-kernel&m=125029329805643&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14013
Subject : hd don't show up
Submitter : Tim Blechmann <tim@klingt.org>
Date : 2009-08-14 8:26 (12 days old)
References : http://marc.info/?l=linux-kernel&m=125023842514480&w=4
Handled-By : Tejun Heo <tj@kernel.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14012
Subject : latest git fried my x86_64 imac
Submitter : Justin P. Mattock <justinmattock@gmail.com>
Date : 2009-08-13 07:20 (13 days old)
References : http://marc.info/?l=linux-kernel&m=125014080427090&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14011
Subject : Kernel paging request failed in kmem_cache_alloc
Submitter : Matthias Dahl <ml_kernel@mortal-soul.de>
Date : 2009-08-10 22:26 (16 days old)
References : http://marc.info/?l=linux-kernel&m=124993603825082&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13987
Subject : Received NMI interrupt at resume
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2009-08-15 07:55 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13950
Subject : Oops when USB Serial disconnected while in use
Submitter : Bruno Prémont <bonbons@linux-vserver.org>
Date : 2009-08-08 17:47 (18 days old)
References : http://marc.info/?l=linux-kernel&m=124975432900466&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13943
Subject : WARNING: at net/mac80211/mlme.c:2292 with ath5k
Submitter : Fabio Comolli <fabio.comolli@gmail.com>
Date : 2009-08-06 20:15 (20 days old)
References : http://marc.info/?l=linux-kernel&m=124958978600600&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13942
Subject : Troubles with AoE and uninitialized object
Submitter : Bruno Prémont <bonbons@linux-vserver.org>
Date : 2009-08-04 10:12 (22 days old)
References : http://marc.info/?l=linux-kernel&m=124938117104811&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13941
Subject : x86 Geode issue
Submitter : Martin-Éric Racine <q-funk@iki.fi>
Date : 2009-08-03 12:58 (23 days old)
References : http://marc.info/?l=linux-kernel&m=124930434732481&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13940
Subject : iwlagn and sky2 stopped working, ACPI-related
Submitter : Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
Date : 2009-08-07 22:33 (19 days old)
References : http://marc.info/?l=linux-kernel&m=124968457731107&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13935
Subject : 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
Submitter : Adrian Ulrich <kernel@blinkenlights.ch>
Date : 2009-08-08 22:08 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13906
Subject : Huawei E169 GPRS connection causes Ooops
Submitter : Clemens Eisserer <linuxhippy@gmail.com>
Date : 2009-08-04 09:02 (22 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13869
Subject : Radeon framebuffer (w/o KMS) corruption at boot.
Submitter : Duncan <1i5t5.duncan@cox.net>
Date : 2009-07-29 16:44 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13848
Subject : iwlwifi (4965) regression since 2.6.30
Submitter : Lukas Hejtmanek <xhejtman@ics.muni.cz>
Date : 2009-07-26 7:57 (31 days old)
References : http://marc.info/?l=linux-kernel&m=124859658502866&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13836
Subject : suspend script fails, related to stdout?
Submitter : Tomas M. <tmezzadra@gmail.com>
Date : 2009-07-17 21:24 (40 days old)
References : http://marc.info/?l=linux-kernel&m=124785853811667&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject : system freeze when switching to console
Submitter : Reinette Chatre <reinette.chatre@intel.com>
Date : 2009-07-23 17:57 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13809
Subject : oprofile: possible circular locking dependency detected
Submitter : Jerome Marchand <jmarchan@redhat.com>
Date : 2009-07-22 13:35 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13740
Subject : X server crashes with 2.6.31-rc2 when options are changed
Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date : 2009-07-07 15:19 (50 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject : 2.6.31-rc2: irq 16: nobody cared
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-07-06 18:32 (51 days old)
References : http://marc.info/?l=linux-kernel&m=124690524027166&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject : NULL pointer dereference at (null) (level2_spare_pgt)
Submitter : poornima nayak <mpnayak@linux.vnet.ibm.com>
Date : 2009-06-17 17:56 (70 days old)
References : http://lkml.org/lkml/2009/6/17/194
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14062
Subject : Failure to boot as xen guest
Submitter : Arnd Hannemann <hannemann@nets.rwth-aachen.de>
Date : 2009-08-25 15:48 (1 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=83b519e8b9572c319c8e0c615ee5dd7272856090
References : http://marc.info/?l=linux-kernel&m=125121534229538&w=4
Handled-By : Jeremy Fitzhardinge <jeremy@goop.org>
Patch : http://patchwork.kernel.org/patch/43799/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14061
Subject : Crash due to buggy flat_phys_pkg_id
Submitter : Ravikiran G Thirumalai <kiran@scalex86.org>
Date : 2009-08-24 18:26 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125114085701508&w=4
Handled-By : Yinghai Lu <yinghai@kernel.org>
Patch : http://patchwork.kernel.org/patch/43806/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14030
Subject : Kernel NULL pointer dereference at 0000000000000008, pty-related
Submitter : Eric W. Biederman <ebiederm@xmission.com>
Date : 2009-08-20 5:46 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125074724623423&w=4
Handled-By : Linus Torvalds <torvalds@linux-foundation.org>
Patch : http://patchwork.kernel.org/patch/43679/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14017
Subject : _end symbol missing from Symbol.map
Submitter : Hannes Reinecke <hare@suse.de>
Date : 2009-08-13 6:45 (13 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=091e52c3551d3031343df24b573b770b4c6c72b6
References : http://marc.info/?l=linux-kernel&m=125014649102253&w=4
Handled-By : Hannes Reinecke <hare@suse.de>
Patch : http://marc.info/?l=linux-kernel&m=125014649102253&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13960
Subject : rtl8187 not connect to wifi
Submitter : okias <d.okias@gmail.com>
Date : 2009-08-10 19:16 (16 days old)
Handled-By : Larry Finger <Larry.Finger@lwfinger.net>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=22798
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13948
Subject : ath5k broken after suspend-to-ram
Submitter : Johannes Stezenbach <js@sig21.net>
Date : 2009-08-07 21:51 (19 days old)
References : http://marc.info/?l=linux-kernel&m=124968192727854&w=4
Handled-By : Nick Kossifidis <mickflemm@gmail.com>
Patch : http://patchwork.kernel.org/patch/38550/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13947
Subject : Libertas: Association request to the driver failed
Submitter : Daniel Mack <daniel@caiaq.de>
Date : 2009-08-07 19:11 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
References : http://marc.info/?l=linux-kernel&m=124967234311481&w=4
Handled-By : Roel Kluin <roel.kluin@gmail.com>
Dan Williams <dcbw@redhat.com>
Patch : http://patchwork.kernel.org/patch/43114/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.30,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=13615
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
* some improvement over yesterday net/wireless/sme.c:617 __cfg80211_disconnected+0x20c/0x220 [cfg80211]
From: ASIC Felix @ 2009-08-25 22:58 UTC (permalink / raw)
To: linux-wireless
2.6.31-rc7-33384-g4f9ed9c
master-2009-08-25
Much better than yesterday: only one double trace every 30 minutes.
Also: connection at higher rate, more stable. Thanks Johannes, Jouni.
Best regards, Felix
ath9k: Set HW Key
ath9k: Set HW Key
wlan0: deauthenticated from 00:0b:85:6f:12:a3 (Reason: 4)
ath9k: Configure tx [queue/halq] [0/3], aifs: 2, cw_min: 3, cw_max: 7, txop: 47
ath9k: Configure tx [queue/halq] [1/2], aifs: 2, cw_min: 7, cw_max:
15, txop: 94
ath9k: Configure tx [queue/halq] [2/1], aifs: 3, cw_min: 15, cw_max:
1023, txop: 0
ath9k: Configure tx [queue/halq] [3/0], aifs: 7, cw_min: 15, cw_max:
1023, txop: 0
ath9k: BSS Changed PREAMBLE 0
ath9k: BSS Changed CTS PROT 0
ath9k: BSS Changed ASSOC 0
ath9k: Bss Info DISASSOC
ath9k: Set HW Key
wlan0: deauthenticating by local choice (reason=3)
------------[ cut here ]------------
WARNING: at net/wireless/sme.c:617 __cfg80211_disconnected+0x20c/0x220
[cfg80211]()
Hardware name: 1875DLU
deauth failed: -67
Modules linked in: aes_i586 aes_generic xt_time xt_connlimit xt_realm
iptable_raw xt_comment ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP
ipt_MASQUERADE ipt_LOG ipt_ECN ipt_ecn ipt_ah ipt_addrtype nf_nat_tftp
nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc
nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda
nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp
nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns
nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss
xt_recent xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG
nfnetlink_log xt_multiport xt_MARK xt_mark xt_mac xt_limit xt_length
xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack
xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat
nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle
nfnetlink iptable_filter ip_tables x_tables af_packet bridge stp llc
bnep sco snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq arc4 snd_seq_device snd_pcm_oss
ecb ath9k snd_pcm snd_timer snd_mixer_oss mac80211 snd soundcore tg3
sg libphy snd_page_alloc i2c_i801 iTCO_wdt iTCO_vendor_support sr_mod
ath cfg80211 pcspkr rfcomm l2cap bluetooth ipv6 i915 drm i2c_algo_bit
i2c_core binfmt_misc yenta_socket rsrc_nonstatic pcmcia_core fuse
cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq
freq_table ehci_hcd uhci_hcd usbcore joydev evdev processor intel_agp
video output thinkpad_acpi rfkill led_class nvram nsc_ircc irda button
ac battery rtc_cmos crc_ccitt agpgart thermal ata_generic
ide_pci_generic ide_gd_mod ide_core pata_acpi ata_piix ahci libata
sd_mod scsi_mod crc_t10dif ext3 jbd
Pid: 2332, comm: phy0 Tainted: G W
2.6.31-rc7-wl-mnbStrip-33384-g4f9ed9c #69
Call Trace:
[<f7f261cc>] ? __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<f7f261cc>] ? __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<c013c55c>] warn_slowpath_common+0x6c/0xc0
[<f7f261cc>] ? __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<c013c5f6>] warn_slowpath_fmt+0x26/0x30
[<f7f261cc>] __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<f7f22f21>] ? nl80211_send_deauth+0x21/0x30 [cfg80211]
[<f7f24164>] __cfg80211_send_deauth+0x224/0x270 [cfg80211]
[<f85e0270>] ? ieee80211_set_disassoc+0x180/0x1e0 [mac80211]
[<f7f2420e>] cfg80211_send_deauth+0x5e/0x70 [cfg80211]
[<f85e1f9b>] ieee80211_sta_work+0xa0b/0x1850 [mac80211]
[<c01412f8>] ? tasklet_action+0x58/0xc0
[<c017d9a8>] ? handle_IRQ_event+0x58/0x140
[<c011bf7e>] ? ack_apic_level+0x7e/0x270
[<c01300c0>] ? rq_online_rt+0x0/0x70
[<c0138795>] ? dequeue_task_fair+0x295/0x2a0
[<c010256a>] ? __switch_to+0xba/0x1a0
[<c01332e6>] ? finish_task_switch+0x56/0xc0
[<c03a9bf4>] ? schedule+0x4a4/0xa50
[<c015379a>] ? prepare_to_wait+0x3a/0x70
[<c014edf1>] worker_thread+0x141/0x210
[<f85e1590>] ? ieee80211_sta_work+0x0/0x1850 [mac80211]
[<c0153550>] ? autoremove_wake_function+0x0/0x50
[<c014ecb0>] ? worker_thread+0x0/0x210
[<c01531fc>] kthread+0x7c/0x90
[<c0153180>] ? kthread+0x0/0x90
[<c0104657>] kernel_thread_helper+0x7/0x10
---[ end trace 31f58961567d44d1 ]---
wlan0: deauthenticating by local choice (reason=3)
------------[ cut here ]------------
WARNING: at net/wireless/sme.c:617 __cfg80211_disconnected+0x20c/0x220
[cfg80211]()
Hardware name: 1875DLU
deauth failed: -67
Modules linked in: aes_i586 aes_generic xt_time xt_connlimit xt_realm
iptable_raw xt_comment ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP
ipt_MASQUERADE ipt_LOG ipt_ECN ipt_ecn ipt_ah ipt_addrtype nf_nat_tftp
nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc
nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda
nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp
nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns
nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss
xt_recent xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG
nfnetlink_log xt_multiport xt_MARK xt_mark xt_mac xt_limit xt_length
xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack
xt_CONNMARK xt_connmark xt_CLASSIFY xt_tcpudp xt_state iptable_nat
nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle
nfnetlink iptable_filter ip_tables x_tables af_packet bridge stp llc
bnep sco snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq arc4 snd_seq_device snd_pcm_oss
ecb ath9k snd_pcm snd_timer snd_mixer_oss mac80211 snd soundcore tg3
sg libphy snd_page_alloc i2c_i801 iTCO_wdt iTCO_vendor_support sr_mod
ath cfg80211 pcspkr rfcomm l2cap bluetooth ipv6 i915 drm i2c_algo_bit
i2c_core binfmt_misc yenta_socket rsrc_nonstatic pcmcia_core fuse
cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq
freq_table ehci_hcd uhci_hcd usbcore joydev evdev processor intel_agp
video output thinkpad_acpi rfkill led_class nvram nsc_ircc irda button
ac battery rtc_cmos crc_ccitt agpgart thermal ata_generic
ide_pci_generic ide_gd_mod ide_core pata_acpi ata_piix ahci libata
sd_mod scsi_mod crc_t10dif ext3 jbd
Pid: 2332, comm: phy0 Tainted: G W
2.6.31-rc7-wl-mnbStrip-33384-g4f9ed9c #69
Call Trace:
[<f7f261cc>] ? __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<f7f261cc>] ? __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<c013c55c>] warn_slowpath_common+0x6c/0xc0
[<f7f261cc>] ? __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<c013c5f6>] warn_slowpath_fmt+0x26/0x30
[<f7f261cc>] __cfg80211_disconnected+0x20c/0x220 [cfg80211]
[<f7f22f21>] ? nl80211_send_deauth+0x21/0x30 [cfg80211]
[<f7f24164>] __cfg80211_send_deauth+0x224/0x270 [cfg80211]
[<f85e0270>] ? ieee80211_set_disassoc+0x180/0x1e0 [mac80211]
[<f7f2420e>] cfg80211_send_deauth+0x5e/0x70 [cfg80211]
[<f85e1f9b>] ieee80211_sta_work+0xa0b/0x1850 [mac80211]
[<c01412f8>] ? tasklet_action+0x58/0xc0
[<c017d9a8>] ? handle_IRQ_event+0x58/0x140
[<c011bf7e>] ? ack_apic_level+0x7e/0x270
[<c01300c0>] ? rq_online_rt+0x0/0x70
[<c0138795>] ? dequeue_task_fair+0x295/0x2a0
[<c010256a>] ? __switch_to+0xba/0x1a0
[<c01332e6>] ? finish_task_switch+0x56/0xc0
[<c03a9bf4>] ? schedule+0x4a4/0xa50
[<c015379a>] ? prepare_to_wait+0x3a/0x70
[<c014edf1>] worker_thread+0x141/0x210
[<f85e1590>] ? ieee80211_sta_work+0x0/0x1850 [mac80211]
[<c0153550>] ? autoremove_wake_function+0x0/0x50
[<c014ecb0>] ? worker_thread+0x0/0x210
[<c01531fc>] kthread+0x7c/0x90
[<c0153180>] ? kthread+0x0/0x90
[<c0104657>] kernel_thread_helper+0x7/0x10
---[ end trace 31f58961567d44d2 ]---
ath9k: Set HW Key
ath9k: Set HW RX filter: 0x10
ath9k: Set channel: 2412 MHz
ath9k: tx chmask: 3, rx chmask: 3
ath9k: (5745 MHz) -> (2412 MHz), chanwidth: 0
ath9k: Set channel: 2417 MHz
ath9k: tx chmask: 3, rx chmask: 3
^ permalink raw reply
* Re: [PATCH 2.6.31] ath5k: temporarily disable crypto for AP mode
From: Bob Copeland @ 2009-08-25 20:58 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linville, ath5k-devel, linux-wireless
In-Reply-To: <1251232252.9398.2.camel@mj>
On Tue, Aug 25, 2009 at 4:30 PM, Pavel Roskin<proski@gnu.org> wrote:
>>
>> Pavel, this ok with you for now?
>
> Sorry for delay. I don't have time to test it, but I have no specific
> objections.
Thanks, for the update. It already went to Linus I believe.
I did spend enough time looking at the root problem to decide that
fixing it won't be too hard, but I also saw some questionable logic
in the original code that wants a cleanup, I can post patches soon.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] b43: LP-PHY: Fix a few typos in the RC calibration code
From: Michael Buesch @ 2009-08-25 20:48 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Larry Finger, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <1251209868-7681-1-git-send-email-netrolller.3d@gmail.com>
On Tuesday 25 August 2009 16:17:48 Gábor Stefanik wrote:
> The RC calibration code has some typos - fix them.
> Also, make the default channel 7, as channel 1 is still
> broken (only channels 7 and 8, and occasionally 9 work).
>
> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
ack
> ---
> drivers/net/wireless/b43/phy_lp.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
> index 2d3a5d8..7e70c07 100644
> --- a/drivers/net/wireless/b43/phy_lp.c
> +++ b/drivers/net/wireless/b43/phy_lp.c
> @@ -44,7 +44,7 @@ static inline u16 channel2freq_lp(u8 channel)
> static unsigned int b43_lpphy_op_get_default_chan(struct b43_wldev *dev)
> {
> if (b43_current_band(dev->wl) == IEEE80211_BAND_2GHZ)
> - return 1;
> + return 7; //FIXME temporary - channel 1 is broken
> return 36;
> }
>
> @@ -705,7 +705,7 @@ static void lpphy_set_rc_cap(struct b43_wldev *dev)
> u8 rc_cap = (lpphy->rc_cap & 0x1F) >> 1;
>
> if (dev->phy.rev == 1) //FIXME check channel 14!
> - rc_cap = max_t(u8, rc_cap + 5, 15);
> + rc_cap = min_t(u8, rc_cap + 5, 15);
>
> b43_radio_write(dev, B2062_N_RXBB_CALIB2,
> max_t(u8, lpphy->rc_cap - 4, 0x80));
> @@ -1008,6 +1008,7 @@ static int lpphy_loopback(struct b43_wldev *dev)
>
> b43_phy_maskset(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0xFFFC, 0x3);
> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x3);
> + b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVR, 1);
> b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVRVAL, 0xFFFE);
> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_0, 0x800);
> b43_phy_set(dev, B43_LPPHY_RF_OVERRIDE_VAL_0, 0x800);
> @@ -1213,7 +1214,7 @@ static void lpphy_rev0_1_rc_calib(struct b43_wldev *dev)
> mean_sq_pwr = ideal_pwr - normal_pwr;
> mean_sq_pwr *= mean_sq_pwr;
> inner_sum += mean_sq_pwr;
> - if ((i = 128) || (inner_sum < mean_sq_pwr_min)) {
> + if ((i == 128) || (inner_sum < mean_sq_pwr_min)) {
> lpphy->rc_cap = i;
> mean_sq_pwr_min = inner_sum;
> }
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] b43: LP-PHY: Fix and simplify Qdiv roundup
From: Michael Buesch @ 2009-08-25 20:48 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Larry Finger, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <1251211217-7816-1-git-send-email-netrolller.3d@gmail.com>
On Tuesday 25 August 2009 16:40:17 Gábor Stefanik wrote:
> The Qdiv roundup routine is essentially a fixed-point
> division algorithm, using only integer math.
> However, the version in the specs had a major error
> that has been recently fixed (a missing quotient++).
>
> Replace Qdiv roundup with a rewritten, simplified version.
Don't we have some sort of standard library function somewhere in
the kernel for this? If not, what about creating one?
>
> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
> ---
> drivers/net/wireless/b43/phy_lp.c | 14 ++++----------
> 1 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
> index 7e70c07..d0280d5 100644
> --- a/drivers/net/wireless/b43/phy_lp.c
> +++ b/drivers/net/wireless/b43/phy_lp.c
> @@ -1034,7 +1034,7 @@ static int lpphy_loopback(struct b43_wldev *dev)
>
> static u32 lpphy_qdiv_roundup(u32 dividend, u32 divisor, u8 precision)
> {
> - u32 quotient, remainder, rbit, roundup, tmp;
> + u32 quotient, remainder;
>
> if (divisor == 0)
> return 0;
> @@ -1042,20 +1042,14 @@ static u32 lpphy_qdiv_roundup(u32 dividend, u32 divisor, u8 precision)
> quotient = dividend / divisor;
> remainder = dividend % divisor;
>
> - rbit = divisor & 0x1;
> - roundup = (divisor >> 1) + rbit;
> -
> while (precision != 0) {
> - tmp = remainder - roundup;
> quotient <<= 1;
> - if (remainder >= roundup)
> - remainder = (tmp << 1) + rbit;
> - else
> - remainder <<= 1;
> + quotient |= (remainder << 1) / divisor;
> + remainder = (remainder << 1) % divisor;
> precision--;
> }
>
> - if (remainder >= roundup)
> + if (remainder << 1 >= divisor)
> quotient++;
>
> return quotient;
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH 2.6.31] ath5k: temporarily disable crypto for AP mode
From: Pavel Roskin @ 2009-08-25 20:30 UTC (permalink / raw)
To: Bob Copeland; +Cc: linville, ath5k-devel, linux-wireless
In-Reply-To: <20090714015739.GA28490@hash.localnet>
On Mon, 2009-07-13 at 21:57 -0400, Bob Copeland wrote:
> Pavel Roskin reported some issues with using AP mode without
> nohwcrypt=1. Most likely this is similar to the problem fixed
> some time ago in ath9k by 3f53dd64f192450cb331c0fecfc26ca952fb242f,
> "ath9k: Fix hw crypto configuration for TKIP in AP mode."
>
> That only affects TKIP but it's easiest to just disable that and
> WEP too until we get a proper fix in.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
>
> Pavel, this ok with you for now?
Sorry for delay. I don't have time to test it, but I have no specific
objections.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] atheros: add ar9170.fw 1-stage firmware
From: Luis R. Rodriguez @ 2009-08-25 19:29 UTC (permalink / raw)
To: Richard Farina
Cc: Luis Rodriguez, dwmw2@infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <4A943AFE.1000500@gmail.com>
On Tue, Aug 25, 2009 at 12:26:54PM -0700, Richard Farina wrote:
> Luis R. Rodriguez wrote:
> > On Thu, Aug 20, 2009 at 01:07:57PM -0700, Richard Farina wrote:
> >
> >> Luis R. Rodriguez wrote:
> >>
> >>> This adds support for ar9170 for using a 1-stage firmware.
> >>> This means only 1 firmware file is required. AVM Fritz
> >>> devices require this.
> >>>
> >>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> >>> ---
> >>>
> >>> Here is a resend, noticed today this wasn't yet in the tree.
> >>>
> >>>
> >>>
> >> Last I tested this firmware it didn't seem to function nearly as well as
> >> the 2 stage firmware, and if present, the 1 stage overrides the 2
> >> stage.
> >>
> >
> > Can you be more specific than that?
> >
> >
> >> Is this an improved version?
> >>
> >
> > No, it is the same firmware.
> >
> >
> >> Does this work properly in your testing?
> >>
> >
> > Works for me, and is also required for usage of AVM Fritz devices.
> >
> >
> I apologize for my confusion. Since we spoke on irc I am now clear that
> this specific ar9170 firmware is slightly different than the open source
> one available in git and seems a bit more stable than the 2 stage I was
> previously using. I have tested monitor mode and packet injection which
> are the only things that interest me about this device at the moment and
> both appear slightly more stable using the 1 stage firmware. Please do
> add the firmware located at
> http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/ar9170.fw
> to the linux firmware git repo. I believe that it would be a benefit to
> many.
>
> ACKED BY: Rick Farina
> TESTED BY: Rick Farina
>
> On a similar note, the open firmware has had issues reported by many
> with speed and stability so I wouldn't recommend using it yet, but this
> is mostly based on the complaints I've heard rather than my own personal
> testing so remember a grain of salt.
Thanks for the clarification, yeah I do believe the open fw needs more work,
the code base is the same though so it remains unclear what could be the
issue. Anyway I'll push this through and if hopefully more interested people
can work on the open fw. I'll respin with the WHENCE changed.
Luis
^ permalink raw reply
* Re: [PATCH] ath5k: fix print on warning on ath5k_hw_to_driver_rix()
From: Bob Copeland @ 2009-08-25 19:22 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <20090825185842.GA7357@mosca>
On Tue, Aug 25, 2009 at 2:58 PM, Luis R.
Rodriguez<lrodriguez@atheros.com> wrote:
> OK how about the band info, think that's useful?
Yeah, band is useful. We don't have to pretty print it though
(unless you really feel like it), %d would work just as well.
Also WARN_ON_ONCE might be a good idea.
>> which could indicate some
>> race condition with flushing the rx queue on channel changes.
>
> I'll see if I can reproduce somehow.
>
>> I haven't yet seen a hw rate we didn't know about.
>
> So you've seen this lately as well?
I saw it some time ago, but then changed the order of how the
curchan/curband variables were set when we change channels and
haven't seen since. But kerneloops says a lot of other people
are still hitting it as well :(
Hmm, ath5k_rx_stop probably wants an equivalent to txq_drainq in
there somewhere.
--
Bob Copeland %% www.bobcopeland.com
^ 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