* [PATCH 1/5] ath5k: Check EEPROM before tweaking SERDES
From: Nick Kossifidis @ 2009-08-10 0:26 UTC (permalink / raw)
To: ath5k-devel, linux-wireless; +Cc: linville, jirislaby, me, mcgrof, nbd
* Read PCI-E infos offset from EEPROM and if it points to
serdes section (0x40), enable serdes programming (further tweaking
of serdes values during attach). This follows Legacy and Sam's
HAL sources.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Acked-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/attach.c | 56 +++++++++++++++++++------------
drivers/net/wireless/ath/ath5k/eeprom.c | 10 +++++
drivers/net/wireless/ath/ath5k/eeprom.h | 4 ++
3 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index 9a84d94..6263065 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -253,28 +253,6 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
}
/*
- * Write PCI-E power save settings
- */
- if ((ah->ah_version == AR5K_AR5212) && (pdev->is_pcie)) {
- ath5k_hw_reg_write(ah, 0x9248fc00, AR5K_PCIE_SERDES);
- ath5k_hw_reg_write(ah, 0x24924924, AR5K_PCIE_SERDES);
- /* Shut off RX when elecidle is asserted */
- ath5k_hw_reg_write(ah, 0x28000039, AR5K_PCIE_SERDES);
- ath5k_hw_reg_write(ah, 0x53160824, AR5K_PCIE_SERDES);
- /* TODO: EEPROM work */
- ath5k_hw_reg_write(ah, 0xe5980579, AR5K_PCIE_SERDES);
- /* Shut off PLL and CLKREQ active in L1 */
- ath5k_hw_reg_write(ah, 0x001defff, AR5K_PCIE_SERDES);
- /* Preserce other settings */
- ath5k_hw_reg_write(ah, 0x1aaabe40, AR5K_PCIE_SERDES);
- ath5k_hw_reg_write(ah, 0xbe105554, AR5K_PCIE_SERDES);
- ath5k_hw_reg_write(ah, 0x000e3007, AR5K_PCIE_SERDES);
- /* Reset SERDES to load new settings */
- ath5k_hw_reg_write(ah, 0x00000000, AR5K_PCIE_SERDES_RESET);
- mdelay(1);
- }
-
- /*
* POST
*/
ret = ath5k_hw_post(ah);
@@ -295,6 +273,40 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
goto err_free;
}
+ /*
+ * Write PCI-E power save settings
+ */
+ if ((ah->ah_version == AR5K_AR5212) && (pdev->is_pcie)) {
+ struct ath5k_eeprom_info *ee = &ah->ah_capabilities.cap_eeprom;
+
+ ath5k_hw_reg_write(ah, 0x9248fc00, AR5K_PCIE_SERDES);
+ ath5k_hw_reg_write(ah, 0x24924924, AR5K_PCIE_SERDES);
+
+ /* Shut off RX when elecidle is asserted */
+ ath5k_hw_reg_write(ah, 0x28000039, AR5K_PCIE_SERDES);
+ ath5k_hw_reg_write(ah, 0x53160824, AR5K_PCIE_SERDES);
+
+ /* If serdes programing is enabled, increase PCI-E
+ * tx power for systems with long trace from host
+ * to minicard connector. */
+ if (ee->ee_serdes)
+ ath5k_hw_reg_write(ah, 0xe5980579, AR5K_PCIE_SERDES);
+ else
+ ath5k_hw_reg_write(ah, 0xf6800579, AR5K_PCIE_SERDES);
+
+ /* Shut off PLL and CLKREQ active in L1 */
+ ath5k_hw_reg_write(ah, 0x001defff, AR5K_PCIE_SERDES);
+
+ /* Preserve other settings */
+ ath5k_hw_reg_write(ah, 0x1aaabe40, AR5K_PCIE_SERDES);
+ ath5k_hw_reg_write(ah, 0xbe105554, AR5K_PCIE_SERDES);
+ ath5k_hw_reg_write(ah, 0x000e3007, AR5K_PCIE_SERDES);
+
+ /* Reset SERDES to load new settings */
+ ath5k_hw_reg_write(ah, 0x00000000, AR5K_PCIE_SERDES_RESET);
+ mdelay(1);
+ }
+
/* Get misc capabilities */
ret = ath5k_hw_set_capabilities(ah);
if (ret) {
diff --git a/drivers/net/wireless/ath/ath5k/eeprom.c b/drivers/net/wireless/ath/ath5k/eeprom.c
index c56b494..8af477d 100644
--- a/drivers/net/wireless/ath/ath5k/eeprom.c
+++ b/drivers/net/wireless/ath/ath5k/eeprom.c
@@ -167,6 +167,16 @@ ath5k_eeprom_init_header(struct ath5k_hw *ah)
ee->ee_rfkill_pin = (u8) AR5K_REG_MS(val, AR5K_EEPROM_RFKILL_GPIO_SEL);
ee->ee_rfkill_pol = val & AR5K_EEPROM_RFKILL_POLARITY ? true : false;
+ /* Check if PCIE_OFFSET points to PCIE_SERDES_SECTION
+ * and enable serdes programming if needed.
+ *
+ * XXX: Serdes values seem to be fixed so
+ * no need to read them here, we write them
+ * during ath5k_hw_attach */
+ AR5K_EEPROM_READ(AR5K_EEPROM_PCIE_OFFSET, val);
+ ee->ee_serdes = (val == AR5K_EEPROM_PCIE_SERDES_SECTION) ?
+ true : false;
+
return 0;
}
diff --git a/drivers/net/wireless/ath/ath5k/eeprom.h b/drivers/net/wireless/ath/ath5k/eeprom.h
index 64be73a..0123f35 100644
--- a/drivers/net/wireless/ath/ath5k/eeprom.h
+++ b/drivers/net/wireless/ath/ath5k/eeprom.h
@@ -19,6 +19,9 @@
/*
* Common ar5xxx EEPROM data offsets (set these on AR5K_EEPROM_BASE)
*/
+#define AR5K_EEPROM_PCIE_OFFSET 0x02 /* Contains offset to PCI-E infos */
+#define AR5K_EEPROM_PCIE_SERDES_SECTION 0x40 /* PCIE_OFFSET points here when
+ * SERDES infos are present */
#define AR5K_EEPROM_MAGIC 0x003d /* EEPROM Magic number */
#define AR5K_EEPROM_MAGIC_VALUE 0x5aa5 /* Default - found on EEPROM */
#define AR5K_EEPROM_MAGIC_5212 0x0000145c /* 5212 */
@@ -391,6 +394,7 @@ struct ath5k_eeprom_info {
u8 ee_rfkill_pin;
bool ee_rfkill_pol;
bool ee_is_hb63;
+ bool ee_serdes;
u16 ee_misc0;
u16 ee_misc1;
u16 ee_misc2;
^ permalink raw reply related
* 2.6.31-rc5-git5: Reported regressions 2.6.29 -> 2.6.30
From: Rafael J. Wysocki @ 2009-08-09 21:07 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-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=13949
Subject : XFS regression
Submitter : Justin Piszcz <jpiszcz@lucidpixels.com>
Date : 2009-08-08 8:39 (2 days old)
References : http://marc.info/?l=linux-kernel&m=124972079229959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13945
Subject : Kernel freezes dual pentium-3 system
Submitter : Martin Rogge <marogge@onlinehome.de>
Date : 2009-08-03 16:25 (7 days old)
References : http://marc.info/?l=linux-kernel&m=124931667320530&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 (10 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 (23 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 (23 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 (26 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 (27 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 (34 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 (39 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 (41 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660
Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
Submitter : Joao Correia <joaomiguelcorreia@gmail.com>
Date : 2009-06-27 16:07 (44 days old)
References : http://lkml.org/lkml/2009/6/27/95
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 (52 days old)
References : http://lkml.org/lkml/2009/6/19/187
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638
Subject : rt2870 driver is broken for (some) cards
Submitter : jakob gruber <jakob.gruber@kabelnet.at>
Date : 2009-06-27 17:33 (44 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634
Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date : 2009-06-27 07:02 (44 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621
Subject : xfs hangs with assertion failed
Submitter : Johannes Engel <jcnengel@googlemail.com>
Date : 2009-06-25 10:07 (46 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620
Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs
Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date : 2009-06-25 08:31 (46 days old)
References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html>
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 (52 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 (52 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 (53 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 (54 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 (59 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 (60 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 (61 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 (72 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 (74 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 (74 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374
Subject : reiserfs blocked for more than 120secs
Submitter : Harald Dunkel <harald.dunkel@t-online.de>
Date : 2009-05-23 8:52 (79 days old)
References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4
http://lkml.org/lkml/2009/5/29/389
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373
Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2009-05-23 5:08 (79 days old)
References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4
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 (80 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351
Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk
Submitter : <unggnu@googlemail.com>
Date : 2009-05-20 14:09 (82 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 (83 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 (99 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 (102 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 (88 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 (101 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 (111 days old)
References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4
http://lkml.org/lkml/2009/4/27/290
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109
Subject : High latency on /sys/class/thermal
Submitter : Tiago Simões Batista <tiagosbatista@gmail.com>
Date : 2009-04-11 14:56 (121 days old)
References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4
Handled-By : Zhang Rui <rui.zhang@intel.com>
Alexey Starikovskiy <astarikovskiy@suse.de>
Regressions with patches
------------------------
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 (76 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 (103 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
* 2.6.31-rc5-git5: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-08-09 20:36 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-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=13950
Subject : Oops when USB Serial disconnected while in use
Submitter : Bruno Prémont <bonbons@linux-vserver.org>
Date : 2009-08-08 17:47 (2 days old)
References : http://marc.info/?l=linux-kernel&m=124975432900466&w=4
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 (3 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>
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 (4 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 (6 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 (7 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 (3 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 (2 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=13914
Subject : e1000e reports invalid NVM Checksum on 82566DM-2 (bisected)
Submitter : <jsbronder@gentoo.org>
Date : 2009-08-04 18:06 (6 days old)
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 (6 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13899
Subject : Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.
Submitter : Gene Heskett <gene.heskett@verizon.net>
Date : 2009-08-01 13:04 (9 days old)
References : http://marc.info/?l=linux-kernel&m=124913190304149&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13895
Subject : 2.6.31-rc4 - slab entry tak_delay_info leaking ???
Submitter : Paul Rolland <rol@as2917.net>
Date : 2009-07-29 08:20 (12 days old)
References : http://marc.info/?l=linux-kernel&m=124884847925375&w=4
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 (12 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 (15 days old)
References : http://marc.info/?l=linux-kernel&m=124859658502866&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13846
Subject : LEDs switched off permanently by power saving with rt61pci driver
Submitter : Chris Clayton <chris2553@googlemail.com>
Date : 2009-07-13 8:27 (28 days old)
References : http://marc.info/?l=linux-kernel&m=124747418828398&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13837
Subject : Input : regression - touchpad not detected
Submitter : Dave Young <hidave.darkstar@gmail.com>
Date : 2009-07-17 07:13 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124780763701571&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 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124785853811667&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13833
Subject : Kernel Oops when trying to suspend with ubifs mounted on block2mtd mtd device
Submitter : Tobias Diedrich <ranma@tdiedrich.de>
Date : 2009-07-15 14:20 (26 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=15bce40cb3133bcc07d548013df97e4653d363c1
References : http://marc.info/?l=linux-kernel&m=124766049207807&w=4
http://marc.info/?l=linux-kernel&m=124704927819769&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 (18 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 (19 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 (34 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 (35 days old)
References : http://marc.info/?l=linux-kernel&m=124690524027166&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13716
Subject : The AIC-7892P controller does not work any more
Submitter : Andrej Podzimek <andrej@podzimek.org>
Date : 2009-07-05 19:23 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13713
Subject : [drm/i915] Possible regression due to commit "Change GEM throttling to be 20ms (...)"
Submitter : <kazikcz@gmail.com>
Date : 2009-07-05 10:49 (36 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b962442e46a9340bdbc6711982c59ff0cc2b5afb
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 (54 days old)
References : http://lkml.org/lkml/2009/6/17/194
Regressions with patches
------------------------
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 (3 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=13946
Subject : x86 MCE malfunction on Thinkpad T42p
Submitter : Johannes Stezenbach <js@sig21.net>
Date : 2009-08-07 17:09 (3 days old)
References : http://marc.info/?l=linux-kernel&m=124966500232399&w=4
Handled-By : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Patch : http://patchwork.kernel.org/patch/37908/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13944
Subject : MD raid regression
Submitter : Mike Snitzer <snitzer@redhat.com>
Date : 2009-08-05 15:06 (5 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=449aad3e25358812c43afc60918c5ad3819488e7
References : http://marc.info/?l=linux-kernel&m=124948481218857&w=4
Handled-By : NeilBrown <neilb@suse.de>
Patch : http://patchwork.kernel.org/patch/39521/
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
* [PATCH] rt2x00: Fix beacon de-synchronization while update beacon
From: Ivo van Doorn @ 2009-08-09 22:58 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, igor.perminov
From: Igor Perminov <igor.perminov@inbox.ru>
When beacon is being updated to refresh TIM (AP mode), beacon frames are
de-synchronizing (i.e. two neighbor beacon frames - before and after
update - are being transmitted with a wrong time interval).
That is because xxx_write_beacon should disable beacon generation only
while beacon data are being uploaded to the device, but it should not
disable the beacon clock.
Signed-off-by: Igor Perminov <igor.perminov@inbox.ru>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2400pci.c | 2 --
drivers/net/wireless/rt2x00/rt2500pci.c | 2 --
drivers/net/wireless/rt2x00/rt2500usb.c | 15 ++++++++-------
drivers/net/wireless/rt2x00/rt2800usb.c | 2 --
drivers/net/wireless/rt2x00/rt61pci.c | 2 --
drivers/net/wireless/rt2x00/rt73usb.c | 2 --
7 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index 30185ad..164df93 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1069,8 +1069,6 @@ static void rt2400pci_write_beacon(struct queue_entry *entry)
* otherwise we might be sending out invalid data.
*/
rt2x00pci_register_read(rt2x00dev, CSR14, ®);
- rt2x00_set_field32(®, CSR14_TSF_COUNT, 0);
- rt2x00_set_field32(®, CSR14_TBCN, 0);
rt2x00_set_field32(®, CSR14_BEACON_GEN, 0);
rt2x00pci_register_write(rt2x00dev, CSR14, reg);
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 3b31715..4186582 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1227,8 +1227,6 @@ static void rt2500pci_write_beacon(struct queue_entry *entry)
* otherwise we might be sending out invalid data.
*/
rt2x00pci_register_read(rt2x00dev, CSR14, ®);
- rt2x00_set_field32(®, CSR14_TSF_COUNT, 0);
- rt2x00_set_field32(®, CSR14_TBCN, 0);
rt2x00_set_field32(®, CSR14_BEACON_GEN, 0);
rt2x00pci_register_write(rt2x00dev, CSR14, reg);
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index de48c5c..09a5894 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1238,8 +1238,6 @@ static void rt2500usb_write_beacon(struct queue_entry *entry)
* otherwise we might be sending out invalid data.
*/
rt2500usb_register_read(rt2x00dev, TXRX_CSR19, ®);
- rt2x00_set_field16(®, TXRX_CSR19_TSF_COUNT, 0);
- rt2x00_set_field16(®, TXRX_CSR19_TBCN, 0);
rt2x00_set_field16(®, TXRX_CSR19_BEACON_GEN, 0);
rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg);
@@ -1287,7 +1285,7 @@ static int rt2500usb_get_tx_data_len(struct queue_entry *entry)
static void rt2500usb_kick_tx_queue(struct rt2x00_dev *rt2x00dev,
const enum data_queue_qid queue)
{
- u16 reg;
+ u16 reg, reg0;
if (queue != QID_BEACON) {
rt2x00usb_kick_tx_queue(rt2x00dev, queue);
@@ -1298,16 +1296,19 @@ static void rt2500usb_kick_tx_queue(struct rt2x00_dev *rt2x00dev,
if (!rt2x00_get_field16(reg, TXRX_CSR19_BEACON_GEN)) {
rt2x00_set_field16(®, TXRX_CSR19_TSF_COUNT, 1);
rt2x00_set_field16(®, TXRX_CSR19_TBCN, 1);
+ reg0 = reg;
rt2x00_set_field16(®, TXRX_CSR19_BEACON_GEN, 1);
/*
* Beacon generation will fail initially.
- * To prevent this we need to register the TXRX_CSR19
- * register several times.
+ * To prevent this we need to change the TXRX_CSR19
+ * register several times (reg0 is the same as reg
+ * except for TXRX_CSR19_BEACON_GEN, which is 0 in reg0
+ * and 1 in reg).
*/
rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg);
- rt2500usb_register_write(rt2x00dev, TXRX_CSR19, 0);
+ rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg0);
rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg);
- rt2500usb_register_write(rt2x00dev, TXRX_CSR19, 0);
+ rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg0);
rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg);
}
}
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 2de0389..3856f06 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -2050,8 +2050,6 @@ static void rt2800usb_write_beacon(struct queue_entry *entry)
* otherwise we might be sending out invalid data.
*/
rt2x00usb_register_read(rt2x00dev, BCN_TIME_CFG, ®);
- rt2x00_set_field32(®, BCN_TIME_CFG_TSF_TICKING, 0);
- rt2x00_set_field32(®, BCN_TIME_CFG_TBTT_ENABLE, 0);
rt2x00_set_field32(®, BCN_TIME_CFG_BEACON_GEN, 0);
rt2x00usb_register_write(rt2x00dev, BCN_TIME_CFG, reg);
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 3447997..f4b4b86 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -1855,8 +1855,6 @@ static void rt61pci_write_beacon(struct queue_entry *entry)
* otherwise we might be sending out invalid data.
*/
rt2x00pci_register_read(rt2x00dev, TXRX_CSR9, ®);
- rt2x00_set_field32(®, TXRX_CSR9_TSF_TICKING, 0);
- rt2x00_set_field32(®, TXRX_CSR9_TBTT_ENABLE, 0);
rt2x00_set_field32(®, TXRX_CSR9_BEACON_GEN, 0);
rt2x00pci_register_write(rt2x00dev, TXRX_CSR9, reg);
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 4b9955b..4d94b65 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -1527,8 +1527,6 @@ static void rt73usb_write_beacon(struct queue_entry *entry)
* otherwise we might be sending out invalid data.
*/
rt2x00usb_register_read(rt2x00dev, TXRX_CSR9, ®);
- rt2x00_set_field32(®, TXRX_CSR9_TSF_TICKING, 0);
- rt2x00_set_field32(®, TXRX_CSR9_TBTT_ENABLE, 0);
rt2x00_set_field32(®, TXRX_CSR9_BEACON_GEN, 0);
rt2x00usb_register_write(rt2x00dev, TXRX_CSR9, reg);
--
1.6.3.3
^ permalink raw reply related
* Re: Deauthentications with p54usb
From: Chunkeey @ 2009-08-09 21:45 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
"Larry Finger" <Larry.Finger@lwfinger.net> wrote:
> Chunkeey@web.de wrote:
> > Ahh, wait... screw up: I failed to explain the difference between:
> > vs.
> > - hibernation (soft rfkill that went in with "[PATCH] p54: implement rfkill")
> > In this mode: the device's radio is completely shutdown... so
> > it only makes sense to enter this mode when there's really nothing
> > to do (=> the device is not scanning or associating/associated)
> >
> > mac80211 will printk (with CONFIG_MAC80211_VERBOSE_DEBUG set)
> > whenever the IEEE80211_CONF_IDLE changes. e.g:
> > phy0: device no longer idle - REASON
> > or:
> > phy0: device now idle
> > in the kernel logs.
> >
> >> Turning off CONFIG_CFG80211_DEFAULT_PS stopped the messages,
> >> thus it certainly looks like a power saving event.
> > so hibernation (rfkill) is fine, just powersave is playing tricks...
> > weirdly, intel disabled ps in their driver _again_ not too long ago,
> > maybe a coincident, maybe not... do you think you can send me
> > a kismet/wireshark/airodump dump whenever the AP kicks the device?
>
> We don't know that hibernation is OK. I just never make my machine
> hibernate (suspend to disk) or sleep (suspend to RAM).
> The last time I tried it had one or more drivers that would not cooperate,
> and I have not tried recently.
meh, overloaded words ;-)
that hibernation paragraph is about the hibernation _filter_ state:
#define P54_FILTER_TYPE_HIBERNATE BIT(5) <-- lmac.h
this operation mode silence the device (no frames will be send, or received),
which makes it ideal for soft - rfkill.
but yeah, that name is definitely misleading. We don't want to
hibernate/(suspend) the whole machine... just the p54 device,
when it's not connected.
> > BTW: you can set different PS modes with the old iwconfig utility:
> > iwconfig wlanX power off <-- disables PS
> > (just like turning off the CONFIG_CFG80211_DEFAULT_PS option)
> >
> > iwconfig wlanX power timeout 0 <--- most aggressive PS setting,
> > (only uses PS-POLL to retrieve data).
> >
> > AFAIK the current default is just "1", maybe your link would be
> > totally reliable with a more _relaxed_ 200, 500 setting...
>
> I'll re-enable CONFIG_CFG80211_DEFAULT_PS and try a more relaxed value
> for the power timeout. In any case, with it disabled, there have been
> no deauthentications nor disassociations. The link is rock solid.
Thanks for confirming my thoughts!
So, the rfkill changes are not to blame for this problem and we can
take them out of the equation.
The weird thing is that the driver's PS code (relevant to STA mode)
has not changed since you did the exhaustive tests last month.
Regards,
Chr
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
^ permalink raw reply
* Re: Deauthentications with p54usb
From: Larry Finger @ 2009-08-09 20:27 UTC (permalink / raw)
To: Chunkeey; +Cc: wireless
In-Reply-To: <1756555272@web.de>
Chunkeey@web.de wrote:
> Ahh, wait... screw up: I failed to explain the difference between:
>
> - powersave (=> responsible for your connection problems)
> In this mode: the device goes into a lower power state,
> but continues to listen for dtim beacons and multicast frames,
> from the AP.
>
> mac80211 does not have printks for these ps events,
> since the device power state may chance every second.
>
> howeve, it's possible to trace them through the generic _trace_
> framework with MAC80211_DRIVER_API_TRACER Kconfig
> option enabled.
>
> vs.
>
> - hibernation (soft rfkill that went in with "[PATCH] p54: implement rfkill")
> In this mode: the device's radio is completely shutdown... so
> it only makes sense to enter this mode when there's really nothing
> to do (=> the device is not scanning or associating/associated)
>
> mac80211 will printk (with CONFIG_MAC80211_VERBOSE_DEBUG set)
> whenever the IEEE80211_CONF_IDLE changes. e.g:
> phy0: device no longer idle - REASON
> or:
> phy0: device now idle
> in the kernel logs.
>
>> Turning off CONFIG_CFG80211_DEFAULT_PS stopped the messages,
>> thus it certainly looks like a power saving event.
> so hibernation (rfkill) is fine, just powersave is playing tricks...
> weirdly, intel disabled ps in their driver _again_ not too long ago,
> maybe a coincident, maybe not... do you think you can send me
> a kismet/wireshark/airodump dump whenever the AP kicks the device?
We don't know that hibernation is OK. I just never make my machine
hibernate (suspend to disk) or sleep (suspend to RAM). The last time I
tried it had one or more drivers that would not cooperate, and I have
not tried recently.
I'll try to collect a dump.
> BTW: you can set different PS modes with the old iwconfig utility:
> iwconfig wlanX power off <-- disables PS
> (just like turning off the CONFIG_CFG80211_DEFAULT_PS option)
>
> iwconfig wlanX power timeout 0 <--- most aggressive PS setting,
> (only uses PS-POLL to retrieve data).
>
> AFAIK the current default is just "1", maybe your link would be
> totally reliable with a more _relaxed_ 200, 500 setting...
I'll re-enable CONFIG_CFG80211_DEFAULT_PS and try a more relaxed value
for the power timeout. In any case, with it disabled, there have been
no deauthentications nor disassociations. The link is rock solid.
Larry
^ permalink raw reply
* Re: Deauthentications with p54usb
From: Chunkeey @ 2009-08-09 20:02 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
"Larry Finger" <Larry.Finger@lwfinger.net> wrote
> Christian Lamparter wrote:
> >
> > reason 7 must be:
> > WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA
> >
> > and class 3 frames are (according to 802.11-2007 11.3.c)
> > - "normal" data frames
> > (- some MLMEs - probably not relevant )
> > - control frame:
> > => especially: Power Save Poll.
> >
> > your log doesn't hold any records about a disassoc event from the AP.
> > so, my first guess would be that you're hitting yet another
> > power saving related issue. And as far as I know b43 does not do that yet.
> > So, can you please give the device another go without ps?
> >
> > (BTW: mac80211 prints a debug text (if enabled in kconfig),
> > whenever the device goes or leaves the hibernation mode...
> > do you see any of those too?)
>
> Once I got that debug mode set with PS enabled, I still got the deauth
> events, but no messages from mac80211. I may not have had the debug
> value set correctly.
Ahh, wait... screw up: I failed to explain the difference between:
- powersave (=> responsible for your connection problems)
In this mode: the device goes into a lower power state,
but continues to listen for dtim beacons and multicast frames,
from the AP.
mac80211 does not have printks for these ps events,
since the device power state may chance every second.
howeve, it's possible to trace them through the generic _trace_
framework with MAC80211_DRIVER_API_TRACER Kconfig
option enabled.
vs.
- hibernation (soft rfkill that went in with "[PATCH] p54: implement rfkill")
In this mode: the device's radio is completely shutdown... so
it only makes sense to enter this mode when there's really nothing
to do (=> the device is not scanning or associating/associated)
mac80211 will printk (with CONFIG_MAC80211_VERBOSE_DEBUG set)
whenever the IEEE80211_CONF_IDLE changes. e.g:
phy0: device no longer idle - REASON
or:
phy0: device now idle
in the kernel logs.
> Turning off CONFIG_CFG80211_DEFAULT_PS stopped the messages,
> thus it certainly looks like a power saving event.
so hibernation (rfkill) is fine, just powersave is playing tricks...
weirdly, intel disabled ps in their driver _again_ not too long ago,
maybe a coincident, maybe not... do you think you can send me
a kismet/wireshark/airodump dump whenever the AP kicks the device?
BTW: you can set different PS modes with the old iwconfig utility:
iwconfig wlanX power off <-- disables PS
(just like turning off the CONFIG_CFG80211_DEFAULT_PS option)
iwconfig wlanX power timeout 0 <--- most aggressive PS setting,
(only uses PS-POLL to retrieve data).
AFAIK the current default is just "1", maybe your link would be
totally reliable with a more _relaxed_ 200, 500 setting...
Regards,
Chr
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
^ permalink raw reply
* Re: Libertas: Association request to the driver failed
From: Cyrill Gorcunov @ 2009-08-09 19:13 UTC (permalink / raw)
To: Michael Buesch
Cc: Roel Kluin, Daniel Mack, John W. Linville, libertas-dev,
linux-wireless, linux-kernel
In-Reply-To: <200908091310.56919.mb@bu3sch.de>
[Michael Buesch - Sun, Aug 09, 2009 at 01:10:56PM +0200]
| On Sunday 09 August 2009 13:11:20 Roel Kluin wrote:
| > @@ -43,21 +44,21 @@ static int get_common_rates(struct lbs_private *priv,
| > u16 *rates_size)
| > {
| > u8 *card_rates = lbs_bg_rates;
| > - size_t num_card_rates = sizeof(lbs_bg_rates);
| > int ret = 0, i, j;
| > - u8 tmp[30];
| > + u8 tmp[*rates_size * ARRAY_SIZE(lbs_bg_rates)];
|
| Is it a good idea to use dynamic stack arrays in the kernel?
| What about kmalloc for dynamic allocations?
|
| --
| Greetings, Michael.
I saw one pattern in trace code (not sure if it's
still there) but personally don't like dynamic
stack arrays (though at moment the max value
being passed into routine is known maybe just
use MAX_RATES instead of (*rates_size)?). Hmm?
-- Cyrill
^ permalink raw reply
* Re: [PATCH] b43: LP-PHY: Implement STX synchronization
From: Michael Buesch @ 2009-08-09 18:17 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Larry Finger, Johannes Berg, linux-wireless,
Broadcom Wireless
In-Reply-To: <4A7F122D.3010803@gmail.com>
On Sunday 09 August 2009 20:15:09 Gábor Stefanik wrote:
> The v2+ radio init (B2063) is now complete, modulo BCM4325 support.
>
> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
ack
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] b43: LP-PHY: Implement STX synchronization
From: Gábor Stefanik @ 2009-08-09 18:15 UTC (permalink / raw)
To: John Linville, Michael Buesch
Cc: Larry Finger, Johannes Berg, linux-wireless, Broadcom Wireless
The v2+ radio init (B2063) is now complete, modulo BCM4325 support.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
drivers/net/wireless/b43/phy_lp.c | 57 +++++++++++++++++++++++++++++++++++-
1 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
index 5d50943..27eadee 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -346,9 +346,60 @@ static void lpphy_2063_init(struct b43_wldev *dev)
b43_radio_write(dev, B2063_PA_SP2, 0x18);
}
+struct lpphy_stx_table_entry {
+ u16 phy_offset;
+ u16 phy_shift;
+ u16 rf_addr;
+ u16 rf_shift;
+ u16 mask;
+};
+
+static const struct lpphy_stx_table_entry lpphy_stx_table[] = {
+ { .phy_offset = 2, .phy_shift = 6, .rf_addr = 0x3d, .rf_shift = 3, .mask = 0x01, },
+ { .phy_offset = 1, .phy_shift = 12, .rf_addr = 0x4c, .rf_shift = 1, .mask = 0x01, },
+ { .phy_offset = 1, .phy_shift = 8, .rf_addr = 0x50, .rf_shift = 0, .mask = 0x7f, },
+ { .phy_offset = 0, .phy_shift = 8, .rf_addr = 0x44, .rf_shift = 0, .mask = 0xff, },
+ { .phy_offset = 1, .phy_shift = 0, .rf_addr = 0x4a, .rf_shift = 0, .mask = 0xff, },
+ { .phy_offset = 0, .phy_shift = 4, .rf_addr = 0x4d, .rf_shift = 0, .mask = 0xff, },
+ { .phy_offset = 1, .phy_shift = 4, .rf_addr = 0x4e, .rf_shift = 0, .mask = 0xff, },
+ { .phy_offset = 0, .phy_shift = 12, .rf_addr = 0x4f, .rf_shift = 0, .mask = 0x0f, },
+ { .phy_offset = 1, .phy_shift = 0, .rf_addr = 0x4f, .rf_shift = 4, .mask = 0x0f, },
+ { .phy_offset = 3, .phy_shift = 0, .rf_addr = 0x49, .rf_shift = 0, .mask = 0x0f, },
+ { .phy_offset = 4, .phy_shift = 3, .rf_addr = 0x46, .rf_shift = 4, .mask = 0x07, },
+ { .phy_offset = 3, .phy_shift = 15, .rf_addr = 0x46, .rf_shift = 0, .mask = 0x01, },
+ { .phy_offset = 4, .phy_shift = 0, .rf_addr = 0x46, .rf_shift = 1, .mask = 0x07, },
+ { .phy_offset = 3, .phy_shift = 8, .rf_addr = 0x48, .rf_shift = 4, .mask = 0x07, },
+ { .phy_offset = 3, .phy_shift = 11, .rf_addr = 0x48, .rf_shift = 0, .mask = 0x0f, },
+ { .phy_offset = 3, .phy_shift = 4, .rf_addr = 0x49, .rf_shift = 4, .mask = 0x0f, },
+ { .phy_offset = 2, .phy_shift = 15, .rf_addr = 0x45, .rf_shift = 0, .mask = 0x01, },
+ { .phy_offset = 5, .phy_shift = 13, .rf_addr = 0x52, .rf_shift = 4, .mask = 0x07, },
+ { .phy_offset = 6, .phy_shift = 0, .rf_addr = 0x52, .rf_shift = 7, .mask = 0x01, },
+ { .phy_offset = 5, .phy_shift = 3, .rf_addr = 0x41, .rf_shift = 5, .mask = 0x07, },
+ { .phy_offset = 5, .phy_shift = 6, .rf_addr = 0x41, .rf_shift = 0, .mask = 0x0f, },
+ { .phy_offset = 5, .phy_shift = 10, .rf_addr = 0x42, .rf_shift = 5, .mask = 0x07, },
+ { .phy_offset = 4, .phy_shift = 15, .rf_addr = 0x42, .rf_shift = 0, .mask = 0x01, },
+ { .phy_offset = 5, .phy_shift = 0, .rf_addr = 0x42, .rf_shift = 1, .mask = 0x07, },
+ { .phy_offset = 4, .phy_shift = 11, .rf_addr = 0x43, .rf_shift = 4, .mask = 0x0f, },
+ { .phy_offset = 4, .phy_shift = 7, .rf_addr = 0x43, .rf_shift = 0, .mask = 0x0f, },
+ { .phy_offset = 4, .phy_shift = 6, .rf_addr = 0x45, .rf_shift = 1, .mask = 0x01, },
+ { .phy_offset = 2, .phy_shift = 7, .rf_addr = 0x40, .rf_shift = 4, .mask = 0x0f, },
+ { .phy_offset = 2, .phy_shift = 11, .rf_addr = 0x40, .rf_shift = 0, .mask = 0x0f, },
+};
+
static void lpphy_sync_stx(struct b43_wldev *dev)
{
- //TODO
+ const struct lpphy_stx_table_entry *e;
+ unsigned int i;
+ u16 tmp;
+
+ for (i = 0; i < ARRAY_SIZE(lpphy_stx_table); i++) {
+ e = &lpphy_stx_table[i];
+ tmp = b43_radio_read(dev, e->rf_addr);
+ tmp >>= e->rf_shift;
+ tmp <<= e->phy_shift;
+ b43_phy_maskset(dev, B43_PHY_OFDM(0xF2 + e->phy_offset),
+ e->mask << e->phy_shift, tmp);
+ }
}
static void lpphy_radio_init(struct b43_wldev *dev)
@@ -366,7 +417,9 @@ static void lpphy_radio_init(struct b43_wldev *dev)
lpphy_sync_stx(dev);
b43_phy_write(dev, B43_PHY_OFDM(0xF0), 0x5F80);
b43_phy_write(dev, B43_PHY_OFDM(0xF1), 0);
- //TODO Do something on the backplane
+ if (dev->dev->bus->chip_id == 0x4325) {
+ // TODO SSB PMU recalibration
+ }
}
}
--
1.6.2.4
^ permalink raw reply related
* wext channel configuration broken
From: Michael Buesch @ 2009-08-09 17:26 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, Johannes Berg
Hi,
Doing an "iwconfig wlanX channel 1" on current wireless-testing _without_
doing an "iwconfig wlanX mode XXX" previously freezes the current process.
No debug messages (but I don't have manu debugging options enabled, like lock debugging).
Doing an "iwconfig wlanX mode XXX" before changing the channel fixes the issue.
This happens both on an up and down device.
--
Greetings, Michael.
^ permalink raw reply
* Re: 2.6.31-rc5 regression: ath5k broken after suspend-to-ram
From: Johannes Stezenbach @ 2009-08-09 17:04 UTC (permalink / raw)
To: Bob Copeland; +Cc: ath5k-devel, linux-wireless, linux-kernel, Rafael J. Wysocki
In-Reply-To: <b6c5339f0908090906p3d29fdd2x8473dcc6df178167@mail.gmail.com>
On Sun, Aug 09, 2009 at 12:06:03PM -0400, Bob Copeland wrote:
> On Fri, Aug 7, 2009 at 5:51 PM, Johannes Stezenbach<js@sig21.net> wrote:
>
> > If I use nl80211 the second ifup fails with
> > "SIOCSIFFLAGS: Input/output error" messages and the follwing
> > is in dmesg:
> >
> > ath5k phy0: failed to wakeup the MAC Chip
> > ath5k phy0: can't reset hardware (-5)
>
> Ok, does this patch help the above?
>
> http://patchwork.kernel.org/patch/38550/
Yes, it helps a lot! The above wakeup error is gone,
and as a result I can switch to use the wpa_supplicant
nl80211 driver. With the nl80211 driver everything works.
However, with the wpa_supplicant wext driver the issue remains
that only the frst ifup after module load works, the second
ifup shows the association problem most of the time (but not always).
So this turns out to be a mix of two problems, with the wext one
not having anything to do with suspend/resume.
If you want me to test something wext related, let me know.
Otherwise I'm fine with using nl80211.
Thanks,
Johannes
^ permalink raw reply
* Re: 2.6.31-rc5 regression: ath5k broken after suspend-to-ram
From: Bob Copeland @ 2009-08-09 16:06 UTC (permalink / raw)
To: Johannes Stezenbach
Cc: ath5k-devel, linux-wireless, linux-kernel, Rafael J. Wysocki
In-Reply-To: <20090807215155.GA17043@sig21.net>
On Fri, Aug 7, 2009 at 5:51 PM, Johannes Stezenbach<js@sig21.net> wrote:
> Hi,
Hi!
> If I use nl80211 the second ifup fails with
> "SIOCSIFFLAGS: Input/output error" messages and the follwing
> is in dmesg:
>
> ath5k phy0: failed to wakeup the MAC Chip
> ath5k phy0: can't reset hardware (-5)
Ok, does this patch help the above?
http://patchwork.kernel.org/patch/38550/
> Aug 7 20:13:28 void wpa_supplicant[9932]: Trying to associate with 00:00:00:00:00:00 (SSID='...' freq=2412 MHz)
I assume in all cases you have elided the mac addresses and they
are the same in all of the examples? (You can keep the first three
octets in the future, they are just vendor information.)
> Aug 7 23:10:08 void kernel: wlan0: RX AssocResp from 00:00:00:00:00:00 (capab=0x411 status=0 aid=1)
> Aug 7 23:10:08 void kernel: wlan0: associated
> Aug 7 23:10:08 void wpa_supplicant[16215]: Associated with 00:00:00:00:00:00
> Aug 7 23:10:08 void wpa_supplicant[16215]: WPA: Key negotiation completed with 00:00:00:00:00:00 [PTK=CCMP GTK=TKIP]
> Aug 7 23:10:08 void wpa_supplicant[16215]: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (auth) [id=0 id_str=]
> Aug 7 23:10:12 void wpa_supplicant[16215]: CTRL-EVENT-SCAN-RESULTS
> Aug 7 23:10:12 void wpa_supplicant[16215]: Trying to associate with 00:00:00:00:00:00 (SSID='...' freq=2412 MHz)
Hmm so it completed association... then 4 seconds later, got some
scan results and tried again. Odd.
> During resume the following is logged:
>
> ath5k 0000:02:02.0: restoring config space at offset 0x3 (was 0x5008, writing 0xa808)
> pm_op(): pci_pm_resume+0x0/0x79 returns -16
> PM: Device 0000:00:00.0 failed to resume: error -16
>
> Not sure if this is causing the problem?
-EBUSY... not sure.
> In case it matters:
> CONFIG_MAC80211_DEFAULT_PS=y
> CONFIG_MAC80211_DEFAULT_PS_VALUE=1
That's for 802.11 power saving which ath5k doesn't do yet, so it
doesn't matter here.
Ok thanks for the very detailed report, I'll take a look. My
hardware suspends/resumes under 2.6.31, but I do have a few
differences in my setup compared to yours.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH] crap/rtl8187se: Fix comment-out-typo
From: Michael Buesch @ 2009-08-09 16:02 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
This fixes a comment-out-typo that resulted in a dangling if-branch.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Completely untested, but looks sane.
drivers/staging/rtl8187se/r8180_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-testing.orig/drivers/staging/rtl8187se/r8180_core.c
+++ wireless-testing/drivers/staging/rtl8187se/r8180_core.c
@@ -3394,21 +3394,21 @@ short rtl8180_tx(struct net_device *dev,
if(remain == 4 && i+4 >= buflen) break;
/* ensure the last desc has at least 4 bytes payload */
}
txbuf = txbuf + i;
*(tail+3)=*(tail+3) &~ 0xfff;
*(tail+3)=*(tail+3) | i; // buffer lenght
// Use short preamble or not
if (priv->ieee80211->current_network.capability&WLAN_CAPABILITY_SHORT_PREAMBLE)
if (priv->plcp_preamble_mode==1 && rate!=0) // short mode now, not long!
- // *tail |= (1<<16); // enable short preamble mode.
+ ;// *tail |= (1<<16); // enable short preamble mode.
#ifdef CONFIG_RTL8185B
if(bCTSEnable) {
*tail |= (1<<18);
}
if(bRTSEnable) //rts enable
{
*tail |= ((ieeerate2rtlrate(priv->ieee80211->basic_rate))<<19);//RTS RATE
*tail |= (1<<23);//rts enable
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] rtl818x: Add some documentation to the TX desc flags
From: Michael Buesch @ 2009-08-09 15:57 UTC (permalink / raw)
To: linville
Cc: Herton Ronaldo Krzesinski, Hin-Tak Leung, Larry Finger,
linux-wireless
Add some TX desc flags docs.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
It's incomplete. Just the ones I could easily figure out by myself...
drivers/net/wireless/rtl818x/rtl818x.h | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl818x.h
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl818x.h
@@ -187,22 +187,32 @@ struct rtl818x_csr {
} __attribute__((packed));
struct rtl818x_rf_ops {
char *name;
void (*init)(struct ieee80211_hw *);
void (*stop)(struct ieee80211_hw *);
void (*set_chan)(struct ieee80211_hw *, struct ieee80211_conf *);
void (*conf_erp)(struct ieee80211_hw *, struct ieee80211_bss_conf *);
};
-/* Tx/Rx flags are common between RTL818X chips */
-
+/**
+ * enum rtl818x_tx_desc_flags - Tx/Rx flags are common between RTL818X chips
+ *
+ * @RTL818X_TX_DESC_FLAG_NO_ENC: Disable hardware based encryption.
+ * @RTL818X_TX_DESC_FLAG_TX_OK: TX frame was ACKed.
+ * @RTL818X_TX_DESC_FLAG_SPLCP: Use short preamble.
+ * @RTL818X_TX_DESC_FLAG_MOREFRAG: More fragments follow.
+ * @RTL818X_TX_DESC_FLAG_CTS: Use CTS-to-self protection.
+ * @RTL818X_TX_DESC_FLAG_RTS: Use RTS/CTS protection.
+ * @RTL818X_TX_DESC_FLAG_LS: Last segment of the frame.
+ * @RTL818X_TX_DESC_FLAG_FS: First segment of the frame.
+ */
enum rtl818x_tx_desc_flags {
RTL818X_TX_DESC_FLAG_NO_ENC = (1 << 15),
RTL818X_TX_DESC_FLAG_TX_OK = (1 << 15),
RTL818X_TX_DESC_FLAG_SPLCP = (1 << 16),
RTL818X_TX_DESC_FLAG_RX_UNDER = (1 << 16),
RTL818X_TX_DESC_FLAG_MOREFRAG = (1 << 17),
RTL818X_TX_DESC_FLAG_CTS = (1 << 18),
RTL818X_TX_DESC_FLAG_RTS = (1 << 23),
RTL818X_TX_DESC_FLAG_LS = (1 << 28),
RTL818X_TX_DESC_FLAG_FS = (1 << 29),
--
Greetings, Michael.
^ permalink raw reply
* Re: Deauthentications with p54usb
From: Larry Finger @ 2009-08-09 15:12 UTC (permalink / raw)
To: Christian Lamparter; +Cc: wireless
In-Reply-To: <200908072350.26193.chunkeey@web.de>
Christian Lamparter wrote:
>
> reason 7 must be:
> WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA
>
> and class 3 frames are (according to 802.11-2007 11.3.c)
> - "normal" data frames
> (- some MLMEs - probably not relevant )
> - control frame:
> => especially: Power Save Poll.
>
> your log doesn't hold any records about a disassoc event from the AP.
> so, my first guess would be that you're hitting yet another
> power saving related issue. And as far as I know b43 does not do that yet.
> So, can you please give the device another go without ps?
>
> (BTW: mac80211 prints a debug text (if enabled in kconfig),
> whenever the device goes or leaves the hibernation mode...
> do you see any of those too?)
Once I got that debug mode set with PS enabled, I still got the deauth
events, but no messages from mac80211. I may not have had the debug
value set correctly. Turning off CONFIG_CFG80211_DEFAULT_PS stopped
the messages, thus it certainly looks like a power saving event.
Larry
^ permalink raw reply
* [PATCH 2.6.31] ar9170: fix read & write outside array bounds
From: Christian Lamparter @ 2009-08-09 12:24 UTC (permalink / raw)
To: wireless, Dan Carpenter; +Cc: John W. Linville
From: Dan Carpenter <error27@gmail.com>
queue == __AR9170_NUM_TXQ would cause a bug on the next line.
found by Smatch ( http://repo.or.cz/w/smatch.git ).
Cc: stable@kernel.org
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
index 4fc389a..ea8c941 100644
--- a/drivers/net/wireless/ath/ar9170/main.c
+++ b/drivers/net/wireless/ath/ar9170/main.c
@@ -2458,13 +2458,14 @@ static int ar9170_conf_tx(struct ieee80211_hw *hw, u16 queue,
int ret;
mutex_lock(&ar->mutex);
- if ((param) && !(queue > __AR9170_NUM_TXQ)) {
+ if (queue < __AR9170_NUM_TXQ) {
memcpy(&ar->edcf[ar9170_qos_hwmap[queue]],
param, sizeof(*param));
ret = ar9170_set_qos(ar);
- } else
+ } else {
ret = -EINVAL;
+ }
mutex_unlock(&ar->mutex);
return ret;
^ permalink raw reply related
* Re: Libertas: Association request to the driver failed
From: Michael Buesch @ 2009-08-09 11:10 UTC (permalink / raw)
To: Roel Kluin
Cc: Daniel Mack, John W. Linville, libertas-dev, linux-wireless,
linux-kernel
In-Reply-To: <4A7EAED8.9090900@gmail.com>
On Sunday 09 August 2009 13:11:20 Roel Kluin wrote:
> @@ -43,21 +44,21 @@ static int get_common_rates(struct lbs_private *priv,
> u16 *rates_size)
> {
> u8 *card_rates = lbs_bg_rates;
> - size_t num_card_rates = sizeof(lbs_bg_rates);
> int ret = 0, i, j;
> - u8 tmp[30];
> + u8 tmp[*rates_size * ARRAY_SIZE(lbs_bg_rates)];
Is it a good idea to use dynamic stack arrays in the kernel?
What about kmalloc for dynamic allocations?
--
Greetings, Michael.
^ permalink raw reply
* Re: Libertas: Association request to the driver failed
From: Roel Kluin @ 2009-08-09 11:11 UTC (permalink / raw)
To: Daniel Mack; +Cc: John W. Linville, libertas-dev, linux-wireless, linux-kernel
In-Reply-To: <20090809102417.GH13639@buzzloop.caiaq.de>
Several arrays were read before checking whether the index was within
bounds. ARRAY_SIZE() should be used to determine the size of arrays.
rates->rates has an arraysize of 1, so calling get_common_rates()
with a rates_size of MAX_RATES (14) was causing reads out of bounds.
tmp_size can increment at most to *rates_size * ARRAY_SIZE(lbs_bg_rates),
so that should be the number of elements of tmp[].
A goto can be eliminated: ret was already set upon its declaration.
---
>>>> The change came in after -rc5,
>>>> and I found 57921c31 ("libertas: Read buffer overflow") to be the
>>>> culprit. Reverting it brings my libertas device back to life. I copied
>>>> the author.
>>>>
>>>> Thanks,
>>>> Daniel
>>> Ah, I think I made an error, I think tmp is too small and should be
>>>
>>> u8 tmp[*rates_size * ARRAY_SIZE(lbs_bg_rates) - 1];
>> After some sleep I realized it should be:
>>
>> u8 tmp[*rates_size * ARRAY_SIZE(lbs_bg_rates)];
>
> I'll test that tomorrow. Would be easier if you send in a new patch I
> can ack directly in case it works :)
This is the patch that should be applied after the revert, or do you want a
delta patch?
And does this give your libertas back?
Thanks for testing,
Roel
diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index b9b3741..e9efc4c 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -1,6 +1,7 @@
/* Copyright (C) 2006, Red Hat, Inc. */
#include <linux/types.h>
+#include <linux/kernel.h>
#include <linux/etherdevice.h>
#include <linux/ieee80211.h>
#include <linux/if_arp.h>
@@ -43,21 +44,21 @@ static int get_common_rates(struct lbs_private *priv,
u16 *rates_size)
{
u8 *card_rates = lbs_bg_rates;
- size_t num_card_rates = sizeof(lbs_bg_rates);
int ret = 0, i, j;
- u8 tmp[30];
+ u8 tmp[*rates_size * ARRAY_SIZE(lbs_bg_rates)];
size_t tmp_size = 0;
/* For each rate in card_rates that exists in rate1, copy to tmp */
- for (i = 0; card_rates[i] && (i < num_card_rates); i++) {
- for (j = 0; rates[j] && (j < *rates_size); j++) {
+ for (i = 0; i < ARRAY_SIZE(lbs_bg_rates) && card_rates[i]; i++) {
+ for (j = 0; j < *rates_size && rates[j]; j++) {
if (rates[j] == card_rates[i])
tmp[tmp_size++] = card_rates[i];
}
}
lbs_deb_hex(LBS_DEB_JOIN, "AP rates ", rates, *rates_size);
- lbs_deb_hex(LBS_DEB_JOIN, "card rates ", card_rates, num_card_rates);
+ lbs_deb_hex(LBS_DEB_JOIN, "card rates ", card_rates,
+ ARRAY_SIZE(lbs_bg_rates));
lbs_deb_hex(LBS_DEB_JOIN, "common rates", tmp, tmp_size);
lbs_deb_join("TX data rate 0x%02x\n", priv->cur_rate);
@@ -69,10 +70,7 @@ static int get_common_rates(struct lbs_private *priv,
lbs_pr_alert("Previously set fixed data rate %#x isn't "
"compatible with the network.\n", priv->cur_rate);
ret = -1;
- goto done;
}
- ret = 0;
-
done:
memset(rates, 0, *rates_size);
*rates_size = min_t(int, tmp_size, *rates_size);
@@ -322,7 +320,7 @@ static int lbs_associate(struct lbs_private *priv,
rates = (struct mrvl_ie_rates_param_set *) pos;
rates->header.type = cpu_to_le16(TLV_TYPE_RATES);
memcpy(&rates->rates, &bss->rates, MAX_RATES);
- tmplen = MAX_RATES;
+ tmplen = min_t(u16, ARRAY_SIZE(rates->rates), MAX_RATES);
if (get_common_rates(priv, rates->rates, &tmplen)) {
ret = -1;
goto done;
@@ -598,7 +596,7 @@ static int lbs_adhoc_join(struct lbs_private *priv,
/* Copy Data rates from the rates recorded in scan response */
memset(cmd.bss.rates, 0, sizeof(cmd.bss.rates));
- ratesize = min_t(u16, sizeof(cmd.bss.rates), MAX_RATES);
+ ratesize = min_t(u16, ARRAY_SIZE(cmd.bss.rates), MAX_RATES);
memcpy(cmd.bss.rates, bss->rates, ratesize);
if (get_common_rates(priv, cmd.bss.rates, &ratesize)) {
lbs_deb_join("ADHOC_JOIN: get_common_rates returned error.\n");
^ permalink raw reply related
* Re: Libertas: Association request to the driver failed
From: Daniel Mack @ 2009-08-09 10:24 UTC (permalink / raw)
To: Roel Kluin; +Cc: John W. Linville, libertas-dev, linux-wireless, linux-kernel
In-Reply-To: <4A7E9596.4070901@gmail.com>
On Sun, Aug 09, 2009 at 11:23:34AM +0200, Roel Kluin wrote:
> >> The change came in after -rc5,
> >> and I found 57921c31 ("libertas: Read buffer overflow") to be the
> >> culprit. Reverting it brings my libertas device back to life. I copied
> >> the author.
> >>
> >> Thanks,
> >> Daniel
> >
> > Ah, I think I made an error, I think tmp is too small and should be
> >
> > u8 tmp[*rates_size * ARRAY_SIZE(lbs_bg_rates) - 1];
>
> After some sleep I realized it should be:
>
> u8 tmp[*rates_size * ARRAY_SIZE(lbs_bg_rates)];
I'll test that tomorrow. Would be easier if you send in a new patch I
can ack directly in case it works :)
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] cfg80211: add missing device list locking
From: Kalle Valo @ 2009-08-09 10:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1249811489.4636.2.camel@johannes.local>
Johannes Berg <johannes@sipsolutions.net> writes:
> When calling into the wext code from the NETDEV_UP
> notifier, we need to hold the devlist_mtx mutex as
> the wext code ends up calling into channel checks.
>
> Reported-by: Kalle Valo <kalle.valo@iki.fi>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Thanks for fixing this. I wasn't able to reproduce the warning after one
suspend/resume cycle, but I'll test this patch a bit more before I send
my Tested-by tag.
--
Kalle Valo
^ permalink raw reply
* [PATCH] cfg80211: add missing device list locking
From: Johannes Berg @ 2009-08-09 9:51 UTC (permalink / raw)
To: John Linville; +Cc: Kalle Valo, linux-wireless
When calling into the wext code from the NETDEV_UP
notifier, we need to hold the devlist_mtx mutex as
the wext code ends up calling into channel checks.
Reported-by: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/core.c | 2 ++
1 file changed, 2 insertions(+)
--- wireless-testing.orig/net/wireless/core.c 2009-08-09 11:48:16.000000000 +0200
+++ wireless-testing/net/wireless/core.c 2009-08-09 11:48:32.000000000 +0200
@@ -710,6 +710,7 @@ static int cfg80211_netdev_notifier_call
case NETDEV_UP:
#ifdef CONFIG_WIRELESS_EXT
cfg80211_lock_rdev(rdev);
+ mutex_lock(&rdev->devlist_mtx);
wdev_lock(wdev);
switch (wdev->iftype) {
case NL80211_IFTYPE_ADHOC:
@@ -722,6 +723,7 @@ static int cfg80211_netdev_notifier_call
break;
}
wdev_unlock(wdev);
+ mutex_unlock(&rdev->devlist_mtx);
cfg80211_unlock_rdev(rdev);
#endif
break;
^ permalink raw reply
* Re: 2.6.31-rc5 regression: ath5k broken after suspend-to-ram
From: Johannes Stezenbach @ 2009-08-09 9:34 UTC (permalink / raw)
To: ath5k-devel, linux-wireless; +Cc: linux-kernel, Rafael J. Wysocki
In-Reply-To: <20090807215155.GA17043@sig21.net>
On Fri, Aug 07, 2009 at 11:51:55PM +0200, Johannes Stezenbach wrote:
>
> On my old Thinkpad T42p running linux-2.6.31-rc5-246-g90bc1a6,
> after suspend-to-RAM ath5k cannot associate to an AP using WPA
> anymore. It worked with kernel 2.6.29.1.
FWFI, it also works with 2.6.30. (I could not initialliy test
with 2.6.30 because suspend/resume is broken in that kernel,
but it can be fixed up with a workaround patch.)
Johannes
^ permalink raw reply
* Re: Libertas: Association request to the driver failed
From: Roel Kluin @ 2009-08-09 9:23 UTC (permalink / raw)
To: Roel Kluin
Cc: Daniel Mack, John W. Linville, libertas-dev, linux-wireless,
linux-kernel
In-Reply-To: <4A7D8AB6.9030707@gmail.com>
>> The change came in after -rc5,
>> and I found 57921c31 ("libertas: Read buffer overflow") to be the
>> culprit. Reverting it brings my libertas device back to life. I copied
>> the author.
>>
>> Thanks,
>> Daniel
>
> Ah, I think I made an error, I think tmp is too small and should be
>
> u8 tmp[*rates_size * ARRAY_SIZE(lbs_bg_rates) - 1];
After some sleep I realized it should be:
u8 tmp[*rates_size * ARRAY_SIZE(lbs_bg_rates)];
> Sorry and thanks for testing,
>
> Roel
^ permalink raw reply
* Re: Mesh fixes and improvements
From: Javier Cardona @ 2009-08-09 4:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, andrey, linville, devel
In-Reply-To: <1249722543.31670.19.camel@johannes.local>
Johannes,
Thanks for the review.
On Sat, Aug 8, 2009 at 2:09 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
>> This series includes some fixes, testing aids and improvements to the mesh
>> stack. It is important to note that the patch
>> "Use-3-address-format-for-mesh-broadcast-frames" breaks compatibility with
>> previous versions. This is unavoidable and will keep happening as new versions
>> of the 802.11s drafts are produced.
>
> That's ok, can you update the Kconfig though to indicate which draft
> it's compatible with? It says 1.08 right now.
Unfortunately I don't think it is fully compatible to one particular
version. Furthermore, compliance with a Draft is not really
achievable: a vast number of identifiers (reason codes, element ids,
status codes, ...) are not defined until the standard is ratified.
This particular change to the broadcast frame format was introduced
between D2.03 and D2.08. Without it mesh networks will badly interact
with widely deployed lazy WDS APs. It is not purely an
interoperability issue with other mesh implementations but a
requirement to achieve harmonious coexistence with deployed systems.
I don't think we should hold this change back until closer compliance
to a given draft version is implemented.
I'll still be happy to change the Kconfig, but bumping the version
number to, say D2.08, might be misleading. I guess we should be more
verbose in the Kconfig description.
>> Also, I'm not sure if "Simulate-transmission-losses-on-plinks-to-..." should be
>> merged upstream, but we find it really useful to test mesh configurations.
>> Please comment if you have different opinions on its adequacy or
>> implementation.
>
> As I said elsewhere in this thread I don't think that should be in,
> especially not, as Kalle points out, using nl80211.
Understood. I'll withdraw that patch and regenerate the series...
> All the other patches look ok on a cursory look, I just wish you'd write
> more detailed changelog entries.
... with more changelogs.
Cheers,
Javier
^ 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