b43: out-of-standard behavior

2008-09-10 Thread Francesco Gringoli
Hello everybody,

we found a strange behavior problem with the b43 driver. We begin  
investigating this when doing some access tests with several boards:  
we discovered that the Broadcom boards usually acquire the channel  
usage with higher priority when the b43 driver is used as respect to  
other vendor boards.

After investigating we saw that the intra-queue contention procedure  
is carried out by the firmware which stores information, such as AIFS  
and current backoffs for each queue, inside the shared memory. The  
AIFS for each queue is used to compute the initial backoff so that  
internal contention usually gives more priority to VO queue (smallest  
AIFS) and less to background (biggest AIFS). AIFS parameters are  
initialized by the driver which is told to use a 22 words long  
structures. The firmware instead use 16 words structures: this means  
that AIFS parameters initialized by the driver do not match the  
corresponding values read by the firmware. We saw that the firmware  
reads (2,0,0,0) instead of (2,2,3,7) which results in very short  
backoff procedures.

Has anyone noticed similar behavior? For the sake of clarity, I'm  
referring to latest (30 minutes ago) version of wireless-git and  
broadcom-wl-4.150.10.5 driver version. I verified that all ucode5.s,  
ucode9.s, ucode11.s, ucode13.s and ucode14.s firmwares use 16 words  
structures, and the driver instead still uses 22 words long  
structures.  Probably the attached patch sorts out the problem.

I also noticed that the specs say that these structures are 16 words:  
could not someone read 16 as 0x16 that finally became 0x16 = 22?

Cheers,
FG

--- b43.h.old   2008-09-10 21:12:59.0 +0200
+++ b43.h   2008-09-10 21:13:09.0 +0200
@@ -569,7 +569,7 @@
  #define B43_QOS_VOICE B43_QOS_PARAMS(3)

  /* QOS parameter hardware data structure offsets. */
-#define B43_NR_QOSPARAMS   22
+#define B43_NR_QOSPARAMS   16
  enum {
B43_QOSPARAM_TXOP = 0,
B43_QOSPARAM_CWMIN,



___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: b43: out-of-standard behavior

2008-09-10 Thread Michael Buesch
On Wednesday 10 September 2008 21:42:57 Francesco Gringoli wrote:
 Hello everybody,
 
 we found a strange behavior problem with the b43 driver. We begin  
 investigating this when doing some access tests with several boards:  
 we discovered that the Broadcom boards usually acquire the channel  
 usage with higher priority when the b43 driver is used as respect to  
 other vendor boards.
 
 After investigating we saw that the intra-queue contention procedure  
 is carried out by the firmware which stores information, such as AIFS  
 and current backoffs for each queue, inside the shared memory. The  
 AIFS for each queue is used to compute the initial backoff so that  
 internal contention usually gives more priority to VO queue (smallest  
 AIFS) and less to background (biggest AIFS). AIFS parameters are  
 initialized by the driver which is told to use a 22 words long  
 structures. The firmware instead use 16 words structures: this means  
 that AIFS parameters initialized by the driver do not match the  
 corresponding values read by the firmware. We saw that the firmware  
 reads (2,0,0,0) instead of (2,2,3,7) which results in very short  
 backoff procedures.
 
 Has anyone noticed similar behavior? For the sake of clarity, I'm  
 referring to latest (30 minutes ago) version of wireless-git and  
 broadcom-wl-4.150.10.5 driver version. I verified that all ucode5.s,  
 ucode9.s, ucode11.s, ucode13.s and ucode14.s firmwares use 16 words  
 structures, and the driver instead still uses 22 words long  
 structures.  Probably the attached patch sorts out the problem.
 
 I also noticed that the specs say that these structures are 16 words:  
 could not someone read 16 as 0x16 that finally became 0x16 = 22?

The specs are ambiguous here.
The specs table for QoS clearly has 0x16 fields. So I implemented it
this way and read the foobar has 16 words text in hex.

How many people can read hex, if only you and dead people can read hex? ;)


 --- b43.h.old 2008-09-10 21:12:59.0 +0200
 +++ b43.h 2008-09-10 21:13:09.0 +0200
 @@ -569,7 +569,7 @@
   #define B43_QOS_VOICE   B43_QOS_PARAMS(3)
 
   /* QOS parameter hardware data structure offsets. */
 -#define B43_NR_QOSPARAMS 22
 +#define B43_NR_QOSPARAMS 16
   enum {
   B43_QOSPARAM_TXOP = 0,
   B43_QOSPARAM_CWMIN,

PS: Can you please avoid starting yet another thread for the topic?
We already have one.

Please, guys, keep _threads_. It's important to _not_ start new threads
all the time, so email archive searching is made possible. This is _also_
the case for private mail from you.
You're not the only one in my inbox, but every time I have to search for
your old mail it's a headache.
So good subjects (this one is _not_ a good one) and not breaking threads
is very important.

-- 
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev