headers
Pavel Roskin | 1 Mar 06:07
Picon

Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition

On Thu, 2009-02-26 at 21:27 -0500, Bob Copeland wrote:

> Actually, I remembered in the dark recesses of my moldering brain 
> that someone had a lost patch for this a while ago, so I searched
> the archives.  Pavel, ok to add your s-o-b?

Since my patch was dropped and the new patch was implemented without my
participation, it makes no sense to put my s-o-b on the code I didn't
write (even though I wrote something similar before).

--

-- 
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Pavel Roskin | 1 Mar 06:21
Picon

Re: [PATCH 1/1] ath5k: fix hw rate index condition

On Thu, 2009-02-26 at 22:06 -0500, Bob Copeland wrote:
> On Thu, Feb 26, 2009 at 06:39:12PM -0800, Luis R. Rodriguez wrote:
> > Might be worth adding a note why this is the case. Can't we simply avoid
> > this by checking earlier for the error or simply assigning it an actual
> > default _good_ hw rate value?
> 
> I guess an alternative is to initialize to 0, that would count any rx
> packets whose hw rate we don't know about as the base rate, so it would
> probably bias the RC to 1mb, but this is already one of those 'should 
> never happen' cases.

I would prefer that we don't hide problems.

If we don't know why we cannot get a valid rate, we should use WARN_ON
and find out why and when it happens.  I'm fine with using a bogus rate
with WARN_ON.

If we decide that we indeed cannot find the actual rate, then WARN_ON
should be removed and the bogus rate replaced with an "unknown rate",
that is, a special value that is never translated to a valid rate and
never given to any rate control algorithm.  Using a bogus rate without a
warning is wrong in my opinion.

It should be possible to represent "unknown rate" as such.  That applies
to all drivers.  I remember that b43 also failed to report the rate in
some cases (for the first received packet or something like that).

--

-- 
Regards,
Pavel Roskin
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Miller | 1 Mar 07:12
Favicon

Re: pull request: wireless-next-2.6 2009-02-27

From: David Miller <davem@...>
Date: Sat, 28 Feb 2009 15:50:43 -0800 (PST)

> >From git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
>  * branch            master     -> FETCH_HEAD
> fatal: unable to read tree c9ee57c5c20c3b7a2d7784a4172aef8b34c3a844
> davem <at> sunset:~/src/GIT/net-next-2.6$ git show c9ee57c5c20c3b7a2d7784a4172aef8b34c3a844
> fatal: bad object c9ee57c5c20c3b7a2d7784a4172aef8b34c3a844
> davem <at> sunset:~/src/GIT/net-next-2.6$ 
 ...
> I wonder if I reverted a push and it contaminated your tree?

It's my local tree which is corrupt, so don't worry about this :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Kevin Wilson | 1 Mar 09:41
Picon

Multi Queue hardware support for wireless network cards

Hello,
 - I know that Intel PRO/Wireless 3945ABG wireless card and and Intel
   PRO/Wireless 2200BG have Multiple hardware queues.

- My question is: Is there a way to know from a command line whether a
wireless card has
Multiple hardware queue support ?

- And on this occasion: does anybody know:
 are there any other wireless cards which have Multiple hardware
queues support?

Regards,
  Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Bob Copeland | 1 Mar 15:36
Favicon

Re: [ath5k-devel] [PATCH 1/1] ath5k: fix hw rate index condition

On Sun, Mar 1, 2009 at 12:07 AM, Pavel Roskin <proski@...> wrote:
> On Thu, 2009-02-26 at 21:27 -0500, Bob Copeland wrote:
>
>> Actually, I remembered in the dark recesses of my moldering brain
>> that someone had a lost patch for this a while ago, so I searched
>> the archives.  Pavel, ok to add your s-o-b?
>
> Since my patch was dropped and the new patch was implemented without my
> participation, it makes no sense to put my s-o-b on the code I didn't
> write (even though I wrote something similar before).

Ok, I just wanted to be sure to maintain proper credit, the "From" should
suffice.  I did rewrite the patch but it actually had an identical diff.
FWIW, the thread didn't give a clue why it didn't make it upstream, just
missed I guess (http://marc.info/?l=linux-wireless&m=122480002519627&w=2,
ultimately that problem was fixed by correctly setting the rs_more flag).

Anyway, the patch, while IMO correct, will still result in mac80211
warning in ieee80211_rx with -1 just as 255 will; it just fixes the
subsequent out of bound read.  If we want to tell mac80211 a real rate,
I think we should change it to s8 then hw_to_driver_rix should do
something like:

idx = array[x][y];
if (WARN_ON(idx < 0))
   idx = 0;

return idx;

Then we get the warning in the driver and we also return a real rate up
(Continue reading)

Permalink | Reply | 0 comments |
headers
wzabolot-1JbLm1bU5j4vRRJbHPUgXW5tqTv5QFrZ@public.gmane.org | 1 Mar 15:26
Picon
Picon

Belkin K7SF5D7050 hangs the khubd or modprobe with p54usb driver

Hi,

I have a Belkin K7SF5D7050 NIC, which is supposed to work with the
p54usb driver.
The original driver may be found here:
http://www.belkin.com/support/article/?lid=en&aid=5381
When I extract the original firmware with the fwextract3 tool, I get the
firmware which, when copied to the
/lib/firmware/isl3890usb causes the following information to be logged
into /var/log/messages (I use the kernel 2.6.28.7):

Mar  1 14:35:21 wzab kernel: usb 2-2.1: new full speed USB device using
uhci_hcd and address 5
Mar  1 14:35:21 wzab kernel: usb 2-2.1: not running at top speed;
connect to a high speed hub
Mar  1 14:35:21 wzab kernel: usb 2-2.1: configuration #1 chosen from 1
choice
Mar  1 14:35:21 wzab kernel: cfg80211: Using static regulatory domain info
Mar  1 14:35:21 wzab kernel: cfg80211: Regulatory domain: US
Mar  1 14:35:21 wzab kernel: ^I(start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
Mar  1 14:35:21 wzab kernel: ^I(2402000 KHz - 2472000 KHz @ 40000 KHz),
(600 mBi, 2700 mBm)
Mar  1 14:35:21 wzab kernel: ^I(5170000 KHz - 5190000 KHz @ 40000 KHz),
(600 mBi, 2300 mBm)
Mar  1 14:35:21 wzab kernel: ^I(5190000 KHz - 5210000 KHz @ 40000 KHz),
(600 mBi, 2300 mBm)
Mar  1 14:35:21 wzab kernel: ^I(5210000 KHz - 5230000 KHz @ 40000 KHz),
(600 mBi, 2300 mBm)
Mar  1 14:35:21 wzab kernel: ^I(5230000 KHz - 5330000 KHz @ 40000 KHz),
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ivo van Doorn | 1 Mar 17:42
Picon

rt2x00: Fix SW antenna diversity

Software antenna tuning is broken because of an function
ordering problem during rt2x00link_tuner().

rt2x00link_precalculate_signal()
rt2x00leds_led_quality()
rt2x00lib_antenna_diversity()

rt2x00link_precalculate_signal() will reset the quality TX/RX counters,
however rt2x00lib_antenna_diversity() requires the RX counter to
see what RSSI value must be used for a particular antenna.
We can't change the ordering since rt2x00lib_antenna_diversity() might
reset other statistics which are needed by the function called earlier.

Move the reset of the quality TX/RX counters into a seperate function
and move the call to after rt2x00lib_antenna_diversity().

Signed-off-by: Ivo van Doorn <IvDoorn@...>
---
diff --git a/drivers/net/wireless/rt2x00/rt2x00link.c b/drivers/net/wireless/rt2x00/rt2x00link.c
index 9223a6d..7eb5cd7 100644
--- a/drivers/net/wireless/rt2x00/rt2x00link.c
+++ b/drivers/net/wireless/rt2x00/rt2x00link.c
@@ -302,11 +302,6 @@ static void rt2x00link_precalculate_signal(struct rt2x00_dev *rt2x00dev)
 	    PERCENTAGE(qual->rx_success, qual->rx_failed + qual->rx_success);
 	link->tx_percentage =
 	    PERCENTAGE(qual->tx_success, qual->tx_failed + qual->tx_success);
-
-	qual->rx_success = 0;
-	qual->rx_failed = 0;
-	qual->tx_success = 0;
(Continue reading)

Permalink | Reply | 0 comments |
headers
P.G. Richardson | 1 Mar 18:48
Picon

rtl8187 performance diagnostics (was: rtl8187 cannot fix rate)

> I'm not an expert in reading these tables, but the success rates above 11
> Mb/s
> are very low, which seems to indicate that 11 Mb/s is a reasonable rate
> for your
> device. There is, however, a possibility that the code is not reporting
> the
> retry count correctly. I know from your initial post that 54M doesn't
> work, but
> can you get any throughput at 24, 36, or 48M? There is also the
> possibility that
> your hardware is broken for OFDM encoding. That scheme is used for 6, 9,
> and all
> rates 18M and above.
>
> Larry

Further playing around with my rtl8187b card. I have installed windows
onto my laptop too for performance comparisons. Just how crude or accurate
such comparisons are I dont know so if anyone has any experience then do
shout.

After installing windows, I did the following:

1) ping -n 10000 [server]
Result: Ping replies were good from throughout the house. Only 1 packet
lost out of about 600.

