Re: [PATCH] Fix handling of failure to create debugfs directory

2007-08-08 Thread Larry Finger
Larry Finger wrote:
 Pavel Roskin wrote:
 This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
 CONFIG_DEBUG_FS is not.

 Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
 ---

 With this patch installed, and the DEBUG configuration set as above, I get a 
 kernel panic on an 
 x86_64 SMP system. The reason for the panic scrolled off the screen, but the 
 complete stack dump 
 (hand copied) is as follows:
 
 lock_acquire+0x85/0x31
 bcm43xx_mac80211: bcm43xx_debugfs_log_txstat+0x5a/099
 _spin_lock+0x25/0x31

Ignore the noise above. I had failed to get the right patch. The crash confirms 
the problem 
_without_ the patch. Getting it in properly fixes the problem

Acked-by: Larry Finger [EMAIL PROTECTED]

Larry

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


Re: 4311 works with fedora 7 but only at 1mb/s

2007-08-08 Thread Brennan Ashton
Sorry work has been calling (very late nights from server migration),
I will try to get the script going soon, as i need to upgrade to the
new tree anyway.

On 8/7/07, John H. [EMAIL PROTECTED] wrote:
 Did I misunderstand something?  I thought some script was available or
 some easy way to use either bcm43xx or the new one.  brennan says he
 has a script to just let you use the newer driver with higher mbps,
 but I have never heard back from him.

 On 8/3/07, John H. [EMAIL PROTECTED] wrote:
  yes, please post such a script so I can use it and not need
  ndiswrapper anymore:)
 
  On 8/3/07, Brennan Ashton [EMAIL PROTECTED] wrote:
The OP's meaning of this thread, which is that bcm43xx_mac80211 doesn't 
work well enough for him,
has been lost. He wants bcm43xx (softmac)!
   
One other option is to get the stand-alone version of bcm43xx from my 
FTP site
(ftp://lwfinger.dynalias.org/patches/bcm43xx-softmac-sa.tar.bz2), and 
build that.
  
   which is what the directions that i posted do, with the new version of
   bcm43xx_mac80211 it should work fine, that is what i have on F7 with
   the same card, and i am getting speeds over 1mb/s.  This weekend, i
   could write a script to automate the process if people are interested.
  
   --
   Brennan Ashton
   Bellingham, Washington
  
   The box said, 'Requires Windows 98 or better'. So I installed Linux
  
 



-- 
Brennan Ashton
Bellingham, Washington

The box said, 'Requires Windows 98 or better'. So I installed Linux
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH] Fix handling of failure to create debugfs directory

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 07:17:10 Pavel Roskin wrote:
 This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
 CONFIG_DEBUG_FS is not.
 
 Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
 ---

Thanks, queued.
Larry, this might also apply to bcm4301.

  .../wireless/bcm43xx-mac80211/bcm43xx_debugfs.c|8 ++--
  1 files changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c 
 b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
 index 9ca4625..aded2b3 100644
 --- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
 +++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
 @@ -408,7 +408,7 @@ static struct file_operations restart_fops = {
  
  int bcm43xx_debug(struct bcm43xx_wldev *dev, enum bcm43xx_dyndbg feature)
  {
 - return !!(dev-dfsentry-dyn_debug[feature]);
 + return !!(dev-dfsentry  dev-dfsentry-dyn_debug[feature]);
  }
  
  static void bcm43xx_remove_dynamic_debug(struct bcm43xx_wldev *dev)
 @@ -472,7 +472,9 @@ void bcm43xx_debugfs_add_device(struct bcm43xx_wldev *dev)
   snprintf(devdir, sizeof(devdir), %s, wiphy_name(dev-wl-hw-wiphy));
   e-subdir = debugfs_create_dir(devdir, fs.root);
   if (!e-subdir || IS_ERR(e-subdir)) {
 - e-subdir = NULL;
 + bcmerr(dev-wl, debugfs: cannot create %s directory\n,
 +devdir);
 + dev-dfsentry = NULL;
   kfree(log-log);
   kfree(e);
   return;
 @@ -525,6 +527,8 @@ void bcm43xx_debugfs_log_txstat(struct bcm43xx_wldev *dev,
   struct bcm43xx_txstatus *cur;
   int i;
  
 + if (!e)
 + return;
   log = e-txstatlog;
   assert(irqs_disabled());
   spin_lock(log-lock);

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


Re: Odd network locking

2007-08-08 Thread Johannes Berg
On Sat, 2007-08-04 at 00:56 -0700, Brennan Ashton wrote:
 the trace overflows dmesg buffer, but here is what is left in the log:
 
 [...]

Not very understandable unfortunately. Somewhere there must be a missing
dev_put but I can't pinpoint it.

johannes


signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH] Fix handling of failure to create debugfs directory

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 07:52:21 Larry Finger wrote:
 Pavel Roskin wrote:
  This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
  CONFIG_DEBUG_FS is not.
  
  Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
  ---
  
 With this patch installed, and the DEBUG configuration set as above, I get a 
 kernel panic on an 
 x86_64 SMP system. The reason for the panic scrolled off the screen, but the 
 complete stack dump 
 (hand copied) is as follows:
 
 lock_acquire+0x85/0x31
 bcm43xx_mac80211: bcm43xx_debugfs_log_txstat+0x5a/099
 _spin_lock+0x25/0x31
 bcm43xx_mac80211: bcm43xx_interrupt_tasklet+0x21/0x723
 bcm43xx_mac80211: bcm43xx_debugfs_log_txstat+0x5a/0x99
 bcm43xx_mac80211: bcm43xx_handle_txstatsus+0x12/0x72
 bcm43xx_mac80211: bcm43xx_interrupt_tasklet+0x699/0x723
 __lock_acquire+0xca2/0xcf0
 bcm43xx_mac80211: bcm43xx_interrupt_handler+0x296/0x723
 tasklet_action+0x5e/0xb2
 __do_softirq+0x5f/0xe3
 call_softirq+0x1c/0x28
 do_softirq+0x39/0x9f
 irq_exit+0x4e/0x50
 do_IRQ+0xba/0xd8
 default_idle+0x35/0x51
 cpu_idle+0xce/0xf1
 start_secondary+0x2e0/0x2f2

Ah crap. I missed this. I'll do a patch.
But first some lunch :)

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


Re: [PATCH] Fix handling of failure to create debugfs directory

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 08:02:29 Larry Finger wrote:
 Larry Finger wrote:
  Pavel Roskin wrote:
  This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
  CONFIG_DEBUG_FS is not.
 
  Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
  ---
 
  With this patch installed, and the DEBUG configuration set as above, I get 
  a kernel panic on an 
  x86_64 SMP system. The reason for the panic scrolled off the screen, but 
  the complete stack dump 
  (hand copied) is as follows:
  
  lock_acquire+0x85/0x31
  bcm43xx_mac80211: bcm43xx_debugfs_log_txstat+0x5a/099
  _spin_lock+0x25/0x31
 
 Ignore the noise above. I had failed to get the right patch. The crash 
 confirms the problem 
 _without_ the patch. Getting it in properly fixes the problem
 
 Acked-by: Larry Finger [EMAIL PROTECTED]

Yeah, I just noticed that, too :)
So, I applied it to my queue and it will soon go upstream.
http://bu3sch.de/patches/wireless-dev/LATEST/patches/

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


Re: Usage of bcm43xx-sprom tool

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 05:27:13 Jhonie Walker wrote:
 Hello, I tried to use the tool with the drivers
 working ok, but this is what I get in the console:
 ./sprommod.sh eth0
 ./sprommod.sh: line 31: bcm43xx-sprom: command not
 found
 Could not modify SPROM data (127)
 
 I noticed that the file bcm43xx-sprom does not exist.
 Instead it is a ssb-sprom binary file.

Ah, it was renamed.
That's a bug in that script.
I think I will simply remove that script, as it's just a
hack that only works on the old non-ssb based driver.

 I installed the tool in Fedora 7 using the 'make
 install' command. I was using the last version
 available throug svn.
 
 I think I need more information on how to use this
 tool (i.e. a short tutorial).

In general you don't want to use it.
What are you trying to do?
Doing the wrong things with this tool can make it very
difficult to recover to a properly working device.

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


Re: Odd network locking

2007-08-08 Thread Michael Buesch
On Saturday 04 August 2007 07:12:46 Brennan Ashton wrote:
 When the bcm43xx_mac80211 driver stops communicating, and needs to be
 reset (this seems to happens when coming from strong to week to strong
 signal area quickly) i have been rmmod and then modprobing it. this

Can you test if you still have that stop communication problem, if you
pull latest wireless-dev and apply these patches on top of it?
http://bu3sch.de/patches/wireless-dev/LATEST/patches/

 works most of the time, but some times (~20%), it will lock up the
 network with this error that repeats.
 
 Message from [EMAIL PROTECTED] at Fri Aug  3 00:55:41 2007 ...
 localhost kernel: [19316.256549] unregister_netdevice: waiting for eth1 to 
 becom
 e free. Usage count = 5

Most likely a bug in mac80211.
But it _could_ be related to the ieee80211_stop_queues() call we
do when stopping the wireless core. I think it's still not race free.
But I don't know if that can cause something like this.

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


Re: [PATCH] Fix handling of failure to create debugfs directory

2007-08-08 Thread Larry Finger
Michael Buesch wrote:
 On Wednesday 08 August 2007 07:17:10 Pavel Roskin wrote:
 This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
 CONFIG_DEBUG_FS is not.

 Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
 ---
 
 Thanks, queued.
 Larry, this might also apply to bcm4301.

Yes it will. Thanks,

Larry

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Pavel Roskin
On Mon, 2007-08-06 at 15:45 -0400, Will Dyson wrote:

 The spec is telling us to lookup an invalid index in the LO table.

I see.  Thanks for your explanation!

I think the way to solve it would be to see how the table is used in the
proprietary driver.  Either the data from the extra entries is used, and
we need to find out where it comes from, or there is an algorithm to
limit the index to only access valid entries.

I hope the reverse engineering team knows that.  I wish them good luck.

-- 
Regards,
Pavel Roskin

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Larry Finger
To the list: The beginnings of this thread were done off-list, but I want to 
let everyone know about
the problem, and to discover if anyone else has it. Since 2.6.23-rc1, Ehud has 
a problem in that the 
information his interface is transmitting is garbled. He did a bisection and 
discovered that the 
problem is involved with commit 85a83d26 bcm43xx-mac80211: Rewrite and 
simplify handling of the 
initialization status.. Neither Michael nor I can reproduce the problem, nor 
is anything obviously 
wrong with the patch, other than this patch exposes an error in the location of 
the initial 
interrupt. I found this error on my old/slow notebook. Fixing that error did 
not resolve Ehud's 
problem. That fix is now in Linville's tree.

Ehud - please make your test tree current with a 'git checkout -f' command, and 
do a 'git pull' to
make certain you have the latest code. Then apply the trial patch below, which 
reverts a small part 
of Michael's patch, and see if it fixes the problem.

Larry


Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -1503,7 +1503,7 @@ static void bcm43xx_interrupt_ack(struct
  /* Interrupt handler top-half */
  static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
  {
-   irqreturn_t ret = IRQ_NONE;
+   irqreturn_t ret = IRQ_HANDLED;
struct bcm43xx_wldev *dev = dev_id;
u32 reason;

@@ -1512,12 +1512,11 @@ static irqreturn_t bcm43xx_interrupt_han

spin_lock(dev-wl-irq_lock);

-   if (bcm43xx_status(dev)  BCM43xx_STAT_STARTED)
-   goto out;
reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
-   if (reason == 0x) /* shared IRQ */
+   if (reason == 0x) { /* shared IRQ */
+   ret = IRQ_NONE;
goto out;
-   ret = IRQ_HANDLED;
+   }
reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_MASK);
if (!reason)
goto out;

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Ehud Gavron
I had hoped this would be the cure so I don't have to undo the 85a83d26 
commit patch by patch.


However, while this did not solve the problem it DID show a new error:
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) == 
BCM43xx_STAT_STARTED) at: 
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1377:bcm43xx_interrupt_tasklet()


Is that a clue to bigger things, or a problem with this patch? 
dmesg and tcpdump (of garbage) included along with a log of what I did 
with the git test tree to get there.


Ehud


Larry Finger wrote:
To the list: The beginnings of this thread were done off-list, but I 
want to let everyone know about
the problem, and to discover if anyone else has it. Since 2.6.23-rc1, 
Ehud has a problem in that the information his interface is 
transmitting is garbled. He did a bisection and discovered that the 
problem is involved with commit 85a83d26 bcm43xx-mac80211: Rewrite 
and simplify handling of the initialization status.. Neither Michael 
nor I can reproduce the problem, nor is anything obviously wrong with 
the patch, other than this patch exposes an error in the location of 
the initial interrupt. I found this error on my old/slow notebook. 
Fixing that error did not resolve Ehud's problem. That fix is now in 
Linville's tree.


Ehud - please make your test tree current with a 'git checkout -f' 
command, and do a 'git pull' to
make certain you have the latest code. Then apply the trial patch 
below, which reverts a small part of Michael's patch, and see if it 
fixes the problem.


Larry


Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- 
wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c

+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
@@ -1503,7 +1503,7 @@ static void bcm43xx_interrupt_ack(struct
 /* Interrupt handler top-half */
 static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
 {
-irqreturn_t ret = IRQ_NONE;
+irqreturn_t ret = IRQ_HANDLED;
 struct bcm43xx_wldev *dev = dev_id;
 u32 reason;

@@ -1512,12 +1512,11 @@ static irqreturn_t bcm43xx_interrupt_han

 spin_lock(dev-wl-irq_lock);

-if (bcm43xx_status(dev)  BCM43xx_STAT_STARTED)
-goto out;
 reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_REASON);
-if (reason == 0x) /* shared IRQ */
+if (reason == 0x) { /* shared IRQ */
+ret = IRQ_NONE;
 goto out;
-ret = IRQ_HANDLED;
+}
 reason = bcm43xx_read32(dev, BCM43xx_MMIO_GEN_IRQ_MASK);
 if (!reason)
 goto out;
bcm43xx-phy0: Broadcom 4311 WLAN found
bcm43xx-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8
bcm43xx-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
bcm43xx-phy0 debug: Radio turned off
bcm43xx driver
bcm43xx-phy1: Broadcom 4311 WLAN found
bcm43xx-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8
bcm43xx-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
bcm43xx-phy1 debug: Radio turned off
bcm43xx-phy1 debug: Adding Interface type 2
bcm43xx-phy1 debug: Loading firmware version 371.1061 (2006-10-04 21:02:04)
bcm43xx-phy1 debug: Radio turned on
bcm43xx-phy1 debug: Radio enabled by hardware
bcm43xx-phy1 debug: bbatt(11) = size of LO array
 [8817daaf] :bcm43xx_mac80211:bcm43xx_get_lo_g_ctl+0x65/0xa8
 [8817db28] :bcm43xx_mac80211:bcm43xx_lo_g_ctl_current+0x36/0x3b
 [8817dc0c] :bcm43xx_mac80211:bcm43xx_lo_g_adjust+0x9/0x15
 [8817824b] :bcm43xx_mac80211:bcm43xx_phy_init_pctl+0x338/0x6a6
 [88172ae4] :bcm43xx_mac80211:bcm43xx_phy_read+0x5c/0x63
 [8817b52e] :bcm43xx_mac80211:bcm43xx_phy_initg+0xc85/0xd0a
 [8817bd61] :bcm43xx_mac80211:bcm43xx_phy_init+0x582/0x5a7
 [8816fcce] :bcm43xx_mac80211:bcm43xx_chip_init+0x68c/0x9a3
 [8817026d] :bcm43xx_mac80211:bcm43xx_wireless_core_init+0x288/0x73e
 [881712bb] :bcm43xx_mac80211:bcm43xx_add_interface+0x5f/0xf4
bcm43xx-phy1 debug: Chip initialized
bcm43xx-phy1 debug: 32-bit DMA initialized
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) == 
BCM43xx_STAT_STARTED) at: 
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1525:bcm43xx_interrupt_handler()
bcm43xx_mac80211: ASSERTION FAILED (bcm43xx_status(dev) == 
BCM43xx_STAT_STARTED) at: 
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c:1377:bcm43xx_interrupt_tasklet()
bcm43xx-phy1 debug: Wireless interface started
08:47:25.934468 00:a0:c8:0e:c0:e5  00:1a:92:0e:40:1f, 802.3, length 78: LLC, 
dsap Unknown (0xd0) Group, ssap Unknown (0x1e) Command, ctrl 0x007c: 
Information, send seq 62, rcv seq 0, Flags [Command], length 64
0x:  001a 920e 401f 00a0 c80e c0e5 0040 d11e
0x0010:  7c00 d33d 7497 de0e 21e6 f6fe 8382 bf04
0x0020:  e081 7838 36f2 114a 3ee3 9c19 e3fc 402c
0x0030:  8746 083d 4fb9 0b86 4965 f272 86e1 963b
0x0040:  2efe a2c5 c3ac f6ca 4363 eb91 a233

Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 18:11:03 Larry Finger wrote:
  [EMAIL PROTECTED] test]# patch -p1  patch-2007-aug-08-lfinger.txt 
  patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
  Hunk #1 FAILED at 1503.
  Hunk #2 FAILED at 1512.
  2 out of 2 hunks FAILED -- saving rejects to file 
  drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej
 
 The patch failed, but it shouldn't have. Have you done a 'git bisect reset' 
 since we finished the 
 bisecting? That would be a problem. Just in case, do the following:
 
 git bisect reset
 git checkout -f
 git pull
 
 Then apply the patch. If you get any REJECTS, please let me know. I'll hold 
 off on analyzing those 
 assertions until the code is in a known state.

Yeah, your tree is still unclean.
After cleaning it you can verify if it's clean by inspecting
the output of
git status
and
git diff

status should _not_ talk about modified files
or something like that. diff should output nothing.
A clean tree looks like this:

[EMAIL PROTECTED]:~/develop/git/wireless-dev$ git status
nothing to commit
[EMAIL PROTECTED]:~/develop/git/wireless-dev$ git diff
[EMAIL PROTECTED]:~/develop/git/wireless-dev$ 

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Ehud Gavron

[EMAIL PROTECTED] test]# git status
# On branch master
# Untracked files:
#   (use git add file... to include in what will be committed)
#
#   arch/x86_64/vdso/vdso.lds
nothing added to commit but untracked files present (use git add to track)
[EMAIL PROTECTED] test]# git diff
[EMAIL PROTECTED] test]#


Michael Buesch wrote:

On Wednesday 08 August 2007 18:11:03 Larry Finger wrote:
  
[EMAIL PROTECTED] test]# patch -p1  patch-2007-aug-08-lfinger.txt 
patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c

Hunk #1 FAILED at 1503.
Hunk #2 FAILED at 1512.
2 out of 2 hunks FAILED -- saving rejects to file 
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej
  
The patch failed, but it shouldn't have. Have you done a 'git bisect reset' since we finished the 
bisecting? That would be a problem. Just in case, do the following:


git bisect reset
git checkout -f
git pull

Then apply the patch. If you get any REJECTS, please let me know. I'll hold off on analyzing those 
assertions until the code is in a known state.



Yeah, your tree is still unclean.
After cleaning it you can verify if it's clean by inspecting
the output of
git status
and
git diff

status should _not_ talk about modified files
or something like that. diff should output nothing.
A clean tree looks like this:

[EMAIL PROTECTED]:~/develop/git/wireless-dev$ git status
nothing to commit
[EMAIL PROTECTED]:~/develop/git/wireless-dev$ git diff
[EMAIL PROTECTED]:~/develop/git/wireless-dev$ 

  


smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote:
 [EMAIL PROTECTED] test]# git status
 # On branch master
 # Untracked files:
 #   (use git add file... to include in what will be committed)
 #
 #   arch/x86_64/vdso/vdso.lds
 nothing added to commit but untracked files present (use git add to track)
 [EMAIL PROTECTED] test]# git diff
 [EMAIL PROTECTED] test]#
 


Larry, your patch is broken

[EMAIL PROTECTED]:~/develop/git/wireless-dev$ patch -p1 xxx.patch 
patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
Hunk #1 FAILED at 1503.
Hunk #2 FAILED at 1512.
2 out of 2 hunks FAILED -- saving rejects to file 
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Larry Finger
Michael Buesch wrote:
 On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote:
 [EMAIL PROTECTED] test]# git status
 # On branch master
 # Untracked files:
 #   (use git add file... to include in what will be committed)
 #
 #   arch/x86_64/vdso/vdso.lds
 nothing added to commit but untracked files present (use git add to track)
 [EMAIL PROTECTED] test]# git diff
 [EMAIL PROTECTED] test]#

 
 
 Larry, your patch is broken
 
 [EMAIL PROTECTED]:~/develop/git/wireless-dev$ patch -p1 xxx.patch 
 patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
 Hunk #1 FAILED at 1503.
 Hunk #2 FAILED at 1512.
 2 out of 2 hunks FAILED -- saving rejects to file 
 drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej
 

The white space must have been garbled. When it didn't apply, Ehud contacted me 
privately and I sent 
him the patch file as an attachment. It has applied cleanly and is now 
compiling.

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Ehud Gavron
The corrected patch shows the same results.  I have a 2.6.23-rc2 kernel 
where bcm43xx_mac80211 receives garbage.


Ehud

Larry Finger wrote:

Michael Buesch wrote:

On Wednesday 08 August 2007 18:24:14 Ehud Gavron wrote:

[EMAIL PROTECTED] test]# git status
# On branch master
# Untracked files:
#   (use git add file... to include in what will be committed)
#
#   arch/x86_64/vdso/vdso.lds
nothing added to commit but untracked files present (use git add 
to track)

[EMAIL PROTECTED] test]# git diff
[EMAIL PROTECTED] test]#




Larry, your patch is broken

[EMAIL PROTECTED]:~/develop/git/wireless-dev$ patch -p1 xxx.patch patching 
file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c

Hunk #1 FAILED at 1503.
Hunk #2 FAILED at 1512.
2 out of 2 hunks FAILED -- saving rejects to file 
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej




The white space must have been garbled. When it didn't apply, Ehud 
contacted me privately and I sent him the patch file as an attachment. 
It has applied cleanly and is now compiling.


Larry


smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Larry Finger
Ehud Gavron wrote:
 The corrected patch shows the same results.  I have a 2.6.23-rc2 kernel 
 where bcm43xx_mac80211 receives garbage.

Mumble, mumble, swear words,.

OK, back to the drawing board. Was this test with BCM43XX_DEBUG on or off?

Larry

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 19:46:33 Ehud Gavron wrote:
 The corrected patch shows the same results.  I have a 2.6.23-rc2 kernel 
 where bcm43xx_mac80211 receives garbage.

Please enable almost every option under Kernel Hacking.
Especially those to detect memory corruption.
But also the lock debugging stuff.
When done, reproduce.

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Ehud Gavron

Patch with debug on or off both fail.

I'm unable to apply Michael's patch to either a virgin test or virgin 
wireless-dev tree (I rm -rf'd both and re git clone'd them)


[EMAIL PROTECTED] test]# patch -p1  
~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch

patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n] y
Hunk #1 FAILED at 3018.
1 out of 1 hunk FAILED -- saving rejects to file 
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej

[EMAIL PROTECTED] test]# cd ../wireless-dev
[EMAIL PROTECTED] wireless-dev]# patch -p1  
~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch

patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] y
Hunk #1 FAILED at 3018.
1 out of 1 hunk FAILED -- saving rejects to file 
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej


I can do this all day long.  It's much more fun than dissecting the 
original commit and doing it step by step.


Ehud

Larry Finger wrote:

Ehud Gavron wrote:
  
The corrected patch shows the same results.  I have a 2.6.23-rc2 kernel 
where bcm43xx_mac80211 receives garbage.



Mumble, mumble, swear words,.

OK, back to the drawing board. Was this test with BCM43XX_DEBUG on or off?

Larry

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Larry Finger

Ehud Gavron wrote:

Patch with debug on or off both fail.

I'm unable to apply Michael's patch to either a virgin test or virgin 
wireless-dev tree (I rm -rf'd both and re git clone'd them)


It works here. Again there must be a white-space problem with the patch. A 
working version is attached.

Larry

Subject: bcm43xx-mac80211: Reorder starting of wireless core.

Reorder the starting of the wireless core.
First set the we are ready to go status and then poke operation.

Signed-off-by: Michael Buesch [EMAIL PROTECTED]

Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c  
2007-08-08 19:32:05.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c   
2007-08-08 20:10:36.0 +0200
@@ -3086,13 +3086,18 @@ static int bcm43xx_wireless_core_start(s
   dev-dev-irq);
goto out;
}
+
+   /* We are ready to run. */
+   bcm43xx_set_status(dev, BCM43xx_STAT_STARTED);
+
+   /* Start data flow (TX/RX). */
bcm43xx_mac_enable(dev);
+   bcm43xx_interrupt_enable(dev, dev-irq_savedstate);
+   ieee80211_start_queues(dev-wl-hw);
 
+   /* Start maintainance work */
bcm43xx_periodic_tasks_setup(dev);
 
-   ieee80211_start_queues(dev-wl-hw);
-   bcm43xx_set_status(dev, BCM43xx_STAT_STARTED);
-   bcm43xx_interrupt_enable(dev, dev-irq_savedstate);
bcmdbg(dev-wl, Wireless interface started\n);
 out:
return err;

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 21:56:24 Ehud Gavron wrote:
 Patch with debug on or off both fail.
 
 I'm unable to apply Michael's patch to either a virgin test or virgin 
 wireless-dev tree (I rm -rf'd both and re git clone'd them)
 
 [EMAIL PROTECTED] test]# patch -p1  
 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch
 patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
 Reversed (or previously applied) patch detected!  Assume -R? [n]

John just pushed the IRQ patch upstream.

