* [patch 2/9] ath9k: range checking issues in htc_hst.c
From: Sujith @ 2010-05-10 4:37 UTC (permalink / raw)
To: Dan Carpenter
Cc: Luis Rodriguez, Jouni Malinen, Vasanth Thiagarajan,
Senthilkumar Balasubramanian, John W. Linville, Ming Lei,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <20100508162201.GN27064@bicker>
Dan Carpenter wrote:
> The original code had ENDPOINT_MAX and HST_ENDPOINT_MAX switched.
Hm, no.
> Also the first loop was off by one, it started past the end of the array
> and went down to 1 instead of going down to 0. The test at the end of
> the loop to see if we exited via a break wasn't right because
> "tmp_endpoint" is always non-null here.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/drivers/net/wireless/ath/ath9k/htc_hst.c b/drivers/net/wireless/ath/ath9k/htc_hst.c
> index 7bf6ce1..0c062d0 100644
> --- a/drivers/net/wireless/ath/ath9k/htc_hst.c
> +++ b/drivers/net/wireless/ath/ath9k/htc_hst.c
> @@ -116,7 +116,7 @@ static void htc_process_conn_rsp(struct htc_target *target,
> max_msglen = be16_to_cpu(svc_rspmsg->max_msg_len);
> endpoint = &target->endpoint[epid];
>
> - for (tepid = ENDPOINT_MAX; tepid > ENDPOINT0; tepid--) {
> + for (tepid = HST_ENDPOINT_MAX - 1; tepid >= ENDPOINT0; tepid--) {
This should be (tepid = (ENDPOINT_MAX - 1); tepid > ENDPOINT0; tepid--),
and the NULL check below can be retained.
This is because ENDPOINT0 is reserved.
> tmp_endpoint = &target->endpoint[tepid];
> if (tmp_endpoint->service_id == service_id) {
> tmp_endpoint->service_id = 0;
> @@ -124,7 +124,7 @@ static void htc_process_conn_rsp(struct htc_target *target,
> }
> }
>
> - if (!tmp_endpoint)
> + if (tepid < ENDPOINT0)
> return;
>
> endpoint->service_id = service_id;
> @@ -297,7 +297,7 @@ void htc_stop(struct htc_target *target)
> enum htc_endpoint_id epid;
> struct htc_endpoint *endpoint;
>
> - for (epid = ENDPOINT0; epid <= ENDPOINT_MAX; epid++) {
> + for (epid = ENDPOINT0; epid < HST_ENDPOINT_MAX; epid++) {
ENDPOINT_MAX should be used here, but '<=' should be replaced by '<'.
> endpoint = &target->endpoint[epid];
> if (endpoint->service_id != 0)
> target->hif->stop(target->hif_dev, endpoint->ul_pipeid);
> @@ -309,7 +309,7 @@ void htc_start(struct htc_target *target)
> enum htc_endpoint_id epid;
> struct htc_endpoint *endpoint;
>
> - for (epid = ENDPOINT0; epid <= ENDPOINT_MAX; epid++) {
> + for (epid = ENDPOINT0; epid < HST_ENDPOINT_MAX; epid++) {
> endpoint = &target->endpoint[epid];
Same as above.
> if (endpoint->service_id != 0)
> target->hif->start(target->hif_dev,
> @@ -377,7 +377,7 @@ void ath9k_htc_rx_msg(struct htc_target *htc_handle,
> htc_hdr = (struct htc_frame_hdr *) skb->data;
> epid = htc_hdr->endpoint_id;
>
> - if (epid >= ENDPOINT_MAX) {
> + if (epid >= HST_ENDPOINT_MAX) {
> if (pipe_id != USB_REG_IN_PIPE)
> dev_kfree_skb_any(skb);
> else
The original check was correct ...
Sujith
^ permalink raw reply
* [PATCH] ssb: Handle alternate SSPROM location
From: Larry Finger @ 2010-05-10 3:01 UTC (permalink / raw)
To: John W Linville, Michael Buesch; +Cc: b43-dev, linux-wireless
In kernel Bugzilla #15825 (2 users), in a wireless mailing list thread
(http://lists.infradead.org/pipermail/b43-dev/2010-May/000124.html), and on a
netbook owned by John Linville
(http://marc.info/?l=linux-wireless&m=127230751408818&w=4), there are reports
of ssb failing to detect an SPROM at the normal location. After studying the
MMIO trace dump for the Broadcom wl driver, it was determined that the affected
boxes had a relocated SPROM.
This patch fixes all systems that have reported this problem.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@kernel.org>
---
John,
This patch and the one by Gabor entitled "[PATCH] ssb: Implement
fast powerup delay calculation" are needed to fix these systems. As there is the
possibility that this patch will break some 14e4:4315 devices, it should stew in
testing for a while. I am confident enough in it to add the Cc for stable.
Larry
---
Index: wireless-testing/drivers/ssb/pci.c
===================================================================
--- wireless-testing.orig/drivers/ssb/pci.c
+++ wireless-testing/drivers/ssb/pci.c
@@ -631,8 +631,17 @@ static int ssb_pci_sprom_get(struct ssb_
return -ENODEV;
}
- bus->sprom_offset = (bus->chipco.dev->id.revision < 31) ?
- SSB_SPROM_BASE1 : SSB_SPROM_BASE31;
+ /* get SPROM offset: SSB_SPROM_BASE1 except for chipcommon rev >= 31
+ * or chip ID is 0x4312 and chipcommon status & 3 == 2
+ */
+ if (bus->chipco.dev->id.revision >= 31)
+ bus->sprom_offset = SSB_SPROM_BASE31;
+ else if (bus->chip_id == 0x4312 && (bus->chipco.status & 0x03) == 2)
+ bus->sprom_offset = SSB_SPROM_BASE31;
+ else
+ bus->sprom_offset = SSB_SPROM_BASE1;
+
+ ssb_dprintk(KERN_INFO PFX "SPROM offset is 0x%x\n", bus->sprom_offset);
buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
if (!buf)
Index: wireless-testing/drivers/ssb/driver_chipcommon.c
===================================================================
--- wireless-testing.orig/drivers/ssb/driver_chipcommon.c
+++ wireless-testing/drivers/ssb/driver_chipcommon.c
@@ -252,15 +252,17 @@ void ssb_chipcommon_init(struct ssb_chip
{
u16 delay;
+ cc->status = 0;
if (!cc->dev)
return; /* We don't have a ChipCommon */
if (cc->dev->id.revision >= 11)
cc->status = chipco_read32(cc, SSB_CHIPCO_CHIPSTAT);
+ ssb_dprintk(KERN_INFO PFX "chipcommon status is 0x%x\n", cc->status);
ssb_pmu_init(cc);
chipco_powercontrol_init(cc);
ssb_chipco_set_clockmode(cc, SSB_CLKMODE_FAST);
delay = calc_fast_powerup_delay(cc);
- ssb_printk(KERN_INFO PFX "fast_pwrup_delay is %d\n", delay);
+ ssb_dprintk(KERN_INFO PFX "fast_pwrup_delay is %d\n", delay);
cc->fast_pwrup_delay = delay;
ssb_write16(cc->dev, SSB_MMIO_POWERUP_DELAY, delay);
}
^ permalink raw reply
* Re: [patch 6/9] ath5k: several off by one range checks
From: Bruno Randolf @ 2010-05-10 1:18 UTC (permalink / raw)
To: Bob Copeland, Dan Carpenter
Cc: John W. Linville, Bruno Randolf, linux-wireless, ath5k-devel
In-Reply-To: <20100508223319.GA6377@hash.localnet>
On Sunday 09 May 2010 07:33:19 you wrote:
> On Sat, May 08, 2010 at 06:24:38PM +0200, Dan Carpenter wrote:
> > There are several places that use > ARRAY_SIZE() instead of
> >
> > >= ARRAY_SIZE().
> >
> > Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> Thanks,
> Acked-by: Bob Copeland <me@bobcopeland.com>
ah, yes. found these too, but haven't sent the patch yet.
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* Re: [PATCH] mac80211: remove deprecated noise field from ieee80211_rx_status
From: Bruno Randolf @ 2010-05-10 1:15 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, johannes
In-Reply-To: <1272656351-5983-1-git-send-email-linville@tuxdriver.com>
On Saturday 01 May 2010 04:39:11 John W. Linville wrote:
> Also remove associated IEEE80211_HW_NOISE_DBM from ieee80211_hw_flags.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/ath/ar9170/main.c | 3 +--
> drivers/net/wireless/ath/ath5k/base.c | 3 +--
> drivers/net/wireless/b43/main.c | 3 +--
> drivers/net/wireless/b43legacy/main.c | 3 +--
> drivers/net/wireless/iwlwifi/iwl-agn.c | 1 -
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 1 -
> drivers/net/wireless/mwl8k.c | 4 ++--
> drivers/net/wireless/p54/main.c | 3 +--
> drivers/net/wireless/wl12xx/wl1251_main.c | 1 -
> drivers/net/wireless/wl12xx/wl1271_main.c | 1 -
> include/net/mac80211.h | 8 +-------
> net/mac80211/rx.c | 2 --
> 12 files changed, 8 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ar9170/main.c
> b/drivers/net/wireless/ath/ar9170/main.c index cfc6a35..dfcc055 100644
> --- a/drivers/net/wireless/ath/ar9170/main.c
> +++ b/drivers/net/wireless/ath/ar9170/main.c
> @@ -2550,8 +2550,7 @@ void *ar9170_alloc(size_t priv_size)
> BIT(NL80211_IFTYPE_ADHOC);
> ar->hw->flags |= IEEE80211_HW_RX_INCLUDES_FCS |
> IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
> - IEEE80211_HW_SIGNAL_DBM |
> - IEEE80211_HW_NOISE_DBM;
> + IEEE80211_HW_SIGNAL_DBM;
>
> if (modparam_ht) {
> ar->hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> diff --git a/drivers/net/wireless/ath/ath5k/base.c
> b/drivers/net/wireless/ath/ath5k/base.c index 1f3e5b0..feb7b9e 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -547,8 +547,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
> SET_IEEE80211_DEV(hw, &pdev->dev);
> hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
> IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
> - IEEE80211_HW_SIGNAL_DBM |
> - IEEE80211_HW_NOISE_DBM;
> + IEEE80211_HW_SIGNAL_DBM;
>
> hw->wiphy->interface_modes =
> BIT(NL80211_IFTYPE_AP) |
> diff --git a/drivers/net/wireless/b43/main.c
> b/drivers/net/wireless/b43/main.c index 14cf3bd..e057559 100644
> --- a/drivers/net/wireless/b43/main.c
> +++ b/drivers/net/wireless/b43/main.c
> @@ -4904,8 +4904,7 @@ static int b43_wireless_init(struct ssb_device *dev)
>
> /* fill hw info */
> hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
> - IEEE80211_HW_SIGNAL_DBM |
> - IEEE80211_HW_NOISE_DBM;
> + IEEE80211_HW_SIGNAL_DBM;
>
> hw->wiphy->interface_modes =
> BIT(NL80211_IFTYPE_AP) |
> diff --git a/drivers/net/wireless/b43legacy/main.c
> b/drivers/net/wireless/b43legacy/main.c index 1d070be..b2df432 100644
> --- a/drivers/net/wireless/b43legacy/main.c
> +++ b/drivers/net/wireless/b43legacy/main.c
> @@ -3768,8 +3768,7 @@ static int b43legacy_wireless_init(struct ssb_device
> *dev)
>
> /* fill hw info */
> hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
> - IEEE80211_HW_SIGNAL_DBM |
> - IEEE80211_HW_NOISE_DBM;
> + IEEE80211_HW_SIGNAL_DBM;
> hw->wiphy->interface_modes =
> BIT(NL80211_IFTYPE_AP) |
> BIT(NL80211_IFTYPE_STATION) |
> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c
> b/drivers/net/wireless/iwlwifi/iwl-agn.c index c22d3d8..0cd3386 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-agn.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
> @@ -2653,7 +2653,6 @@ static int iwl_mac_setup_register(struct iwl_priv
> *priv)
>
> /* Tell mac80211 our characteristics */
> hw->flags = IEEE80211_HW_SIGNAL_DBM |
> - IEEE80211_HW_NOISE_DBM |
> IEEE80211_HW_AMPDU_AGGREGATION |
> IEEE80211_HW_SPECTRUM_MGMT;
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> b/drivers/net/wireless/iwlwifi/iwl3945-base.c index e7263ed..c9da39d
> 100644
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -3872,7 +3872,6 @@ static int iwl3945_setup_mac(struct iwl_priv *priv)
>
> /* Tell mac80211 our characteristics */
> hw->flags = IEEE80211_HW_SIGNAL_DBM |
> - IEEE80211_HW_NOISE_DBM |
> IEEE80211_HW_SPECTRUM_MGMT;
>
> if (!priv->cfg->broken_powersave)
> diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
> index 9af6c94..a90bb6d 100644
> --- a/drivers/net/wireless/mwl8k.c
> +++ b/drivers/net/wireless/mwl8k.c
> @@ -3981,8 +3981,8 @@ static int __devinit mwl8k_probe(struct pci_dev
> *pdev,
>
> hw->queues = MWL8K_TX_QUEUES;
>
> - /* Set rssi and noise values to dBm */
> - hw->flags |= IEEE80211_HW_SIGNAL_DBM | IEEE80211_HW_NOISE_DBM;
> + /* Set rssi values to dBm */
> + hw->flags |= IEEE80211_HW_SIGNAL_DBM;
> hw->vif_data_size = sizeof(struct mwl8k_vif);
> hw->sta_data_size = sizeof(struct mwl8k_sta);
>
> diff --git a/drivers/net/wireless/p54/main.c
> b/drivers/net/wireless/p54/main.c index 36f4c82..10a4b16 100644
> --- a/drivers/net/wireless/p54/main.c
> +++ b/drivers/net/wireless/p54/main.c
> @@ -545,8 +545,7 @@ struct ieee80211_hw *p54_init_common(size_t
> priv_data_len) IEEE80211_HW_SUPPORTS_PS |
> IEEE80211_HW_PS_NULLFUNC_STACK |
> IEEE80211_HW_BEACON_FILTER |
> - IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> - IEEE80211_HW_NOISE_DBM;
> + IEEE80211_HW_REPORTS_TX_ACK_STATUS;
>
> dev->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
> BIT(NL80211_IFTYPE_ADHOC) |
> diff --git a/drivers/net/wireless/wl12xx/wl1251_main.c
> b/drivers/net/wireless/wl12xx/wl1251_main.c index 4d3be80..b70621f 100644
> --- a/drivers/net/wireless/wl12xx/wl1251_main.c
> +++ b/drivers/net/wireless/wl12xx/wl1251_main.c
> @@ -1291,7 +1291,6 @@ int wl1251_init_ieee80211(struct wl1251 *wl)
> wl->hw->channel_change_time = 10000;
>
> wl->hw->flags = IEEE80211_HW_SIGNAL_DBM |
> - IEEE80211_HW_NOISE_DBM |
> IEEE80211_HW_SUPPORTS_PS |
> IEEE80211_HW_BEACON_FILTER |
> IEEE80211_HW_SUPPORTS_UAPSD;
> diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c
> b/drivers/net/wireless/wl12xx/wl1271_main.c index a794d5e..b083725 100644
> --- a/drivers/net/wireless/wl12xx/wl1271_main.c
> +++ b/drivers/net/wireless/wl12xx/wl1271_main.c
> @@ -2275,7 +2275,6 @@ int wl1271_init_ieee80211(struct wl1271 *wl)
> wl->hw->max_listen_interval = wl->conf.conn.max_listen_interval;
>
> wl->hw->flags = IEEE80211_HW_SIGNAL_DBM |
> - IEEE80211_HW_NOISE_DBM |
> IEEE80211_HW_BEACON_FILTER |
> IEEE80211_HW_SUPPORTS_PS |
> IEEE80211_HW_SUPPORTS_UAPSD |
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 2879c8e..00502b1 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -560,7 +560,6 @@ enum mac80211_rx_flags {
> * @signal: signal strength when receiving this frame, either in dBm, in
> dB or * unspecified depending on the hardware capabilities flags
> * @IEEE80211_HW_SIGNAL_*
> - * @noise: noise when receiving this frame, in dBm (DEPRECATED).
> * @antenna: antenna used
> * @rate_idx: index of data rate into band's supported rates or MCS index
> if * HT rates are use (RX_FLAG_HT)
> @@ -571,7 +570,6 @@ struct ieee80211_rx_status {
> enum ieee80211_band band;
> int freq;
> int signal;
> - int noise __deprecated;
> int antenna;
> int rate_idx;
> int flag;
> @@ -934,10 +932,6 @@ enum ieee80211_tkip_key_type {
> * one milliwatt. This is the preferred method since it is standardized
> * between different devices. @max_signal does not need to be set.
> *
> - * @IEEE80211_HW_NOISE_DBM:
> - * Hardware can provide noise (radio interference) values in units dBm,
> - * decibel difference from one milliwatt.
> - *
> * @IEEE80211_HW_SPECTRUM_MGMT:
> * Hardware supports spectrum management defined in 802.11h
> * Measurement, Channel Switch, Quieting, TPC
> @@ -1001,7 +995,7 @@ enum ieee80211_hw_flags {
> IEEE80211_HW_2GHZ_SHORT_PREAMBLE_INCAPABLE = 1<<4,
> IEEE80211_HW_SIGNAL_UNSPEC = 1<<5,
> IEEE80211_HW_SIGNAL_DBM = 1<<6,
> - IEEE80211_HW_NOISE_DBM = 1<<7,
> + /* use this hole */
> IEEE80211_HW_SPECTRUM_MGMT = 1<<8,
> IEEE80211_HW_AMPDU_AGGREGATION = 1<<9,
> IEEE80211_HW_SUPPORTS_PS = 1<<10,
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 8ee7db1..e4f325f 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -80,8 +80,6 @@ ieee80211_rx_radiotap_len(struct ieee80211_local *local,
> len += 8;
> if (local->hw.flags & IEEE80211_HW_SIGNAL_DBM)
> len += 1;
> - if (local->hw.flags & IEEE80211_HW_NOISE_DBM)
> - len += 1;
>
> if (len & 1) /* padding for RX_FLAGS if necessary */
> len++;
sorry for the late reply:
please, don't... this way we loose the information which drivers can report
noise values and which can't.
bruno
^ permalink raw reply
* 2.6.34-rc6-git6: Reported regressions from 2.6.33
From: Rafael J. Wysocki @ 2010-05-09 21:13 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
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.33,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.33, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
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
----------------------------------------
2010-05-09 80 27 24
2010-05-04 76 26 22
2010-04-20 64 35 34
2010-04-07 48 35 33
2010-03-21 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15951
Subject : commit 9630bdd9 changes behavior of the poweroff
Submitter : Michal Hocko <mhocko@suse.cz>
Date : 2010-04-01 13:39 (39 days old)
Message-ID : <20100401133923.GA4104@tiehlicka.suse.cz>
References : http://marc.info/?l=linux-kernel&m=127012918316305&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15936
Subject : Suspicious rcu_dereference_check() usage detected during 2.6.34-rc6 boot on PPC64/p5 processor
Submitter : Subrata Modak <subrata@linux.vnet.ibm.com>
Date : 2010-05-06 7:29 (4 days old)
Message-ID : <1273130279.4898.5.camel@subratamodak.linux.ibm.com>
References : http://marc.info/?l=linux-kernel&m=127313031922395&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15935
Subject : [BUG] btrfs: report a direct-IO bug
Submitter : liubo <liubo2009@cn.fujitsu.com>
Date : 2010-05-06 1:47 (4 days old)
Message-ID : <4BE21FC1.1010901@cn.fujitsu.com>
References : http://marc.info/?l=linux-kernel&m=127311036803487&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15924
Subject : kacpid consumes ~100% CPU, system freezes randomly
Submitter : Jaroslav Kameník <jaroslav@kamenik.cz>
Date : 2010-05-06 21:12 (4 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15909
Subject : open("a/",O_NOFOLLOW) fails with ELOOP if "a" is a symbolic link to a directory.
Submitter : Marius Tolzmann <tolzmann@molgen.mpg.de>
Date : 2010-05-05 13:01 (5 days old)
Handled-By : OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15880
Subject : Very bad regression from 2.6.33 as of 1600f9def
Submitter : Alex Elsayed <eternaleye@gmail.com>
Date : 2010-04-29 2:28 (11 days old)
Message-ID : <loom.20100429T041908-663@post.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127250825306178&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15863
Subject : 2.6.34-rc5-git7 (plus all patches) -- another suspicious rcu_dereference_check() usage.
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2010-04-27 0:51 (13 days old)
Message-ID : <h2ya44ae5cd1004261751waa5cb65ei3d139cbcfa2cc5cf@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127232949104878&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15862
Subject : 2.6.34-rc4/5: iwlagn unusable until reload
Submitter : Nico Schottelius <nico-linux-20100427@schottelius.org>
Date : 2010-04-27 7:49 (13 days old)
Message-ID : <20100427074934.GB3261@ikn.schottelius.org>
References : http://marc.info/?l=linux-kernel&m=127235784004839&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15858
Subject : [2.6.34-rc5] bad page state copying to/from HFS+ filesystem...
Submitter : Daniel J Blueman <daniel.blueman@gmail.com>
Date : 2010-04-25 21:14 (15 days old)
Message-ID : <v2k6278d2221004251414kbbcc41baw78b86120d81dce7d@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127223008621881&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15805
Subject : reiserfs locking
Submitter : Alexander Beregalov <a.beregalov@gmail.com>
Date : 2010-04-15 21:02 (25 days old)
Message-ID : <t2ka4423d671004151402n7b2dc425mdc9c6bb9640d63fb@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127136535323933&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15788
Subject : external usb sound card doesn't work after resume
Submitter : François Valenduc <francois.valenduc@tvcablenet.be>
Date : 2010-04-15 10:16 (25 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15717
Subject : bluetooth oops
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-03-14 20:14 (57 days old)
Message-ID : <20100314201434.GE22059@elf.ucw.cz>
References : http://marc.info/?l=linux-kernel&m=126859771528426&w=4
Handled-By : Marcel Holtmann <marcel@holtmann.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15713
Subject : hackbench regression due to commit 9dfc6e68bfe6e
Submitter : Alex Shi <alex.shi@intel.com>
Date : 2010-03-25 8:40 (46 days old)
First-Bad-Commit: http://git.kernel.org/linus/9dfc6e68bfe6ee452efb1a4e9ca26a9007f2b864
Message-ID : <1269506457.4513.141.camel@alexs-hp.sh.intel.com>
References : http://marc.info/?l=linux-kernel&m=126950632920682&w=4
Handled-By : Christoph Lameter <cl@linux-foundation.org>
Pekka Enberg <penberg@cs.helsinki.fi>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15712
Subject : [regression] 2.6.34-rc1 to -rc3 on zaurus: no longer boots
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-04-01 6:06 (39 days old)
Message-ID : <20100401060624.GA1329@ucw.cz>
References : http://marc.info/?l=linux-kernel&m=127010200817402&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15704
Subject : [r8169] WARNING: at net/sched/sch_generic.c
Submitter : Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date : 2010-03-31 10:21 (40 days old)
Message-ID : <<<20100331102142.GA3294@swordfish.minsk.epam.com>>>
References : http://marc.info/?l=linux-kernel&m=127003090406108&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15673
Subject : 2.6.34-rc2: "ima_dec_counts: open/free imbalance"?
Submitter : Thomas Meyer <thomas@m3y3r.de>
Date : 2010-03-28 11:31 (43 days old)
Message-ID : <1269775909.5301.4.camel@localhost.localdomain>
References : http://marc.info/?l=linux-kernel&m=126977593326800&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15671
Subject : intel graphic card hanging (Hangcheck timer elapsed... GPU hung)
Submitter : Norbert Preining <preining@logic.at>
Date : 2010-03-27 16:11 (44 days old)
Message-ID : <20100327161104.GA12043@gamma.logic.tuwien.ac.at>
References : http://marc.info/?l=linux-kernel&m=126970883105262&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15669
Subject : INFO: suspicious rcu_dereference_check()
Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date : 2010-03-08 1:26 (63 days old)
Message-ID : <c4e36d111003250348q678eb2e6w4f3e8133e7fd6e58@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=126801163107713&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15664
Subject : Graphics hang and kernel backtrace when starting Azureus with Compiz enabled
Submitter : Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec>
Date : 2010-04-01 01:09 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15659
Subject : [Regresion] [2.6.34-rc1] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2010-03-25 20:04 (46 days old)
Message-ID : <<201003252104.24965.maciej.rutecki@gmail.com>>
References : http://marc.info/?l=linux-kernel&m=126954749618319&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15610
Subject : fsck leads to swapper - BUG: unable to handle kernel NULL pointer dereference & panic
Submitter : Ozgur Yuksel <ozgur.yuksel@oracle.com>
Date : 2010-03-22 15:59 (49 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15601
Subject : [BUG] SLOB breaks Crypto
Submitter : michael-dev@fami-braun.de
Date : 2010-03-15 13:39 (56 days old)
Message-ID : <4B9E38AF.70309@fami-braun.de>
References : http://marc.info/?l=linux-kernel&m=126866044724539&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15590
Subject : 2.6.34-rc1: regression: ^Z no longer stops sound
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-03-14 7:58 (57 days old)
Message-ID : <<20100314075831.GA13457@elf.ucw.cz>>
References : http://marc.info/?l=linux-kernel&m=126855353122623&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15589
Subject : 2.6.34-rc1: Badness at fs/proc/generic.c:316
Submitter : Christian Kujau <lists@nerdbynature.de>
Date : 2010-03-13 23:53 (58 days old)
Message-ID : <<alpine.DEB.2.01.1003131544340.5493@bogon.housecafe.de>>
References : http://marc.info/?l=linux-kernel&m=126852442903680&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15768
Subject : Incorrectly calculated free blocks result in ENOSPC from writepage
Submitter : Dmitry Monakhov <dmonakhov@openvz.org>
Date : 2010-04-12 11:24 (28 days old)
Handled-By : Dmitry Monakhov <dmonakhov@openvz.org>
Patch : http://patchwork.ozlabs.org/patch/49989/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15729
Subject : BUG: physmap modprobe & rmmod
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2010-04-02 20:40 (38 days old)
Message-ID : <20100402134058.c4682716.randy.dunlap@oracle.com>
References : http://marc.info/?l=linux-kernel&m=127024096210230&w=2
Handled-By : Hartley Sweeten <hsweeten@visionengravers.com>
Patch : https://patchwork.kernel.org/patch/90497/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15505
Subject : No more b43 wireless interface since 2.6.34-rc1
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2010-03-10 06:59 (61 days old)
Handled-By : Yinghai Lu <yinghai@kernel.org>
Patch : https://bugzilla.kernel.org/show_bug.cgi?id=15505#c11
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.33,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=15310
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: Packet injection with ath9k
From: Gábor Stefanik @ 2010-05-09 20:24 UTC (permalink / raw)
To: Roberto Riggio; +Cc: linux-wireless
In-Reply-To: <4BE46584.5060304@create-net.org>
2010/5/7 Roberto Riggio <roberto.riggio@create-net.org>:
> Hi,
>
> well, that is what i wanted to understand. These are the struct
> that I'm using to compose the rediotap header:
>
> struct ieee80211_radiotap_header {
> u_int8_t it_version;
> u_int8_t it_pad;
> u_int16_t it_len;
> u_int32_t it_present;
AFAIK these 2 fields need to be little-endian even on big-endian
machines. If your system is big-endian, this can cause problems.
> } __attribute__((__packed__));
>
> struct click_radiotap_header {
> struct ieee80211_radiotap_header wt_ihdr;
> u_int8_t wt_rate;
> u_int8_t wt_txpower;
> u_int8_t wt_rts_retries;
> u_int8_t wt_data_retries;
> };
>
> The flags are set in order to take into account the fields that I
> specify. But i do not know at which point the frame are
> dropped.
>
> R.
>
> On 05/07/2010 06:35 PM, Gábor Stefanik wrote:
>>
>> Hi!
>> Are you sure it is not your injector that is having alignment issues?
>> AFAIK the radiotap parser explicitly uses endianness-aware function
>> everywhere.
>>
>> On Fri, May 7, 2010 at 6:13 PM, Roberto Riggio
>> <roberto.riggio@create-net.org> wrote:
>>
>>>
>>> Hi,
>>>
>>> I'm writing an application to inject traffic over a wireless interface.
>>> This
>>> app
>>> is working fine on an x86 machine. However if i compile the same app for
>>> an arm platform, no frame are sent over the wireless interface (ath9k).
>>>
>>> I'm guessing that this is because of some alignment issues but i cannot
>>> track
>>> the piece of code that is actually parsing the frame. I've found the
>>> __ieee80211_parse_tx_radiotap in net/mac80211/tx.c function, but it is
>>> not called when i try to inject some traffic, so the frame are dropped
>>> before that.
>>>
>>> Any hints?
>>>
>>> Thanks
>>> R.
>>> --
>>> 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
>>>
>>>
>>
>>
>>
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH 6/9 v2] rt2x00: Clean up generic procedures on descriptor writing.
From: Gertjan van Wingerde @ 2010-05-09 19:24 UTC (permalink / raw)
To: John W. Linville
Cc: Ivo van Doorn, linux-wireless, users, Gertjan van Wingerde
With a little bit of restructuring it isn't necessary to have special
cases in rt2x00queue_write_tx_descriptor for writing the descriptor
for beacons.
Simply split off the kicking of the TX queue to a separate function
with is only called for non-beacons.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
---
v2: Fix up editorial in comment as reported by Adam Baker.
---
drivers/net/wireless/rt2x00/rt2x00queue.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index 59d9459..8768c6f 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -428,20 +428,23 @@ static void rt2x00queue_write_tx_descriptor(struct queue_entry *entry,
* it is now ready to be dumped to userspace through debugfs.
*/
rt2x00debug_dump_frame(rt2x00dev, DUMP_FRAME_TX, entry->skb);
+}
+
+static void rt2x00queue_kick_tx_queue(struct queue_entry *entry,
+ struct txentry_desc *txdesc)
+{
+ struct data_queue *queue = entry->queue;
+ struct rt2x00_dev *rt2x00dev = queue->rt2x00dev;
/*
* Check if we need to kick the queue, there are however a few rules
- * 1) Don't kick beacon queue
- * 2) Don't kick unless this is the last in frame in a burst.
+ * 1) Don't kick unless this is the last in frame in a burst.
* When the burst flag is set, this frame is always followed
* by another frame which in some way are related to eachother.
* This is true for fragments, RTS or CTS-to-self frames.
- * 3) Rule 2 can be broken when the available entries
+ * 2) Rule 1 can be broken when the available entries
* in the queue are less then a certain threshold.
*/
- if (entry->queue->qid == QID_BEACON)
- return;
-
if (rt2x00queue_threshold(queue) ||
!test_bit(ENTRY_TXD_BURST, &txdesc->flags))
rt2x00dev->ops->lib->kick_tx_queue(rt2x00dev, queue->qid);
@@ -537,6 +540,7 @@ int rt2x00queue_write_tx_frame(struct data_queue *queue, struct sk_buff *skb,
rt2x00queue_index_inc(queue, Q_INDEX);
rt2x00queue_write_tx_descriptor(entry, &txdesc);
+ rt2x00queue_kick_tx_queue(entry, &txdesc);
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 6/9] rt2x00: Clean up generic procedures on descriptor writing.
From: Gertjan van Wingerde @ 2010-05-09 19:23 UTC (permalink / raw)
To: Adam Baker; +Cc: linux-wireless
In-Reply-To: <loom.20100509T205352-131@post.gmane.org>
On 05/09/10 20:54, Adam Baker wrote:
> Gertjan van Wingerde <gwingerde@...> writes:
>
>> - * 3) Rule 2 can be broken when the available entries
>> + * 2) Rule 2 can be broken when the available entries
>> * in the queue are less then a certain threshold.
>> */
>
> shouldn't this say Rule 1 can be broken now?
>
Yes, you're right. Update of the patch is on its way.
---
Gertjan
^ permalink raw reply
* Re: [PATCH 6/9] rt2x00: Clean up generic procedures on descriptor writing.
From: Adam Baker @ 2010-05-09 18:54 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1273354826-4335-7-git-send-email-gwingerde@gmail.com>
Gertjan van Wingerde <gwingerde@...> writes:
> - * 3) Rule 2 can be broken when the available entries
> + * 2) Rule 2 can be broken when the available entries
> * in the queue are less then a certain threshold.
> */
shouldn't this say Rule 1 can be broken now?
Adam
^ permalink raw reply
* Jumbo frame messages?
From: Philip A. Prindeville @ 2010-05-09 18:11 UTC (permalink / raw)
To: wireless
I'm running linux 2.6.27.42 with compat-wireless 2010-04-26 and using an
AR-5413 card (ath5k).
I'm also running hostapd 0.7.1 with WPA2 authentication.
I'm seeing a lot of:
May 9 12:07:21 pbx user.warn kernel: ath5k phy0: unsupported jumbo
I thought this issue was resolved a while ago.
Anyone have a root cause on this, or a workaround?
Thanks,
-Philip
^ permalink raw reply
* Re: The case of the bogus SSID
From: Javier Cardona @ 2010-05-09 15:07 UTC (permalink / raw)
To: John W. Linville; +Cc: pigiron, linux-wireless
In-Reply-To: <20100509004006.GA5790@tuxdriver.com>
John,
On Sat, May 8, 2010 at 5:40 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Sat, May 08, 2010 at 09:34:45AM -0500, pigiron wrote:
>> On Fri, 7 May 2010 09:29:18 -0700 Javier Cardona <javier@cozybit.com> wrote:
>
>> > I don't know about the router, nor if the IE ID clash is causing your
>> > problem, but moving the mesh codes somewhere else in the unassigned ID
>> > space would be a "A Good Thing To Do (tm)".
>
>> Really?
>>
>> Wouldn't that cause a problem for the kids running OLPC? For instance, where
>> some of the laptops are running an old level of code where WLAN_EID_MESH_ID=52
>> and others are running new code where WLAN_EID_MESH_ID=X.
>
> If I'm not mistaken, the mesh done in OLPC is already incompatible w/
> 802.11s anyway.
Yes, the currently deployed laptops implement an earlier version of
the 802.11s draft that's not compatible with what's in the kernel now.
Javier
--
Javier Cardona
cozybit Inc.
http://www.cozybit.com
^ permalink raw reply
* Re: [PATCH 9/9] rt2x00: Fix beaconing on rt2800.
From: Ivo Van Doorn @ 2010-05-09 9:42 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <4BE6832C.1020408@gmail.com>
On Sun, May 9, 2010 at 11:41 AM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> On 05/09/10 11:21, Ivo Van Doorn wrote:
>> On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
>> <gwingerde@gmail.com> wrote:
>>> According to the Ralink vendor driver for rt2800 we don't need a full
>>> TXD for a beacon but just a TXWI in front of the actual beacon.
>>> Fix the rt2800pci and rt2800usb beaconing code accordingly.
>>>
>>> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
>>> ---
>>> drivers/net/wireless/rt2x00/rt2800pci.c | 17 +++++++++--------
>>> drivers/net/wireless/rt2x00/rt2800usb.c | 14 ++++++--------
>>> 2 files changed, 15 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
>>> index 80c6768..7d4778d 100644
>>> --- a/drivers/net/wireless/rt2x00/rt2800pci.c
>>> +++ b/drivers/net/wireless/rt2x00/rt2800pci.c
>>> @@ -682,7 +682,6 @@ static void rt2800pci_write_beacon(struct queue_entry *entry,
>>> struct txentry_desc *txdesc)
>>> {
>>> struct rt2x00_dev *rt2x00dev = entry->queue->rt2x00dev;
>>> - struct skb_frame_desc *skbdesc = get_skb_frame_desc(entry->skb);
>>> unsigned int beacon_base;
>>> u32 reg;
>>>
>>> @@ -695,15 +694,17 @@ static void rt2800pci_write_beacon(struct queue_entry *entry,
>>> rt2800_register_write(rt2x00dev, BCN_TIME_CFG, reg);
>>>
>>> /*
>>> - * Write entire beacon with descriptor to register.
>>> + * Add the TXWI for the beacon to the skb.
>>> + */
>>> + rt2800_write_txwi(entry->skb, txdesc);
>>> + skb_push(entry->skb, TXWI_DESC_SIZE);
>>
>> This looks quite suspicious...
>> First writing into the SKB and only then making room for it?
>> Perhaps we should make sure rt2800_write_txwi demands the
>> room is already added (or it calls skb_push itself).
>>
>
> Yep, I wasn't too happy with this as well. It's on my TODO-list to fix that up, but that
> requires more restructuring of the common code.
> For the sake of keeping this patch small I kept it this way, and I'm already working on
> follow-up patches to clean the skb handling up, so that we don't have to fiddle around
> with the skb->data pointer anymore when creating descriptors and TXWI's.
Ok. In that case:
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH 9/9] rt2x00: Fix beaconing on rt2800.
From: Gertjan van Wingerde @ 2010-05-09 9:41 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <AANLkTilX7auYKpqXFyVs-1EJ8X5wL5PebnDSXtOW1Swk@mail.gmail.com>
On 05/09/10 11:21, Ivo Van Doorn wrote:
> On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
> <gwingerde@gmail.com> wrote:
>> According to the Ralink vendor driver for rt2800 we don't need a full
>> TXD for a beacon but just a TXWI in front of the actual beacon.
>> Fix the rt2800pci and rt2800usb beaconing code accordingly.
>>
>> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
>> ---
>> drivers/net/wireless/rt2x00/rt2800pci.c | 17 +++++++++--------
>> drivers/net/wireless/rt2x00/rt2800usb.c | 14 ++++++--------
>> 2 files changed, 15 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
>> index 80c6768..7d4778d 100644
>> --- a/drivers/net/wireless/rt2x00/rt2800pci.c
>> +++ b/drivers/net/wireless/rt2x00/rt2800pci.c
>> @@ -682,7 +682,6 @@ static void rt2800pci_write_beacon(struct queue_entry *entry,
>> struct txentry_desc *txdesc)
>> {
>> struct rt2x00_dev *rt2x00dev = entry->queue->rt2x00dev;
>> - struct skb_frame_desc *skbdesc = get_skb_frame_desc(entry->skb);
>> unsigned int beacon_base;
>> u32 reg;
>>
>> @@ -695,15 +694,17 @@ static void rt2800pci_write_beacon(struct queue_entry *entry,
>> rt2800_register_write(rt2x00dev, BCN_TIME_CFG, reg);
>>
>> /*
>> - * Write entire beacon with descriptor to register.
>> + * Add the TXWI for the beacon to the skb.
>> + */
>> + rt2800_write_txwi(entry->skb, txdesc);
>> + skb_push(entry->skb, TXWI_DESC_SIZE);
>
> This looks quite suspicious...
> First writing into the SKB and only then making room for it?
> Perhaps we should make sure rt2800_write_txwi demands the
> room is already added (or it calls skb_push itself).
>
Yep, I wasn't too happy with this as well. It's on my TODO-list to fix that up, but that
requires more restructuring of the common code.
For the sake of keeping this patch small I kept it this way, and I'm already working on
follow-up patches to clean the skb handling up, so that we don't have to fiddle around
with the skb->data pointer anymore when creating descriptors and TXWI's.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH 9/9] rt2x00: Fix beaconing on rt2800.
From: Ivo Van Doorn @ 2010-05-09 9:21 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <1273354826-4335-10-git-send-email-gwingerde@gmail.com>
On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> According to the Ralink vendor driver for rt2800 we don't need a full
> TXD for a beacon but just a TXWI in front of the actual beacon.
> Fix the rt2800pci and rt2800usb beaconing code accordingly.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800pci.c | 17 +++++++++--------
> drivers/net/wireless/rt2x00/rt2800usb.c | 14 ++++++--------
> 2 files changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
> index 80c6768..7d4778d 100644
> --- a/drivers/net/wireless/rt2x00/rt2800pci.c
> +++ b/drivers/net/wireless/rt2x00/rt2800pci.c
> @@ -682,7 +682,6 @@ static void rt2800pci_write_beacon(struct queue_entry *entry,
> struct txentry_desc *txdesc)
> {
> struct rt2x00_dev *rt2x00dev = entry->queue->rt2x00dev;
> - struct skb_frame_desc *skbdesc = get_skb_frame_desc(entry->skb);
> unsigned int beacon_base;
> u32 reg;
>
> @@ -695,15 +694,17 @@ static void rt2800pci_write_beacon(struct queue_entry *entry,
> rt2800_register_write(rt2x00dev, BCN_TIME_CFG, reg);
>
> /*
> - * Write entire beacon with descriptor to register.
> + * Add the TXWI for the beacon to the skb.
> + */
> + rt2800_write_txwi(entry->skb, txdesc);
> + skb_push(entry->skb, TXWI_DESC_SIZE);
This looks quite suspicious...
First writing into the SKB and only then making room for it?
Perhaps we should make sure rt2800_write_txwi demands the
room is already added (or it calls skb_push itself).
Ivo
^ permalink raw reply
* Re: [PATCH 1/9] rt2x00: Fix setting of txdesc->length field.
From: Pavel Roskin @ 2010-05-09 9:18 UTC (permalink / raw)
To: Ivo Van Doorn
Cc: Gertjan van Wingerde, John W. Linville, linux-wireless, users
In-Reply-To: <AANLkTikWtLvG-J9UclCEsp7V1B7_J69eujVseWVsZk2y@mail.gmail.com>
On Sun, 2010-05-09 at 11:03 +0200, Ivo Van Doorn wrote:
> On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
> <gwingerde@gmail.com> wrote:
> > We should take the stripping of the IV into account for the txdesc->length
> > field.
> >
> > Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
>
> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Tested-by: Pavel Roskin <proski@gnu.org>
It's working. Thank you!
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 8/9] rt2x00: provide beacon's txdesc to write_beacon callback function.
From: Ivo Van Doorn @ 2010-05-09 9:17 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <1273354826-4335-9-git-send-email-gwingerde@gmail.com>
On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> Preparation to fix rt2800 beaconing.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH 7/9] rt2x00: Clean up all driver's kick_tx_queue callback functions.
From: Ivo Van Doorn @ 2010-05-09 9:16 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <1273354826-4335-8-git-send-email-gwingerde@gmail.com>
On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> All of the driver's kick_tx_queue callback functions treat the TX queue
> for beacons in a special manner.
> Clean this up by integrating the kicking of the beacon queue into the
> write_beacon callback function, and let the generic code no longer call
> the kick_tx_queue callback function when updating the beacon.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH 6/9] rt2x00: Clean up generic procedures on descriptor writing.
From: Ivo Van Doorn @ 2010-05-09 9:11 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <1273354826-4335-7-git-send-email-gwingerde@gmail.com>
On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> With a little bit of restructuring it isn't necessary to have special
> cases in rt2x00queue_write_tx_descriptor for writing the descriptor
> for beacons.
> Simply split off the kicking of the TX queue to a separate function
> with is only called for non-beacons.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH 5/9] rt2x00: Factor out RXWI processing to common rt2800 code.
From: Ivo Van Doorn @ 2010-05-09 9:10 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <1273354826-4335-6-git-send-email-gwingerde@gmail.com>
On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> RXWI processing is exactly the same for rt2800pci and rt2800usb, so
> make it common code.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH 4/9] rt2x00: Factor out TXWI writing to common rt2800 code.
From: Ivo Van Doorn @ 2010-05-09 9:09 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <1273354826-4335-5-git-send-email-gwingerde@gmail.com>
On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> TXWI writing is exactly the same for rt2800pci and rt2800usb, so
> make it common code.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/9] rt2x00: Don't check whether hardware crypto is enabled when reading RXD.
From: Ivo Van Doorn @ 2010-05-09 9:08 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <1273354826-4335-4-git-send-email-gwingerde@gmail.com>
On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> We should simply follow what the hardware told us it has done.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/9] rt2x00: Clean up rt2800usb.h.
From: Ivo Van Doorn @ 2010-05-09 9:04 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <1273354826-4335-3-git-send-email-gwingerde@gmail.com>
On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> Remove unused RXD_DESC_SIZE define and remove duplicated RXWI definitions
> from rt2800.h.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/9] rt2x00: Fix setting of txdesc->length field.
From: Ivo Van Doorn @ 2010-05-09 9:03 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John W. Linville, linux-wireless, users
In-Reply-To: <1273354826-4335-2-git-send-email-gwingerde@gmail.com>
On Sat, May 8, 2010 at 11:40 PM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> We should take the stripping of the IV into account for the txdesc->length
> field.
>
> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2x00crypto.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00crypto.c b/drivers/net/wireless/rt2x00/rt2x00crypto.c
> index d291c78..583dacd 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00crypto.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00crypto.c
> @@ -128,6 +128,7 @@ void rt2x00crypto_tx_remove_iv(struct sk_buff *skb, struct txentry_desc *txdesc)
>
> /* Pull buffer to correct size */
> skb_pull(skb, txdesc->iv_len);
> + txdesc->length -= txdesc->iv_len;
>
> /* IV/EIV data has officially been stripped */
> skbdesc->flags |= SKBDESC_IV_STRIPPED;
> --
> 1.7.1
>
>
^ permalink raw reply
* Re: The case of the bogus SSID
From: John W. Linville @ 2010-05-09 0:40 UTC (permalink / raw)
To: pigiron; +Cc: Javier Cardona, linux-wireless
In-Reply-To: <20100508093445.581e180e@atom.pigiron.org>
On Sat, May 08, 2010 at 09:34:45AM -0500, pigiron wrote:
> On Fri, 7 May 2010 09:29:18 -0700 Javier Cardona <javier@cozybit.com> wrote:
> > I don't know about the router, nor if the IE ID clash is causing your
> > problem, but moving the mesh codes somewhere else in the unassigned ID
> > space would be a "A Good Thing To Do (tm)".
> Really?
>
> Wouldn't that cause a problem for the kids running OLPC? For instance, where
> some of the laptops are running an old level of code where WLAN_EID_MESH_ID=52
> and others are running new code where WLAN_EID_MESH_ID=X.
If I'm not mistaken, the mesh done in OLPC is already incompatible w/
802.11s anyway.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [patch 6/9] ath5k: several off by one range checks
From: Bob Copeland @ 2010-05-08 22:33 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, John W. Linville,
Bruno Randolf, linux-wireless, ath5k-devel
In-Reply-To: <20100508162438.GR27064@bicker>
On Sat, May 08, 2010 at 06:24:38PM +0200, Dan Carpenter wrote:
> There are several places that use > ARRAY_SIZE() instead of
> >= ARRAY_SIZE().
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Thanks,
Acked-by: Bob Copeland <me@bobcopeland.com>
--
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