2) Observation of wireless connection
Result: From the little diagnostics there are on windows, it reckons it
connected at 54g (completely false as windows might just say that anyway).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Seidel | 1 Mar 20:25
Picon
Favicon

[PATCH] iwlwifi: reduce stack size

From: Frank Seidel <frank@...>

Reduce stack memory footprint of iwlwifi.
(From >1000 bytes for each *_table_read
on i386 down to 32)

Signed-off-by: Frank Seidel <frank@...>
---
 drivers/net/wireless/iwlwifi/iwl-3945-rs.c |   11 +++++++++--
 drivers/net/wireless/iwlwifi/iwl-agn-rs.c  |   23 +++++++++++++++++++----
 2 files changed, 28 insertions(+), 6 deletions(-)

--- a/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
@@ -815,11 +815,16 @@ static ssize_t iwl3945_sta_dbgfs_stats_t
 						  char __user *user_buf,
 						  size_t count, loff_t *ppos)
 {
-	char buff[1024];
+	char *buff;
 	int desc = 0;
 	int j;
+	ssize_t ret;
 	struct iwl3945_rs_sta *lq_sta = file->private_data;

+	buff = kmalloc(1024, GFP_KERNEL);
+	if (!buff)
+		return -ENOMEM;
+
 	desc += sprintf(buff + desc, "tx packets=%d last rate index=%d\n"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larry Finger | 1 Mar 20:29
Favicon

Re: rtl8187 performance diagnostics

P.G. Richardson wrote:
> Is there anything I can do to help improve this situation? These results
> seems to rule out hardware in favour of being driver related. Are there
> other tests I could perform to determine where the fragility lies?
> 
> Any thoughts, let me know.

OK, the Windows driver is better than the Linux one. Unfortunately, source is
not available.

You can check what we did when the RTL8187B was implemented. To do that, you
need to download the Realtek vendor-written Linux driver and check what they do
against what is in the current in-kernel driver. The critical areas will likely
be associated with power settings for the radio. Be aware that their code is
quite difficult to read as it has multiple conditional compilations that are
hard to keep straight.

I will be happy to test any improvements that you suggest.

Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |

Gmane