Please try my patch that I just sent.
This one:
http://bu3sch.de/patches/wireless-dev/20070808-1186596983/patches/bcm43xx-mac80211-start-queues-after-setting-status.patch

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Larry Finger
Ehud Gavron wrote:
 Patch with debug on or off both fail.
 
 I'm unable to apply Michael's patch to either a virgin test or virgin 
 wireless-dev tree (I rm -rf'd both and re git clone'd them)
 
 [EMAIL PROTECTED] test]# patch -p1  
 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch
 patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
 Reversed (or previously applied) patch detected!  Assume -R? [n]
 Apply anyway? [n] y
 Hunk #1 FAILED at 3018.
 1 out of 1 hunk FAILED -- saving rejects to file 
 drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej
 [EMAIL PROTECTED] test]# cd ../wireless-dev
 [EMAIL PROTECTED] wireless-dev]# patch -p1  
 ~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch
 patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c

No, you got the wrong patch. That one was previously applied, which is what the 
error message is 
saying. In any case, apply the one I just sent. BTW, it isn't necessart to 
repull the tree to get a 
clean version. That is what 'git checkout -f' does.

Larry

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Ehud Gavron
Re git checkout -f... that's what I thought but when I kept getting the 
patch was previously applied... I figured I'd just clean it out.  Costs 
me 30 minutes of compile/link time, but it's nice'd out of the way.


The new patch (that was attached by you, and that Michael re-referenced) 
applied, and it is now building.  Should have results in 35m.


Thanks

Ehud

Larry Finger wrote:

Ehud Gavron wrote:
  

Patch with debug on or off both fail.

I'm unable to apply Michael's patch to either a virgin test or virgin 
wireless-dev tree (I rm -rf'd both and re git clone'd them)


[EMAIL PROTECTED] test]# patch -p1  
~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch

patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n] y
Hunk #1 FAILED at 3018.
1 out of 1 hunk FAILED -- saving rejects to file 
drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c.rej

[EMAIL PROTECTED] test]# cd ../wireless-dev
[EMAIL PROTECTED] wireless-dev]# patch -p1  
~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch

patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c



No, you got the wrong patch. That one was previously applied, which is what the error message is 
saying. In any case, apply the one I just sent. BTW, it isn't necessart to repull the tree to get a 
clean version. That is what 'git checkout -f' does.


Larry

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: Port of bcm43xx from softmac to mac80211 is available for testing

2007-08-08 Thread Richard Jonsson
On Monday 06 August 2007 03:21:11 you wrote:
 Richard Jonsson wrote:
  Isn't Desired TX power supposed to adapt so that higher bitrates are
  possible, with Bit Rate going lower if that is not enough to keep a good
  connection?

 Richard,

 Please grab a new copy of the port_to_mac80211 patch, and try the patch
 below. It boosts the desired power by up to 5 dBm as signal - noise
 decreases from 20 to 0.

 Larry

Hard to say if there is a difference. I've noticed that signal quality changes 
between reboots. When I first tried this patch I couldn't get above 36M even 
at the AP, so I loaded the version without the patch. Same thing.
So I rebooted and then all rates worked, even 11M. Even for the driver version 
that didn't work a few days ago.

New/updated observations:
Rate scaling seems to work, but if it gets down to 1M it will not rise again 
unless I force it to a higher bitrate and run iperf for a few seconds before 
setting it to auto. This is even when signal is -5dBm and noise is -80dBm. I 
get a feeling it's a bit to sensitive as it will drop quickly at a few meters 
away. At this distance forced 54M still works well.
Maybe this is due to small dips (0.5sec) in traffic flow?!

With the patch applied power is reported as 27dB in debugfs. With 
debug_xmitpower dmesg reports desired power to be 16.5 and actual 16.25. This 
is max when I manually set power through debugfs. After a while it's down to 
10dB, even though only 1M works where I sit.

Range seems to be higher for B-rates. Maybe this is just how things are, I 
lack experience.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


[patch 0/9] New patch series for merge

2007-08-08 Thread Michael Buesch
Hi John,

This patch series catches wireless-dev up to my
current wireless-development patchset.

Please merge this into wireless-dev.


--

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


[patch 2/9] bcm43xx-mac80211: Fix handling of failure to create debugfs directory

2007-08-08 Thread Michael Buesch
From: Pavel Roskin [EMAIL PROTECTED]

This can happen if CONFIG_BCM43XX_MAC80211_DEBUG is enabled, but
CONFIG_DEBUG_FS is not.

Debugging message added by Michael Buesch.

Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]

Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c   
2007-08-08 22:09:48.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
2007-08-08 22:17:03.0 +0200
@@ -408,7 +408,7 @@ static struct file_operations restart_fo
 
 int bcm43xx_debug(struct bcm43xx_wldev *dev, enum bcm43xx_dyndbg feature)
 {
-   return !!(dev-dfsentry-dyn_debug[feature]);
+   return !!(dev-dfsentry  dev-dfsentry-dyn_debug[feature]);
 }
 
 static void bcm43xx_remove_dynamic_debug(struct bcm43xx_wldev *dev)
