Re: Fwd: [PATCH] bcm43xx: (hopefully) fix watchdog timeouts.

[Michael Buesch]

Oh, damn crap. Please remove the words "fwd" and "hopefully"
from the subject.
Sorry for the inconvenience.

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

Easy, but valueable janitorial work

[Michael Buesch]

Hi,

Since reverse engineering efforts progressed a lot,
we need someone who can do easy janitorial work on the driver.
The work would be to replace existing hardcoded magic device
register values into now-known #defined constants.

If you are interrested in doing this, please contact me
before starting work.
Please work against my tree at
git clone http://bu3sch.de/git/wireless-dev.git
as that's latest available code.

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

Re: Easy, but valueable janitorial work

[Michael Buesch]

On Tuesday 24 October 2006 18:54, Johannes Berg wrote:
> On Tue, 2006-10-24 at 18:21 +0200, Michael Buesch wrote:
> 
> > Since reverse engineering efforts progressed a lot,
> > we need someone who can do easy janitorial work on the driver.
> > The work would be to replace existing hardcoded magic device
> > register values into now-known #defined constants.
> 
> Also, it might be useful to not just convert the register values but
> also the register names. What we used to call 'microcode flags' is
> called 'host flags' by broadcom and we adopted that for the v4 specs.

Yeah, I meant that. Sorry for the confusion.

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

Re: Fwd: [PATCH] bcm43xx: (hopefully) fix watchdog timeouts.

[Michael Buesch]

On Wednesday 25 October 2006 02:37, John W. Linville wrote:
> Michael,
> 
> It looks like you have a patch that I don't have, one that moves the
> netif_tx_disable and spin_lock_irqsave outside of the "if (badness >
> BADNESS_LIMIT)" conditional.
> 
> Could you pass that one along as well, or correct this patch to match
> what is in Linus' tree?

Well, I'm not sure who moved the tx_disable outside of the
conditional. It is not needed. We only need to disable TX on
the slowpath (the first branch of the if condition). It does not
hurt to disable it always, though.
But I will send a new patch against wireless-2.6, which only disables
TX for the slowpath and fakes a TX there.

But for Greg, the original patch is ok.
How was the stable mailing list again? [EMAIL PROTECTED] seems to bounce.

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

Please pull bcm43xx-d80211 features and bugfixes

[Michael Buesch]

Hi John,

Please pull latest bcm43xx-d80211 features and bugfixes.

git pull http://bu3sch.de/git/wireless-dev.git for-linville

This will introduce hardware encryption for everything
but TKIP on v4 firmware. For v3 firmware or TKIP it will
transparently fall back to software encryption.
It also fixes a bug that caused high CPU usage due to an IRQ
not stopping to trigger.


  bcm43xx-d80211: Fix runaway IRQ which caused high CPU usage.
  bcm43xx-d80211: Rename IRQs
  bcm43xx-d80211: Fix hardware based encryption for v4 firmware.
  bcm43xx-d80211: Use software encryption for TKIP for now.
  bcm43xx-d80211: No support for hw encryption with v3 firmware. Various 
hwenc fixes.
  bcm43xx-d80211: Only set USEDEFKEYS hostflag for WEP.

 drivers/net/wireless/d80211/bcm43xx/bcm43xx.h  |  103 +++-
 drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c |  488 +---
 drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.h |3 
 drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c |   93 +++-
 drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.h |2 
 5 files changed, 461 insertions(+), 228 deletions(-)

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

Re: Back On-line

[Michael Buesch]

On Friday 27 October 2006 18:01, Larry Finger wrote:
> That fix is 
> destined for both wireless-2.6 (and 2.6.19-rcX), and 2.6.18.Y (Y=2?).

I am doing a fix for wireless-2.6.
This fix will be a little bit more complex.
Current patch submitted to -stable fixes the problem, but also
modifies the watchdog behaviour. This is OK for -stable.
I am doing some testing at the moment and will submit the patch
for inclusion in wireless-2.6 afterwards.

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

Re: master mode support?

[Michael Buesch]

On Saturday 28 October 2006 09:16, Mike Mohr wrote:
> Hello,
> 
> I'd like to inquire about the status of master mode w.r.t the bcm43xxx
> driver.  I see that there was some noise about this on the mailing
> list some time ago, but it appears to be (from what I can tell)
> incomplete.

I don't think so. We implemented it and submitted the code
to wireless-dev. There we are. Last time I checked it worked for me.

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

Re: Null pointer error in wireless-dev

[Michael Buesch]

On Saturday 28 October 2006 02:55, Jeff Williams wrote:
> Hello, and thanks for the great driver!
> 
> For the past month of so, linville's wireless-dev has been crashing on
> bringing up bcm43xx_d80211 (unless of course I'm not understanding how git
> updates and I've been pulling it wrong). Until tonight, when I finally sat
> down and have figured out what was causing it, I had been using an old
> version of the git tree. The symptom of the problem I encounter is in
> bcm43xx_dma_handle_txstatus
> 
> while (1) {
> 
> assert(slot >= 0 && slot < ring->nr_slots);
> desc = ops->idx2desc(ring, slot, &meta);
> unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, 1);
> 
> at this point (in the second pass after startup, I believe) meta->skb is a
> null pointer. I can see in idx2desc that meta is a pointer to a ring in
> memory. What is the problem? Am I using a bad firmware? Is the driver not
> properly storing the skb pointer? Where would I look in the code to find
> the root of this problem?
> 
> I've fixed this temporarily by skipping unmap_descbuffer when meta->skb is
> 0, but I imagine that that is not a good idea.

Yep, that's a bug. I'll fix it and submit the fix to wireless-dev.

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

Re: 4311 without CC and/or PCI core?

[Michael Buesch]

On Saturday 28 October 2006 14:06, Johannes Berg wrote:
> On Sat, 2006-10-28 at 13:52 +0200, Tobias Diedrich wrote:
> 
> > is it possible to have bcm43xx-device without CC or PCI core?
> 
> yes. it isn't the case here though.
> 
> > on my WRT54GL v1.1 I get the following output
> 
> That is probably an ssb based one, not PCI. Did you define the config
> symbol for that? :)
> 
> > <7>ssb: Core 0 found: cc 0812, rev 09, vendor 4243
> > <7>ssb: Core 1 found: cc 0812, rev 09, vendor 4243
> > <7>ssb: Core 2 found: cc 0812, rev 09, vendor 4243
> > <7>ssb: Core 3 found: cc 0812, rev 09, vendor 4243
> > <7>ssb: Core 4 found: cc 0812, rev 09, vendor 4243
> > <7>ssb: Core 5 found: cc 0812, rev 09, vendor 4243
> > <7>ssb: Core 6 found: cc 0812, rev 09, vendor 4243
> > <7>ssb: Core 7 found: cc 0812, rev 09, vendor 4243
> 
> Like I said. This makes no sense at all. Core switching is different on
> ssb based systems. It (used to?) work(s) with the appropriate bcm64309
> config symbol defined. However, mb and nbd are working on porting the
> whole system code to ssb which will be much nicer anyway. Until then, I
> suggest you either explicitly state that you want to help with it, or
> just wait :)

On SSB based devices the SSB-BUS is the system bus.
That means the wireless "core" is _directly_ hooked up to
the system bus (which is PCI in normal systems).
I think that's the case for you here, too.
On the SSB-BUS we don't need to switch cores and can access
cores concurrently. It's a real (small) bus for embedded
devices. Some of these devices still have a PCI bus,
but that's bridged through a PCI core and only secondary.
So the SSB is still the main system bus.

If you are using broadcom's system code for the SSB, your
802.11 device will show up as PCI device, as this system
code will emulate a PCI device. Broadcom decided to implement
it this way to mostly re-use existing PCI drivers. I don't
think that's a good idea, as the drivers need modification
anyway, but that's another story. :) Our new ssb system code
tries to prevent these issues by being a real bus-driver.
It will drive the SSB-BUS like any other real bus (because
it _is_ a real bus). It will do so even on devices like PCI
wireless LAN cards, where the SSB-BUS is built into the chip.
So far we have been hable to boot with the code and Florian
was able to port b44 and was able to transmit data through
ethernet.

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

Please pull bcm43xx-d80211 bugfixes

[Michael Buesch]

Hi John,

Please
git pull http://bu3sch.de/git/wireless-dev.git for-linville

This will pull the following things since my last
pull request:

Michael Buesch:
  bcm43xx-d80211: Fix DMA engine TX buffer unmap crash.
  bcm43xx-d80211: Don't ignore return value of pci_enable_device()

 drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c  |7 ++-
 drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c |6 --
 2 files changed, 10 insertions(+), 3 deletions(-)


diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c 
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
index ac7b734..24fc47d 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -1102,6 +1102,7 @@ void bcm43xx_dma_handle_txstatus(struct 
 const struct bcm43xx_txstatus *status)
 {
const struct bcm43xx_dma_ops *ops;
+   struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
struct bcm43xx_dmaring *ring;
struct bcm43xx_dmadesc_generic *desc;
struct bcm43xx_dmadesc_meta *meta;
@@ -1116,7 +1117,11 @@ void bcm43xx_dma_handle_txstatus(struct 
assert(slot >= 0 && slot < ring->nr_slots);
desc = ops->idx2desc(ring, slot, &meta);
 
-   unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, 1);
+   if (meta->skb)
+   unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, 
1);
+   else
+   unmap_descbuffer(ring, meta->dmaaddr, phy->txhdr_size, 
1);
+
if (meta->is_last_fragment) {
/* Call back to inform the ieee80211 subsystem about the
 * status of the transmission.
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
index 1e857ca..813112e 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -4129,12 +4129,14 @@ static int bcm43xx_resume(struct pci_dev
 {
struct net_device *net_dev = pci_get_drvdata(pdev);
struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
-   int err = 0;
+   int err;
 
dprintk(KERN_INFO PFX "Resuming...\n");
 
pci_set_power_state(pdev, 0);
-   pci_enable_device(pdev);
+   err = pci_enable_device(pdev);
+   if (err)
+   return err;
pci_restore_state(pdev);
 
bcm43xx_chipset_attach(bcm);


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

Re: [PATCH] bcm43xx: Fix low-traffic netdev watchdog TX timeouts

[Michael Buesch]

On Sunday 29 October 2006 10:11, Hendrik Sattler wrote:
> Am Sonntag 29 Oktober 2006 09:50 schrieb Johannes Berg:
> > On Sun, 2006-10-29 at 09:19 +0100, Hendrik Sattler wrote:
> > > Is this patch also available for 2.6.18.x?
> >
> > quoting Larry:
> > "BTW, that simplified version has been sent to -stable."
> 
> Believe it or not but that simplified version (from Michael) does not fix it 
> for me:
> Oct 29 04:12:03 yavin kernel: SoftMAC: Start scanning with channel: 1
> Oct 29 04:12:03 yavin kernel: SoftMAC: Scanning 14 channels
> Oct 29 04:12:03 yavin kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> Oct 29 04:12:03 yavin kernel: bcm43xx: select_wireless_core: cleanup
> Oct 29 04:12:13 yavin kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> Oct 29 04:12:18 yavin kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> Oct 29 04:12:23 yavin kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> Oct 29 04:12:28 yavin kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> Oct 29 04:12:33 yavin kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> Oct 29 04:12:38 yavin kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> Oct 29 04:12:43 yavin kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> Oct 29 04:12:48 yavin kernel: NETDEV WATCHDOG: wlan0: transmit timed out
> 
> And this appears every five seconds. I did not reboot though, just manually 
> reloaded the bcm43xx driver with modprobe. I'll see how it behaves after a 
> complete reboot.

Complete dmesg with all debugging enabled, please.


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

Re: [PATCH] bcm43xx: Fix low-traffic netdev watchdog TX timeouts

[Michael Buesch]

On Sunday 29 October 2006 16:58, Hendrik Sattler wrote:
> Am Sonntag 29 Oktober 2006 14:30 schrieb Michael Buesch:
> > Complete dmesg with all debugging enabled, please.
> 
> $ grep DEBUG /boot/config-$(uname -r) | grep -v ^#
> CONFIG_IEEE80211_SOFTMAC_DEBUG=y
> CONFIG_BCM43XX_DEBUG=y
> CONFIG_DEBUG_BUGVERBOSE=y
> 
> Network configuration is done with network-manager.
> The entries are from the time on when I reloaded the driver to use the 
> patched 
> one (2.6.18.1+watchdog-fix).
> 
> I attached the /var/log/kern.log from that time.
> 
> It definitely is an improvement (before it would timeout every few hours).

Softmac is racing against your AP.
Softmac is known broken. Please try with devicescape 802.11 stack.

I don't know what happens at the time it resets the device. But
that is not the first bug that triggers. First it heavily races in softmac.

Try d80211. I really bet it will fix all your problems.

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

Re: bcm43xx stops passing traffic on FC6

[Michael Buesch]

On Sunday 29 October 2006 17:28, Gregory Gulik wrote:
> 
> I recently updated a compaq notebook to Fedora Core 6 which has the 
> bcm43xx driver in the 2.6.18 kernel.  I followed the instructions here:
> Installing Fedora Core 6 on Compaq Presario R3000Z 
> 
> 
> The chipset is:
> 02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g 
> Wireless LAN Controller (rev 03)
> 
> However, I'm having a problem where I lose network connectivity every 
> few hours.  The connection appears up it just doesn't pass packets.  I 
> can't ping my server or anything else for example.  I have to manually 
> "ifdown eth1 " and "ifup eth1" to get it working again.  I've put in a 
> cron job to check for this condition and fix it as needed because it's 
> so common.
> 
> There is no clear reason for this in dmesg or /var/log/messages.  dmesg 
> just has:
> 
> 
> SoftMAC: Authentication response received from 00:0b:6b:36:1e:43 but no 
> queue item exists.
> NETDEV WATCHDOG: eth1: transmit timed out
> bcm43xx: Controller RESET (TX timeout) ...
> bcm43xx: select_wireless_core: cleanup
> bcm43xx: Radio turned off
> bcm43xx: DMA-32 0x0200 (RX) max used slots: 28/64
> bcm43xx: DMA-32 0x02A0 (TX) max used slots: 0/512
> bcm43xx: DMA-32 0x0280 (TX) max used slots: 0/512
> bcm43xx: DMA-32 0x0260 (TX) max used slots: 0/512
> bcm43xx: DMA-32 0x0240 (TX) max used slots: 0/512
> bcm43xx: DMA-32 0x0220 (TX) max used slots: 49/512
> bcm43xx: DMA-32 0x0200 (TX) max used slots: 0/512
> bcm43xx: Microcode rev 0x123, pl 0x21 (2005-01-22  19:48:06)
> bcm43xx: Radio turned on
> bcm43xx: Chip initialized
> bcm43xx: 32-bit DMA initialized
> bcm43xx: Keys cleared
> bcm43xx: Selected 802.11 core (phytype 2)
> bcm43xx: Controller restarted
> 
> 
> That's prior to doing the ifdown/ifup thing.
> 
> Anything else I can try?

Please wait for 2.6.18.2 or try the patch posted here on the list.

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

Re: ASSERTION FAILED

[Michael Buesch]

On Tuesday 31 October 2006 07:45, nfrench wrote:
> Larry Finger wrote:
> > nfrench wrote:
> >> I have been tring to get my bcm43xx working with the following system
> >>
> >> amd_x64
> >> kernel 2.6.18.1
> >>
> >> patches
> >>
> >> patch_2.6.18.1_fix_leds
> >> patch_2.6.18.1_signal_quality
> >> patch_2.6.18.1_for_PCI-E
> >
> > Of the above patches, only signal quality has any effect on your 
> > system. If you were to get any NETDEV WATCHDOG TX timeouts, you should 
> > apply "patch_2.6.18.1_watchdog_timeout2" from the ftp location.
> >
> >> After a modprobe everything is fine but after bringing the interface 
> >> up I get ASSERTION errors and I cannot seem to see anything.
> >> I understand this is still under development so if I can be of any 
> >> help please ask away.
> >
> > Those radio attenuation assertions occur for _ALL_ 4318 chips. There 
> > is a known problem with the radio on that chip, which has not yet been 
> > fixed. Using the 4318 is particularly a problem in a noisy radio 
> > environment. If it is possible for you to change channels, please try 
> > another.
> >
> > Larry
> >
> "iwconfig eth1 channel 1" did the trick thanks.
> 
> Does the driver not support auto ? or is it planned.

An "auto" attribute for the channel value is pretty stupid.
There is nothing the driver can do, except selecting some random
channel automatically.
What you want is to set your SSID (iwconfig essid). It will
scan channels then. That's kind of auto. ;)

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

Re: ASSERTION FAILED

[Michael Buesch]

On Tuesday 31 October 2006 01:35, nfrench wrote:
> Thanks for comments so far up and working.
> 
> I have noticed that I am now getting the following messages
> 
>  APIC error on CPU0: 40(40)
> 
> while wireless is enabled, is this just noise from the wireless causing 
> the APIC to hicup ?

I saw these errors only on cheap crap mainboards.
It's some kind of CRC error for the APIC<->CPU bus.
These errors are not fatal, if they occur only now and
then, but replacing the mainboard usually fixes the issue.

Ah, and, this has nothing to do with wireless in particular.
It's just bad luck that your wireless card is able to trigger
this.

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

Re: [PATCH] bcm43xx: fix unexpected LED control values in BCM4303 sprom

[Michael Buesch]

On Wednesday 01 November 2006 05:34, Larry Finger wrote:
> John,
> 
> I had not responded to Michael's comments as I heard from another user with 
> thousands of these 
> assertions in his logs, and I have been waiting for his sprom values and 
> hoped to make a single 
> patch. It is good, however, that you pushed the patch upstream.
> 
> John W. Linville wrote:
> > On Wed, Oct 18, 2006 at 04:37:08PM +0200, Michael Buesch wrote:
> > 
> >>> @@ -257,7 +263,11 @@ void bcm43xx_leds_update(struct bcm43xx_
> >>>   continue;
> >>>  #endif /* CONFIG_BCM43XX_DEBUG */
> >>>   default:
> >>> - assert(0);
> >>> + if (bcm43xx_max_led_err) {
> >>> + printkl(KERN_INFO PFX "Bad value in 
> >>> leds_update,"
> >>> + " led->behaviour: 0x%x\n", 
> >>> led->behaviour);
> >>> + --bcm43xx_max_led_err;
> >>> + }
> >> I'd call this message bloat. ;) This is the first time the assertion
> >> triggers since it was added.
> >> You could instead remove the assert(), remove bcm43xx_max_led_err
> >> and use dprintkl instead of printkl.
> 
> I disagree with part of Michael's comments. I think we should have a dprintk, 
> rather than dprintkl, 

An unlimited printk will hang the system on UP.

> so that we get printouts from all four of the sprom values.

I don't really think that dprintkl will prevent this.

> That way the user will be able to report  
> the numbers we need. As this would not limit the log entries and potentially 
> generate thousands, 
> there should be a variable like bcm43xx_max_led_err to limit the number of 
> log entries.
> 
> I will propose a new patch once I get the data for the second case. In the 
> meantime, the patch you 
> have pushed upstream will fix the BCM4303 led assertions.

I still think it's a waste to add a variable, a printk and a long string which
all eat unswappable kernel memory for this cornercase.
I don't think it's really hard to tell somebody to execute "iwpriv ethX 
read_sprom"
when he reports the assert() is triggering.
You must communicate with him anyway to find out how the LEDs are mapped
to the physical descriptions on the device case.

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

Re: [RFC] bcm43xx: Removal of "badness" variable

[Michael Buesch]

On Wednesday 01 November 2006 21:30, Larry Finger wrote:
> Michael,
> 
> The "badness" variable and the concept of BADNESS_LIMIT were useful during 
> the debugging of the
> preemptible periodic work routines, but now that those problems seem to be 
> fixed, I propose
> simplifying that section of the code according to the patch below. I believe 
> the functionality to be
> identical to what was there before the patch. I expected the size of bcm43xx 
> to be smaller, but on
> i386, at least, the reduction does not cross a page boundary. It does, 
> however, give us a little
> more headroom before we cross that next boundary.

I don't care. You're the maintainer.

> Larry
> 
> 
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -3192,55 +3192,27 @@ static void bcm43xx_periodic_every15sec(
> 
>   static void do_periodic_work(struct bcm43xx_private *bcm)
>   {
> - unsigned int state;
> -
> - state = bcm->periodic_state;
> - if (state % 8 == 0)
> + if (bcm->periodic_state % 8 == 0)
>   bcm43xx_periodic_every120sec(bcm);
> - if (state % 4 == 0)
> + if (bcm->periodic_state % 4 == 0)
>   bcm43xx_periodic_every60sec(bcm);
> - if (state % 2 == 0)
> + if (bcm->periodic_state % 2 == 0)
>   bcm43xx_periodic_every30sec(bcm);
> - if (state % 1 == 0)
> - bcm43xx_periodic_every15sec(bcm);
> - bcm->periodic_state = state + 1;
> + bcm43xx_periodic_every15sec(bcm);
> 
>   schedule_delayed_work(&bcm->periodic_work, HZ * 15);
>   }
> 
> -/* Estimate a "Badness" value based on the periodic work
> - * state-machine state. "Badness" is worse (bigger), if the
> - * periodic work will take longer.
> - */
> -static int estimate_periodic_work_badness(unsigned int state)
> -{
> - int badness = 0;
> -
> - if (state % 8 == 0) /* every 120 sec */
> - badness += 10;
> - if (state % 4 == 0) /* every 60 sec */
> - badness += 5;
> - if (state % 2 == 0) /* every 30 sec */
> - badness += 1;
> - if (state % 1 == 0) /* every 15 sec */
> - badness += 1;
> -
> -#define BADNESS_LIMIT4
> - return badness;
> -}
> -
>   static void bcm43xx_periodic_work_handler(void *d)
>   {
>   struct bcm43xx_private *bcm = d;
>   struct net_device *net_dev = bcm->net_dev;
>   unsigned long flags;
>   u32 savedirqs = 0;
> - int badness;
>   unsigned long orig_trans_start = 0;
> 
>   mutex_lock(&bcm->mutex);
> - badness = estimate_periodic_work_badness(bcm->periodic_state);
> - if (badness > BADNESS_LIMIT) {
> + if (unlikely(bcm->periodic_state % 4 == 0)) {
>   /* Periodic work will take a long time, so we want it to
>* be preemtible.
>*/
> @@ -3272,7 +3244,7 @@ static void bcm43xx_periodic_work_handle
> 
>   do_periodic_work(bcm);
> 
> - if (badness > BADNESS_LIMIT) {
> + if (unlikely(bcm->periodic_state % 4 == 0)) {
>   spin_lock_irqsave(&bcm->irq_lock, flags);
>   tasklet_enable(&bcm->isr_tasklet);
>   bcm43xx_interrupt_enable(bcm, savedirqs);
> @@ -3283,6 +3255,7 @@ static void bcm43xx_periodic_work_handle
>   net_dev->trans_start = orig_trans_start;
>   }
>   mmiowb();
> + bcm->periodic_state++;
>   spin_unlock_irqrestore(&bcm->irq_lock, flags);
>   mutex_unlock(&bcm->mutex);
>   }
> 
> 
> ---
> 

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

Re: [RFC] Update to power control function for b/g phys

[Michael Buesch]

On Thursday 02 November 2006 17:44, Danny van Dyk wrote:
> Hi guys,
> 
> as I'm a bit out of work on this, I'd like to post this patch as RFC first. It
> brings the power control routine on par with
> 
>   http://bcm-specs.sipsolutions.net/InitPowerControl
> 
> but it contains a huge FIXME() where specs aren't as clear as I'd like them.
> Johannes, Joseph: Can you both have a look at
> 
>   http://bcm-specs.sipsolutions.net/GPHY_DC_Lookup_Table
> 
> please? Following your specs, the code needed to loop of a RF Attenuation
> list of 7 elements, as we obviously do support HW Power Control at this point.
> Now, with 7 elements if RF and 9 in baseband attenuation, this makes 63 LO
> pairs. However, we only have 56 = 14 * 4 pairs available. (If i'm not 
> mistaken,
> that is :-)

Please look at the new LO code in my development tree.
It was rewritten and semantics changed a lot.
It's also possible that I already implemented bits of your
patch below in my tree. But I did not compare it.

But please don't try to merge this patch upstream through
John. It will result in horrible rejects in my tree, as I'm
rewriting PHY stuff there. Please prepare a patch which applies
to my tree (which still should be easy. But it will get harder
the more I change).

> Danny
> ---
> diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_phy.c 
> b/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
> index 52ce2a9..e49acfe 100644
> --- a/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
> @@ -190,7 +190,70 @@ out:
>   return 0;
>  }
>  
> -/* intialize B PHY power control
> +static inline
> +void bcm43xx_gphy_init_plt(struct bcm43xx_private *bcm)
> +{
> + int i;
> + u16 val;
> +
> + for (i = 0; i < 32; i++)
> + bcm43xx_ilt_write(bcm, 0x32C0 + i, bcm43xx_tssi2dbm_g_table[i]);
> +
> + for (i = 0; i < 32; i++)
> + bcm43xx_ilt_write(bcm, 0x3C00 + i, bcm43xx_tssi2dbm_g_table[i + 
> 32]);
> +
> + for (i = 0; i < 64; i++) {
> + val = (u8)bcm43xx_tssi2dbm_b_table[i];
> + val <<= 8;
> + val |= (u8)bcm43xx_tssi2dbm_g_table[i];

Ehm, what is this code supposed to do? It assgnes "val"
several times and throws the result away.
And is it right to mix b_table and g_table?

> + }
> +}
> +
> +static inline
> +struct bcm43xx_lopair * bcm43xx_current_lopair(struct bcm43xx_private *bcm);
> +
> +static inline
> +void bcm43xx_gphy_init_glt(struct bcm43xx_private *bcm)
> +{
> + struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
> + static const u8 rf_att_table[14] = {
> + 2,  4,  6,  8, 10, 12, 14, // 2050 radio, rev 8
> + 0,  2,  4,  6,  8,  9,  9  // otherwise
> + };

I think this table already is implemented in a slightly different
way in my code.

> +
> + unsigned count = 0, i, j, rf_offset;
> + u16 val, set = (radio->rev == 8) ? 0x50 : 0x40;
> +
> + if (bcm43xx_current_lopair(bcm)->used) {
> + //XXX: ^^^ Correct way to check if LO has been measured?

No, I think we have a flag for that in struct bcm43xx_txpower_lo_control
(look at my tree). This flag has been moved from the old bcm43xx_phyinfo.

> + rf_offset = ((radio->version == 0x2050) && (radio->rev == 8)) ? 
> 7 : 0;
> + for (i = 0; i < 7; i++) {
> + for (j = 0; j < 9; j++) {
> + if (count >= 64)
> + goto out;
> + val = j << 8;
> + val |= set;
> + val |= rf_att_table[i + rf_offset];
> + bcm43xx_phy_write(bcm, 0x3C0 + count, val);
> + count++;
> + }
> + }
> + } else {
> + bcm43xx_phy_write(bcm, 0x03FF, 0x);
> + }
> +out:
> + return;
> +}

Besides that, I think I already implemented that function.

> +static inline void bcm43xx_gphy_init_dclt(struct bcm43xx_private *bcm)
> +{
> + FIXME();
> + // http://bcm-specs.sipsolutions.net/GPHY_DC_Lookup_Table
> + //FIXME: The specs aren't clear here. How many loops? For HW PCTL, we'd 
> need
> + //7 * 9 == 63 LO pairs. But we only have 14 * 4 == 56 pairs available.
> +}

I already implemented that.

> +/* intialize B/G PHY power control
>   * as described in http://bcm-specs.sipsolutions.net/InitPowerControl
>   */
>  static void bcm43xx_phy_init_pctl(struct bcm43xx_private *bcm)
> @@ -198,48 +261,86 @@ static void bcm43xx_phy_init_pctl(struct
>   struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
>   struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
>   u16 saved_batt = 0, saved_ratt = 0, saved_txctl1 = 0;
> - int must_reset_txpower = 0;
> + int has_hw_pctl = 0;
>  
>   assert(phy->type != BCM43xx_PHYTYPE_A);
>   if ((bcm->board_vendor == PCI_VENDOR_ID_BROADCOM) &&
>   (bcm->board_type == 0x0416))
>

Re: [PATCH 2/4] bcm43xx-d80211: Add wireless statistics

[Michael Buesch]

On Thursday 02 November 2006 19:46, Larry Finger wrote:
> These patches modify bcm43xx-d80211 to use the wireless statics added in 
> patch 1.
> 
> Signed-Off-By: Larry [EMAIL PROTECTED]>

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

> ---
> 
> Please apply to wireless-dev
> 
> 
> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
> ===
> --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
> +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
> @@ -27,6 +27,8 @@
>  
>  #define BCM43xx_IO_SIZE  8192
>  
> +#define BCM43xx_RX_MAX_SSI   60
> +
>  /* MMIO offsets */
>  #define BCM43xx_MMIO_DMA0_REASON 0x20
>  #define BCM43xx_MMIO_DMA0_IRQ_MASK   0x24
> @@ -610,7 +612,7 @@ struct bcm43xx_noise_calculation {
>  };
>  
>  struct bcm43xx_stats {
> - u8 link_quality;
> + u8 link_noise;
>   /* Store the last TX/RX times here for updating the leds. */
>   unsigned long last_tx;
>   unsigned long last_rx;
> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
> +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
> @@ -1199,15 +1199,7 @@ static void handle_irq_noise(struct bcm4
>   else
>   average -= 48;
>  
> - if (average > -65)
> - bcm->stats.link_quality = 0;
> - else if (average > -75)
> - bcm->stats.link_quality = 1;
> - else if (average > -85)
> - bcm->stats.link_quality = 2;
> - else
> - bcm->stats.link_quality = 3;
> -//   dprintk(KERN_INFO PFX "Link Quality: %u (avg was %d)\n", 
> bcm->stats.link_quality, average);
> + bcm->stats.link_noise = average;
>  drop_calculation:
>   bcm->noisecalc.calculation_running = 0;
>   return;
> @@ -3981,6 +3973,7 @@ static int __devinit bcm43xx_init_one(st
>   ieee->host_gen_beacon_template = 1;
>   ieee->rx_includes_fcs = 0;
>   ieee->monitor_during_oper = 1;
> + ieee->maxssi = BCM43xx_RX_MAX_SSI;
>   ieee->tx = bcm43xx_net_hard_start_xmit;
>   ieee->open = bcm43xx_net_open;
>   ieee->stop = bcm43xx_net_stop;
> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
> +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c
> @@ -678,10 +678,12 @@ void bcm43xx_rx(struct bcm43xx_private *
>   status.flag |= RX_FLAG_DECRYPTED;
>   }
>  
> - status.ssi = bcm43xx_rssi_postprocess(bcm, jssi,
> + status.signal = bcm43xx_rssi_postprocess(bcm, jssi,
> (phystat0 & 
> BCM43xx_RX_PHYST0_OFDM),
> (phystat0 & 
> BCM43xx_RX_PHYST0_GAINCTL),
> (phystat3 & 
> BCM43xx_RX_PHYST3_TRSTATE));
> + status.noise = bcm->stats.link_noise;
> + status.ssi = jssi;
>   if (phystat0 & BCM43xx_RX_PHYST0_OFDM)
>   status.rate = bcm43xx_plcp_get_bitrate_ofdm(plcp);
>   else
> 

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

Re: [PATCH 1/4] d80211: Add wireless statistics

[Michael Buesch]

On Thursday 02 November 2006 22:13, Larry Finger wrote:
> Hendrik Sattler wrote:
> > Am Donnerstag 02 November 2006 19:45 schrieb Larry Finger:
> >> This patch modifies d80211 to support wireless statistics.
> > 
> > Just a short question, since git is quite a bit different than e.g. 
> > subversion:
> > How do I correctly apply those patches to my local copy of wireless (got it 
> > with cg-clone)?
> > I would do it with "cg-patch -m" but the implied -c (commit) looks wrong to 
> > me. Or do I have to branch it first or...? Puzzled.
> 
> There are at least two ways to handle patches within git. The first is with 
> the simple "patch" 
> utility. You then back it out with "patch -R", or with "git checkout -f", 
> which restores your 
> repository to its original form. A second way to apply and remove patches is 
> to use "quilt". After 
> you have a patch file, it is put into quilt with a "quilt import filename" 
> command. You then apply 
> the patch with a "quilt push" command and remove it with a "quilt pop". To 
> create a new patch, use 
> touch to create a new patch file, import it, and push it. Quilt will note 
> that it is empty, but do 

Or use "quilt new" directly ;)

> it anyway. Then you use "quilt edit drivers/net/" to modify the source. 
> To create the patch 
> file, use a "quilt refresh" command.

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

Re: broadcom pcmcia card supported?

[Michael Buesch]

On Sunday 05 November 2006 14:07, Christian Hoffmann wrote:
> Hello,
> 
> I have a broadcom pcmcia wifi card. Is this supported by the bcm43xx driver?
> 
> r2d2 ~ # cat /sys/bus/pcmcia/devices/0.0/prod_id1
> Broadcom
> r2d2 ~ # cat /sys/bus/pcmcia/devices/0.0/prod_id2
> 802.11g PCMCIA
> r2d2 ~ # cat /sys/bus/pcmcia/devices/0.0/prod_id3
> 8.0
> r2d2 ~ # cat /sys/bus/pcmcia/devices/0.0/manf_id
> 0x02d0
> r2d2 ~ # cat /sys/bus/pcmcia/devices/0.0/card_id
> 0x0425
> 
> If not, is anyone interested to make it work? I could lend it for a while. I 
> would pay for shipping it. :)
> 
> Christian Hoffmann
> 

What about simply trying it? It's not that this is a
hard task. ;)

PS: Most likely it is supported.

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

Re: broadcom pcmcia card supported?

[Michael Buesch]

On Sunday 05 November 2006 15:20, Hendrik Sattler wrote:
> Am Sonntag 05 November 2006 15:01 schrieb Michael Buesch:
> > On Sunday 05 November 2006 14:07, Christian Hoffmann wrote:
> > > I have a broadcom pcmcia wifi card. Is this supported by the bcm43xx
> > > driver?
> [...]
> > PS: Most likely it is supported.
> 
> That reminds me of the previous thread about a 16bit-only PCMCIA card. Did 
> someone add PCMCIA code since then or do you think that this actually is a
> 32bit Cardbus card?

I plan to do so, but did not, yet. But please don't pin me
to a release date, as there are lots of other things with much
higher priority.
But don't you think this particular pcmcia card appears
to the system like a normal pci card like any other mainstream
pcmcia wireless card, too?

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

Re: broadcom pcmcia card supported?

[Michael Buesch]

On Sunday 05 November 2006 15:20, Christian Hoffmann wrote:
> On Sunday 05 November 2006 15:01, Michael Buesch wrote:
> > On Sunday 05 November 2006 14:07, Christian Hoffmann wrote:
> > > Hello,
> > >
> > > I have a broadcom pcmcia wifi card. Is this supported by the bcm43xx
> > > driver?
> > >
> > > r2d2 ~ # cat /sys/bus/pcmcia/devices/0.0/prod_id1
> > > Broadcom
> > > r2d2 ~ # cat /sys/bus/pcmcia/devices/0.0/prod_id2
> > > 802.11g PCMCIA
> > > r2d2 ~ # cat /sys/bus/pcmcia/devices/0.0/prod_id3
> > > 8.0
> > > r2d2 ~ # cat /sys/bus/pcmcia/devices/0.0/manf_id
> > > 0x02d0
> > > r2d2 ~ # cat /sys/bus/pcmcia/devices/0.0/card_id
> > > 0x0425
> > >
> > > If not, is anyone interested to make it work? I could lend it for a
> > > while. I would pay for shipping it. :)
> > >
> > > Christian Hoffmann
> >
> > What about simply trying it? It's not that this is a
> > hard task. ;)
> >
> > PS: Most likely it is supported.
> 
> I tried of course, but it doesnt seem to load any drivers or create a network 
> device. Dmesg only shows:
> 
> pccard: PCMCIA card inserted into slot 0
> pcmcia: registering new device pcmcia0.0
> 
> But maybe I have to configure pcmcia to attach bcm43xx driver? Sorry this 
> might be a stupid question, but I am new to pcmcia ...
> 
> Chris
> PS: pccardctl shows
> 
> $> pccardctl ident
> Socket 0:
>   product info: "Broadcom", "802.11g PCMCIA", "8.0", ""
>   manfid: 0x02d0, 0x0425
>   function: 6 (network)

I have no idea.
If this is a pcmcia card, that does not appear to the system
as PCI card, it is not supported, yet.

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

Re: [PATCH] bcm43xx: Add error checking in bcm43xx_sprom_write()

[Michael Buesch]

On Monday 06 November 2006 16:48, Larry Finger wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> 
> The Coverity checker noted that these "if (err)"'s couldn't ever be 
> true.
> 
> It seems the intention was to check the return values of the 
> bcm43xx_pci_write_config32()'s?

Whoops, I thought I had fixed this bug long time ago.
The patch is correct.

> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>

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

> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -750,7 +750,7 @@ int bcm43xx_sprom_write(struct bcm43xx_p
>   if (err)
>   goto err_ctlreg;
>   spromctl |= 0x10; /* SPROM WRITE enable. */
> - bcm43xx_pci_write_config32(bcm, BCM43xx_PCICFG_SPROMCTL, spromctl);
> + err = bcm43xx_pci_write_config32(bcm, BCM43xx_PCICFG_SPROMCTL, 
> spromctl);
>   if (err)
>   goto err_ctlreg;
>   /* We must burn lots of CPU cycles here, but that does not
> @@ -772,7 +772,7 @@ int bcm43xx_sprom_write(struct bcm43xx_p
>   mdelay(20);
>   }
>   spromctl &= ~0x10; /* SPROM WRITE enable. */
> - bcm43xx_pci_write_config32(bcm, BCM43xx_PCICFG_SPROMCTL, spromctl);
> + err = bcm43xx_pci_write_config32(bcm, BCM43xx_PCICFG_SPROMCTL, 
> spromctl);
>   if (err)
>   goto err_ctlreg;
>   mdelay(500);
> 

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

Re: Any problems with bcm43xx-softmac?

[Michael Buesch]

On Friday 10 November 2006 19:41, Larry Finger wrote:
> As of this morning, the last two bug fixes on my list were pushed from Jeff 
> Garzik to Andrew Morton 
> and Linus Torvalds for inclusion in -mainline (2.6.19-rcX). In addition, all 
> but one of the 
> enhancements that I have sent to Linville are now in wireless-2.6.git. Fixes 
> for the worst bugs are 
> also queued for 2.6.18.3.
> 
> Are there any issues that I do not know about? I do know, of course, about 
> the generally poor 
> transmit performance that limits the rate to 11M in most cases,

I don't really agree to the "most cases" statement here.
But I think you know that ;)

> and the difficulty in getting the radio turned on for those cards with a 
> radio on/off button. 

Only to repeat it. This is _not_ a bcm43xx bug.
These buttons require a seperate driver, which simply does not exist,
if someone who owns such a button does not write it.

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

Re: Any problems with bcm43xx-softmac?

[Michael Buesch]

On Monday 13 November 2006 19:02, Will Dyson wrote:
> On 11/10/06, Larry Finger <[EMAIL PROTECTED]> wrote:
> > As of this morning, the last two bug fixes on my list were pushed from Jeff 
> > Garzik to Andrew Morton
> > and Linus Torvalds for inclusion in -mainline (2.6.19-rcX). In addition, 
> > all but one of the
> > enhancements that I have sent to Linville are now in wireless-2.6.git. 
> > Fixes for the worst bugs are
> > also queued for 2.6.18.3.
> 
> I have an amd64 system w/ 3GB ram and a PCI 4306. Whenever I try to

That's very likely the >1G problem.
Try to boot with at most 1G of RAM.

> scan or associate, my system panics.
> 
> I am running 2.6.19-git (updated on 11/12). Attached is a trace from
> an attempt to scan for networks. I have serial console setup and can
> provide any additional info that would be helpful.
> 

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

Re: bug report : dscape bcm43xx on linksys WRT54G

[Michael Buesch]

On Monday 13 November 2006 23:45, Vincent Danjean wrote:
> Index: dscape-ieee80211/src/wireless-dev/ssb/ssb.c
> ===
> --- dscape-ieee80211.orig/src/wireless-dev/ssb/ssb.c  2006-11-13 
> 02:00:02.0 +0100
> +++ dscape-ieee80211/src/wireless-dev/ssb/ssb.c   2006-11-13 
> 01:58:55.0 +0100
> @@ -590,6 +590,7 @@
>   int err;
>   int attempts = 0;
>   u32 cur_core;
> + static int last_core = 1;
> 
>   while (1) {
>   err = ssb_pci_write_config32(ssb, SSB_BAR0_WIN,
> @@ -610,6 +611,10 @@
>   goto error;
>   udelay(10);
>   }
> + char* mmio=(char*)((coreidx-last_core)*SSB_CORE_SIZE + 
> (char*)ssb->mmio);
> + ssb->mmio=mmio;
> + last_core=coreidx;
> + printk(KERN_DEBUG PFX "switched to core %i, mmio set to %p\n", coreidx, 
> ssb->mmio);
>   return 0;
>  error:
>   printk(KERN_ERR PFX "Failed to switch to core %u\n", coreidx);

I am working on a port of bcm43xx to this machine.
The issue is really more complicated than this mmio hack.

If you want to have some hack that actually works on the wrt,
please lookup the mail archives.

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

Re: bcm4318

[Michael Buesch]

On Tuesday 14 November 2006 23:51, Joseph Jezak wrote:
> Jory A. Pratt wrote:
> > Well after doing a serious upgrade on my line I discovered just how
> > bad off the bcm4318 truely is. I have a 3Mbp/s line and with bcm4318 I
> > am lucky if I can utilize a 1/3rd of that. ( i.e <=1.0Mbps ) Those who
> > have this card might want to concider throwing it in the trash, it does
> > not work with dscape and softmac development is dead if you read
> > Micheal's post to the mail list. ALL development should only be done on
> > wireless-dev tree :/ . So for now I will stick with my wired ethernet
> > just so I get to use what I pay for.
> > 
> > Just figured I would let you all know how bad off the bcm4318 truely
> > is right now :/ If your interested in testing your line results see
> > www.2wire.com and run their "speed meter".
> > 
> > Jory
> 
> Honestly, what's the problem here?  It's incredible that it works
> even a little bit.  That's better than it was before bcm43xx
> existed.  I don't see how you can claim that it's awful and that
> we're not working on trying to make it better.  Larry has done a lot
> of work to keep the SoftMAC port working as best as possible and has
> backported many of Michael's devicescape fixes.  Just because
> Michael isn't working on SoftMAC doesn't mean that it's useless.

In fact, there are a few damn hard to solve bugs in softmac.
But that doesn't mean it's useless. It works correctly for, say 90%
of the people. Nobody is going to fix this, because it will be fixed
by the d80211 merge. If you want this fixed, step forward, please.

4318, well. I can't really understand why you are writing this mail.
We _never_ claimed 4318 was supported. We _always_ said it only works
by luck on lowest data rate.

We are working on the issue. I committed some fixes for this to my
development tree. These fixes don't quite work correctly, yet, but
it's a step in the right direction. If you want 4318 support _now_,
it's as "simple" as reading the specs and the driver and fixing the
remaining bugs. If you don't want to do this, you'll have to wait
until somebody else (me) continues on the issue.

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

Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

[Michael Buesch]

On Wednesday 15 November 2006 20:01, Ray Lee wrote:
> Suggestions? Requests for  even more info?

Yeah, enable bcm43xx debugging.

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

[PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Michael Buesch]

This fixes various bcm43xx-d80211 hwcrypto issues,
which mainly prevented mcast frames from being decrypted properly.

This is mostly a rewrite of the key managing code.
Note that after this patch v3 firmware is no longer supported.

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

Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h 
2006-11-14 16:03:00.0 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h  2006-11-14 
18:34:14.0 +0100
@@ -620,7 +620,6 @@ struct bcm43xx_stats {
 
 struct bcm43xx_key {
u8 enabled;
-   u8 used;
u8 algorithm;
u8 address[6];
 };
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-11-14 16:03:00.0 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 
2006-11-15 18:58:51.0 +0100
@@ -874,11 +874,12 @@ static void keymac_write(struct bcm43xx_
 {
u32 addrtmp[2];
 
+   assert(index >= 4 + 4);
+   memcpy(bcm->key[index].address, addr, 6);
/* We have two default TX keys and two default RX keys.
 * Physical mac 0 is mapped to physical key 8.
 * So we must adjust the index here.
 */
-   assert(index >= 4 + 4);
index -= 8;
 
addrtmp[0] = addr[0];
@@ -912,97 +913,88 @@ static void keymac_write(struct bcm43xx_
}
 }
 
-static int key_write_common(struct bcm43xx_private *bcm,
-   u8 index, u8 algorithm,
-   struct ieee80211_key_conf *keyconf,
-   const u8 *mac_addr)
+static void do_key_write(struct bcm43xx_private *bcm,
+u8 index, u8 algorithm,
+const u8 *key, size_t key_len,
+const u8 *mac_addr)
 {
u8 buf[BCM43xx_SEC_KEYSIZE];
 
-   /* The "index" passed to this function is the
-* absolute key table index.
-*/
-
-   if ((index >= bcm->max_nr_keys) ||
-   (keyconf && (keyconf->keylen > BCM43xx_SEC_KEYSIZE)))
-   return -EINVAL;
+   assert(index < bcm->max_nr_keys);
+   assert(key_len <= BCM43xx_SEC_KEYSIZE);
 
memset(buf, 0, sizeof(buf));
-   if (mac_addr)
+   if (index >= 8)
keymac_write(bcm, index, buf); /* First zero out mac. */
-   if (keyconf)
-   memcpy(buf, keyconf->key, keyconf->keylen);
+   memcpy(buf, key, key_len);
key_write(bcm, index, algorithm, buf);
-   if (mac_addr)
+   if (index >= 8)
keymac_write(bcm, index, mac_addr);
-   bcm->key[index].algorithm = algorithm;
-   bcm->key[index].used = 1;
-   bcm->key[index].enabled = 1;
-   if (mac_addr)
-   memcpy(bcm->key[index].address, mac_addr, 6);
-   else
-   memset(bcm->key[index].address, 0, 6);
 
-   return 0;
+   bcm->key[index].algorithm = algorithm;
 }
 
-static int bcm43xx_default_key_write(struct bcm43xx_private *bcm,
-u8 index, u8 algorithm,
-struct ieee80211_key_conf *key)
+static int bcm43xx_key_write(struct bcm43xx_private *bcm,
+int index, u8 algorithm,
+const u8 *key, size_t key_len,
+const u8 *mac_addr,
+struct ieee80211_key_conf *keyconf)
 {
-   int err;
+   int i;
 
-   if (index > 3)
+   if (key_len > BCM43xx_SEC_KEYSIZE)
return -EINVAL;
+   if (index < 0) {
+   /* Per station key with associated MAC address.
+* Look if it already exists, if yes update, otherwise
+* allocate a new key.
+*/
+   for (i = 8; i < bcm->max_nr_keys; i++) {
+   if (compare_ether_addr(bcm->key[i].address, mac_addr) 
== 0) {
+   /* found existing */
+   index = i;
+   break;
+   }
+   }
+   if (index < 0) {
+   for (i = 8; i < bcm->max_nr_keys; i++) {
+   if (!bcm->key[i].enabled) {
+   /* found empty */
+   index = i;
+   break;
+   }
+   }
+   }
+   if (index < 0) {
+   dprintk(KERN_ERR PFX "Out of hw k

Re: [PATCH]: bcm43xx-d80211: fix hwcrypto issues (mcast)

[Michael Buesch]

On Thursday 16 November 2006 16:22, Hendrik Sattler wrote:
> Am Donnerstag 16 November 2006 15:07 schrieb Michael Buesch:
> > Note that after this patch v3 firmware is no longer supported.
> 
> The the firmware files for v3 and v4 have different names?
> If not, that would be bad backward compatibility: older kernels only support 
> v3, newer only v4. How is one supposed to test bcm43xx-d80211 while having
> a released kernel for normal work (e.g. wireless-dev didn't work, here, when 
> I 
> last tried).

See fwpostfix modparam.

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

Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

[Michael Buesch]

On Thursday 16 November 2006 19:17, Larry Finger wrote:
> Ray Lee wrote:
> > Larry Finger wrote:
> >> Ray Lee wrote:
> >>> Michael Buesch wrote:
> >>>> On Wednesday 15 November 2006 20:01, Ray Lee wrote:
> >>>>> Suggestions? Requests for  even more info?
> >>>> Yeah, enable bcm43xx debugging.
> >>> Sigh, didn't even think to look for that. Okay, enabled and compiling
> >>> a new kernel. This will take a few days to trigger, if the pattern holds, 
> >>> so
> >>> in the meantime, any *other* thoughts?
> >> Which chip and revision do you have? Send me your equivalent of the line
> >> "bcm43xx: Chip ID 0x4306, rev 0x2".
> > 
> > bcm43xx: Chip ID 0x4306, rev 0x3
> > 
> > Also, another thing I wasn't clear about in my first email was that the 
> > netdev
> > watchdog timeouts are new with rc5:
> > 
> > $ zgrep 'NETDEV WATCH' /var/log/messages{,.0,.1.gz} | cut -d: -f2| cut -c 
> > 1-6
> > | uniq -c
> >1249 Nov 13
> >   6 Nov  6
> >   1 Nov  7
> >   3 Nov  8
> >   2 Nov  9
> >5717 Nov 10
> >5652 Nov 11
> >   5 Oct 29
> >   3 Oct 30
> >   3 Oct 31
> >   4 Nov  1
> >   1 Nov  2
> >   1 Nov  3
> > 
> > I booted into 2.6.19-rc5 on November 10th. Previous to that was 2.6.19-rc3.
> > There really does seem to be something suspicious with that patch, yes?
> > 
> > Thanks,
> > 
> > Ray
> > 
> 
> It certainly looks as if the "Drain TX status" patch is causing the problem; 
> however, it should do 
> nothing for core revisions < 5, and yours is a 3.

You are looking at the wrong revision number.
You are looking at the chip revision, while this tests for the
802.11 core revision. Get the dmesg line which prints info for the
core with ID 0x812.

> Could you do me a favor? Please use git to download the current contents of 
> Linus's tree with a "git 
> clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 
> new_dir". Using the same 
> .config as your current kernel and the git bisect command, you should be able 
> to isolate the commit 
> that is causing the error. I know that it is a lot of work and will take 
> considerable time; however, 
> that way we will see if some other change is triggering the problem.

Well, please bisect it anyway. Otherwise it will be very hard to track down.

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

Re: ibook issues

[Michael Buesch]

On Saturday 18 November 2006 18:56, Marco wrote:
> Hi all,
> i have just reinstalled Ubuntu Edgy on my ibook g4 (12'') with an
> Airport Express card.
> 
> The first thing that puzzled me is that the fwcutter doesn't recognize
> the AppleAirport2 file from MacOS X to get the firmware to be put in
> /lib/firmware/(kernelversionoptionally).
> 
> I can provide extended information as needed, as now i am just
> investingating known issues.
> 
> The second thing is that, even if i get the firmware in place (taken
> from wl_apsta.o and extracted with fwcutter), i can't use the Airport
> Express: at boot time (and everytime i modprobe the module) dmesg
> states bcm is found and ieee802whatelse is in place, but issuing
> iwconfig eth1 essid *myessid*
> 
> isn't working,

Isn't working isn't a bugreport.

> it doesn't change a thing. 
> 
> Where's the problem? Where should i look into?

dmesg

> TIA for you help,
> 
> marco
> 
> PS
> Using kernel version 2.6.17, bcm43xx-fwcutter version 20060501

Upgrade the kernel.
We can only support current stable kernel.

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

Re: BCM4318, come on guys :-)

[Michael Buesch]

On Sunday 19 November 2006 04:24, Larry Finger wrote:
> Ramanalinarivo Sandrinah Vonisoa Annie wrote:
> > Hi,
> > I just post this to encourage guys to fix problems on 4318 chipset.
> > I have a 32bit (Celeron M) Acer 3630 (notebook), and "lspci":
> > 
> > 00:0b.0 Network controller: Broadcom Corporation BCM4318 
> > [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
> > 
> > I still have to use ndiswrapper for the moment.
> > Hold on, take care, do it well, do your best! :-)
> 
> Now that most bcm43xx cards do not lock up or crash the computer, I am 
> planning on seeing what can 
> be done with BCM4318's. I'm currently bidding on E-bay for a Linksys WPC54G 
> V3, which has a 4318 
> chip. Please do not bid against me - my name there is lw_wanderer.
> 
> Once I get the card and an RF receiver, I hope to investigate the 4318 
> problems, as well as the 11 
> Mbs upper limit for most of us.

Look at my tree for what has to be done. I think I implemented most stuff there
what was missing for 4318. But the problem is that there still seem to be
lots of bugs in the new code. ;)
You're really welcome to fix these. hehe.
If you want to port all these changes to bcm43xx-softmac, it'll be a nontrivial
task. Possible, but lots of work.

Please ask Stefano to get the money for the card. ;)

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

Re: BCM4318, come on guys :-)

[Michael Buesch]

On Sunday 19 November 2006 20:54, evan foss wrote:
> I would just like to express my gratitude that anyone is working on
> this. I have a 4311 card built into my laptop and while it still does
> not actually work I am grateful for all the work done on it. The fact
> that the developers have gotten this far without one to test their
> work is incredible.

What about _you_ testing it?
I actually have one report of a working PCI-E card with
the wireless-dev tree.

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

Re: [PATCH] softmac: remove netif_tx_disable when scanning

[Michael Buesch]

On Sunday 26 November 2006 11:03, Johannes Berg wrote:
> On Sat, 2006-11-25 at 23:05 -0500, Daniel Drake wrote:
> 
> > Surely disabling the queue actually makes sense, in order to avoid 
> > frames designated for the "current session" being transmitted on 
> > different channels during scanning?
> 
> The problem is that queue disabling isn't refcounted so that a scan that
> collides with bcm43xx having disabled the queue for calibration might
> re-enable the queue while bcm43xx is still calibrating.
> 
> Clearly, this doesn't fully fix the problem because softmac will try to
> transmit frames during the calibration. Hence, a proper fix would be to
> not remove the calls to netif_tx_disable but make them go through
> softmac (ieee80211_tx_disable) to make sure that softmac doesn't try to
> scan while the queues are disabled, which would fix the aforementioned
> problem of softmac enabling the queue while the driver needs it disabled
> for free.

Yeah, but I don't think it's worth fixing. ;)
Simply removing this tx_disable in softmac fixes a _big_ bug
and that must be applied. The bug of being able to scan while
calibrating is very minor and not worth to fix. Fixing this
will likely introduce other bugs. It's simply not worth it
anymore.

This tx_disable remove patch must be applied, because it fixes
actual locking issues in the driver(s). And I think it is responsible
for several mysterious bugs we have seen in the past. I cannot
prove that, but I am pretty sure.
It must also be pushed for inclusion in -stable.

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

Re: [PATCH] softmac: remove netif_tx_disable when scanning

[Michael Buesch]

On Sunday 26 November 2006 05:05, Daniel Drake wrote:
> Larry Finger wrote:
> > In the scan section of ieee80211softmac, network transmits are disabled.
> > Clearly, this does not make any sense as transmit is necessary for active
> > scanning, and transmits are not used when passive scanning.
> 
> Probe request frames are generated by softmac and do not go through the 
> TX queue. Disabling the TX queue has no effect on that.

That's just yet another problem. ;)
The driver has its damn good reasons to disable the queue. (And only
the driver should be allowed to disable that queue). Softmac ignoring
this queue-disabled flag is just yet another bug.

> Surely disabling the queue actually makes sense, in order to avoid 
> frames designated for the "current session" being transmitted on 
> different channels during scanning?

This should be avoided by mechanisms in the firmware, as that's
the only race-free place where a "Am I on the correct channel"
check can happen. Additionally, the ieee80211 stack should
keep track of the currently set channel and don't transmit frames
on the wrong channel.

But I don't really think this is worth fixing, as it's all already
fixed in d80211 (Well, these bugs have never been in there afaik ;) ).

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

Re: [PATCH] softmac: remove netif_tx_disable when scanning

[Michael Buesch]

On Sunday 26 November 2006 14:05, Larry Finger wrote:
> Michael Buesch wrote:
> > On Sunday 26 November 2006 11:03, Johannes Berg wrote:
> >> On Sat, 2006-11-25 at 23:05 -0500, Daniel Drake wrote:
> >>
> >>> Surely disabling the queue actually makes sense, in order to avoid 
> >>> frames designated for the "current session" being transmitted on 
> >>> different channels during scanning?
> >> The problem is that queue disabling isn't refcounted so that a scan that
> >> collides with bcm43xx having disabled the queue for calibration might
> >> re-enable the queue while bcm43xx is still calibrating.
> >>
> >> Clearly, this doesn't fully fix the problem because softmac will try to
> >> transmit frames during the calibration. Hence, a proper fix would be to
> >> not remove the calls to netif_tx_disable but make them go through
> >> softmac (ieee80211_tx_disable) to make sure that softmac doesn't try to
> >> scan while the queues are disabled, which would fix the aforementioned
> >> problem of softmac enabling the queue while the driver needs it disabled
> >> for free.
> > 
> > Yeah, but I don't think it's worth fixing. ;)
> > Simply removing this tx_disable in softmac fixes a _big_ bug
> > and that must be applied. The bug of being able to scan while
> > calibrating is very minor and not worth to fix. Fixing this
> > will likely introduce other bugs. It's simply not worth it
> > anymore.
> 
> I actually found one of these while testing WX locking as suggested by Dan 
> Williams. His method has 
> two scripts running at the same time with one of them doing an 'iwlist ethX 
> scan' and the other 
> executing an 'iwconfig ethX' as fast as possible. Running this test for 36 
> hours failed to indicate 
> any locking errors, but running it without the patch under discussion led to 
> a number of the 
> following errors:
> 
> kernel: bcm43xx: ASSERTION FAILED (!ring->suspended) at: 
> drivers/net/wireless/bcm43xx/bcm43xx_dma.c:71:request_slot()
> 
> This error _NEVER_ happened when softmac was not allowed to disable TX.

Yeah, that's the error I expected.
Nice that you proved my point for this being an important patch. ;)

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

Re: [PATCH] softmac: remove netif_tx_disable when scanning

[Michael Buesch]

On Sunday 26 November 2006 17:37, Daniel Drake wrote:
> Johannes Berg wrote:
> > The problem is that queue disabling isn't refcounted so that a scan that
> > collides with bcm43xx having disabled the queue for calibration might
> > re-enable the queue while bcm43xx is still calibrating.
> 
> I agree with that part. However the other reason for the patch (transmit 
> queue needed for active scanning) is bogus, and the patch introduces a 
> problem where session frames may be transmitted during scanning (using 
> TX queue control avoids that problem).
> 
> > Clearly, this doesn't fully fix the problem because softmac will try to
> > transmit frames during the calibration. Hence, a proper fix would be to
> > not remove the calls to netif_tx_disable but make them go through
> > softmac (ieee80211_tx_disable) to make sure that softmac doesn't try to
> > scan while the queues are disabled, which would fix the aforementioned
> > problem of softmac enabling the queue while the driver needs it disabled
> > for free.
> 
> Stack-level refcounted TX control like this would also be beneficial for 
> zd1211rw, currently we have a semi-ugly implementation inside the driver.
> 
> > Also, for bcm43xx this isn't a problem since the firmware (optionally
> > but we use that afaik) takes care of not transmitting frames that are
> > tagged for a different channel than currently tuned to.
> 
> zd1211 has no such functionality :(
> 
> Michael Buesch wrote:
> > Softmac ignoring
> > this queue-disabled flag is just yet another bug.
> 
> Agreed, but this one isn't going to be fixed any time soon. This was the 
> first point I raised against softmac during early zd1211rw development a 
> long while back.
> 
> I agree with the objectives of this patch but the way I see it is that 
> it trades one bug for another. A proper solution, as suggested by 

Yeah, it trades one fat big bug against a very minor one.
AND!! Currently it's possible to transmit frames while scanning, too.
Don't forget that. Today we have both bugs. With this patch we have only
one left. The only "issue" is that today the "transmit packet while
scanning" bug is less likely to trigger. But it's still possible (because
of disabling not being refcounted).

> Johannes (refcounted stack-level TX control) would not be hard to 
> implement and would solve the bug without introducing another.

So, please do so.
But please apply this one regardless of what you do. ;)
It fixes a nasty kind of bug. With this trivial to fix bug
in the tree I won't look at periodic work "bugs" anymore, that
are reported now and then, because I really thing they are all
caused by this hidden bug.
I also saw a real life bugreport of the asserion in the DMA code
triggering. I didn't know back than how that was possible to happen,
but now I know.

Besides that, what's the problem with some bogus frames being transmitted
throughout the short period of scanning? I don't really see how that
can hurt anyone (besides consuming minor bandwidth).

I already said it in the past. We _have_ to trade one bug for the other
in softmac, because it's buggy by design. And it really doesn't make sense
to fix them all. Well, actually it does. Because fixing all these bugs
would mean replacing softmac by d80211. There's no real other way. ;)

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

Re: [PATCH take2] softmac: remove netif_tx_disable when scanning

[Michael Buesch]

On Monday 27 November 2006 21:37, Larry Finger wrote:
> From: Michael Buesch <[EMAIL PROTECTED]>
> 
> In the scan section of ieee80211softmac, network transmits are disabled.
> When SoftMAC re-enables transmits, it may override the wishes of a driver
> that may have very good reasons for disabling transmits. At least one failure
> in bcm43xx can be traced to this problem. In addition, several unexplained
> problems may arise from the unexpected enabling of transmits.


> Note that 
> making this change introduces a new bug that would allow transmits for the
> current session to be transmitted on the wrong channel;

Nono, please don't confuse that.
It does not _indruduce_ a new bug. The bug is already there. It's only less
likely to trigger without this bugfix patch.

> however, the new bug 
> is much less severe than the one being fixed, as the new one only leads to
> a few retransmits, whereas the old one can bring the interface down.

Yeah, that too.

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

Re: Progress report

[Michael Buesch]

On Wednesday 29 November 2006 15:55, Larry Finger wrote:
> Erik Mouw wrote:
> > On Wed, Nov 29, 2006 at 12:00:49PM +0100, Florian Fainelli wrote:
> >> Le mercredi 29 novembre 2006 07:54, Larry Finger a écrit :
> >>> When using the standard bcm43xx-softmac software and transmitting with CCK
> >>> modulation at 11 Mbs, I get TX power at my receiver of -36 dBm. When
> >>> transmitting with OFDM modulation at 54 Mbs, the maximum power in exactly
> >>> the same configuration is -48 dBm. Thus the signal is weaker by a factor 
> >>> of
> >>> 10^12. That is too weak for reliable communication to my AP, which is 
> >>> about
> >>> twice as far as the RF receiver.
> >> As far as I know, power is in Watt or mW, what you are pointing out is a 
> >> power 
> >> level, ok this is the . I don't really understand your 10^12 factor ? 
> >> 10log(10^12) (basis 10) = 120 ?
> > 
> > dBm is an accepted way to measure power in radio systems. See
> > http://en.wikipedia.org/wiki/DBm . The difference between -36 and -48
> > dBm is 12, which is roughly a 16 fold decrease.
> 
> I had a couple of errors in my original post. The first is that my RF meter 
> outputs the RF 
> amplitude, not power, in dBm. My second was too quickly using the intrinsic 
> logarithmic relationship 
> between the power in dBm and the power in mW, which is dBm = 10 log(mW).
> 
> The ratio of two quantities measured in dBm is R = 10^((q1-q2)/10). Thus Erik 
> is correct that the 
> ratio between -34 and -46 dBm is ~16 (15.8).
> 
> Since I measured amplitude, and P is proportional to amplitude^2, the 
> received power ratio that I 
> observed is roughly 250 (15.8^2).
> 
> Additionally, the background contains noise spikes that are as large as -55 
> dBm. Thus S/N (signal to 
> noise) of the power is 16,000 for 11 Mbs, but only 63 for 54 Mbs.
> 
> In any case, I still need to find the missing power.

You need to rework the _whole_ PHY code. Otherwise it's impossible to find.

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

Re: 4311 and pcie patch results

[Michael Buesch]