@@ -472,7 +472,14 @@ void bcm43xx_debugfs_add_device(struct b
snprintf(devdir, sizeof(devdir), %s, wiphy_name(dev-wl-hw-wiphy));
e-subdir = debugfs_create_dir(devdir, fs.root);
if (!e-subdir || IS_ERR(e-subdir)) {
-   e-subdir = NULL;
+   if (e-subdir == ERR_PTR(-ENODEV)) {
+   bcmdbg(dev-wl, DebugFS (CONFIG_DEBUG_FS) not 
+  enabled in kernel config\n);
+   } else {
+   bcmerr(dev-wl, debugfs: cannot create %s directory\n,
+  devdir);
+   }
+   dev-dfsentry = NULL;
kfree(log-log);
kfree(e);
return;
@@ -525,6 +532,8 @@ void bcm43xx_debugfs_log_txstat(struct b
struct bcm43xx_txstatus *cur;
int i;
 
+   if (!e)
+   return;
log = e-txstatlog;
assert(irqs_disabled());
spin_lock(log-lock);

--

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


[patch 8/9] bcm43xx-mac80211: Reorder starting of wireless core.

2007-08-08 Thread Michael Buesch
Reorder the starting of the wireless core.
First set the we are ready to go status and then poke operation.

Signed-off-by: Michael Buesch [EMAIL PROTECTED]

Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c  
2007-08-08 22:17:24.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c   
2007-08-08 22:17:29.0 +0200
@@ -3086,13 +3086,18 @@ static int bcm43xx_wireless_core_start(s
   dev-dev-irq);
goto out;
}
+
+   /* We are ready to run. */
+   bcm43xx_set_status(dev, BCM43xx_STAT_STARTED);
+
+   /* Start data flow (TX/RX). */
bcm43xx_mac_enable(dev);
+   bcm43xx_interrupt_enable(dev, dev-irq_savedstate);
+   ieee80211_start_queues(dev-wl-hw);
 
+   /* Start maintainance work */
bcm43xx_periodic_tasks_setup(dev);
 
-   ieee80211_start_queues(dev-wl-hw);
-   bcm43xx_set_status(dev, BCM43xx_STAT_STARTED);
-   bcm43xx_interrupt_enable(dev, dev-irq_savedstate);
bcmdbg(dev-wl, Wireless interface started\n);
 out:
return err;

--

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


[patch 4/9] bcm43xx-mac80211: Remove assert() define and use WARN_ON()

2007-08-08 Thread Michael Buesch
Remove our own assert() definition and use the standard kernel WARN_ON().

Signed-off-by: Michael Buesch [EMAIL PROTECTED]

Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h   
2007-08-08 22:16:56.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08-08 22:17:10.0 +0200
@@ -23,6 +23,13 @@
 #include bcm43xx_phy.h
 
 
+#ifdef CONFIG_BCM43XX_MAC80211_DEBUG
+# define BCM43xx_DEBUG 1
+#else
+# define BCM43xx_DEBUG 0
+#endif
+
+
 #define BCM43xx_IRQWAIT_MAX_RETRIES50
 
 #define BCM43xx_IO_SIZE8192
@@ -434,25 +441,6 @@ enum {
 };
 
 
-#ifdef assert
-# undef assert
-#endif
-#ifdef CONFIG_BCM43XX_MAC80211_DEBUG
-# define assert(expr) \
-   do {\
-   if (unlikely(!(expr))) {\
-   printk(KERN_ERR KBUILD_MODNAME :  \
-  ASSERTION FAILED (%s) at: %s:%d:%s()\n,\
-   #expr, __FILE__, __LINE__, __FUNCTION__);   \
-   }   \
-   } while (0)
-# define BCM43xx_DEBUG 1
-#else
-# define assert(expr)  do { /* nothing */ } while (0)
-# define BCM43xx_DEBUG 0
-#endif
-
-
 struct net_device;
 struct pci_dev;
 struct bcm43xx_dmaring;
@@ -853,6 +841,15 @@ void bcmdbg(struct bcm43xx_wl *wl, const
 # define bcmdbg(wl, fmt...) do { /* nothing */ } while (0)
 #endif /* DEBUG */
 
+/* A WARN_ON variant that vanishes when bcm43xx debugging is disabled.
+ * This _also_ evaluates the arg with debugging disabled. */
+#if BCM43xx_DEBUG
+# define BCM43xx_WARN_ON(x)WARN_ON(x)
+#else
+static inline bool __bcm43xx_warn_on_dummy(bool x) { return x; }
+# define BCM43xx_WARN_ON(x)__bcm43xx_warn_on_dummy(unlikely(!!(x)))
+#endif
+
 
 /** Limit a value between two limits */
 #ifdef limit_value
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c   
2007-08-08 22:17:03.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_debugfs.c
2007-08-08 22:17:10.0 +0200
@@ -448,7 +448,7 @@ void bcm43xx_debugfs_add_device(struct b
struct bcm43xx_txstatus_log *log;
char devdir[16];
 
-   assert(dev);
+   BCM43xx_WARN_ON(!dev);
e = kzalloc(sizeof(*e), GFP_KERNEL);
if (!e) {
bcmerr(dev-wl, debugfs: add device OOM\n);
@@ -535,7 +535,7 @@ void bcm43xx_debugfs_log_txstat(struct b
if (!e)
return;
log = e-txstatlog;
-   assert(irqs_disabled());
+   BCM43xx_WARN_ON(!irqs_disabled());
spin_lock(log-lock);
i = log-end + 1;
if (i == BCM43xx_NR_LOGGED_TXSTATUS)
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c   
2007-08-08 22:09:48.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-08 22:17:10.0 +0200
@@ -67,7 +67,7 @@ static void op32_fill_descriptor(struct 
u32 addrext;
 
slot = (int)((desc-dma32) - descbase);
-   assert(slot = 0  slot  ring-nr_slots);
+   BCM43xx_WARN_ON(!(slot = 0  slot  ring-nr_slots));
 
addr = (u32)(dmaaddr  ~SSB_DMA_TRANSLATION_MASK);
addrext = (u32)(dmaaddr  SSB_DMA_TRANSLATION_MASK)
@@ -164,7 +164,7 @@ static void op64_fill_descriptor(struct 
u32 addrext;
 
slot = (int)((desc-dma64) - descbase);
-   assert(slot = 0  slot  ring-nr_slots);
+   BCM43xx_WARN_ON(!(slot = 0  slot  ring-nr_slots));
 
addrlo = (u32)(dmaaddr  0x);
addrhi = (((u64)dmaaddr  32)  ~SSB_DMA_TRANSLATION_MASK);
@@ -245,7 +245,7 @@ static inline int free_slots(struct bcm4
 
 static inline int next_slot(struct bcm43xx_dmaring *ring, int slot)
 {
-   assert(slot = -1  slot = ring-nr_slots - 1);
+   BCM43xx_WARN_ON(!(slot = -1  slot = ring-nr_slots - 1));
if (slot == ring-nr_slots - 1)
return 0;
return slot + 1;
@@ -253,7 +253,7 @@ static inline int next_slot(struct bcm43
 
 static inline int prev_slot(struct bcm43xx_dmaring *ring, int slot)
 {
-   assert(slot = 0  slot = ring-nr_slots - 1);
+   BCM43xx_WARN_ON(!(slot = 0  slot = ring-nr_slots - 1));
if (slot == 0)
return ring-nr_slots - 1;
return slot - 1;
@@ -287,9 +287,9 @@ int request_slot(struct bcm43xx_dmaring 
 {
int slot;
 
-   assert(ring-tx);
-   assert(!ring-stopped);
-   assert(free_slots(ring) != 0);
+   

[patch 6/9] bcm43xx-mac80211: Remove unneeded stuff from bcm43xx.h

2007-08-08 Thread Michael Buesch
Cleanup.

Signed-off-by: Michael Buesch [EMAIL PROTECTED]

Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h   
2007-08-08 22:17:10.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx.h
2007-08-08 22:17:20.0 +0200
@@ -1,20 +1,11 @@
 #ifndef BCM43xx_H_
 #define BCM43xx_H_
 
-#include linux/hw_random.h
 #include linux/kernel.h
 #include linux/spinlock.h
 #include linux/interrupt.h
-#include linux/stringify.h
-#include linux/netdevice.h
-#include linux/pci.h
-#include asm/atomic.h
-#include asm/io.h
-
+#include linux/hw_random.h
 #include linux/ssb/ssb.h
-#include linux/ssb/ssb_driver_chipcommon.h
-
-#include linux/wireless.h
 #include net/mac80211.h
 
 #include bcm43xx_debugfs.h
@@ -30,10 +21,6 @@
 #endif
 
 
-#define BCM43xx_IRQWAIT_MAX_RETRIES50
-
-#define BCM43xx_IO_SIZE8192
-
 #define BCM43xx_RX_MAX_SSI 60
 
 /* MMIO offsets */
@@ -50,7 +37,6 @@
 #define BCM43xx_MMIO_DMA5_REASON   0x48
 #define BCM43xx_MMIO_DMA5_IRQ_MASK 0x4C
 #define BCM43xx_MMIO_MACCTL0x120
-#define BCM43xx_MMIO_STATUS_BITFIELD   0x120//TODO replace all instances by 
MACCTL
 #define BCM43xx_MMIO_STATUS2_BITFIELD  0x124
 #define BCM43xx_MMIO_GEN_IRQ_REASON0x128
 #define BCM43xx_MMIO_GEN_IRQ_MASK  0x12C
@@ -336,25 +322,6 @@ enum {
 #define BCM43xx_MACCTL_DISCPMQ 0x4000 /* Discard Power Management 
Queue */
 #define BCM43xx_MACCTL_GMODE   0x8000 /* G Mode */
 
-/* StatusBitField *///FIXME rename these all
-#define BCM43xx_SBF_MAC_ENABLED0x0001
-#define BCM43xx_SBF_2  0x0002 /*FIXME: fix name*/
-#define BCM43xx_SBF_CORE_READY 0x0004
-#define BCM43xx_SBF_4000x0400 /*FIXME: fix name*/
-#define BCM43xx_SBF_4000   0x4000 /*FIXME: fix name*/
-#define BCM43xx_SBF_8000   0x8000 /*FIXME: fix name*/
-#define BCM43xx_SBF_XFER_REG_BYTESWAP  0x0001
-#define BCM43xx_SBF_MODE_NOTADHOC  0x0002
-#define BCM43xx_SBF_MODE_AP0x0004
-#define BCM43xx_SBF_RADIOREG_LOCK  0x0008
-#define BCM43xx_SBF_MODE_MONITOR   0x0040
-#define BCM43xx_SBF_MODE_PROMISC   0x0100
-#define BCM43xx_SBF_PS10x0200
-#define BCM43xx_SBF_PS20x0400
-#define BCM43xx_SBF_NO_SSID_BCAST  0x0800
-#define BCM43xx_SBF_TIME_UPDATE0x1000
-#define BCM43xx_SBF_8000   0x8000 /*FIXME: fix name*/
-
 /* 802.11 core specific TM State Low flags */
 #define BCM43xx_TMSLOW_GMODE   0x2000 /* G Mode Enable */
 #define BCM43xx_TMSLOW_PLLREFSEL   0x0020 /* PLL Frequency Reference 
Select */
@@ -441,8 +408,6 @@ enum {
 };
 
 
-struct net_device;
-struct pci_dev;
 struct bcm43xx_dmaring;
 struct bcm43xx_pioqueue;
 
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c  
2007-08-08 22:17:10.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c   
2007-08-08 22:17:20.0 +0200
@@ -263,12 +263,12 @@ void bcmdbg(struct bcm43xx_wl *wl, const
 
 static void bcm43xx_ram_write(struct bcm43xx_wldev *dev, u16 offset, u32 val)
 {
-   u32 status;
+   u32 macctl;
 
BCM43xx_WARN_ON(offset % 4 != 0);
 
-   status = bcm43xx_read32(dev, BCM43xx_MMIO_STATUS_BITFIELD);
-   if (status  BCM43xx_SBF_XFER_REG_BYTESWAP)
+   macctl = bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
+   if (macctl  BCM43xx_MACCTL_BE)
val = swab32(val);
 
bcm43xx_write32(dev, BCM43xx_MMIO_RAM_CONTROL, offset);
@@ -462,21 +462,24 @@ void bcm43xx_tsf_read(struct bcm43xx_wld
 
 static void bcm43xx_time_lock(struct bcm43xx_wldev *dev)
 {
-   u32 status;
+   u32 macctl;
 
-   status = bcm43xx_read32(dev, BCM43xx_MMIO_STATUS_BITFIELD);
-   status |= BCM43xx_SBF_TIME_UPDATE;
-   bcm43xx_write32(dev, BCM43xx_MMIO_STATUS_BITFIELD, status);
-   mmiowb();
+   macctl = bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
+   macctl |= BCM43xx_MACCTL_TBTTHOLD;
+   bcm43xx_write32(dev, BCM43xx_MMIO_MACCTL, macctl);
+   /* Commit the write */
+   bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
 }
 
 static void bcm43xx_time_unlock(struct bcm43xx_wldev *dev)
 {
-   u32 status;
+   u32 macctl;
 
-   status = bcm43xx_read32(dev, BCM43xx_MMIO_STATUS_BITFIELD);
-   status = ~BCM43xx_SBF_TIME_UPDATE;
-   bcm43xx_write32(dev, BCM43xx_MMIO_STATUS_BITFIELD, status);
+   macctl = bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
+   macctl = ~BCM43xx_MACCTL_TBTTHOLD;
+   bcm43xx_write32(dev, BCM43xx_MMIO_MACCTL, 

[patch 5/9] ssb: Remove verbose coreswitch printk

2007-08-08 Thread Michael Buesch
To: Andrew Morton [EMAIL PROTECTED]

This makes the verbose printk on every coreswitch dependent
on a default-off debugging variable.
Verbose coreswitch messages are only needed when debugging
strange crashes or machine check exceptions.

Signed-off-by: Michael Buesch [EMAIL PROTECTED]

Index: wireless-dev/drivers/ssb/pci.c
===
--- wireless-dev.orig/drivers/ssb/pci.c 2007-08-08 22:09:48.0 +0200
+++ wireless-dev/drivers/ssb/pci.c  2007-08-08 22:17:16.0 +0200
@@ -23,6 +23,10 @@
 #include ssb_private.h
 
 
+/* Define the following to 1 to enable a printk on each coreswitch. */
+#define SSB_VERBOSE_PCICORESWITCH_DEBUG0
+
+
 /* Lowlevel coreswitching */
 int ssb_pci_switch_coreidx(struct ssb_bus *bus, u8 coreidx)
 {
@@ -61,10 +65,12 @@ int ssb_pci_switch_core(struct ssb_bus *
int err;
unsigned long flags;
 
-   ssb_dprintk(KERN_INFO PFX
-   Switching to %s core, index %d\n,
-   ssb_core_name(dev-id.coreid),
-   dev-core_index);
+#if SSB_VERBOSE_PCICORESWITCH_DEBUG
+   ssb_printk(KERN_INFO PFX
+  Switching to %s core, index %d\n,
+  ssb_core_name(dev-id.coreid),
+  dev-core_index);
+#endif
 
spin_lock_irqsave(bus-bar_lock, flags);
err = ssb_pci_switch_coreidx(bus, dev-core_index);
Index: wireless-dev/drivers/ssb/pcmcia.c
===
--- wireless-dev.orig/drivers/ssb/pcmcia.c  2007-08-08 22:09:48.0 
+0200
+++ wireless-dev/drivers/ssb/pcmcia.c   2007-08-08 22:17:16.0 +0200
@@ -21,6 +21,10 @@
 #include ssb_private.h
 
 
+/* Define the following to 1 to enable a printk on each coreswitch. */
+#define SSB_VERBOSE_PCMCIACORESWITCH_DEBUG 0
+
+
 int ssb_pcmcia_switch_coreidx(struct ssb_bus *bus,
  u8 coreidx)
 {
@@ -91,10 +95,12 @@ int ssb_pcmcia_switch_core(struct ssb_bu
int err;
unsigned long flags;
 
-   ssb_dprintk(KERN_INFO PFX
-   Switching to %s core, index %d\n,
-   ssb_core_name(dev-id.coreid),
-   dev-core_index);
+#if SSB_VERBOSE_PCMCIACORESWITCH_DEBUG
+   ssb_printk(KERN_INFO PFX
+  Switching to %s core, index %d\n,
+  ssb_core_name(dev-id.coreid),
+  dev-core_index);
+#endif
 
spin_lock_irqsave(bus-bar_lock, flags);
err = ssb_pcmcia_switch_coreidx(bus, dev-core_index);

--

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


[patch 3/9] bcm43xx-mac80211: Add more help text for firmware failure

2007-08-08 Thread Michael Buesch
People won't read it, but hey. Let's do our best :)

Signed-off-by: Michael Buesch [EMAIL PROTECTED]

Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c  
2007-08-08 22:11:25.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c   
2007-08-08 22:17:06.0 +0200
@@ -1679,6 +1679,9 @@ static int bcm43xx_request_firmware(stru
 out:
return err;
 error:
+   bcmerr(dev-wl, You must go to 
+  
http://linuxwireless.org/en/users/Drivers/bcm43xx#devicefirmware 
+  and download the correct firmware (version 4)\n);
bcm43xx_release_firmware(dev);
goto out;
 err_noinitval:

--

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


[patch 9/9] bcm43xx-mac80211: Fix uninit-var warnings in lo.c

2007-08-08 Thread Michael Buesch
Fix uninitialized-var warnings in lo.c

Signed-off-by: Michael Buesch [EMAIL PROTECTED]

Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.c
2007-08-08 22:32:08.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.c 
2007-08-08 22:32:43.0 +0200
@@ -1028,7 +1028,7 @@ static inline void validate_all_loctls(s
 void bcm43xx_lo_g_measure(struct bcm43xx_wldev *dev)
 {
struct bcm43xx_phy *phy = dev-phy;
-   struct lo_g_saved_values sav;
+   struct lo_g_saved_values uninitialized_var(sav);
 
BCM43xx_WARN_ON((phy-type != BCM43xx_PHYTYPE_B) 
(phy-type != BCM43xx_PHYTYPE_G));

--

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


[patch 7/9] bcm43xx-mac80211: Remove power.c

2007-08-08 Thread Michael Buesch
power.c is not needed anymore. Move the only function
included in power.c into main.c.

Signed-off-by: Michael Buesch [EMAIL PROTECTED]

Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/Makefile
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/Makefile
2007-08-08 22:09:47.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/Makefile 2007-08-08 
22:17:24.0 +0200
@@ -10,7 +10,6 @@ bcm43xx-mac80211-obj-$(CONFIG_BCM43XX_MA
 bcm43xx-mac80211-objs := bcm43xx_main.o \
 bcm43xx_tables.o \
 bcm43xx_phy.o \
-bcm43xx_power.o \
 bcm43xx_sysfs.o \
 bcm43xx_leds.o \
 bcm43xx_xmit.o \
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c   
2007-08-08 22:17:10.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_dma.c
2007-08-08 22:17:24.0 +0200
@@ -31,7 +31,6 @@
 #include bcm43xx_dma.h
 #include bcm43xx_main.h
 #include bcm43xx_debugfs.h
-#include bcm43xx_power.h
 #include bcm43xx_xmit.h
 
 #include linux/dma-mapping.h
@@ -1499,7 +1498,7 @@ static void bcm43xx_dma_tx_resume_ring(s
 
 void bcm43xx_dma_tx_suspend(struct bcm43xx_wldev *dev)
 {
-   bcm43xx_power_saving_ctl_bits(dev, -1, 1);
+   bcm43xx_power_saving_ctl_bits(dev, BCM43xx_PS_AWAKE);
bcm43xx_dma_tx_suspend_ring(dev-dma.tx_ring0);
bcm43xx_dma_tx_suspend_ring(dev-dma.tx_ring1);
bcm43xx_dma_tx_suspend_ring(dev-dma.tx_ring2);
@@ -1516,5 +1515,5 @@ void bcm43xx_dma_tx_resume(struct bcm43x
bcm43xx_dma_tx_resume_ring(dev-dma.tx_ring2);
bcm43xx_dma_tx_resume_ring(dev-dma.tx_ring1);
bcm43xx_dma_tx_resume_ring(dev-dma.tx_ring0);
-   bcm43xx_power_saving_ctl_bits(dev, -1, -1);
+   bcm43xx_power_saving_ctl_bits(dev, 0);
 }
Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c  
2007-08-08 22:17:20.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c   
2007-08-08 22:17:24.0 +0200
@@ -46,7 +46,6 @@
 #include bcm43xx_phy.h
 #include bcm43xx_dma.h
 #include bcm43xx_pio.h
-#include bcm43xx_power.h
 #include bcm43xx_sysfs.h
 #include bcm43xx_xmit.h
 #include bcm43xx_sysfs.h
@@ -874,6 +873,66 @@ static void bcm43xx_clear_keys(struct bc
}
 }
 
+void bcm43xx_power_saving_ctl_bits(struct bcm43xx_wldev *dev,
+  unsigned int ps_flags)
+{
+   u32 macctl;
+   u16 ucstat;
+   bool hwps;
+   bool awake;
+   int i;
+
+   BCM43xx_WARN_ON((ps_flags  BCM43xx_PS_ENABLED) 
+   (ps_flags  BCM43xx_PS_DISABLED));
+   BCM43xx_WARN_ON((ps_flags  BCM43xx_PS_AWAKE) 
+   (ps_flags  BCM43xx_PS_ASLEEP));
+
+   if (ps_flags  BCM43xx_PS_ENABLED) {
+   hwps = 1;
+   } else if (ps_flags  BCM43xx_PS_DISABLED) {
+   hwps = 0;
+   } else {
+   //TODO: If powersave is not off and FIXME is not set and we are 
not in adhoc
+   //  and thus is not an AP and we are associated, set bit 25
+   }
+   if (ps_flags  BCM43xx_PS_AWAKE) {
+   awake = 1;
+   } else if (ps_flags  BCM43xx_PS_ASLEEP) {
+   awake = 0;
+   } else {
+   //TODO: If the device is awake or this is an AP, or we are 
scanning, or FIXME,
+   //  or we are associated, or FIXME, or the latest PS-Poll 
packet sent was
+   //  successful, set bit26
+   }
+
+/* FIXME: For now we force awake-on and hwps-off */
+hwps = 0;
+awake = 1;
+
+   macctl = bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
+   if (hwps)
+   macctl |= BCM43xx_MACCTL_HWPS;
+   else
+   macctl = ~BCM43xx_MACCTL_HWPS;
+   if (awake)
+   macctl |= BCM43xx_MACCTL_AWAKE;
+   else
+   macctl = ~BCM43xx_MACCTL_AWAKE;
+   bcm43xx_write32(dev, BCM43xx_MMIO_MACCTL, macctl);
+   /* Commit write */
+   bcm43xx_read32(dev, BCM43xx_MMIO_MACCTL);
+   if (awake  dev-dev-id.revision = 5) {
+   /* Wait for the microcode to wake up. */
+   for (i = 0; i  100; i++) {
+   ucstat = bcm43xx_shm_read16(dev, BCM43xx_SHM_SHARED,
+   BCM43xx_SHM_SH_UCODESTAT);
+   if (ucstat != BCM43xx_SHM_SH_UCODESTAT_SLEEP)
+   break;
+   udelay(10);
+   }
+   }
+}
+
 /* Turn the Analog ON/OFF */
 

Re: Port of bcm43xx from softmac to mac80211 is available for testing

2007-08-08 Thread Larry Finger
Richard Jonsson wrote:
 On Monday 06 August 2007 03:21:11 you wrote:
 Richard Jonsson wrote:
 Isn't Desired TX power supposed to adapt so that higher bitrates are
 possible, with Bit Rate going lower if that is not enough to keep a good
 connection?
 Richard,

 Please grab a new copy of the port_to_mac80211 patch, and try the patch
 below. It boosts the desired power by up to 5 dBm as signal - noise
 decreases from 20 to 0.

 Larry
 
 Hard to say if there is a difference. I've noticed that signal quality 
 changes 
 between reboots. When I first tried this patch I couldn't get above 36M even 
 at the AP, so I loaded the version without the patch. Same thing.
 So I rebooted and then all rates worked, even 11M. Even for the driver 
 version 
 that didn't work a few days ago.

That is scary! That may mean that something is not being reset. The real 
question is whether warm 
reboots are intrinsically different than cold (power-off) reboots.

 New/updated observations:
 Rate scaling seems to work, but if it gets down to 1M it will not rise again 
 unless I force it to a higher bitrate and run iperf for a few seconds before 
 setting it to auto. This is even when signal is -5dBm and noise is -80dBm. I 
 get a feeling it's a bit to sensitive as it will drop quickly at a few meters 
 away. At this distance forced 54M still works well.
 Maybe this is due to small dips (0.5sec) in traffic flow?!

I'm surprised that you get signal values as high as -5 dBm. My maximum is about 
-35. I'm usually in 
the -40 range, even at 2 m from the AP.

 With the patch applied power is reported as 27dB in debugfs. With 
 debug_xmitpower dmesg reports desired power to be 16.5 and actual 16.25. This 
 is max when I manually set power through debugfs. After a while it's down to 
 10dB, even though only 1M works where I sit.
 
 Range seems to be higher for B-rates. Maybe this is just how things are, I 
 lack experience.

The CCCK (B) encoding is much different than OFDM (G) transmissions. I would 
not be surprised to 
learn that its range were longer.

The power setting that comes from mac80211 is 27 dBm, which is completely bogus 
for what is supposed 
to be the FCC table. The regulatory limit is 20 dBm EIRP (a fancy acronym that 
means take the 
antenna into account). I've sent a fix for comment, but as is the usual case 
for mac80211, it will 
take several days or weeks to get a response. The maximum power that a bcm43xx 
device can use is 
encoded in the sprom. For most of them that quantity is 18.5 dBm, corresponding 
to the regulatory 
limit of 20 minus a safety factor of 1.5. I think that is there to prevent 
setting the power too 
high and flunking the certification tests. The output that goes to the radio is 
thus 18.5 less the 
gain of the antenna, which is also in the sprom with a usual value of 2 dBm. 
That is why you see the 
code setting a Desired power of 16.5 dBm.

Initially, I thought that the performance of my BCM4311 fell off as the power 
increased; however, 
that no longer happens. As a result, we can push full power at all times and 
there seems to be no 
need to use the kind of algorithm that you were testing. Don't tell the FCC, 
but we could relax that 
upper power limit as we will never try to get the device certified, but then we 
would use extra 
power, and run the risk of burning out the radio. If you decide to do that, 
please tell me the power 
setting at which it fried!

With the patches that were pushed into wireless-dev a few minutes ago, I 
suggest that you try 
bcm43xx-mac80211. It is getting at least as good, if not better, performance 
than the BCM4301 or the 
softmac port to mac80211 drivers do. We would also appreciate as much testing 
as possible as it will 
help getting it merged into mainstream. That driver will require V4 firmware.

Thanks for your report,

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Ehud Gavron

It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.

Ehud

Michael Buesch wrote:

On Wednesday 08 August 2007 21:56:24 Ehud Gavron wrote:
  

Patch with debug on or off both fail.

I'm unable to apply Michael's patch to either a virgin test or virgin 
wireless-dev tree (I rm -rf'd both and re git clone'd them)


[EMAIL PROTECTED] test]# patch -p1  
~gavron/bcm43xx-mac80211-fix-regression-in-interrupt-handling.patch

patching file drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c
Reversed (or previously applied) patch detected!  Assume -R? [n]



John just pushed the IRQ patch upstream.

Please try my patch that I just sent.
This one:
http://bu3sch.de/patches/wireless-dev/20070808-1186596983/patches/bcm43xx-mac80211-start-queues-after-setting-status.patch

  


smime.p7s
Description: S/MIME Cryptographic Signature
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote:
 It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.

What about enabling the Kernel Hacking options I suggested?

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 23:26:09 Michael Buesch wrote:
 On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote:
  It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.
 
 What about enabling the Kernel Hacking options I suggested?

On IRC was suggested that this might be a compiler bug
generating corrupt code.
Which compiler do you use? Can you upgrade or downgrade?

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Michael Buesch
On Wednesday 08 August 2007 23:26:09 Michael Buesch wrote:
 On Wednesday 08 August 2007 23:06:42 Ehud Gavron wrote:
  It doesn't fix the problem, either with BCM43XX_MAC80211_DEBUG=y or n.
 
 What about enabling the Kernel Hacking options I suggested?

On IRC was suggested that this might be a compiler bug
generating corrupt code.
Which compiler do you use? Can you upgrade or downgrade?

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


Re: 4311 works with fedora 7 but only at 1mb/s

2007-08-08 Thread John H.
I am using larry's .bz2 of bcm43xx and I get this ...

wlan0 IEEE 802.11b/g  ESSID:Network4Home  Nickname:Broadcom 4311
  Mode:Managed  Frequency=2.437 GHz  Access Point:blah
  Bit Rate=24 Mb/s   Tx-Power=18 dBm
  RTS thr:off   Fragment thr:off
  Link Quality=50/100  Signal level=-69 dBm  Noise level=-71 dBm
  Rx invalid nwid:0  Rx invalid crypt:11  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:0   Missed beacon:0


Is it possible to get 54mb/s?  Should I care if it's mainly for
residential cable modem right now?

On 8/8/07, John W. Linville [EMAIL PROTECTED] wrote:
 On Tue, Aug 07, 2007 at 07:57:03PM -0500, Larry Finger wrote:
  John H. wrote:
   Did I misunderstand something?  I thought some script was available or
   some easy way to use either bcm43xx or the new one.  brennan says he
   has a script to just let you use the newer driver with higher mbps,
   but I have never heard back from him.
  
 
  I have no idea what he is/was talking about. Until late yesterday, the best 
  performance was with the
  unaltered bcm43xx, or the port of that driver to mac80211. Today, the 
  changes now propagating
  through the system make bcm43xx-mac80211 into the preferred driver. You 
  should ask Fedora how soon
  those will make it into their development kernels (called Rawhide?).

 Probably tonight.  Maybe earlier if you watch Koji.

 John
 --
 John W. Linville
 [EMAIL PROTECTED]

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Joseph Jezak
Pavel Roskin wrote:
 On Mon, 2007-08-06 at 15:45 -0400, Will Dyson wrote:
 
 The spec is telling us to lookup an invalid index in the LO table.
 
 I see.  Thanks for your explanation!
 
 I think the way to solve it would be to see how the table is used in the
 proprietary driver.  Either the data from the extra entries is used, and
 we need to find out where it comes from, or there is an algorithm to
 limit the index to only access valid entries.
 
 I hope the reverse engineering team knows that.  I wish them good luck.
 

Oh, we're aware of the problem.  It's like I said before, it's one 
of the most complex parts of the driver and it's tough to document 
properly without just copying code to the documentation.  We'll get 
to it, but my time is kind of limited right now.

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


Re: 4311 works with fedora 7 but only at 1mb/s

2007-08-08 Thread Larry Finger
John H. wrote:
 I am using larry's .bz2 of bcm43xx and I get this ...
 
 wlan0 IEEE 802.11b/g  ESSID:Network4Home  Nickname:Broadcom 4311
   Mode:Managed  Frequency=2.437 GHz  Access Point:blah
   Bit Rate=24 Mb/s   Tx-Power=18 dBm
   RTS thr:off   Fragment thr:off
   Link Quality=50/100  Signal level=-69 dBm  Noise level=-71 dBm
   Rx invalid nwid:0  Rx invalid crypt:11  Rx invalid frag:0
   Tx excessive retries:0  Invalid misc:0   Missed beacon:0
 
 
 Is it possible to get 54mb/s?  Should I care if it's mainly for
 residential cable modem right now?

To get a setting of 54M, look at 'man iwconfig'. To get throughput at 54M, you 
need a different 
driver, and much better signal to noise! The highest residential cable rates in 
my area are 8Mbs 
down and 512Kbs up. Business rates ate 10 Mbs down and 2 Mbs up, but that costs 
a lot more. Your 24M 
setting should give you something in the range of 12Mbs throughput. You do the 
math.

Larry

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Larry Finger
Ehud,

I was just reviewing the complete dmesg output that you sent earlier, which I 
think was for a bad 
case. I use WPA encryption, which cannot be done in hardware, and I have not 
seen messages that look 
like this:

bcm43xx-phy0 debug: Using hardware based encryption for keyidx: 0, mac: 
ff:ff:ff:ff:ff:ff
eth1: Initial auth_alg=0
eth1: authenticate with AP 00:0d:88:ac:b2:2a
eth1: RX authentication from 00:0d:88:ac:b2:2a (alg=0 transaction=2 status=0)
eth1: authenticated
eth1: associate with AP 00:0d:88:ac:b2:2a
eth1: RX AssocResp from 00:0d:88:ac:b2:2a (capab=0x431 status=0 aid=1)
eth1: associated
eth1: switched to short barker preamble (BSSID=00:0d:88:ac:b2:2a)
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

In particular, I mean the hardware based encryption, and the short barker 
preamble messages.

Please boot a good kernel and save the dmesg output. Do the same for a bad 
kernel. Send the two 
sets of dmesg output, and iwconfig and ifconfig output for the bad one.

In the meantime, I'll configure my spare AP for WEP encryption and see what I 
get in my logs.

Thanks,

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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Larry Finger
Ehud Gavron wrote:
 good: rc1 git test tree with the commit in question reversed. Works fine.
 bad: rc2 git wireless-dev tree with Michael's latest patch.  Does not 
 work.
 
 full dmesg, iwconfig, and ifconfigs included.
 
 Like I said, I am happy to do this all day long so that I don't have to 
 personally revert that long patch.

With xconfig, select the Kernel hacking section, and turn off the Show 
timing info on printks. 
In addition, turn off Kobject debugging in that section. The latter option 
generates a lot of 
messages and overflows the dmesg buffer. Do a 'make -j3' and 'sudo make 
modules_install install'. 
You do not need to clean out the object files, or any other make options. Boot 
that kernel and send 
me it's dmesg.

One further question - Are you trying to connect to the same AP in both cases? 
The reason I'm asking 
is that the MAC address of the AP is different for the two cases.

Larry


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


Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken

2007-08-08 Thread Ehud Gavron
Understood.  Files attached.  This time I set the channel so that 
bcm43xx_mac80211(noworkie) would associate with the same AP that 
bcm43xx_mac80211(workie) does.


For infrastructure reference there are two APs on the LAN, and one has a 
WDS with a third AP.  All are Buffalo Airstations 54G.  All work fine 
with bcm43xx  ndiswrapper with bcmwl5.


See attached.

Ehud

Larry Finger wrote:

Ehud Gavron wrote:
  

good: rc1 git test tree with the commit in question reversed. Works fine.
bad: rc2 git wireless-dev tree with Michael's latest patch.  Does not 
work.


full dmesg, iwconfig, and ifconfigs included.

Like I said, I am happy to do this all day long so that I don't have to 
personally revert that long patch.



With xconfig, select the Kernel hacking section, and turn off the Show timing info on printks. 
In addition, turn off Kobject debugging in that section. The latter option generates a lot of 
messages and overflows the dmesg buffer. Do a 'make -j3' and 'sudo make modules_install install'. 
You do not need to clean out the object files, or any other make options. Boot that kernel and send 
me it's dmesg.


One further question - Are you trying to connect to the same AP in both cases? The reason I'm asking 
is that the MAC address of the AP is different for the two cases.


Larry


___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
  
Linux version 2.6.23-rc2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red 
Hat 4.1.2-12)) #2 SMP Wed Aug 8 20:36:34 MST 2007
Command line: ro root=LABEL=/ rhgb quiet
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f000 (usable)
 BIOS-e820: 0009f000 - 000a (reserved)
 BIOS-e820: 0010 - 7fe81400 (usable)
 BIOS-e820: 7fe81400 - 7ff0 (reserved)
 BIOS-e820: f000 - f4007000 (reserved)
 BIOS-e820: f4008000 - f400c000 (reserved)
 BIOS-e820: fed2 - feda (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 523905) 1 entries of 3200 used
end_pfn_map = 1043872
DMI 2.4 present.
ACPI: RSDP 000FC0B0, 0014 (r0 DELL  )
ACPI: RSDT 7FE8198A, 0044 (r1 DELLM07 27D60A0D ASL61)
ACPI: FACP 7FE82800, 0074 (r1 DELLM07 27D60A0D ASL61)
ACPI: DSDT 7FE83400, 4D7D (r1 INT430 SYSFexxx 1001 INTL 20050624)
ACPI: FACS 7FE91C00, 0040
ACPI: HPET 7FE82F00, 0038 (r1 DELLM071 ASL61)
ACPI: APIC 7FE83000, 0068 (r1 DELLM07 27D60A0D ASL47)
ACPI: ASF! 7FE82C00, 005B (r16 DELLM07 27D60A0D ASL61)
ACPI: MCFG 7FE82FC0, 003E (r16 DELLM07 27D60A0D ASL61)
ACPI: SLIC 7FE8309C, 0176 (r1 DELLM07 27D60A0D ASL61)
ACPI: TCPA 7FE83300, 0032 (r1 DELLM07 27D60A0D ASL61)
ACPI: SSDT 7FE81A11, 04DC (r1  PmRefCpuPm 3000 INTL 20050624)
No NUMA configuration found
Faking a node at -7fe81000
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 523905) 1 entries of 3200 used
Bootmem setup node 0 -7fe81000
No mptable found.
Zone PFN ranges:
  DMA 0 - 4096
  DMA324096 -  1048576
  Normal1048576 -  1048576
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0:0 -  159
0:  256 -   523905
On node 0 totalpages: 523808
  DMA zone: 96 pages used for memmap
  DMA zone: 2524 pages reserved
  DMA zone: 1379 pages, LIFO batch:0
  DMA32 zone: 12183 pages used for memmap
  DMA32 zone: 507626 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x8086a201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 8000 (gap: 7ff0:7010)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 435320 bytes of per cpu data
Built 1 zonelists in Node order.  Total pages: 509005
Policy zone: DMA32
Kernel command line: ro root=LABEL=/ rhgb quiet
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Marking TSC unstable due to TSCs unsynchronized
time.c: Detected