On Saturday 02 December 2006 00:51, Larry Finger wrote:
> Fernando Toledo wrote:
> > 
> > hi! =(
> > im not using ndiswrapper..
> > i have a realtek pcmcia with kismet a cant see anything
> 
> The reason you don't see anything is that your radio is not turned on. At the 
> moment, bcm43xx does 
> not know what happens in the hardware when you push the RF KILL button on 
> your keyboard. What Jochen 
> does is load ndiswrapper and the Windows driver to turn on the radio, then 
> unloads ndiswrapper and 
> loads bcm43xx. In this process, the radio stays on.
>
> He is running a test for me to see what differences there are in the radio 
> registers between the two 
> situations.

Most likely the radio-hwenabled bit.
It's in different registers, depending on core revs.

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

Re: 4311 and pcie patch results

[Michael Buesch]

On Saturday 02 December 2006 16:49, Larry Finger wrote:
> Michael Buesch wrote:
> > On Saturday 02 December 2006 00:51, Larry Finger wrote:
> >> Fernando Toledo wrote:
> >>> hi! =(
> >>> im not using ndiswrapper..
> >>> i have a realtek pcmcia with kismet a cant see anything
> >> The reason you don't see anything is that your radio is not turned on. At 
> >> the moment, bcm43xx does 
> >> not know what happens in the hardware when you push the RF KILL button on 
> >> your keyboard. What Jochen 
> >> does is load ndiswrapper and the Windows driver to turn on the radio, then 
> >> unloads ndiswrapper and 
> >> loads bcm43xx. In this process, the radio stays on.
> >>
> >> He is running a test for me to see what differences there are in the radio 
> >> registers between the two 
> >> situations.
> > 
> > Most likely the radio-hwenabled bit.
> > It's in different registers, depending on core revs.
> > 
> 
> Is this bit described in the specs? I looked on both the V3 and V4 pages, but 
> couldn't find a reference.

Yes, somewhere. It's located in two different places, depending on
core revision.

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

Re: HW enable patch

[Michael Buesch]

On Saturday 02 December 2006 18:23, Larry Finger wrote:
> Does this patch make your radio come on without any special tricks?
> 
> If it does, we will then be able to go for actually using the RF button.
> 
> Larry
> 

Next time please inline the patch, so it's easier to comment on.

> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -2441,6 +2441,7 @@ static int bcm43xx_chip_init(struct bcm4
> if (err)
> goto err_gpio_cleanup;
> bcm43xx_radio_turn_on(bcm);
> +   bcm43xx_hw_radio_turn_on(bcm);
>  
> bcm43xx_write16(bcm, 0x03E6, 0x);
> err = bcm43xx_phy_init(bcm);
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
> @@ -1951,6 +1951,32 @@ u16 bcm43xx_default_txctl1(struct bcm43x
> return 0;
>  }
>  
> +void bcm43xx_hw_radio_turn_on(struct bcm43xx_private *bcm)
> +{
> +   if (bcm->current_core->rev >= 3)
> +   bcm43xx_write32(bcm, BCM43xx_MMIO_RADIO_HWENABLED_HI,
> +   (bcm43xx_read32(bcm,
> BCM43xx_MMIO_RADIO_HWENABLED_HI) +   & (~(1 <<
> 16;
> +   else
> +   bcm43xx_write16(bcm, BCM43xx_MMIO_RADIO_HWENABLED_LO,
> +   (bcm43xx_read16(bcm,
> BCM43xx_MMIO_RADIO_HWENABLED_LO) +   & (1 <<
> 4)));

Most likely you want bitwise OR here |

> +   dprintk(KERN_INFO PFX "Radio HWenable on\n");
> +}
> +
> +void bcm43xx_hw_radio_turn_off(struct bcm43xx_private *bcm)
> +{
> +   if (bcm->current_core->rev >= 3)
> +   bcm43xx_write32(bcm, BCM43xx_MMIO_RADIO_HWENABLED_HI,
> +   (bcm43xx_read32(bcm,
> BCM43xx_MMIO_RADIO_HWENABLED_HI) +   & (1 <<
> 16)));

Here, too.

> +   else
> +   bcm43xx_write16(bcm, BCM43xx_MMIO_RADIO_HWENABLED_LO,
> +   (bcm43xx_read16(bcm,
> BCM43xx_MMIO_RADIO_HWENABLED_LO) +   & ~(1 <<
> 4)));
> +   dprintk(KERN_INFO PFX "Radio HWenable on\n");
> +}
> +
>  void bcm43xx_radio_turn_on(struct bcm43xx_private *bcm)
>  {
> struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> @@ -65,6 +65,9 @@ void bcm43xx_radio_init2060(struct bcm43
>  void bcm43xx_radio_turn_on(struct bcm43xx_private *bcm);
>  void bcm43xx_radio_turn_off(struct bcm43xx_private *bcm);
>  
> +void bcm43xx_hw_radio_turn_on(struct bcm43xx_private *bcm);
> +void bcm43xx_hw_radio_turn_off(struct bcm43xx_private *bcm);
> +
>  int bcm43xx_radio_selectchannel(struct bcm43xx_private *bcm, u8 channel,
> int synthetic_pu_workaround);
>  

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

Re: RFC/T: bcm43xx: report radio hardware status

[Michael Buesch]

On Tuesday 05 December 2006 18:56, Larry Finger wrote:
> The patch below implements a function to obtain the status of the hardware 
> enable bit of the radio,
> and report this status to the log when the core is initialized. It also 
> places code in the periodic
> work handler to report any changes in the status.
> 
> One other change is to remove some unused code relating to the HW_ENABLE bit.
> 
> Larry
> ---
> 
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -2441,6 +2441,9 @@ static int bcm43xx_chip_init(struct bcm4
>   if (err)
>   goto err_gpio_cleanup;
>   bcm43xx_radio_turn_on(bcm);
> + bcm->radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
> + printk(KERN_INFO PFX "Radio %s by hardware\n",
> + (bcm->radio_hw_enable == 0) ? "disabled" : "enabled");
> 
>   bcm43xx_write16(bcm, 0x03E6, 0x);
>   err = bcm43xx_phy_init(bcm);
> @@ -3222,6 +3225,7 @@ static void bcm43xx_periodic_work_handle
>   unsigned long flags;
>   u32 savedirqs = 0;
>   unsigned long orig_trans_start = 0;
> + int radio_hw_enable;
> 
>   mutex_lock(&bcm->mutex);
>   if (unlikely(bcm->periodic_state % 4 == 0)) {
> @@ -3254,6 +3258,12 @@ static void bcm43xx_periodic_work_handle
>   spin_lock_irqsave(&bcm->irq_lock, flags);
>   }
> 
> + radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
> + if (unlikely(bcm->radio_hw_enable != radio_hw_enable)) {
> + bcm->radio_hw_enable = radio_hw_enable;
> + printk(KERN_INFO PFX "Radio hardware status changed to %s\n",
> + (bcm->radio_hw_enable == 0) ? "disabled" : "enabled");
> + }

Please put this hunk into func bcm43xx_periodic_work_every15sec().

>   do_periodic_work(bcm);
> 
>   if (unlikely(bcm->periodic_state % 4 == 0)) {
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> @@ -65,6 +65,23 @@ void bcm43xx_radio_init2060(struct bcm43
>   void bcm43xx_radio_turn_on(struct bcm43xx_private *bcm);
>   void bcm43xx_radio_turn_off(struct bcm43xx_private *bcm);
> 
> +static inline
> +int bcm43xx_is_hw_radio_enabled(struct bcm43xx_private *bcm)
> +{
> + /* function to return state of hardware enable of radio
> +  * returns 0 if radio disabled, 1 if radio enabled
> +  * This routine MUST be called with locking (mutex and irqsafe) already 
> done.
> +  */
> + if (likely(bcm->current_core->rev >= 3))
> + return ((bcm43xx_read32(bcm, BCM43xx_MMIO_RADIO_HWENABLED_HI)
> + & BCM43xx_MMIO_RADIO_HWENABLED_HI_MASK)
> + == 0) ? 1 : 0;
> + else
> + return ((bcm43xx_read16(bcm, BCM43xx_MMIO_RADIO_HWENABLED_LO)
> + & BCM43xx_MMIO_RADIO_HWENABLED_LO_MASK)
> + == 0) ? 0 : 1;
> +}
> +
>   int bcm43xx_radio_selectchannel(struct bcm43xx_private *bcm, u8 channel,
>   int synthetic_pu_workaround);
> 
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
> @@ -352,6 +352,10 @@
>   #define BCM43xx_UCODEFLAG_UNKPACTRL 0x0040
>   #define BCM43xx_UCODEFLAG_JAPAN 0x0080
> 
> +/* Hardware Radio Enable masks */
> +#define BCM43xx_MMIO_RADIO_HWENABLED_HI_MASK (1 << 16)
> +#define BCM43xx_MMIO_RADIO_HWENABLED_LO_MASK (1 << 4)
> +
>   /* Generic-Interrupt reasons. */
>   #define BCM43xx_IRQ_READY   (1 << 0)
>   #define BCM43xx_IRQ_BEACON  (1 << 1)
> @@ -758,7 +762,8 @@ struct bcm43xx_private {
>   bad_frames_preempt:1,   /* Use "Bad Frames Preemption" (default 
> off) */
>   reg124_set_0x4:1,   /* Some variable to keep track of IRQ 
> stuff. */
>   short_preamble:1,   /* TRUE, if short preamble is enabled. 
> */
> - firmware_norelease:1;   /* Do not release the firmware. Used on 
> suspend. */
> + firmware_norelease:1,   /* Do not release the firmware. Used on 
> suspend. */
> + radio_hw_enable:1;  /* TRUE if radio is hardware enabled */
> 
>   struct bcm43xx_stats stats;
> 
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_power.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_power.c
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bc

Re: RFC/T: bcm43xx: report radio hardware status

[Michael Buesch]

On Tuesday 05 December 2006 19:42, Larry Finger wrote:
> >> +static inline
> >> +int bcm43xx_is_hw_radio_enabled(struct bcm43xx_private *bcm)
> >> +{
> >> +  /* function to return state of hardware enable of radio
> >> +   * returns 0 if radio disabled, 1 if radio enabled
> >> +   * This routine MUST be called with locking (mutex and irqsafe) already 
> >> done.
>=^
> Would this function be safe with just the mutex locked? Is the irq lock 
> needed?

Well, strictly said, I think it's safe to call without any lock at all,
as this is a read-only register.
But I think where you call this, you most likely already have
at least the mutex held (except in init and exit paths, where we
don't need locking anyway).

> >> +   */
> >> +  if (likely(bcm->current_core->rev >= 3))
> >> +  return ((bcm43xx_read32(bcm, BCM43xx_MMIO_RADIO_HWENABLED_HI)
> >> +  & BCM43xx_MMIO_RADIO_HWENABLED_HI_MASK)
> >> +  == 0) ? 1 : 0;
> >> +  else
> >> +  return ((bcm43xx_read16(bcm, BCM43xx_MMIO_RADIO_HWENABLED_LO)
> >> +  & BCM43xx_MMIO_RADIO_HWENABLED_LO_MASK)
> >> +  == 0) ? 0 : 1;
> >> +}
> >> +
> >>   int bcm43xx_radio_selectchannel(struct bcm43xx_private *bcm, u8 channel,
> >>int synthetic_pu_workaround);
> 
> >>
> >>
> >> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_power.c
> >> ===
> >> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_power.c
> >> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_power.c
> >> @@ -312,20 +312,6 @@ int bcm43xx_pctl_set_crystal(struct bcm4
> >>if (bcm->sprom.boardflags & BCM43xx_BFL_XTAL_NOSLOW)
> >>return 0;
> >>
> >> -/*XXX: Why BCM43xx_MMIO_RADIO_HWENABLED_xx can't be read 
> >> at this time?
> >> - *err = bcm43xx_switch_core(bcm, bcm->active_80211_core);
> >> - *if (err)
> >> - *return err;
> >> - *if (((bcm->current_core->rev >= 3) &&
> >> - *(bcm43xx_read32(bcm, 
> >> BCM43xx_MMIO_RADIO_HWENABLED_HI) & (1 << 16))) ||
> >> - *  ((bcm->current_core->rev < 3) &&
> >> - *!(bcm43xx_read16(bcm, 
> >> BCM43xx_MMIO_RADIO_HWENABLED_LO) & (1 << 4
> >> - *return 0;
> >> - *err = bcm43xx_switch_core(bcm, &bcm->core_chipcommon);
> >> - *if (err)
> >> - *return err;
> >> - */
> >> -  
> > 
> > Hm, well. This code actually should be here. Somehow. It's not quite correct
> > as-is (That's why it's commented ;) ). The specs state to do this check 
> > here.
> > But there was some problem, don't remember exactly what. Ehm, maybe we 
> > already
> > disabled the crystal here or something... dunno.
> 
> I'm looking into this.

Ok, thanks. You can try to uncomment it.
I think it will crash with a bus machinecheck. Because we already disabled 
something
of the device before (crystal?).

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

Re: [PATCH] softmac: Fixed handling of deassociation from AP

[Michael Buesch]

On Wednesday 06 December 2006 15:45, Larry Finger wrote:
> From:  Ulrich Kunitz <[EMAIL PROTECTED]>
>  
> A deauthentication from the AP doesn't start a reassociation by
> SoftMAC. To fix this mac->associnfo.associating must be set and the
> ieee80211softmac_assoc_work function must be scheduled.
> 
> Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
> 
>  net/ieee80211/softmac/ieee80211softmac_assoc.c |   14 --
>  net/ieee80211/softmac/ieee80211softmac_auth.c  |2 ++
>  net/ieee80211/softmac/ieee80211softmac_priv.h  |2 ++
>  3 files changed, 16 insertions(+), 2 deletions(-)
> 
> Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
> ===
> --- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
> +++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
> @@ -427,6 +427,17 @@ ieee80211softmac_handle_assoc_response(s
>   return 0;
>  }
>  
> +void
> +ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&mac->lock, flags);
> + mac->associnfo.associating = 1;
> + schedule_work(&mac->associnfo.work);
> + spin_unlock_irqrestore(&mac->lock, flags);
> +}

All data in mac->associnfo is protected by mac->associnfo->mutex
and _not_ mac->lock.

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

Re: [PATCH] softmac: Fixed handling of deassociation from AP

[Michael Buesch]

On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
> On 06-12-06 18:52 Michael Buesch wrote:
> 
> > All data in mac->associnfo is protected by mac->associnfo->mutex
> > and _not_ mac->lock.
> 
> Are you sure?

Yes I am.

> One can find for instance the following function in 
> ieee80211softmac_assoc.c:

This is not the first time we notice that locking
is completely broken in softmac. ;)

> void
> ieee80211softmac_disassoc(struct ieee80211softmac_device *mac)
> {
> unsigned long flags;
> 
> spin_lock_irqsave(&mac->lock, flags);
> if (mac->associnfo.associating)
> cancel_delayed_work(&mac->associnfo.timeout);
> 
> netif_carrier_off(mac->dev);
> 
> mac->associnfo.associated = 0;
> mac->associnfo.bssvalid = 0;
> mac->associnfo.associating = 0;
> ieee80211softmac_init_bss(mac);
> ieee80211softmac_call_events_locked(mac, 
> IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
> spin_unlock_irqrestore(&mac->lock, flags);
> }
> 
> Cheers,
> 
> Uli
> 

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

Re: [PATCH] softmac: Fixed handling of deassociation from AP

[Michael Buesch]

On Wednesday 06 December 2006 22:51, Ulrich Kunitz wrote:
> On 06-12-06 21:52 Michael Buesch wrote:
> 
> > On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
> > > On 06-12-06 18:52 Michael Buesch wrote:
> > > 
> > > > All data in mac->associnfo is protected by mac->associnfo->mutex
> > > > and _not_ mac->lock.
> > > 
> > > Are you sure?
> > 
> > Yes I am.
> > 
> > > One can find for instance the following function in 
> > > ieee80211softmac_assoc.c:
> > 
> > This is not the first time we notice that locking
> > is completely broken in softmac. ;)
> 
> So the right thing would be to add another work function
> (*_start_reassoc_work) which sets the associating variable and
> calls then *_assoc_work? 

Ah, well. I think the right thing doesn't exist.
Even if you replace the lock by the mutex, it's still racy.
The whole lock design of softmac is broken and racy and we
can't simply fix that with a oneliner.

I'd say, John, apply the original patch as-is, as it does
more good than harm.

Basically, I just wanted to point out that this is not race-free.
But I think we can live with it.

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

Re: [PATCH] softmac: Fixed handling of deassociation from AP

[Michael Buesch]

On Thursday 07 December 2006 01:36, Larry Finger wrote:
> it seems to 
> me that the mutex protects only the association data; whereas the spinlock 
> protects more data, but 
> does include the association data.

Nope.

The same way you could argue that the BKL should be taken here,
as it's "the global kernel lock which protects everything".
But it's simply not true and won't protect anything. ;)

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

Re: HW enable patch (V3)

[Michael Buesch]

On Thursday 07 December 2006 16:32, Larry Finger wrote:
> Please note that we do know how to operate 
> the LEDs,

Well, is it probably connected to some GPIO? And
must be switched like any other LEDs, but this one depending
on the radio-hwenabled bit?

> It is really tough that none of the developers have the necessary hardware.

Donations welcome. Haha :D

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

Re: HW enable patch (V3)

[Michael Buesch]

On Thursday 07 December 2006 18:34, Jochen Puchalla wrote:
> [Donnerstag, 7. Dezember 2006 16:58] schrieb Michael Buesch (wrote):
> > On Thursday 07 December 2006 16:32, Larry Finger wrote:
> > > Please note that we do know how to operate
> > > the LEDs,
> >
> > Well, is it probably connected to some GPIO? And
> > must be switched like any other LEDs, but this one depending
> > on the radio-hwenabled bit?
> >
> > > It is really tough that none of the developers have the necessary
> > > hardware.
> >
> > Donations welcome. Haha :D
> 
> Live near Cologne?

Yeah.

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

Re: RFC/T: bcm43xx: report radio hardware status

[Michael Buesch]

On Friday 08 December 2006 16:55, Larry Finger wrote:
> Carlo Marcelo Arenas Belon wrote:
> > 
> >> Michael Buesch wrote:
> >>>> @@ -3254,6 +3258,12 @@ static void bcm43xx_periodic_work_handle
> >>>>  spin_lock_irqsave(&bcm->irq_lock, flags);
> >>>>  }
> >>>>
> >>>> +radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
> >>>> +if (unlikely(bcm->radio_hw_enable != radio_hw_enable)) {
> >>>> +bcm->radio_hw_enable = radio_hw_enable;
> >>>> +printk(KERN_INFO PFX "Radio hardware status changed to 
> >>>> %s\n",
> >>>> +(bcm->radio_hw_enable == 0) ? "disabled" : "enabled");
> >>>> +}
> >>> Please put this hunk into func bcm43xx_periodic_work_every15sec().
> >> Done.
> > 
> > where was this committed?, i couldn't find it neither in wireless-dev or
> > wireless-2.6 git repositories and ended up re-implementing it on my tree
> > instead.
> 
> It has not been committed. When I send a patch around with RFC, RFT, or RFC/T 
> in the subject, it 
> means that I want comments, testing, or both. Once the reports are favorable 
> and all objections have 
> been satisfied, I will submit it for inclusion with "[PATCH] bcm43xx:" in the 
> E-mail subject.
> 
> I think this change is a useful one, but one question remains. Will we be 
> able to control the LED 
> from this code? If so, I suspect that we will want a response that is faster 
> than 15 seconds. In 
> that case, the periodic work handler will need to be restructured. I would 
> prefer to make all this 
> happen with a single submission/commit.

We need a timer with one second heartbeat anyway, if we want to implement
the rest of the spec'ed periodic work stuff.

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

Re: Lockups on Apple G4 PowerBooks/iBooks?

[Michael Buesch]

On Saturday 09 December 2006 08:56, Erik Chakravarty wrote:
> and we suspect it is the bcm43xx driver or softmac
> that is causing this. 

Why?

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

Re: Lockups on Apple G4 PowerBooks/iBooks?

[Michael Buesch]

On Saturday 09 December 2006 16:01, Erik Chakravarty wrote:
> I take it that this is not a problem known to be associated with the
> bcm43xx driver then, which means I will have to do some further testing.
> 
> The problem in diagnosing this is that it's difficult to see log output
> once the machine's locked - the first thing I notice is that the

netconsole

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

Re: PCIE cards with dscape

[Michael Buesch]

On Monday 11 December 2006 02:15, Matthew Garrett wrote:
> Do the PCI-E cards have the same issues as the 4318 chipset?

I think so, yes.

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

Re: RFC/T: bcm43xx: report radio hardware statusa (V2)

[Michael Buesch]

On Monday 11 December 2006 11:33, Carlo Marcelo Arenas Belon wrote:
> On Sun, Dec 10, 2006 at 04:12:45PM -0600, Larry Finger wrote:
> > This version of the patch not only reports the status of the 
> > hardware-enabled flag, but it also sets
> > the LED's 2 and 3 with opposite states.
> 
> why?, isn't LED 3 the only one that is meant to be activated as it indicates
> that radio is enabled as per the SPEC?, or maybe 4 to 6 depending on the mode
> the radio is on? and why are the values being set and no register updated?
> 
> > For those of you with switches to 
> > turn the radio on/off,
> > please report if the LED in the switch changes state, and whether it is on 
> > or off when the radio is on.
> 
> I have only 1 LED and it is not turning ON/OFF with this patch.
> 
> It turns ON/OFF with the patch I made originally though and which uses 
> bcm43xx_leds_switch_all(bcm, 0) to update the LED status during the 
> bcm43xx_periodic_every1sec call.
> 
> As I mentioned originally, the LED turns ON at init of the card regardless of
> the status of the hardware enabled bit (I pressumed when the call for
> bcm43xx_radio_turn_on is done, but never checked), and if the radio is
> disabled it turns off as soon as softmac's association fails and the radio
> gets turned off (no idea where, as I really didn't trace it either) but that
> was why i commented out that probably all those functions were doing was to
> update the LEDs.

Well, this information is all rather useless.
Please track down _which_ exact bits generate your desired behaviour.
We can not do this for you, as we don't have your hardware.

It's as simple as this: If someone sees bad behaviour of _his_ leds,
he must track it down himself, because we don't have the hardware to
do it.

> > This patch also starts the implementation of the current specs regarding 
> > periodic work.
> 
> I see now the SPEC had several tasks to be done every second, including some
> of the ones that were before in the every 15 seconds periodic call in the 
> code 
> (which was somethig that surprised me on the patch to begin with).
> 
> Any idea of why it was done this way before?, just curious.

Come on. You already know the answer.
Hint: How has this spec been developed?

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

Re: ieee80211 sleeping in invalid context

[Michael Buesch]

On Tuesday 12 December 2006 05:06, Ray Lee wrote:
> Hey all, more data on my bcm43xx problem report from a few weeks back.
> 
> By random chance I acquired a brain, and decided to rebuild my latest kernel

Congratulations to your decision ;)

> Dec 11 19:34:47 phoenix kernel: [   57.044691] WARNING at kernel/mutex.c:132 
> __mutex_lock_common()
> Dec 11 19:34:47 phoenix kernel: [   57.044694]

I'm not sure what's happening here. Either one of the following
assertions is failing:

038 #define spin_lock_mutex(lock, flags)\
039 do {\
040 struct mutex *l = container_of(lock, struct mutex, 
wait_lock); \
041 \
042 DEBUG_LOCKS_WARN_ON(in_interrupt());\
043 local_irq_save(flags);  \
044 __raw_spin_lock(&(lock)->raw_lock); \
045 DEBUG_LOCKS_WARN_ON(l->magic != l); \
046 } while (0)

Which kernel are you using?
There is some locking breakage in latest kernels with softmac.
I attached the fixes for the known bugs.






From: Michael Buesch <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Sun, 10 Dec 2006 18:39:28 +0100
Message-Id: <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>, Johannes Berg <[EMAIL PROTECTED]>, "John 
W. Linville" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: ieee80211softmac: Fix mutex_lock at exit of ieee80211_softmac_get_genie

From: Ulrich Kunitz <[EMAIL PROTECTED]>

ieee80211softmac_wx_get_genie locks the associnfo mutex at
function exit. This patch fixes it. The patch is against Linus'
tree (commit af1713e0).

Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
 net/ieee80211/softmac/ieee80211softmac_wx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.19.1.orig/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ linux-2.6.19.1/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -463,7 +463,7 @@ ieee80211softmac_wx_get_genie(struct net
err = -E2BIG;
}
spin_unlock_irqrestore(&mac->lock, flags);
-   mutex_lock(&mac->associnfo.mutex);
+   mutex_unlock(&mac->associnfo.mutex);
 
return err;
 }








From: Ulrich Kunitz <[EMAIL PROTECTED]>

The signature of work functions changed recently from a context
pointer to the work structure pointer. This caused a problem in
the ieee80211softmac code, because the ieee80211softmac_assox_work
function has  been called directly with a parameter explicitly
casted to (void*). This compiled correctly but resulted in a
softlock, because mutex_lock was called with the wrong memory
address. The patch fixes the problem. Another issue was a wrong
call of the schedule_work function. Softmac works again and this
fixes the problem I mentioned earlier in the zd1211rw rx tasklet
patch. The patch is against Linus' tree (commit af1713e0).

Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---

John,

This patch should be pushed upstream to 2.6.20. At the moment, the work
struct changes have not yet propagated to wireless-2.6. When they do,
it will be needed there as well.

Larry

 net/ieee80211/softmac/ieee80211softmac_assoc.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c 
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index eec1a1d..a824852 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -167,7 +167,7 @@ static void
 ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type, 
void *context)
 {
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
-   ieee80211softmac_assoc_work((void*)mac);
+   ieee80211softmac_assoc_work(&mac->associnfo.work.work);
 }
 
 static void
@@ -177,7 +177,7 @@ ieee80211softmac_assoc_notify_auth(struc
 
switch (event_type) {
case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
-   ieee80211softmac_assoc_work((void*)mac);
+   ieee80211softmac_assoc_work(&mac->associnfo.work.work);
break;
case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:
@@ -438,7 +438,7 @@ ieee80211softmac_try_reassoc(struct ieee
 
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.associating = 1;
-   schedule_work(&mac->associnfo.work);
+   schedule_delayed_work(&mac->associnfo.work, 0);
spin_unlock_irqrestore(&mac->lock, flags);
 }


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

Re: bcm4311 softmac assertion

[Michael Buesch]

On Thursday 14 December 2006 19:34, Fernando Toledo wrote:
> when ifconfig eth1 up on 2.6.19 from kernel.org
> 
> 
> SoftMAC: ASSERTION FAILED (0) at:
> net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate()
> bcm43xx: PHY connected
> bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18  02:36:27)
> bcm43xx: Radio turned on
> bcm43xx: Chip initialized
> bcm43xx: 32-bit DMA initialized
> bcm43xx: Keys cleared
> bcm43xx: Selected 802.11 core (phytype 2)

Ah, well. This is rather harmless.
get_rate() was queried before a rate was set.

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

[PATCH 2/2] bcm43xx-d80211: Fix for PHYmode API change.

[Michael Buesch]

This fixes the PHYmode list API breakage for the bcm43xx-d80211 driver.

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

Index: bu3sch-wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===
--- bu3sch-wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h  
2006-12-13 19:24:25.0 +0100
+++ bu3sch-wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h   
2006-12-14 17:42:42.0 +0100
@@ -561,6 +561,8 @@ struct bcm43xx_phy {
enum bcm43xx_firmware_compat fw;
/* The TX header length. This depends on the firmware. */
size_t txhdr_size;
+
+   struct ieee80211_hw_mode hwmode;
 };
 
 /* Data structures for DMA transmission, per 80211 core. */
Index: bu3sch-wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- 
bu3sch-wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 
2006-12-13 19:24:25.0 +0100
+++ bu3sch-wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c  
2006-12-14 17:57:46.0 +0100
@@ -2892,19 +2892,25 @@ static void bcm43xx_chipset_detach(struc
 
 static void bcm43xx_free_modes(struct bcm43xx_private *bcm)
 {
-   struct ieee80211_hw *hw = bcm->ieee;
+   struct ssb_core *core;
+   struct bcm43xx_corepriv_80211 *wlpriv;
+   struct bcm43xx_phy *phy;
int i;
 
-   for (i = 0; i < hw->num_modes; i++) {
-   kfree(hw->modes[i].channels);
-   kfree(hw->modes[i].rates);
+   for (i = 0; i < bcm->nr_80211_available; i++) {
+   core = bcm->wlcores[i];
+   wlpriv = core->priv;
+   phy = &wlpriv->phy;
+
+   kfree(phy->hwmode.channels);
+   phy->hwmode.channels = NULL;
+   kfree(phy->hwmode.rates);
+   phy->hwmode.rates = NULL;
}
-   kfree(hw->modes);
-   hw->modes = NULL;
-   hw->num_modes = 0;
 }
 
-static int bcm43xx_append_mode(struct ieee80211_hw *hw,
+static int bcm43xx_append_mode(struct bcm43xx_private *bcm,
+  struct bcm43xx_phy *phy,
   int mode_id,
   int nr_channels,
   const struct ieee80211_channel *channels,
@@ -2913,10 +2919,10 @@ static int bcm43xx_append_mode(struct ie
   int nr_rates2,
   const struct ieee80211_rate *rates2)
 {
-   struct ieee80211_hw_modes *mode;
+   struct ieee80211_hw_mode *mode;
int err = -ENOMEM;
 
-   mode = &(hw->modes[hw->num_modes]);
+   mode = &phy->hwmode;
 
mode->mode = mode_id;
mode->num_channels = nr_channels;
@@ -2937,11 +2943,14 @@ static int bcm43xx_append_mode(struct ie
   sizeof(*rates2) * nr_rates2);
}
 
-   hw->num_modes++;
-   err = 0;
+   err = ieee80211_register_hwmode(bcm->ieee, mode);
+   if (err)
+   goto err_free_rates;
 out:
return err;
 
+err_free_rates:
+   kfree(mode->rates);
 err_free_channels:
kfree(mode->channels);
goto out;
@@ -2950,17 +2959,9 @@ err_free_channels:
 static int bcm43xx_setup_modes(struct bcm43xx_private *bcm)
 {
int err = -ENOMEM;
-   struct ieee80211_hw *hw = bcm->ieee;
struct ssb_core *core;
struct bcm43xx_corepriv_80211 *wlpriv;
-   int i, nr_modes;
-
-   nr_modes = bcm->nr_80211_available;
-   hw->modes = kzalloc(sizeof(*(hw->modes)) * nr_modes,
- GFP_KERNEL);
-   if (!hw->modes)
-   goto out;
-   hw->num_modes = 0;
+   int i;
 
for (i = 0; i < bcm->nr_80211_available; i++) {
core = bcm->wlcores[i];
@@ -2968,7 +2969,7 @@ static int bcm43xx_setup_modes(struct bc
 
switch (wlpriv->phy.type) {
case BCM43xx_PHYTYPE_A:
-   err = bcm43xx_append_mode(bcm->ieee, MODE_IEEE80211A,
+   err = bcm43xx_append_mode(bcm, &wlpriv->phy, 
MODE_IEEE80211A,
  
ARRAY_SIZE(bcm43xx_a_chantable),
  bcm43xx_a_chantable,
  
ARRAY_SIZE(bcm43xx_ofdm_ratetable),
@@ -2976,7 +2977,7 @@ static int bcm43xx_setup_modes(struct bc
  0, NULL);
break;
case BCM43xx_PHYTYPE_B:
-   err = bcm43xx_append_mode(bcm->ieee, MODE_IEEE80211B,
+   err = bcm43xx_append_mode(bcm, &wlpriv->phy, 
MODE_IEEE80211B,
  
ARRAY_SIZE(bcm43xx_bg

[PATCH 1/2] d80211: Turn PHYmode list from an array into a linked list

[Michael Buesch]

This turns the PHY-modes list into a linked list.
The advantage is that drivers can add modes dynamically, as they probe
them and don't have to settle to a given arraysize at the beginning
of probing.

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

--

Note that I will also send fixup patches for all other d80211 drivers,
if no complaints are done against this patch.

Index: bu3sch-wireless-dev/include/net/d80211.h
===
--- bu3sch-wireless-dev.orig/include/net/d80211.h   2006-12-05 
18:09:34.0 +0100
+++ bu3sch-wireless-dev/include/net/d80211.h2006-12-13 19:40:05.0 
+0100
@@ -76,12 +76,14 @@ struct ieee80211_rate {
   * optimizing channel utilization estimates */
 };
 
-struct ieee80211_hw_modes {
-   int mode;
-   int num_channels;
-   struct ieee80211_channel *channels;
-   int num_rates;
-struct ieee80211_rate *rates;
+struct ieee80211_hw_mode {
+   int mode; /* MODE_IEEE80211... */
+   int num_channels; /* Number of channels (below) */
+   struct ieee80211_channel *channels; /* Array of supported channels */
+   int num_rates; /* Number of rates (below) */
+struct ieee80211_rate *rates; /* Array of supported rates */
+
+   struct list_head list; /* Internal, don't touch */
 };
 
 struct ieee80211_tx_queue_params {
@@ -420,9 +422,7 @@ typedef enum {
SET_KEY, DISABLE_KEY, REMOVE_ALL_KEYS,
 } set_key_cmd;
 
-/* This is driver-visible part of the per-hw state the stack keeps.
- * If you change something in here, call ieee80211_update_hw() to
- * notify the stack about the change. */
+/* This is driver-visible part of the per-hw state the stack keeps. */
 struct ieee80211_hw {
/* these are assigned by d80211, don't write */
int index;
@@ -512,9 +512,6 @@ struct ieee80211_hw {
/* This is maximum value for rssi reported by this device */
int maxssi;
 
-   int num_modes;
-   struct ieee80211_hw_modes *modes;
-
/* Number of available hardware TX queues for data packets.
 * WMM requires at least four queues. */
int queues;
@@ -750,9 +747,9 @@ static inline char *ieee80211_get_rx_led
 #endif
 }
 
-/* Call this function if you changed the hardware description after
- * ieee80211_register_hw */
-int ieee80211_update_hw(struct ieee80211_hw *hw);
+/* Register a new hardware PHYMODE capability to the stack. */
+int ieee80211_register_hwmode(struct ieee80211_hw *hw,
+ struct ieee80211_hw_mode *mode);
 
 /* Unregister a hardware device. This function instructs 802.11 code to free
  * allocated resources and unregister netdevices from the kernel. */
Index: bu3sch-wireless-dev/net/d80211/ieee80211.c
===
--- bu3sch-wireless-dev.orig/net/d80211/ieee80211.c 2006-12-05 
18:09:35.0 +0100
+++ bu3sch-wireless-dev/net/d80211/ieee80211.c  2006-12-13 19:40:05.0 
+0100
@@ -1915,7 +1915,8 @@ int ieee80211_if_config_beacon(struct ne
 
 int ieee80211_hw_config(struct ieee80211_local *local)
 {
-   int i, ret = 0;
+   struct ieee80211_hw_mode *mode;
+   int ret = 0;
 
 #ifdef CONFIG_D80211_VERBOSE_DEBUG
printk(KERN_DEBUG "HW CONFIG: channel=%d freq=%d "
@@ -1926,12 +1927,10 @@ int ieee80211_hw_config(struct ieee80211
if (local->ops->config)
ret = local->ops->config(local_to_hw(local), &local->hw.conf);
 
-   for (i = 0; i < local->hw.num_modes; i++) {
-   struct ieee80211_hw_modes *mode = &local->hw.modes[i];
+   list_for_each_entry(mode, &local->modes_list, list) {
if (mode->mode == local->hw.conf.phymode) {
-   if (local->curr_rates != mode->rates) {
+   if (local->curr_rates != mode->rates)
rate_control_clear(local);
-   }
local->curr_rates = mode->rates;
local->num_curr_rates = mode->num_rates;
ieee80211_prepare_rates(local);
@@ -2511,10 +2510,10 @@ ieee80211_rx_h_data(struct ieee80211_txr
 static struct ieee80211_rate *
 ieee80211_get_rate(struct ieee80211_local *local, int phymode, int hw_rate)
 {
-   int m, r;
+   struct ieee80211_hw_mode *mode;
+   int r;
 
-   for (m = 0; m < local->hw.num_modes; m++) {
-   struct ieee80211_hw_modes *mode = &local->hw.modes[m];
+   list_for_each_entry(mode, &local->modes_list, list) {
if (mode->mode != phymode)
continue;
for (r = 0; r < mode->num_rates; r++) {
@@ -4351,24 +4350,6 @@ void ieee80211_if_mgmt_setup(struct net_
dev->destructor = ieee80211_if_free;
 }
 
-static void ie

Re: bcm4311: card up but scan fails

[Michael Buesch]

On Thursday 14 December 2006 22:08, Fabian Förg wrote:
> Larry Finger wrote:
> > There isn't any hardware in the interface that lets us turn it on, 
> > thus we don't know. None of the developers have your hardware. You can 
> > try pushing the button, or whatever. If you find some special 
> > incantation that works, let the list know.
> >
> > Larry
> >
> I realized that under Windows, the card also does not work anymore. Then 
> I restored the BIOS to the defaults and now it works under Windows AND 
> Linux! This is strange because the only thing I have ever changed in the 
> BIOS was the boot order.

o.O

> I also found out that the card only connects if  
> I enable bluetooth, too.

They probably use the same antenna.
So maybe some bad interaction here.

> When I boot Linux the WLAN LED lights blue but I have to press the radio 
> button so that bluetooth is enabled. Then the LED shines even brighter. 
> If I press the radio button again, the LED dims, and the card cannot 
> establish a connection (bluetooth is disabled then).
> The rates are very low, though, so I decided to change the rate with the 
> following command:
> 
> # iwconfig eth1 rate 1M
> Error for wireless request "Set Bit Rate" (8B20) :
> SET failed on device eth1 ; Operation not supported.
> 
> This is written to the logs:
> PM: Writing back config space on device :02:01.0 at offset b (was 
> 3ed173b, writing 30b0103c)
> PM: Writing back config space on device :02:01.0 at offset 3 (was 0, 
> writing 4010)
> PM: Writing back config space on device :02:01.0 at offset 2 (was 
> 200, writing 203)
> PM: Writing back config space on device :02:01.0 at offset 1 (was 
> 2b0, writing 2b6)
> PM: Writing back config space on device :02:01.0 at offset 0 (was 
> 3ed173b, writing 169c14e4)

You suspended in the meantime? (Closed the notebook).

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

Re: [PATCH 1/2] d80211: Turn PHYmode list from an array into a linked list

[Michael Buesch]

On Friday 15 December 2006 14:48, Jiri Benc wrote:
> On Thu, 14 Dec 2006 19:20:11 +0100, Michael Buesch wrote:
> > This turns the PHY-modes list into a linked list.
> > The advantage is that drivers can add modes dynamically, as they probe
> > them and don't have to settle to a given arraysize at the beginning
> > of probing.
> 
> ACK.

Thanks. Will submit fixes for the other drivers, too.

> > @@ -198,8 +200,7 @@ static int ieee80211_ioctl_scan(struct n
> > param->u.scan.last_rx = local->scan.rx_packets;
> > local->scan.rx_packets = -1;
> > }
> > -   param->u.scan.channel = local->hw.modes[local->scan.mode_idx].
> > -   channels[local->scan.chan_idx].chan;
> > +   param->u.scan.channel = 
> > local->scan.mode->channels[local->scan.chan_idx].chan;
> >  
> > return 0;
> >  }
> 
> The patch is malformed. Fixed and applied to my tree.

I'm sorry. Forgot to remove the "wrap at ~80chars option in my mailer.

Can you also apply the bcm43xx fix for this to your tree?
I think that should be easiest and prevent long-living breakage.

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

Re: [PATCH 1/2] d80211: Turn PHYmode list from an array into a linked list

[Michael Buesch]

On Friday 15 December 2006 15:06, Jiri Benc wrote:
> On Fri, 15 Dec 2006 14:54:55 +0100, Michael Buesch wrote:
> > Can you also apply the bcm43xx fix for this to your tree?
> > I think that should be easiest and prevent long-living breakage.
> 
> It doesn't apply :-( It's probably easy to fix but I'd rather leave it
> to you to not make any damage.

Uh, yeah. Possible. It's diffed against my tree. Forgot that
I have some other changes in there.
I will resend a fixed fix :)

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

Re: [PATCH 1/2] d80211: Turn PHYmode list from an array into a linked list

[Michael Buesch]

On Friday 15 December 2006 15:06, Jiri Benc wrote:
> On Fri, 15 Dec 2006 14:54:55 +0100, Michael Buesch wrote:
> > Can you also apply the bcm43xx fix for this to your tree?
> > I think that should be easiest and prevent long-living breakage.
> 
> It doesn't apply :-( It's probably easy to fix but I'd rather leave it
> to you to not make any damage.

Here's the fixed patch diffed against your tree.

Still Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: jbenc-dscape/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===
--- jbenc-dscape.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h 
2006-12-15 15:58:04.0 +0100
+++ jbenc-dscape/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h  2006-12-15 
16:17:30.0 +0100
@@ -503,6 +503,8 @@ struct bcm43xx_phyinfo {
enum bcm43xx_firmware_compat fw;
/* The TX header length. This depends on the firmware. */
size_t txhdr_size;
+
+   struct ieee80211_hw_mode hwmode;
 };
 
 
Index: jbenc-dscape/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- jbenc-dscape.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-12-15 15:58:04.0 +0100
+++ jbenc-dscape/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 
2006-12-15 16:30:55.0 +0100
@@ -2845,19 +2845,25 @@ static void bcm43xx_chipset_detach(struc
 
 static void bcm43xx_free_modes(struct bcm43xx_private *bcm)
 {
-   struct ieee80211_hw *hw = bcm->ieee;
+   struct ssb_core *core;
+   struct bcm43xx_corepriv_80211 *wlpriv;
+   struct bcm43xx_phyinfo *phy;
int i;
 
-   for (i = 0; i < hw->num_modes; i++) {
-   kfree(hw->modes[i].channels);
-   kfree(hw->modes[i].rates);
+   for (i = 0; i < bcm->nr_80211_available; i++) {
+   core = bcm->wlcores[i];
+   wlpriv = core->priv;
+   phy = &wlpriv->phy;
+
+   kfree(phy->hwmode.channels);
+   phy->hwmode.channels = NULL;
+   kfree(phy->hwmode.rates);
+   phy->hwmode.rates = NULL;
}
-   kfree(hw->modes);
-   hw->modes = NULL;
-   hw->num_modes = 0;
 }
 
-static int bcm43xx_append_mode(struct ieee80211_hw *hw,
+static int bcm43xx_append_mode(struct bcm43xx_private *bcm,
+  struct bcm43xx_phyinfo *phy,
   int mode_id,
   int nr_channels,
   const struct ieee80211_channel *channels,
@@ -2866,10 +2872,10 @@ static int bcm43xx_append_mode(struct ie
   int nr_rates2,
   const struct ieee80211_rate *rates2)
 {
-   struct ieee80211_hw_modes *mode;
+   struct ieee80211_hw_mode *mode;
int err = -ENOMEM;
 
-   mode = &(hw->modes[hw->num_modes]);
+   mode = &phy->hwmode;
 
mode->mode = mode_id;
mode->num_channels = nr_channels;
@@ -2890,11 +2896,14 @@ static int bcm43xx_append_mode(struct ie
   sizeof(*rates2) * nr_rates2);
}
 
-   hw->num_modes++;
-   err = 0;
+   err = ieee80211_register_hwmode(bcm->ieee, mode);
+   if (err)
+   goto err_free_rates;
 out:
return err;
 
+err_free_rates:
+   kfree(mode->rates);
 err_free_channels:
kfree(mode->channels);
goto out;
@@ -2903,17 +2912,9 @@ err_free_channels:
 static int bcm43xx_setup_modes(struct bcm43xx_private *bcm)
 {
int err = -ENOMEM;
-   struct ieee80211_hw *hw = bcm->ieee;
struct ssb_core *core;
struct bcm43xx_corepriv_80211 *wlpriv;
-   int i, nr_modes;
-
-   nr_modes = bcm->nr_80211_available;
-   hw->modes = kzalloc(sizeof(*(hw->modes)) * nr_modes,
- GFP_KERNEL);
-   if (!hw->modes)
-   goto out;
-   hw->num_modes = 0;
+   int i;
 
for (i = 0; i < bcm->nr_80211_available; i++) {
core = bcm->wlcores[i];
@@ -2921,7 +2922,7 @@ static int bcm43xx_setup_modes(struct bc
 
switch (wlpriv->phy.type) {
case BCM43xx_PHYTYPE_A:
-   err = bcm43xx_append_mode(bcm->ieee, MODE_IEEE80211A,
+   err = bcm43xx_append_mode(bcm, &wlpriv->phy, 
MODE_IEEE80211A,
  
ARRAY_SIZE(bcm43xx_a_chantable),
  bcm43xx_a_chantable,
  
ARRAY_SIZE(bcm43xx_ofdm_ratetable),
@@ -2929,7 +2930,7 @@ static int bcm43xx_setup_modes(struct bc
  0, NULL);
  

Re: [PATCH 1/2] d80211: Turn PHYmode list from an array into a linked list

[Michael Buesch]

On Saturday 16 December 2006 07:40, Michael Wu wrote:
> On Thursday 14 December 2006 13:20, Michael Buesch wrote:
> > -int ieee80211_update_hw(struct ieee80211_hw *hw)
> > +int ieee80211_register_hwmode(struct ieee80211_hw *hw,
> > + struct ieee80211_hw_mode *mode)
> Looks like this function never returns nonzero now. Can it return void 
> instead? This would simplify the fixes for drivers a bit.

Well, theoretically, yes.
Maybe it's only my personal way to do things, but I usually
let such API register functions return an error code, because
if we internally change it only slightly, it often turns out
we need an error code. For example let's say we need to
kmalloc something in that function for some reason.

If you say, well, breaking the API again is ok, when this is required,
send a patch. ;)

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

Re: oops in bcm43xx_destroy_dmaring - 4318 mini-pci & d80211

[Michael Buesch]

On Thursday 21 December 2006 01:07, Steve Brown wrote:
> I'm using a recent snap (wpa_supplicant-0.6-2006-12-11) and the current 
> wireless-dev w/ the PHYmode mods backed out so bcm43xx-d80211 compiles.  

WTF is "PHYmode mods backed out so bcm43xx-d80211 compiles"??

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

Re: bcm43xx-softmac code to handle (at least one) iface with an rfkill switch

[Michael Buesch]

On Thursday 21 December 2006 17:01, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 03:08:58PM -0600, Larry Finger wrote:
> > +   radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
> > +   if (unlikely(bcm->radio_hw_enable != radio_hw_enable)) {
> > +   bcm->radio_hw_enable = radio_hw_enable;
> > +   printk(KERN_INFO PFX "Radio hardware status changed to %s\n",
> > +  (radio_hw_enable == 0) ? "disabled" : "enabled");
> 
> Based on discussion on netdev, it seems that the desired behaviour when 
> the radio is disabled is that the interface should be downed. This 
> probably also means that it shouldn't be possible to bring the interface 
> up if the radio is disabled.

Sure, but I don't think we want to implement this into bcm43xx-softmac,
as it just adds instability over very minor gain.
The only gain is reduced power consumption and not having a non-workable
device in ifconfig.

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

Re: oops in bcm43xx_destroy_dmaring - 4318 mini-pci & d80211

[Michael Buesch]

On Thursday 21 December 2006 01:07, Steve Brown wrote:
> I'm using a recent snap (wpa_supplicant-0.6-2006-12-11) and the current 
> wireless-dev w/ the PHYmode mods backed out so bcm43xx-d80211 compiles.  
> The module (WL-120G V2A) is from an ASUS wl500-gp and installed in x86 
> development machine using a mini-pci to pci adapter. I'm using firmware 
> 4.80.17.0.
> 
> wpa_ connects solidly using either no encryption or tkip. Throughput, 
> though not measured, seems fast. I'm using the wext driver in wpa_. I 
> had it running for several days.
> If I kill wpa_supplicant, the bcm43xx oops'es hard with a reboot 
> necessary. I hooked up a serial console to better see what was going on 
> and am attaching the dumps.

Ah, I think I hit (and found) the bug, too :)
This seems to be a double-free bug. Will send a patch, soon.

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

[PATCH] bcm43xx-d80211: Fix DMA TX skb doublefree

[Michael Buesch]

This fixes a possible double-free of the TX skb buffers.
Always NULL the pointer after freeing.

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

Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c 
2006-12-07 17:25:19.0 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c  
2006-12-21 19:05:28.0 +0100
@@ -388,6 +388,7 @@ void free_descriptor_buffer(struct bcm43
dev_kfree_skb_irq(meta->skb);
else
dev_kfree_skb(meta->skb);
+   meta->skb = NULL;
}
 }
 
@@ -1131,6 +1132,7 @@ void bcm43xx_dma_handle_txstatus(struct 
meta->txstat.retry_count = status->frame_count - 1;
ieee80211_tx_status_irqsafe(bcm->ieee, meta->skb, 
&(meta->txstat));
/* skb is freed by ieee80211_tx_status_irqsafe() */
+   meta->skb = NULL;
} else {
/* No need to call free_descriptor_buffer here, as
 * this is only the txhdr, which is not allocated.


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

The new SSB subsystem for bcm43xx (and others)

[Michael Buesch]

This is a development snapshot of the new Sonics Silicon Backplane
subsystem I am currently designing.
A port of the bcm43xx driver is included and it works (more or less).
There are still some things left and broken (most are marked with TODO
or FIXME).

This is just a snapshot for you to look at what it will look
like when it's done. The major API is done. There will be some
minor changes to it, but that's it.

Well, what is this, actually? This subsystem has the goal to make
it possible to drive the mainline kernel with bcm43xx on an
embedded system based on the sonics backplane natively and out of
the box. The Linksys WRT router is a good example for one of these
devices.
There is also a port of b44 available, so it can run on this,
but it's not included here.

In general it works like this:

[Host PCI bus]
  \
[Sonics Backplane]
   \  \ \
bcm43xx   b44   other devices...

The Host PCI bus does not need to be there. In fact, it is
not there for the embedded devices. So the Sonics Backplane is
the main system bus.

The ssb subsystem completely abstracts all these details,
so that we can run the same bcm43xx (and b44) driver on
a normal PCI machine and such an embedded device natively.

In previous implementations the normal bcm43xx PCI driver
was run on these devices, by emulating a PCI bus on top of
the real SSB Bus.

The Quilt series for all this can be downloaded here:
http://bu3sch.de/misc/new-ssb-20061222.tar.bz2

This series applies against my wireless development git tree.

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

Re: Lockups on Apple G4 PowerBooks/iBooks?

[Michael Buesch]

On Friday 22 December 2006 04:42, Erik Chakravarty wrote:
> Update on this issue: I've just experienced another hang and this time
> the following messages were written just as the keyboard stopped
> responding and the OS couldn't execute any programs:
> 
> 
> Dec 22 03:23:10 localhost kernel: [ 3059.099669] NETDEV WATCHDOG: eth1:
> transmit timed out
> Dec 22 03:23:10 localhost kernel: [ 3059.099678] bcm43xx: Controller
> RESET (TX timeout) ...
> Dec 22 03:23:10 localhost kernel: [ 3059.099717] bcm43xx:
> select_wireless_core: cleanup
> Dec 22 03:23:20 localhost kernel: [ 3069.099303] NETDEV WATCHDOG: eth1:
> transmit timed out
> Dec 22 03:23:20 localhost kernel: [ 3069.099312] bcm43xx: Controller
> RESET (TX timeout) ...
> Dec 22 03:23:25 localhost kernel: [ 3074.099302] NETDEV WATCHDOG: eth1:
> transmit timed out
> 
> this continues for a few minutes until all I can do is power off the
> machine. Is this of any help identifying the problem?

Which kernel version are you running.
This looks like a bug which is solved in most recent stable kernel.

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

Re: [PATCH] bcm43xx: Interrogate hardware-enable switch and update LEDs

[Michael Buesch]

On Friday 29 December 2006 21:00, Larry Finger wrote:
> The current bcm43xx driver ignores any wireless-enable switches on mini-PCI
> and mini-PCI-E cards. This patch implements a new routine to interrogate the
> radio hardware enabled bit in the interface, logs the initial state and any
> changes in the switch (if debugging enabled), activates the LED to show the
> state, and changes the periodic work handler to provide 1 second response
> to switch changes and to account for changes in the periodic work specs.
> 
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
> 
> John,
> 
> This should be applied to wireless-2.6. It is a new feature and is
> not appropriate for 2.6.20-rcX. These changes have been tested on
> a PCMCIA card with no wireless switch, A BCM4306 mini-PCI card, and
> a BCM4311 mini-PCIE card.
> 
> Larry
> 
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -2441,6 +2441,9 @@ static int bcm43xx_chip_init(struct bcm4
>   if (err)
>   goto err_gpio_cleanup;
>   bcm43xx_radio_turn_on(bcm);
> + bcm->radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
> + dprintk(KERN_INFO PFX "Radio %s by hardware\n",
> + (bcm->radio_hw_enable == 0) ? "disabled" : "enabled");
>  
>   bcm43xx_write16(bcm, 0x03E6, 0x);
>   err = bcm43xx_phy_init(bcm);
> @@ -3174,9 +3177,24 @@ static void bcm43xx_periodic_every30sec(
>  
>  static void bcm43xx_periodic_every15sec(struct bcm43xx_private *bcm)
>  {
> + bcm43xx_phy_xmitpower(bcm); //FIXME: unless scanning?
> + //TODO for APHY (temperature?)
> +}
> +
> +static void bcm43xx_periodic_every1sec(struct bcm43xx_private *bcm)
> +{
>   struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);
>   struct bcm43xx_radioinfo *radio = bcm43xx_current_radio(bcm);
> + int radio_hw_enable;
>  
> + /* check if radio hardware enabled status changed */
> + radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
> + if (unlikely(bcm->radio_hw_enable != radio_hw_enable)) {
> + bcm->radio_hw_enable = radio_hw_enable;
> + dprintk(KERN_INFO PFX "Radio hardware status changed to %s\n",
> +(radio_hw_enable == 0) ? "disabled" : "enabled");
> + bcm43xx_leds_update(bcm, 0);
> + }
>   if (phy->type == BCM43xx_PHYTYPE_G) {
>   //TODO: update_aci_moving_average
>   if (radio->aci_enable && radio->aci_wlan_automatic) {
> @@ -3200,21 +3218,21 @@ static void bcm43xx_periodic_every15sec(
>   //TODO: implement rev1 workaround
>   }
>   }
> - bcm43xx_phy_xmitpower(bcm); //FIXME: unless scanning?
> - //TODO for APHY (temperature?)
>  }
>  
>  static void do_periodic_work(struct bcm43xx_private *bcm)
>  {
> - if (bcm->periodic_state % 8 == 0)
> + if (bcm->periodic_state % 120 == 0)
>   bcm43xx_periodic_every120sec(bcm);
> - if (bcm->periodic_state % 4 == 0)
> + if (bcm->periodic_state % 60 == 0)
>   bcm43xx_periodic_every60sec(bcm);
> - if (bcm->periodic_state % 2 == 0)
> + if (bcm->periodic_state % 30 == 0)
>   bcm43xx_periodic_every30sec(bcm);
> - bcm43xx_periodic_every15sec(bcm);
> + if (bcm->periodic_state % 15 == 0)
> + bcm43xx_periodic_every15sec(bcm);
> + bcm43xx_periodic_every1sec(bcm);
>  
> - schedule_delayed_work(&bcm->periodic_work, HZ * 15);
> + schedule_delayed_work(&bcm->periodic_work, HZ);
>  }
>  
>  static void bcm43xx_periodic_work_handler(struct work_struct *work)
> @@ -3227,7 +3245,7 @@ static void bcm43xx_periodic_work_handle
>   unsigned long orig_trans_start = 0;
>  
>   mutex_lock(&bcm->mutex);
> - if (unlikely(bcm->periodic_state % 4 == 0)) {
> + if (unlikely(bcm->periodic_state % 60 == 0)) {
>   /* Periodic work will take a long time, so we want it to
>* be preemtible.
>*/
> @@ -3259,7 +3277,7 @@ static void bcm43xx_periodic_work_handle
>  
>   do_periodic_work(bcm);
>  
> - if (unlikely(bcm->periodic_state % 4 == 0)) {
> + if (unlikely(bcm->periodic_state % 60 == 0)) {
>   spin_lock_irqsave(&bcm->irq_lock, flags);
>   tasklet_enable(&bcm->isr_tasklet);
>   bcm43xx_interrupt_enable(bcm, savedirqs);
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_radio.h
> @@ -65,6 +65,22 @@ void bcm43xx_radio_init2060(struct bcm43
>  void bcm43xx_radio_turn_on(struct bcm43xx_private *bcm);
>  void bcm43xx_radio_turn_off(struct bcm43xx_private *bcm);
>  
> +static

Re: [PATCH] bcm43xx-d80211: Interrogate hardware-enable switch and update LEDs

[Michael Buesch]

On Sunday 31 December 2006 06:25, Larry Finger wrote:
> The current bcm43xx driver ignores any wireless-enable switches on mini-PCI
> and mini-PCI-E cards. This patch implements a new routine to interrogate the
> radio hardware enabled bit in the interface, logs the initial state and any
> changes in the switch (if debugging enabled), activates the LED to show the
> state, and changes the periodic work handler to provide 1 second response
> to switch changes and to account for changes in the periodic work specs. It
> also incorporates changes in the LED state that were accepted into mainline
> some time ago.
> 
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>

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

> ---
> 
> Michael,
> 
> This patch is for wireless-idev, and is the same as the patch recently
> submitted for bcm43xx-softmac.  These changes have been tested on
> a PCMCIA card with no wireless switch, A BCM4306 mini-PCI card, and
> a BCM4311 mini-PCIE card.
> 
> Larry
> 
> 
> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
> +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
> @@ -26,6 +26,7 @@
>  */
>  
>  #include "bcm43xx_leds.h"
> +#include "bcm43xx_radio.h"
>  #include "bcm43xx.h"
>  
>  #include 
> @@ -108,6 +109,7 @@ static void bcm43xx_led_init_hardcoded(s
>   switch (led_index) {
>   case 0:
>   led->behaviour = BCM43xx_LED_ACTIVITY;
> + led->activelow = 1;
>   if (bcm->board_vendor == PCI_VENDOR_ID_COMPAQ)
>   led->behaviour = BCM43xx_LED_RADIO_ALL;
>   break;
> @@ -189,26 +191,31 @@ void bcm43xx_leds_update(struct bcm43xx_
>   case BCM43xx_LED_INACTIVE:
>   continue;
>   case BCM43xx_LED_OFF:
> + case BCM43xx_LED_BCM4303_3:
>   break;
>   case BCM43xx_LED_ON:
>   turn_on = 1;
>   break;
>   case BCM43xx_LED_ACTIVITY:
> + case BCM43xx_LED_BCM4303_0:
>   turn_on = activity;
>   break;
>   case BCM43xx_LED_RADIO_ALL:
> - turn_on = radio->enabled;
> + turn_on = radio->enabled && 
> bcm43xx_is_hw_radio_enabled(bcm);
>   break;
>   case BCM43xx_LED_RADIO_A:
> - turn_on = (radio->enabled && phy->type == 
> BCM43xx_PHYTYPE_A);
> + case BCM43xx_LED_BCM4303_2:
> + turn_on = (radio->enabled && 
> bcm43xx_is_hw_radio_enabled(bcm) &&
> +phy->type == BCM43xx_PHYTYPE_A);
>   break;
>   case BCM43xx_LED_RADIO_B:
> - turn_on = (radio->enabled &&
> + case BCM43xx_LED_BCM4303_1:
> + turn_on = (radio->enabled && 
> bcm43xx_is_hw_radio_enabled(bcm) &&
>  (phy->type == BCM43xx_PHYTYPE_B ||
>   phy->type == BCM43xx_PHYTYPE_G));
>   break;
>   case BCM43xx_LED_MODE_BG:
> - if (phy->type == BCM43xx_PHYTYPE_G &&
> + if (phy->type == BCM43xx_PHYTYPE_G && 
> bcm43xx_is_hw_radio_enabled(bcm) &&
>   1/*FIXME: using G rates.*/)
>   turn_on = 1;
>   break;
> @@ -257,7 +264,8 @@ void bcm43xx_leds_update(struct bcm43xx_
>   continue;
>  #endif /* CONFIG_BCM43XX_DEBUG */
>   default:
> - assert(0);
> + dprintkl(KERN_INFO PFX "Bad value in leds_update,"
> + " led->behaviour: 0x%x\n", led->behaviour);
>   };
>  
>   if (led->activelow)
> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.h
> ===
> --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.h
> +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.h
> @@ -46,6 +46,12 @@ enum { /* LED behaviour values */
>   BCM43xx_LED_TEST_BLINKSLOW,
>   BCM43xx_LED_TEST_BLINKMEDIUM,
>   BCM43xx_LED_TEST_BLINKFAST,
> +
> + /* Misc val

Re: BCM4311 problems

[Michael Buesch]

On Saturday 06 January 2007 03:28, Larry Finger wrote:
> Michael,
> 
> With your experience with the bcm43xx and other drivers, I hope you can help 
> me. With my new Turion
> 64 X2 laptop with a Dell 1390 (BCM4311) wireless card, I am getting no 
> transmissions. I don't know
> about received data. If I let it try to scan long enough, I get lots of the 
> following messages logged:
> 
> bcm43xx: Out of DMA descriptor slots!
> 
> When I shut the card down, I get the following slot usage:
> 
> bcm43xx: DMA-32 0x0200 (RX) max used slots: 0/64
> bcm43xx: DMA-32 0x02A0 (TX) max used slots: 0/512
> bcm43xx: DMA-32 0x0280 (TX) max used slots: 0/512
> bcm43xx: DMA-32 0x0260 (TX) max used slots: 0/512
> bcm43xx: DMA-32 0x0240 (TX) max used slots: 0/512
> bcm43xx: DMA-32 0x0220 (TX) max used slots: 512/512
> bcm43xx: DMA-32 0x0200 (TX) max used slots: 0/512
> 
> Obviously, the TX DMA is not getting through. I'm running an x86_64 system. 
> The behavior is the same
> whether I configure SMP or not. This card will not work in PIO mode, so I 
> cannot test it that way.
> I'm a little reluctant to reload an i386 system, but I could if necessary.

knoppix or something?

> When I boot the wireless-dev kernel, it works. I have looked at the 
> differences between wireless-2.6
> and wireless-dev, but I don't see anything other than the obvious design 
> differences.
> 
> Have you seen anything like this before? If so, where should I look? I didn't 
> want to bother you,
> but I'm not making any headway.
> 

You aren't getting TX status interrupts. Why? Well, dunno. v4 firmware perhaps.

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

What is in bcm43xx-wireless-dev.git?

[Michael Buesch]

In case you wonder what's the future of bcm43xx, here's
a list of changes in my bcm43xx development tree:

  bcm43xx-d80211: Add some PHY register definitions.
  bcm43xx-d80211: Move ILT stuff to OFDM table stuff
  bcm43xx-d80211: Remove PHY OFDM routing bit, if we are on A-PHY.
  bcm43xx-d80211: Merge new LO-control code.
  bcm43xx-d80211: Fix compilation: Missing files for LO and VSTACK.
  bcm43xx-d80211: Rename struct bcm43xx_phyinfo to struct bcm43xx_phy
  bcm43xx-d80211: merge struct bcm43xx_radioinfo into struct bcm43xx_phy
  bcm43xx-d80211: Merge all "radio" stuff into phy.c
  bcm43xx-d80211: Fix antenna selection for TX and RX.
  bcm43xx-d80211: Fix bogus LO validation failure.
  bcm43xx-d80211: Remove netpoll and ethtool stuff.
  Remove obsolete SSB driver library.
  Implement new SSB subsystem.
  bcm43xx-d80211: Port driver to the new SSB subsystem.

Well, that doesn't tell you anything, right?
Let's explain it:

Most significant changes are the new "LO" code and
the completely rewritten "SSB" subsystem.

The LO calibration code is not yet finished and contains
a few bugs, so it works _worse_ that the LO calibration
code that's in mainline kernel. But it's the first step
in the direction to support hwpctl cards (4318).

The other major change is the new SSB subsystem. This is
a big step in the embedded direction. The new SSB subsystem
makes it possible to run an (almost) vanilla (vanilla, as in
my tree, which is supposed to get merged upstream some time :))
kernel on broadcom MIPS based embedded WLAN routers (openWRT).

bcm43xx works on the new subsystem. A working b44 port is
available, but not included here. We might probably want to
merge that through jeff directly once this is upstream.
The SSB subsystem is able to boot my Linksys WRT54G.
Wireless and LAN with SSB based chips basically works.

So, what to do?
Next think will be to fix the LO code to make it ready
for upstream merge. I don't know if that means "making
4318 usable", too. Hopefully it does. Let's see. ;)

If you want to test this, get it from my repository.
If you have a linville-wireless-dev tree around, please
_don't_ clone my tree, but simply pull my stuff into
a seperate branch of that tree:

git branch crazy_stuff
git checkout crazy_stuff
git pull http://bu3sch.de/git/wireless-dev.git master

That will save lots of bandwidth. (Yours and mine) Thanks! ;)

Here's also a bzipped patch between today's linville-wireless-dev
and my tree. Yeah, it's huge, so not attached. :)

http://bu3sch.de/misc/linville_to_buesch_20070111.patch.bz2

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

Re: [PATCH] bcm43xx: Fix failure to deliver PCI-E interrupts

[Michael Buesch]

On Friday 12 January 2007 18:54, Stephen Sinclair wrote:
> > That's redundant. If it's not a PCI core, it must be a PCIE core.
> 
> Not to be too blunt, but isn't that sort of sloppy logic?
> Imho it's always better to check what something _is_ rather than what
> something _isn't_.
> The two are only semantically the same in a binary universe. (i.e.,
> PCI vs. PCI-E)
> Of course that's the case right now, but the former logic is more 
> future-proof.

Heh, well, I see your point, but I don't think explicitely
checking for PCI/E cores here does any good, because even if
we specialcase the two core types it will break as soon as
a new PCI-foobar core/bus is released. ;)
So it's broken in either way. Maybe your way is less broken
then mine, or not. But does that really matter, if it crashes
in either way? hehe :)

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

Re: Various patches for PCI-E and radio-enable switches

[Michael Buesch]

On Friday 12 January 2007 20:22, Larry Finger wrote:
> As noted in this list earlier today, there is now a patch that makes PCI-E 
> interfaces work. It has
> only been tested with Dell Wireless 1390 cards (BCM4311), but should also 
> work for BCM4312s. The
> receive level for the 4311 is excellent, but the transmit levels are very 
> weak. Copying of a test
> file of mine takes 7 sec. with a BCM4306. With the BCM4311, it takes a little 
> over 3 minutes given
> the retransmits, etc. Now that the card works (?), my next step is to try to 
> find why the radio has
> such low power.

It is the same problem as with the 4318 cards.

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

Re: Various patches for PCI-E and radio-enable switches

[Michael Buesch]

On Friday 12 January 2007 21:26, Larry Finger wrote:
> Michael Buesch wrote:
> > On Friday 12 January 2007 20:22, Larry Finger wrote:
> >> As noted in this list earlier today, there is now a patch that makes PCI-E 
> >> interfaces work. It has
> >> only been tested with Dell Wireless 1390 cards (BCM4311), but should also 
> >> work for BCM4312s. The
> >> receive level for the 4311 is excellent, but the transmit levels are very 
> >> weak. Copying of a test
> >> file of mine takes 7 sec. with a BCM4306. With the BCM4311, it takes a 
> >> little over 3 minutes given
> >> the retransmits, etc. Now that the card works (?), my next step is to try 
> >> to find why the radio has
> >> such low power.
> > 
> > It is the same problem as with the 4318 cards.
> > 
> 
> I think (and hope) so. I didn't get much time with the 4318 card before my 
> laptop died, and I have
> an Express Card slot on the new one, not a PCMCIA slot. Technology moves too 
> quickly sometimes. I
> can still test the 4318 in the old computer, but it won't be easy to debug 
> there.
> 
> Do you have any thoughts/tentative fixes?

At the moment I am working on the new LO stuff in my tree.
It's horribly broken, but that's the way to fix it.
It seems to be completely non-working on my 4318. Let's see why...
I think there are a bunch of typos in the magic PHY register stuff.
Sometimes a single swapped number makes the operation completely broken.

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

Re: What is in bcm43xx-wireless-dev.git?

[Michael Buesch]

On Friday 12 January 2007 08:25, Pavel Roskin wrote:
> Hello, Michael!
> 
> I've tried the master branch of bcm43xx-wireless-dev.git for the first
> time.  The results are not encouraging so far (although I'm quite new to
> this chipset).
> 
> drivers/ssb/driver_mips/mips.c includes asm/time.h, which is missing on
> x86_64.  It also refers to struct ssb_serial_ports, which is not defined
> anywhere.

Yeah, CONFIG_SSB_MIPS should depend on the MIPS CPU.
Which kconfig option do you suggest to make a "depend" on?

> drivers/ssb/driver_pci/pcicore.c refers to SSB_PCICORE_SBTOPCI1_CFG1
> that is not defined anywhere in the kernel.

Yeah, could be a typo. I'll have a look at it.

> I could send you huge logs, but I think it's already a clear sign that
> you didn't compile-test the current tree with CONFIG_SSB_DRIVER_MIPS
> enabled.  Things are better if it is disabled.

It is tested. But obviously on MIPS platform.

> In case you haven't seen those warnings:
> 
> /home/proski/src/linux-2.6/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:843:
>  warning: 'bcm43xx_wireless_core_mark_inactive' defined but not used
> /home/proski/src/linux-2.6/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:3032:
>  warning: 'bcm43xx_bluetooth_coext_enable' defined but not used

I am very well aware of these warnings, as they mark
unimplemented features.

> I could compile the code, and it even loaded as a module, but the kernel
> oopsed once I brought wlan0 up by ifconfig.
> 
> bcm43xx_d80211: Adding Interface type 2
> bcm43xx_d80211: Found PHY: Version 4, Type 2, Revision 8
> bcm43xx_d80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
> bcm43xx_d80211: Loading firmware version 351.126 (2006-07-29 05:54:02)
> bcm43xx_d80211: Radio turned on
> bcm43xx_d80211: FIXME: Possibly broken code in bcm43xx_phy_initg() at 
> /home/proski/src/linux-2.6/drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c:1650
> bcm43xx_d80211: Chip initialized
> Unable to handle kernel NULL pointer dereference at  RIP: 
>  [] dma_alloc_coherent+0x52/0x23f
> PGD 50d1067 PUD 5201067 PMD 0 
> Oops:  [1] SMP 
> CPU 1 
> Modules linked in: bcm43xx_d80211 ssb
> Pid: 2623, comm: ifconfig Not tainted 2.6.20-rc3 #5
> RIP: 0010:[]  [] 
> dma_alloc_coherent+0x52/0x23f
> RSP: 0018:810005127bd8  EFLAGS: 00010206
> RAX:  RBX: 3500 RCX: 10d4
> RDX:  RSI: 1000 RDI: 81000196c3a8
> RBP: 10d0 R08: 81001f6d1600 R09: 0004
> R10: 0001 R11: 810001122c60 R12: 1000
> R13: 810001b96000 R14: 81000196c3a8 R15: 
> FS:  2b411b2133b0() GS:810001827440() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2:  CR3: 15fdf000 CR4: 06e0
> Process ifconfig (pid: 2623, threadinfo 810005126000, task 
> 81001f58d180)
> Stack:  81001ee6a3c0 81001ee6a3e8 810001b96000 3500
>  81001ee6a3c0 0080 810001b96000 
>   88019966 0005 00010036
> Call Trace:
>  [] :bcm43xx_d80211:bcm43xx_setup_dmaring+0x1a7/0x460
>  [] :bcm43xx_d80211:bcm43xx_dma_init+0xc0/0x290
>  [] :bcm43xx_d80211:bcm43xx_wireless_core_init+0x78f/0x9f1
>  [] mntput_no_expire+0x19/0x77
>  [] do_page_fault+0x40b/0x74a
>  [] :bcm43xx_d80211:bcm43xx_add_interface+0x67/0xeb
>  [] ieee80211_open+0x1c6/0x2c5
>  [] dev_open+0x2f/0x6e
>  [] dev_change_flags+0x5a/0x119
>  [] devinet_ioctl+0x235/0x59c
>  [] sock_ioctl+0x1c8/0x1e5
>  [] do_ioctl+0x21/0x6b
>  [] vfs_ioctl+0x25c/0x275
>  [] sys_ioctl+0x3c/0x5c
>  [] system_call+0x7e/0x83
> 
> 
> Code: 4c 23 38 49 39 d7 0f 46 e9 49 8d 44 24 ff 83 ca ff 49 89 c5 
> RIP  [] dma_alloc_coherent+0x52/0x23f
>  RSP 
> CR2: 

Hm, not sure why this oopses. It works on PPC (can transmit data and so on).

> It's Fedora Core 6 x86_64 on a Dell Latitude with Core 2 Duo and an PCIe
> wireless card.  SMP is enabled.  From .config:

PCIe is a seperate issue and not really supported by bcm43xx.

> CONFIG_BCM43XX_D80211=m
> CONFIG_BCM43XX_D80211_PCI=y
> CONFIG_BCM43XX_D80211_DEBUG=y
> CONFIG_BCM43XX_D80211_DMA=y
> CONFIG_BCM43XX_D80211_PIO=y
> CONFIG_BCM43XX_D80211_DMA_AND_PIO_MODE=y
> # CONFIG_BCM43XX_D80211_DMA_MODE is not set
> # CONFIG_BCM43XX_D80211_PIO_MODE is not set
> [skip]
> CONFIG_SSB=m
> # CONFIG_SSB_SILENT is not set
> # CONFIG_SSB_DEBUG is not set
> CONFIG_SSB_DRIVER_EXTIF=y

You can disable that. I think that should probably depend
on CONFIG_SSB_DRIVER_MIPS. I'll take a look.

> # CONFIG_SSB_DRIVER_MIPS is not set
> 
> [EMAIL PROTECTED] proski]# lspci -v -s 0c:00.0
> 0c:00.0 Network controller: Broadcom Corporation BCM4310 UART (rev 01)
> Subsystem: Dell Unknown device 0007
> Flags: bus master, fast devsel, latency 0, IRQ 17
> Memory at efdfc000 (32-bit, non-prefetchable) [size=16K]
> Capabil

Re: [PATCH] bcm43xx: Fix failure to deliver PCI-E interrupts

[Michael Buesch]

On Friday 12 January 2007 05:52, Larry Finger wrote:
> The PCI-E modifications to bcm43xx do not set up the interrupt vector
> correctly.
> 
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
> 
> John,
> 
> This fix should be applied to wireless-2.6 _AND_ pushed upstream to
> 2.6.20-rcX. Without this patch, none of the PCI-E interfaces will work.
> 
> Larry
> 
> 
> Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===
> --- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -2704,7 +2704,7 @@ static int bcm43xx_probe_cores(struct bc
>   sb_id_hi = bcm43xx_read32(bcm, BCM43xx_CIR_SB_ID_HI);
>  
>   /* extract core_id, core_rev, core_vendor */
> - core_id = (sb_id_hi & 0xFFF0) >> 4;
> + core_id = (sb_id_hi & 0x8FF0) >> 4;

ACK. That one fixes a bug.

>   core_rev = (sb_id_hi & 0xF);

This is also buggy. Should be something like:

core_rev = ((sb_id_hi & 0xF) | ((sb_id_hi & 0x7000) >> 8));

>   core_vendor = (sb_id_hi & 0x) >> 16;
>  
> @@ -2717,7 +2717,7 @@ static int bcm43xx_probe_cores(struct bc
>   case BCM43xx_COREID_PCIE:
>   core = &bcm->core_pci;
>   if (core->available) {
> - printk(KERN_WARNING PFX "Multiple PCI cores 
> found.\n");
> + printk(KERN_WARNING PFX "Multiple PCI/PCI-E 
> cores found.\n");
>   continue;
>   }
>   break;
> @@ -2872,11 +2872,14 @@ static int bcm43xx_wireless_core_init(st
>   u32 sbimconfiglow;
>   u8 limit;
>  
> - if (bcm->core_pci.rev <= 5 && bcm->core_pci.id != BCM43xx_COREID_PCIE) {
> + if (bcm->core_pci.rev <= 5 && bcm->core_pci.id == BCM43xx_COREID_PCI) {

That's semantically equal.

>   sbimconfiglow = bcm43xx_read32(bcm, BCM43xx_CIR_SBIMCONFIGLOW);
>   sbimconfiglow &= ~ BCM43xx_SBIMCONFIGLOW_REQUEST_TOUT_MASK;
>   sbimconfiglow &= ~ BCM43xx_SBIMCONFIGLOW_SERVICE_TOUT_MASK;
> - sbimconfiglow |= 0x32;
> + if (bcm->bustype == BCM43xx_BUSTYPE_PCI)
> + sbimconfiglow |= 0x32;
> + else
> + sbimconfiglow |= 0x53;

That used to be there until someone ripped it out (not me). Not sure why.

>   bcm43xx_write32(bcm, BCM43xx_CIR_SBIMCONFIGLOW, sbimconfiglow);
>   }
>  
> @@ -3070,6 +3073,7 @@ static int bcm43xx_setup_backplane_pci_c
>   u32 backplane_flag_nr;
>   u32 value;
>   struct bcm43xx_coreinfo *old_core;
> + struct bcm43xx_coreinfo *pci_core = &bcm->core_pci ;
>   int err = 0;
>  
>   value = bcm43xx_read32(bcm, BCM43xx_CIR_SBTPSFLAG);
> @@ -3080,26 +3084,22 @@ static int bcm43xx_setup_backplane_pci_c
>   if (err)
>   goto out;
>  
> - if (bcm->current_core->rev < 6 ||
> - bcm->current_core->id == BCM43xx_COREID_PCI) {
> - value = bcm43xx_read32(bcm, BCM43xx_CIR_SBINTVEC);
> - value |= (1 << backplane_flag_nr);
> - bcm43xx_write32(bcm, BCM43xx_CIR_SBINTVEC, value);
> - } else {
> + if ((pci_core->rev >= 6) || (pci_core->id == BCM43xx_COREID_PCIE)) {
>   err = bcm43xx_pci_read_config32(bcm, BCM43xx_PCICFG_ICR, 
> &value);
> - if (err) {
> - printk(KERN_ERR PFX "Error: ICR setup failure!\n");
> + if (err)
>   goto out_switch_back;
> - }
>   value |= core_mask << 8;
>   err = bcm43xx_pci_write_config32(bcm, BCM43xx_PCICFG_ICR, 
> value);
> - if (err) {
> - printk(KERN_ERR PFX "Error: ICR setup failure!\n");
> + if (err)
>   goto out_switch_back;
> - }
> + } else {
> +err = -EINVAL;
> +value = bcm43xx_read32(bcm, BCM43xx_CIR_SBINTVEC);
> + value |= 1 << backplane_flag_nr;
> +bcm43xx_write32(bcm, BCM43xx_CIR_SBINTVEC, value);
>   }

The above doesn't change semantics. Or am I simply not seeing it? :)
Seems that it just shuffles the code.

>  
> - if (bcm->current_core->id == BCM43xx_COREID_PCI) {
> + if (pci_core->id == BCM43xx_COREID_PCI) {

That's semantically equal.

>   value = bcm43xx_read32(bcm, BCM43xx_PCICORE_SBTOPCI2);
>   value |= BCM43xx_SBTOPCI2_PREFETCH | BCM43xx_SBTOPCI2_BURST;
>   bcm43xx_write32(bcm, BCM43xx_PCICORE_SBTOPCI2, value);
> @@ -3118,21 +3118,21 @@ static int bcm43xx_setup_backplane_pci_c
>   value |= BCM43xx_SBTOPCI2_MEMREAD_MULTI;
>   bcm43xx_write32(bcm, BCM43xx_PCICORE_SBTOPCI2, value);
>   }
> - } else {
> - if (bcm->current_core->

Re: [PATCH] bcm43xx: Fix failure to deliver PCI-E interrupts

[Michael Buesch]

On Friday 12 January 2007 17:36, Larry Finger wrote:
> Michael Buesch wrote:
> 
> I have one general question before I address your comments. Does a BCM43xx 
> chip always have either a
> PCI or a PCI-E core? I've seen discussion on this list that makes me wonder. 
> That is why I had some
> explicit tests for PCI-E in the code.

Ok, I see your point.
I don't think we have devices without PCI core.
BUT:
If you think there are devices without a PCI core, you
must not switch to it in the first place. So your check is
worthless nevertheless, because in case of no PCI core you
have crashed much earlier anyway. ;)

If we have a PCI core (and I think we always have), it can only
be PCI or PCIE.

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

Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

[Michael Buesch]

On Friday 12 January 2007 19:08, Larry Finger wrote:
> The PCI-E modifications to bcm43xx do not set up the interrupt vector
> correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.
> 
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>

ACK.

> ---
> 
> John,
> 
> This fix should be applied to wireless-2.6 _AND_ pushed upstream to
> 2.6.20-rcX. Without this patch, none of the PCI-E interfaces will work.
> This version incorporates Michael Buesch's comments, and forgoes some
> code clean-ups that were in the first version/
> 
> Larry
> 
> 
> Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===
> --- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -2704,8 +2704,8 @@ static int bcm43xx_probe_cores(struct bc
>   sb_id_hi = bcm43xx_read32(bcm, BCM43xx_CIR_SB_ID_HI);
>  
>   /* extract core_id, core_rev, core_vendor */
> - core_id = (sb_id_hi & 0xFFF0) >> 4;
> - core_rev = (sb_id_hi & 0xF);
> + core_id = (sb_id_hi & 0x8FF0) >> 4;
> + core_rev = ((sb_id_hi & 0xF) | ((sb_id_hi & 0x7000) >> 8));
>   core_vendor = (sb_id_hi & 0x) >> 16;
>  
>   dprintk(KERN_INFO PFX "Core %d: ID 0x%x, rev 0x%x, vendor 
> 0x%x\n",
> @@ -2876,7 +2876,10 @@ static int bcm43xx_wireless_core_init(st
>   sbimconfiglow = bcm43xx_read32(bcm, BCM43xx_CIR_SBIMCONFIGLOW);
>   sbimconfiglow &= ~ BCM43xx_SBIMCONFIGLOW_REQUEST_TOUT_MASK;
>   sbimconfiglow &= ~ BCM43xx_SBIMCONFIGLOW_SERVICE_TOUT_MASK;
> - sbimconfiglow |= 0x32;
> + if (bcm->bustype == BCM43xx_BUSTYPE_PCI)
> + sbimconfiglow |= 0x32;
> + else
> + sbimconfiglow |= 0x53;

This hunk is OK, but I just want to point out that bustype is
always equal to BCM43xx_BUSTYPE_PCI ;)
The 0x53 timeouts are for an SSB-BUS.
So strictly said this hunk is a NOP.

The other hunks are OK, too. They fix real bugs.
Thanks for spotting them, Larry!

>   bcm43xx_write32(bcm, BCM43xx_CIR_SBIMCONFIGLOW, sbimconfiglow);
>   }
>  
> @@ -3080,7 +3083,7 @@ static int bcm43xx_setup_backplane_pci_c
>   if (err)
>   goto out;
>  
> - if (bcm->current_core->rev < 6 ||
> + if (bcm->current_core->rev < 6 &&
>   bcm->current_core->id == BCM43xx_COREID_PCI) {
>   value = bcm43xx_read32(bcm, BCM43xx_CIR_SBINTVEC);
>   value |= (1 << backplane_flag_nr);
> 
> ---
> 
> 

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

Re: [PATCH V2] bcm43xx: Fix failure to deliver PCI-E interrupts

[Michael Buesch]

On Friday 12 January 2007 19:50, Stephen Sinclair wrote:
> > The PCI-E modifications to bcm43xx do not set up the interrupt vector
> > correctly. Tested with BCM4311 (PCI-E) on x86_64 and BCM4306 (PCI) on i386.
> 
> This was successful for me.  My 4311 is now getting interrupts, and I
> was able to successfully associate with an AP.  (i386)

That does the (i386) mean here?
Were you able to accociate with your PCI or PCI-E card?

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

Re: What is in bcm43xx-wireless-dev.git?

[Michael Buesch]

On Saturday 13 January 2007 08:45, Pavel Roskin wrote:
> Quoting Michael Buesch <[EMAIL PROTECTED]>:
> 
> > > drivers/ssb/driver_mips/mips.c includes asm/time.h, which is missing on
> > > x86_64.  It also refers to struct ssb_serial_ports, which is not defined
> > > anywhere.
> >
> > Yeah, CONFIG_SSB_MIPS should depend on the MIPS CPU.
> > Which kconfig option do you suggest to make a "depend" on?
> 
> I try not to add artificial restrictions.  The driver should depend on the
> components providing the necessary API.

Ehm, it is clearly not artificial. The MIPS core depends on the MIPS
platform. Logically and technically. You must not enable it on
non-MIPS platforms, as it's tied with the internals of the MIPS
arch dependent code.

The only logical way to solve the compile issues are to make a dependency
on the MIPS platform.

> > > drivers/ssb/driver_pci/pcicore.c refers to SSB_PCICORE_SBTOPCI1_CFG1
> > > that is not defined anywhere in the kernel.
> >
> > Yeah, could be a typo. I'll have a look at it.
> 
> I only found it because the driver didn't depend on MIPS.  See what I mean?
> 
> This only manifests if CONFIG_SSB_PCICORE_HOSTMODE is defined, and it is only
> selected by CONFIG_SSB_DRIVER_MIPS.

HOSTMODE is not really tested, yet.
And HOSTMODE is _also_ very closely tied to the MIPS platform. So
it must depend on it, too (probably indirectly through the MIPS core driver).

To be honest, I did not even compiletest the HOSTMODE code, as I don't
even have a device for it. But I am going to fix that before pushing stuff
upstream.

> > Hm, not sure why this oopses. It works on PPC (can transmit data and so on).
> 
> My PPC machine is a venerable Blue&White G3, so it won't take PCIe.

I looked more closely at it, but I really can't see why it oopses.
Any idea what's happening there?

> > Does it work with linville's tree (in DMA mode)?
> 
> Yes, it does.  I couldn't connect to the AP, but it's a different story.  I 
> may
> be doing things wrong.  At least I can scan and I see the APs around.

Well, ok. So it should work in my tree, too, once we fixed the DMA oops.

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

Re: Various patches for PCI-E and radio-enable switches

[Michael Buesch]

On Friday 12 January 2007 22:13, Larry Finger wrote:
> Daniel wrote:
> > I know it's working out of the box, but could I still make a developper 
> > happy with an asus wl-100g? Recently replaced it with a Netgear WG500T 
> 
> What is the chip in the wl-100g? The web told me it is Broadcom, but not the 
> flavor.

4306. I have one. It works pretty good.

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

Re: What is in bcm43xx-wireless-dev.git?

[Michael Buesch]

On Saturday 13 January 2007 20:30, Pavel Roskin wrote:
> Quoting Michael Buesch <[EMAIL PROTECTED]>:
> 
> > I looked more closely at it, but I really can't see why it oopses.
> > Any idea what's happening there?
> 
> I haven't looked at the code yet, but I tried to locate the bad commit.  I 
> tried
> commit a13f85d8a8eb40dfd157ab78c2fb91b5765b7b9d, which is your last merge, 
> just
> before the SSB changes.

Yeah, sure. I know that this is the commit which introduced this.

> The kernel doesn't oops anymore!  But it doesn't connect either.  I 
> reconfigured
> the AP to use WPA-PSK with TKIP.  MadWifi works with it, but bcm43xx fails in
> the same configuration.  The wireless-dev tip has the same problem.

Note that LO calibration is horribly broken in my tree.
So you have a very weak signal, if any. My 4318 has no signal, for example.
So basically don't expect to be able to transmit any data.
This includes association.

But I think you should be able to assoc with a plain linville tree.

> So, the oops was introduced in the transition to the new SSB. 
> bcm43xx_setup_dmaring(), which appears in the stack dump, is affected by the
> patch.

Yeah, but I don't see where we can get such an oops from :)

> I'll try to look closely at the changes.  My immediate suspect is that we have
> too many different fields called "dev".  All it takes is one cast to hide a
> horrible mistake.  Although I think it would have affected you as well (unless

We don't cast devs.

> it's casts to/from integers, something that won't be a problem on 32-bit
> kernels).

dito.

> > Well, ok. So it should work in my tree, too, once we fixed the DMA oops.
> 
> You mean there is a reason for me to think that your changes would fix
> accociation to the AP?

No.


We oops in dma_alloc_coherent, right?
Where can we get a NULL pointer there? I don't see it. Any idea?
Also, regarding to the oops message, it's oopsing somewhere at
the beginning of the function.

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

Re: What is in bcm43xx-wireless-dev.git?

[Michael Buesch]

On Sunday 14 January 2007 03:10, Pavel Roskin wrote:
> Quoting Michael Buesch <[EMAIL PROTECTED]>:
> 
> > > I haven't looked at the code yet, but I tried to locate the bad commit.  I
> > tried
> > > commit a13f85d8a8eb40dfd157ab78c2fb91b5765b7b9d, which is your last merge,
> > just
> > > before the SSB changes.
> >
> > Yeah, sure. I know that this is the commit which introduced this.
> 
> Basically, you set up DMA on the PCI device, but use it on the SSB device.
> That's inconsistent.  dma_alloc_coherent() is very picky on x86_64 and crashes
> if dev->dma_mask is NULL, which was the case for the SSB device.
> 
> Looking at the patch, it's clear that the SSB device is used instead of the 
> PCI
> device in some places.  I restored the old logic.  If you meant to switch to
> SSB devices, then please remove the last PCI references from that file.

Already done. Please pull my tree and check if it still crashes.

> The patch is attached.  It fixes the crash.  I didn't check that it's 
> complete.
> I really don't like the long chain of dereferences, and I hope you'll come up
> with something better.

No. I don't think we have shorter chains in other subsystems like PCI. They
are just hidden.

We could probably get rid of one level in the DMA code, by embedding the DMA
structs into the device struct. But I think there are more important things
to do at the moment.

> I still cannot associate.  The kernel log is attached.  Notice massive 
> assertion
> failures.
> 
> > Note that LO calibration is horribly broken in my tree.
> 
> I guess that's what the assertion failures are about.

You're right.

> > So you have a very weak signal, if any. My 4318 has no signal, for example.
> > So basically don't expect to be able to transmit any data.
> > This includes association.
> 
> Actually, I could scan, and I got 7 access points around.  Only one is in my
> apartment.

RX sensitivity is not quite as bad.

> > But I think you should be able to assoc with a plain linville tree.
> 
> Nope.  Although I got DadWifi to work, and this message will we sent over it.
> So it's not like I'm missing something essential about d80211 stack.

Well, I don't really know what to do all about this.
It's strange. I have people reporting that exactly the same cards work
and people reporting that exactly the same cards don't work over and
over again.
So, well. What to do? :)

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

Re: What is in bcm43xx-wireless-dev.git?

[Michael Buesch]

On Sunday 14 January 2007 15:18, Pavel Roskin wrote:
> Quoting Michael Buesch <[EMAIL PROTECTED]>:
> 
> > Already done. Please pull my tree and check if it still crashes.
> 
> The crash is gone!  Thanks!  Still no association though.

Ok, nice.
Can you send me a complete dmesg log after you brought up the card
and tried to assoc/send some packets?

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

Re: What is in bcm43xx-wireless-dev.git?

[Michael Buesch]

On Sunday 14 January 2007 17:39, Pavel Roskin wrote:
> Quoting Michael Buesch <[EMAIL PROTECTED]>:
> 
> > Ok, nice.
> > Can you send me a complete dmesg log after you brought up the card
> > and tried to assoc/send some packets?
> 
> Attached.

Ok, thanks. I don't see something unusual.

You should try to monitor traffic and see if the card is able to
transmit packets. It seems like it's able to receive.

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

Can someone please try...

[Michael Buesch]

...the bcm43xx driver in my tree with a 4318 chip?
The code there works excellent with my 4306 now, but I can't
get it to work with my 4318. It's strange, it doesn't seem
to work at all. I don't seem to be able to TX and RX any packet.
Not sure why.

To get it, please try to avoid cloning the whole tree
from my repository to avoid unnecessary bandwidth wasting.
If you have a linville-wireless-dev tree, you can do the
following:

cd wireless-dev
git branch mb
git checkout mb
git pull http://bu3sch.de/git/wireless-dev.git master

I think this should also work if you have a linus-2.6 tree
checked out somewhere.

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

Re: Can someone please try...

[Michael Buesch]

On Tuesday 16 January 2007 19:29, Pavel Roskin wrote:
> On Tue, 2007-01-16 at 18:06 +0100, Michael Buesch wrote:
> > ...the bcm43xx driver in my tree with a 4318 chip?
> 
> Things are progressing for me a bit because I observed an association to
> an AP with no security.  I still had to use wpa_supplicant.
> 
> Unfortunately, there is a bigger issue with the new code.  When I
> interrupt wpa_supplicant, the kernel reports several oopses and then
> panics, so I have to reboot.  I had to use serial console just to
> capture the messages.
> 
> I assume the first message is most relevant.  Here it is:

A patch for that is already upstream.
It's surprising that it doesn't happen for me, though.
Neiter on PPC, nor on i386.

Patch was
[PATCH] bcm43xx-d80211: Fix DMA TX skb doublefree

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

Re: Can someone please try...

[Michael Buesch]

On Tuesday 16 January 2007 20:00, Andreas Schwab wrote:
> Michael Buesch <[EMAIL PROTECTED]> writes:
> 
> > ...the bcm43xx driver in my tree with a 4318 chip?
> > The code there works excellent with my 4306 now, but I can't
> > get it to work with my 4318.
> 
> Doesn't work for me either.  I cannot get it to associate to the AP.

Ok, let's see.
I found a few other bugs. But I can't make any promises when
I'll find all of them. ;)

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

Re: Can someone please try...

[Michael Buesch]

On Tuesday 16 January 2007 22:50, Pavel Roskin wrote:
> On Tue, 2007-01-16 at 20:23 +0100, Michael Buesch wrote:
> 
> > A patch for that is already upstream.
> 
> I don't see it.  It's not in your tree yet.

It is on its way upstream to linville.

> > It's surprising that it doesn't happen for me, though.
> > Neiter on PPC, nor on i386.
> 
> It did happen for me on i386, as well as on x86_64.  The dump was for
> x86_64, as evidenced by the register size.  Maybe you have less
> debugging options enabled?

All.

> > Patch was
> > [PATCH] bcm43xx-d80211: Fix DMA TX skb doublefree
> 
> Even with this hint, I cannot spot the bug immediately, so it would be
> great if you sync the public repository soon.

Linville has to put the patch into his tree first, so I can pull it.
You can find the patch easily by searching bcm43xx-dev or netdev
archives.

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

Re: Can someone please try...

[Michael Buesch]

On Wednesday 17 January 2007 00:51, Pavel Roskin wrote:
> On Tue, 2007-01-16 at 23:07 +0100, Michael Buesch wrote:
> > On Tuesday 16 January 2007 22:50, Pavel Roskin wrote:
> > > On Tue, 2007-01-16 at 20:23 +0100, Michael Buesch wrote:
> > > 
> > > > A patch for that is already upstream.
> > > 
> > > I don't see it.  It's not in your tree yet.
> > 
> > It is on its way upstream to linville.
> 
> Well, it's pretty cruel to ask others to test code with known fatal
> bugs, IMHO.

I forgot that the bug was there, because it doesn't trigger on my
machines. I already explained that...

> Even it git were extremely poor at handling a patch applied 
> in two branches.  In fact, git is not so bad at all at handling such
> situations.

I have to wait until linville pulls it. Fullstop.

> > > > It's surprising that it doesn't happen for me, though.
> > > > Neiter on PPC, nor on i386.
> > > 
> > > It did happen for me on i386, as well as on x86_64.  The dump was for
> > > x86_64, as evidenced by the register size.  Maybe you have less
> > > debugging options enabled?
> > 
> > All.
> 
> That's commendable.  I tried the 32-bit kernel without SMP and with
> almost all debugging.  One thing I noticed is that scanning ignores the
> pure 802.11b AP running HostAP that I was going to use for testing.
> Other APs are detected.  The association didn't work, probably for that
> reason.

Probably some d80211 bug. Dunno.

> Scanning may trigger many assertion failures:
> 
> bcm43xx_d80211: ASSERTION FAILED ((lna & ~0x7) == 0)
> at: /home/proski/src/linux-2.6/drivers/net/
> wireless/d80211/bcm43xx/bcm43xx_lo.c:235:lo_measure_feedthrough()

It's not triggered by scanning, it's known and it's nonfatal.

> Finally, interrupting wpa_supplicant hits another bug:
> 
> BUG: unable to handle kernel paging request at virtual address c3e2cbf8
>  printing eip:
> e03835e1
> *pde = f067
> *pte = 03e2c000
> Oops: 0002 [#1]
> DEBUG_PAGEALLOC
> Modules linked in: bcm43xx_d80211 ssb
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00210282   (2.6.20-rc3 #3)
> EIP is at bcm43xx_wireless_core_init+0x5a/0x98e [bcm43xx_d80211]
> eax:    ebx: c3dab740   ecx: 00e1   edx: c3493808
> esi: c34937f8   edi: c3e2cbf8   ebp: c3e60e38   esp: c3e60db8
> ds: 007b   es: 007b   ss: 0068
> Process wpa_supplicant (pid: 2942, ti=c3e6 task=c3f92590 task.ti=c3e6)
> Stack: c0339db6 c0339db6  c3f92590 c0339db6 00200246 c3e60df0 
> c3f3 
>c3dab740 c0339de4 c3493808 c3e60e0c c3e60e0c 00200246 c3e60e2c 
> c0339dc0 
> 0002 c0339de4 c3e60e50 c3f92590   
>  
> Call Trace:
>  [] show_trace_log_lvl+0x1a/0x2f
>  [] show_stack_log_lvl+0x9b/0xa3
>  [] show_registers+0x191/0x267
>  [] die+0x113/0x212
>  [] do_page_fault+0x43a/0x50c
>  [] error_code+0x74/0x7c
>  [] bcm43xx_add_interface+0x4f/0xb7 [bcm43xx_d80211]
>  [] ieee80211_open+0x19d/0x27e
>  [] dev_open+0x2d/0x64
>  [] dev_change_flags+0x51/0xf1
>  [] devinet_ioctl+0x235/0x53a
>  [] inet_ioctl+0x73/0x91
>  [] sock_ioctl+0x1ac/0x1c9
>  [] do_ioctl+0x1c/0x51
>  [] vfs_ioctl+0x1fb/0x212
>  [] sys_ioctl+0x31/0x49
>  [] sysenter_past_esp+0x5f/0x99
>  ===
> Code: 00 80 66 0d ef 8d be 9c 01 00 00 f3 ab 8b 7a 5c 80 62 49 c5 c7 42 4c ff 
> ff ff ff 85 ff c7 
> 42 50 00 00 00 00 74 13 b9 e1 00 00 00  ab 8b 42 5c 66 c7 80 76 03 00 00 
> ff ff 8b 4d a8 89 f
> 0 c7 41 
> EIP: [] bcm43xx_wireless_core_init+0x5a/0x98e [bcm43xx_d80211] 
> SS:ESP 0068:c3e60db8

Doesn't happen for me. I have no idea what's happening.
Care to debug it?
But it's weird that _killing_ the supplicant calls add_interface.
I'd expect it to call remove_interface.

> Then I used MadWifi on the AP side, and "iwpriv scan" picked it.
> Moreover, wpa_supplicant reported connection!  I interrupted
> wpa_supplicant and started it again, and then the kernel oopsed again.
> Strangely, the driver is not even mentioned in the backtrace.
> 
> BUG: unable to handle kernel NULL pointer dereference at virtual address 
> 0004
>  printing eip:
> c02d8863
> *pde = 
> Oops: 0002 [#1]
> DEBUG_PAGEALLOC
> Modules linked in: bcm43xx_d80211 ssb
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00210246   (2.6.20-rc3 #3)
> EIP is at datagram_poll+0xba/0xc5
> eax:    ebx: cc252bf8   ecx: 0049   edx: 
> esi: 0002   edi: 0004   ebp: cb940b70   esp: cb940b68
> ds: 007b   es: 007b   ss: 0068
> Process wpa_supplicant (pid: 4344, ti=cb94 task

Re: [PATCH] bcm43xx: Check error returns in initialization routines

[Michael Buesch]

On Friday 19 January 2007 05:06, Larry Finger wrote:
> A number of the calls in the initialization routines fail to check the 
> returned value for
> errors. This patch adds the necessary checks and logs any errors found when 
> appropriate.

ACK

> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
> 
> To be applied to wireless-2.6.
> 
> 
> Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -2980,8 +2980,10 @@ static int bcm43xx_chipset_attach(struct
>   err = bcm43xx_pctl_set_crystal(bcm, 1);
>   if (err)
>   goto out;
> - bcm43xx_pci_read_config16(bcm, PCI_STATUS, &pci_status);
> - bcm43xx_pci_write_config16(bcm, PCI_STATUS, pci_status & 
> ~PCI_STATUS_SIG_TARGET_ABORT);
> + err = bcm43xx_pci_read_config16(bcm, PCI_STATUS, &pci_status);
> + if (err)
> + goto out;
> + err = bcm43xx_pci_write_config16(bcm, PCI_STATUS, pci_status & 
> ~PCI_STATUS_SIG_TARGET_ABORT);
>  
>  out:
>   return err;
> @@ -3793,12 +3795,18 @@ static int bcm43xx_attach_board(struct b
>   }
>   net_dev->base_addr = (unsigned long)bcm->mmio_addr;
>  
> - bcm43xx_pci_read_config16(bcm, PCI_SUBSYSTEM_VENDOR_ID,
> + err = bcm43xx_pci_read_config16(bcm, PCI_SUBSYSTEM_VENDOR_ID,
> &bcm->board_vendor);
> - bcm43xx_pci_read_config16(bcm, PCI_SUBSYSTEM_ID,
> + if (err)
> + goto err_iounmap;
> + err = bcm43xx_pci_read_config16(bcm, PCI_SUBSYSTEM_ID,
> &bcm->board_type);
> - bcm43xx_pci_read_config16(bcm, PCI_REVISION_ID,
> + if (err)
> + goto err_iounmap;
> + err = bcm43xx_pci_read_config16(bcm, PCI_REVISION_ID,
> &bcm->board_revision);
> + if (err)
> + goto err_iounmap;
>  
>   err = bcm43xx_chipset_attach(bcm);
>   if (err)
> @@ -3889,6 +3897,7 @@ err_pci_release:
>   pci_release_regions(pci_dev);
>  err_pci_disable:
>   pci_disable_device(pci_dev);
> + printk(KERN_ERR PFX "Unable to attach board\n");
>   goto out;
>  }
> 
> --- 
> 
> 

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

Re: [PATCH] bcm43xx: Fix problem with >1 GB RAM

[Michael Buesch]

On Saturday 20 January 2007 17:18, Larry Finger wrote:
> Some versions of the bcm43xx chips only support 30-bit DMA, which means
> that the descriptors and buffers must be in the first 1 GB of RAM. On
> the i386 and x86_64 architectures with more than 1 GB RAM, an incorrect
> assignment may occur. This patch ensures that the various DMA addresses
> are within the capability of the chip. Testing has been limited to x86_64
> as no one has an i386 system with more than 1 GB RAM.
> 
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
> 
> John,
> 
> This patch should be applied to wireless-2.6 and pushed up to 2.6.20.
> 
> Thanks,
> 
> Larry
> 
> Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
> ===
> --- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
> +++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
> @@ -145,16 +145,14 @@ dma_addr_t map_descbuffer(struct bcm43xx
> int tx)
>  {
>   dma_addr_t dmaaddr;
> + int direction = PCI_DMA_FROMDEVICE;
>  
> - if (tx) {
> - dmaaddr = dma_map_single(&ring->bcm->pci_dev->dev,
> -  buf, len,
> -  DMA_TO_DEVICE);
> - } else {
> - dmaaddr = dma_map_single(&ring->bcm->pci_dev->dev,
> + if (tx)
> + direction = PCI_DMA_TODEVICE;
> +
> + dmaaddr = pci_map_single(ring->bcm->pci_dev,
>buf, len,
> -  DMA_FROM_DEVICE);
> - }
> +  direction);
>  
>   return dmaaddr;
>  }
> @@ -166,13 +164,13 @@ void unmap_descbuffer(struct bcm43xx_dma
> int tx)
>  {
>   if (tx) {
> - dma_unmap_single(&ring->bcm->pci_dev->dev,
> + pci_unmap_single(ring->bcm->pci_dev,
>addr, len,
> -  DMA_TO_DEVICE);
> +  PCI_DMA_TODEVICE);
>   } else {
> - dma_unmap_single(&ring->bcm->pci_dev->dev,
> + pci_unmap_single(ring->bcm->pci_dev,
>addr, len,
> -  DMA_FROM_DEVICE);
> +  PCI_DMA_FROMDEVICE);
>   }
>  }
>  
> @@ -183,8 +181,8 @@ void sync_descbuffer_for_cpu(struct bcm4
>  {
>   assert(!ring->tx);
>  
> - dma_sync_single_for_cpu(&ring->bcm->pci_dev->dev,
> - addr, len, DMA_FROM_DEVICE);
> + pci_dma_sync_single_for_cpu(ring->bcm->pci_dev,
> + addr, len, PCI_DMA_FROMDEVICE);
>  }

Any special reason why you convert the DMA operations to the PCI
stuff? I ask, because if this makes a difference, it affects the
new SSB subsystem as well.

>  static inline
> @@ -194,8 +192,8 @@ void sync_descbuffer_for_device(struct b
>  {
>   assert(!ring->tx);
>  
> - dma_sync_single_for_device(&ring->bcm->pci_dev->dev,
> -addr, len, DMA_FROM_DEVICE);
> + pci_dma_sync_single_for_cpu(ring->bcm->pci_dev,
> + addr, len, PCI_DMA_TODEVICE);
>  }
>  
>  /* Unmap and free a descriptor buffer. */
> @@ -214,17 +212,53 @@ void free_descriptor_buffer(struct bcm43
>  
>  static int alloc_ringmemory(struct bcm43xx_dmaring *ring)
>  {
> - struct device *dev = &(ring->bcm->pci_dev->dev);
> -
> - ring->descbase = dma_alloc_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
> - &(ring->dmabase), GFP_KERNEL);
> + ring->descbase = pci_alloc_consistent(ring->bcm->pci_dev, 
> BCM43xx_DMA_RINGMEMSIZE,
> + &(ring->dmabase));
>   if (!ring->descbase) {
> - printk(KERN_ERR PFX "DMA ringmemory allocation failed\n");
> - return -ENOMEM;
> + /* Allocation may have failed due to pci_alloc_consistent
> +insisting on use of GFP_DMA, which is more restrictive
> +than necessary...  */
> + struct dma_desc *rx_ring;
> + dma_addr_t rx_ring_dma;
> +
> + rx_ring = kzalloc(BCM43xx_DMA_RINGMEMSIZE, GFP_KERNEL);
> + if (!rx_ring)
> + goto out_err;
> +
> + rx_ring_dma = pci_map_single(ring->bcm->pci_dev, rx_ring,
> +  BCM43xx_DMA_RINGMEMSIZE,
> +  PCI_DMA_BIDIRECTIONAL);
> +
> + if (pci_dma_mapping_error(rx_ring_dma) ||
> + rx_ring_dma + BCM43xx_DMA_RINGMEMSIZE > 
> ring->bcm->dma_mask) {
> + /* Sigh... */
> + if (!pci_dma_mapping_error(rx_ring_dma))
> + pci_unmap_single(ring->bcm->pci_dev,
> +  rx_ring_dma, 
> BCM43xx_DMA_RINGMEMSIZE,
> + 

Re: Can someone please try...

[Michael Buesch]

On Friday 19 January 2007 08:54, Pavel Roskin wrote:
> Hello, Michael!
> 
> I did more testing, and the results are following.  It looks like the
> oopses and panics on i386 were triggered by 4k stacks.  x86_64 doesn't
> have this option.
> 
> Now that I enabled other debug options on both platforms. but not 4k
> stacks, I'm seeing exactly the same problem on each platform.  When run
> initially, wpa_supplicant connects with no problems (except very poor
> reception of the data packets, but it's another story).  If interrupted
> and restarted, wpa_supplicant reconnects, but I'm getting messages like
> this (i386):

That's a very interresting discover.
Partly, because I don't see this on my i386 machine. ;)

It's obviously some stack/memory corruption. But I'm not
sure if this is a stackoverflow. I'd rather say no, it isn't.

Could probably be triggered by something like kfree()ing
a dangling pointer or something...

> Slab corruption: start=cfdaece0, len=1024
> Redzone: 0x5a2cf071/0x5a2cf071.
> Last user: [](skb_release_data+0x7b/0x7f)
> 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Prev obj: start=cfdae8d4, len=1024
> Redzone: 0x170fc2a5/0x170fc2a5.
> Last user: [](device_create+0x2c/0x98)
> 000: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 010: ad 4e ad de ff ff ff ff ff ff ff ff 10 3a 6d c0
> Next obj: start=cfdaf0ec, len=1024
> Redzone: 0x170fc2a5/0x170fc2a5.
> Last user: [](expand_files+0x95/0x2c2)
> 000: 78 55 39 c7 78 55 39 c7 78 55 39 c7 88 da 52 df
> 010: d8 18 3b c7 00 00 00 00 00 00 00 00 00 00 00 00
> 
> and this (x86_64):
> 
> Slab corruption: start=81000ec8a198, len=1024
> Redzone: 0x5a2cf071/0x5a2cf071.
> Last user: [](skb_release_data+0x94/0x99)
> 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Next obj: start=81000ec8a5b0, len=1024
> Redzone: 0x170fc2a5/0x170fc2a5.
> Last user: [](device_create+0x5f/0x110)
> 000: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> I can restart wpa_supplicant again, and it would show similar messages.
> The first "Last user" is inevitably skb_release_data.
> 
> I have no idea how to deal with it.  I think I need a stack trace at the
> time when skb_release_data is called.
> 
> This is a stack trace at the time when slab corruption is detected.
> It's actually incorrect closer to the top, perhaps from gcc
> optimizations for static functions.
> 
> Slab corruption: start=8100066f81d8, len=1024
> 
> Call Trace:
>  [] vsnprintf+0x338/0x5a8
>  [] check_poison_obj+0x69/0x1ae
>  [] _request_firmware+0x8f/0x326
>  [] _request_firmware+0x8f/0x326
> 
> 
>  [] cache_alloc_debugcheck_after+0x32/0x1a2
>  [] _request_firmware+0x8f/0x326
>  [] kmem_cache_zalloc+0xaf/0xd8
>  [] _request_firmware+0x8f/0x326
>  [] :bcm43xx_d80211:bcm43xx_phy_init_tssi2dbm_table
> +0xf0/0x2ca
>  [] request_firmware+0xe/0x10
>  [] :bcm43xx_d80211:bcm43xx_chip_init+0x96/0xaba
>  [] kmem_cache_alloc+0xaf/0xbe
>  [] :bcm43xx_d80211:bcm43xx_wireless_core_init
> +0x4de/0xa3d
>  [] :bcm43xx_d80211:bcm43xx_add_interface+0x64/0xde
>  [] ieee80211_open+0x1c7/0x2cc
>  [] dev_open+0x36/0x76
>  [] dev_change_flags+0x5d/0x122
>  [] devinet_ioctl+0x259/0x5e8
>  [] inet_ioctl+0x71/0x8f
>  [] sock_ioctl+0x1db/0x1fd
>  [] do_ioctl+0x1b/0x50
>  [] vfs_ioctl+0x22a/0x23c
>  [] trace_hardirqs_on+0x124/0x14e
>  [] sys_ioctl+0x42/0x65
>  [] system_call+0x7e/0x83
> 
> Anyway, I could narrow down this message to the first kzalloc() call in
> fw_register_device(), file drivers/base/firmware_class.c.  This only
> seems to confirm my suspicion that the actual corruption happened before
> this point.  We are just hitting it when trying to allocate more memory.
> 
> Help with debugging this problem will be appreciated.  I've never hunted
> down such problems, especially in kernel space.
> 

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

Re: [PATCH] bcm43xx: Fix problem with >1 GB RAM

[Michael Buesch]

On Monday 22 January 2007 21:18, Larry Finger wrote:
> When I looked at the b44 driver to see how that code handled the problem, it 
> used the pci-form of
> the calls rather than the dma-version. Thus I switched early in the debug 
> process - even before I
> had the necessary hardware. Once I got it working and understood the problem, 
> I never tried
> restoring the dma-forms.

Ok, I see. I'm OK with that.

> > That isn't a BUG. Just remove this call, please.
> 
> It was accidentally left in from my debugging. I have already submitted a 
> revised version to
> Linville that removes this, and one other BUG statement that you didn't note.

Yeah, saw it too late. That patch is ACKed then by me.

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

Re: Can someone please try...

[Michael Buesch]

On Monday 22 January 2007 21:44, Pavel Roskin wrote:
> Hello, Michael!
> 
> On Mon, 2007-01-22 at 21:06 +0100, Michael Buesch wrote: 
> > It's obviously some stack/memory corruption. But I'm not
> > sure if this is a stackoverflow. I'd rather say no, it isn't.
> > 
> > Could probably be triggered by something like kfree()ing
> > a dangling pointer or something...
> 
> Yes.  That's what my patch was for ("Fix major memory corruption bug").
> It was pretty hard to catch because I would find the consequences rather
> than to the offending code.  I got lucky after I enabled some weird
> options, such as 64Gb support and highmem debugging.  Whether it played
> any role or not, the oops finally happened where the driver tried to
> erase memory pointed to by the stale phy->lo_control pointer.
> 
> Now the situation is following.
> 
> No more random crashes.  There is still a crash if I rmmod the driver
> while wlan0 is up, but it's a separate issue, and it's easy to avoid
> (unlike the interface going down).  I hope to look at it soon.

Did you apply that d80211 rmmod crash fix that Michael Wu posted
recently. I bet it will fix your issue.

> The driver connects to a 802.11b Linksys router just fine.  I can send
> and receive data.  The driver is fully functional.  128-bit WEP is
> supported.

Nice.

> There are periodic bursts of assertion failures.  Looking at the driver,
> I see three places where lna a.k.a. phy->lo_gain[0] is assigned the
> value of 32 (written as 0x20 in one place).  It's not surprising that it
> exceeds 7 in lo_measure_feedthrough().

I know about these and I am going to fix that, soon.
Ignore it for the time being, please.

> I think the assert() should be replaced with a FIXME, which would not
> annoy end users so much.

Well, no. It's kind of: Michael, go ahead and fix that crap!
So I'd like to keep it to get me to fix it. :D

> And while at that, it would be great to 
> replace phy->lo_gain with four fields with descriptive names.
> phy->lo_gain is never used as an array.  Alternatively, you could make
> it a structure within bcm43xx_phy.

Yeah, one step after the other. ;)
We didn't know the meanings of the values until recently. Of course
I am going to rename them.

> The problems with a MadWifi based AP turn out to be related to 802.11g.
> If the AP is configured for 802.11b only, everything is working.  If
> 802.11g is enabled, strange things are happening.  Judging by what's on
> the air, it looks like the driver loses the data frames is receives.
> wpa_supplicant connects instantly, but ARP and ping packets from AP to
> STA are lost.  The frames are even acknowledged, but not seen on the
> station side.  It takes from one to ten minutes util ping suddenly
> starts working.

Hm, is this 4318? It is known to loose lots of packets.

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