[PATCH] bcm43xx-d80211: add DMA rx poll workaround to DMA4
This is the same patch as before, but for the dscape port.
Please apply to wireless-dev.
--
Also add the Poll RX DMA Memory workaround to the DMA4
(xmitstatus) path.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
index dc11260..ebe0984 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -604,25 +604,28 @@ err_destroy_tx0:
static u16 generate_cookie(struct bcm43xx_dmaring *ring,
int slot)
{
- u16 cookie = 0x;
+ u16 cookie = 0xF000;
/* Use the upper 4 bits of the cookie as
* DMA controller ID and store the slot number
-* in the lower 12 bits
+* in the lower 12 bits.
+* Note that the cookie must never be 0, as this
+* is a special value used in RX path.
*/
switch (ring-mmio_base) {
default:
assert(0);
case BCM43xx_MMIO_DMA1_BASE:
+ cookie = 0xA000;
break;
case BCM43xx_MMIO_DMA2_BASE:
- cookie = 0x1000;
+ cookie = 0xB000;
break;
case BCM43xx_MMIO_DMA3_BASE:
- cookie = 0x2000;
+ cookie = 0xC000;
break;
case BCM43xx_MMIO_DMA4_BASE:
- cookie = 0x3000;
+ cookie = 0xD000;
break;
}
assert(((u16)slot 0xF000) == 0x);
@@ -640,16 +643,16 @@ struct bcm43xx_dmaring * parse_cookie(st
struct bcm43xx_dmaring *ring = NULL;
switch (cookie 0xF000) {
- case 0x:
+ case 0xA000:
ring = dma-tx_ring0;
break;
- case 0x1000:
+ case 0xB000:
ring = dma-tx_ring1;
break;
- case 0x2000:
+ case 0xC000:
ring = dma-tx_ring2;
break;
- case 0x3000:
+ case 0xD000:
ring = dma-tx_ring3;
break;
default:
@@ -867,8 +870,18 @@ static void dma_rx(struct bcm43xx_dmarin
/* We received an xmit status. */
struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus
*)skb-data;
struct bcm43xx_xmitstatus stat;
+ int i = 0;
stat.cookie = le16_to_cpu(hw-cookie);
+ while (stat.cookie == 0) {
+ if (unlikely(++i = 1)) {
+ assert(0);
+ break;
+ }
+ udelay(2);
+ barrier();
+ stat.cookie = le16_to_cpu(hw-cookie);
+ }
stat.flags = hw-flags;
stat.cnt1 = hw-cnt1;
stat.cnt2 = hw-cnt2;
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] bcm43xx-d80211: Fix 64bit compiler warnings
Fix all 64bit compiler warnings.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
index e882bc1..0f7303e 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
@@ -227,7 +227,7 @@ static ssize_t tsf_write_file(struct fil
res = -EFAULT;
goto out_unlock;
}
- if (sscanf(buf, %lli, tsf) != 1) {
+ if (sscanf(buf, %llu, (unsigned long long *)(tsf)) != 1) {
printk(KERN_INFO PFX debugfs: invalid values for \tsf\\n);
res = -EINVAL;
goto out_unlock;
@@ -449,11 +449,11 @@ void bcm43xx_printk_dump(const char *dat
size_t size,
const char *description)
{
- size_t i;
+ unsigned int i;
char c;
- printk(KERN_INFO PFX Data dump (%s, %u bytes):,
- description, size);
+ printk(KERN_INFO PFX Data dump (%s, %lu bytes):,
+ description, (unsigned long)size);
for (i = 0; i size; i++) {
c = data[i];
if (i % 8 == 0)
@@ -468,12 +468,13 @@ void bcm43xx_printk_bitdump(const unsign
size_t bytes, int msb_to_lsb,
const char *description)
{
- size_t i;
+ unsigned int i;
int j;
const unsigned char *d;
- printk(KERN_INFO PFX *** Bitdump (%s, %u bytes, %s) ***,
- description, bytes, msb_to_lsb ? MSB to LSB : LSB to MSB);
+ printk(KERN_INFO PFX *** Bitdump (%s, %lu bytes, %s) ***,
+ description, (unsigned long)bytes,
+ msb_to_lsb ? MSB to LSB : LSB to MSB);
for (i = 0; i bytes; i++) {
d = data + i;
if (i % 8 == 0)
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
index dc11260..1dfd74e 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -180,7 +180,7 @@ static int alloc_ringmemory(struct bcm43
if (ring-dmabase + BCM43xx_DMA_RINGMEMSIZE BCM43xx_DMA_BUSADDRMAX) {
printk(KERN_ERR PFX FATAL ERROR DMA RINGMEMORY 1G
(0x%08x, len: %lu)\n,
- ring-dmabase, BCM43xx_DMA_RINGMEMSIZE);
+ (unsigned int)ring-dmabase, BCM43xx_DMA_RINGMEMSIZE);
dma_free_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
ring-vbase, ring-dmabase);
return -ENOMEM;
@@ -292,7 +292,7 @@ static int setup_rx_descbuffer(struct bc
dev_kfree_skb_any(skb);
printk(KERN_ERR PFX FATAL ERROR DMA RX SKB 1G
(0x%08x, len: %u)\n,
- dmaaddr, ring-rx_buffersize);
+ (unsigned int)dmaaddr, ring-rx_buffersize);
return -ENOMEM;
}
meta-skb = skb;
@@ -711,7 +711,7 @@ static int dma_tx_fragment(struct bcm43x
dev_kfree_skb_irq(hdr_skb);
printk(KERN_ERR PFX FATAL ERROR DMA TX SKB 1G
(0x%08x, len: %u)\n,
- meta-dmaaddr, hdr_skb-len);
+ (unsigned int)meta-dmaaddr, hdr_skb-len);
return -ENOMEM;
}
@@ -742,7 +742,7 @@ static int dma_tx_fragment(struct bcm43x
dev_kfree_skb_irq(hdr_skb);
printk(KERN_ERR PFX FATAL ERROR DMA TX SKB 1G
(0x%08x, len: %u)\n,
- meta-dmaaddr, skb-len);
+ (unsigned int)meta-dmaaddr, skb-len);
return -ENOMEM;
}
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sunday 04 June 2006 10:55, Richard Harman wrote: Ok, how about this :) I'll compile up the latest kernel +bcm/softmac and pull out my debugging stuff to see what revision my 4306 card is. If it's one you want, I'll buy myself a replacement one, and ship you mine. What exactly do I need to look for when I insmod with debugging turned on? Well, that depends on what you want to get working. ;) The problem which is discussed in this thread seems to be related to a wireless core revision 5. Note that I am not 100% sure here, but there is definately much untested code in the driver for wlcore 5 cards. You can find out which revisions are on your card by looking at insmod dmesg: Jun 3 00:56:29 thirtytwo bcm43xx driver Jun 3 00:56:29 thirtytwo bcm43xx: Chip ID 0x4306, rev 0x2 Jun 3 00:56:29 thirtytwo bcm43xx: Number of cores: 6 Jun 3 00:56:29 thirtytwo bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled ^ ^^^ 0x812 is a wireless core and 0x4 is the revision here. As you can see it is 5. Jun 3 00:56:29 thirtytwo bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Ignoring additional 802.11 core. Jun 3 00:56:29 thirtytwo bcm43xx: PHY connected Jun 3 00:56:29 thirtytwo bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 Jun 3 00:56:29 thirtytwo bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off There might be other revisions accounting here, too. For example, we often check radio and PHY revisions. And as you can see PHY and radio revisions are also very low numbers here. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH, RFT] bcm43xx: export radio disabled by hardware bits to sysfs
This patch exports the hardware rfkill bits to sysfs, as Joe Jezak
suggested. I tested it on my bcm4318, but it seems that those bits can't be
set, so this shouldn't solve any issue with radio buttons. Please tell me
if it gives different behaviour on laptops with a radio button switch.
Signed-off-by: Stefano Brivio [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c
@@ -305,6 +305,83 @@ static DEVICE_ATTR(shortpreamble, 0644,
bcm43xx_attr_preamble_show,
bcm43xx_attr_preamble_store);
+static ssize_t bcm43xx_attr_rfkill_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct bcm43xx_private *bcm = dev_to_bcm(dev);
+ unsigned long flags;
+ ssize_t count;
+
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
+ bcm43xx_lock_mmio(bcm, flags);
+ assert(bcm-initialized);
+
+ if (bcm-core_80211[0].rev = 3) {
+ if (bcm43xx_read32(bcm, 0x0158) (1 16))
+ count = snprintf(buf, PAGE_SIZE, 1 (Radio disabled by
hardware)\n);
+ else
+ count = snprintf(buf, PAGE_SIZE, 0 (Radio not disabled
by hardware)\n);
+ } else {
+ if (bcm43xx_read16(bcm, 0x049A) (1 4))
+ count = snprintf(buf, PAGE_SIZE, 0 (Radio not disabled
by hardware)\n);
+ else
+ count = snprintf(buf, PAGE_SIZE, 1 (Radio disabled by
hardware)\n);
+ }
+
+ bcm43xx_unlock_mmio(bcm, flags);
+
+ return count;
+}
+
+static ssize_t bcm43xx_attr_rfkill_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct bcm43xx_private *bcm = dev_to_bcm(dev);
+ unsigned long flags;
+ int value;
+
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
+ value = get_boolean(buf, count);
+ if (value 0)
+ return value;
+ bcm43xx_lock_mmio(bcm, flags);
+ assert(bcm-initialized);
+
+ if (value) {
+ if (bcm-core_80211[0].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));
+ } else {
+ if (bcm-core_80211[0].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));
+ }
+
+ bcm43xx_unlock_mmio(bcm, flags);
+
+ return count;
+}
+
+static DEVICE_ATTR(rfkill, 0644,
+ bcm43xx_attr_rfkill_show,
+ bcm43xx_attr_rfkill_store);
+
int bcm43xx_sysfs_register(struct bcm43xx_private *bcm)
{
struct device *dev = bcm-pci_dev-dev;
@@ -321,9 +398,14 @@ int bcm43xx_sysfs_register(struct bcm43x
err = device_create_file(dev, dev_attr_shortpreamble);
if (err)
goto err_remove_interfmode;
+ err = device_create_file(dev, dev_attr_rfkill);
+ if (err)
+ goto err_remove_shortpreamble;
out:
return err;
+err_remove_shortpreamble:
+ device_remove_file(dev, dev_attr_shortpreamble);
err_remove_interfmode:
device_remove_file(dev, dev_attr_interference);
err_remove_sprom:
@@ -335,6 +417,7 @@ void bcm43xx_sysfs_unregister(struct bcm
{
struct device *dev = bcm-pci_dev-dev;
+ device_remove_file(dev, dev_attr_rfkill);
device_remove_file(dev, dev_attr_shortpreamble);
device_remove_file(dev, dev_attr_interference);
device_remove_file(dev, dev_attr_sprom);
--
Ciao
Stefano
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] quiet down log spam from set_security
The debug logging in bcm43xx_ieee80211_set_security() is pretty noisy
for me. The following patch turns pages of this:
Jun 4 14:17:01 localhost kernel: bcm43xx: set security called
Jun 4 14:17:01 localhost kernel: bcm43xx:.level = 0
Jun 4 14:17:01 localhost kernel: bcm43xx:.enabled = 0
Jun 4 14:17:01 localhost kernel: bcm43xx:.encrypt = 0
Jun 4 14:17:02 localhost kernel: bcm43xx: set security called
Jun 4 14:17:02 localhost kernel: bcm43xx:.active_key = 0
Jun 4 14:17:02 localhost kernel: bcm43xx:.level = 4
Jun 4 14:17:02 localhost kernel: bcm43xx:.enabled = 1
Jun 4 14:17:02 localhost kernel: bcm43xx:.encrypt = 1
Jun 4 14:17:02 localhost kernel: bcm43xx: set security called
Jun 4 14:17:02 localhost kernel: bcm43xx:.enabled = 1
Jun 4 14:17:02 localhost kernel: bcm43xx:.encrypt = 1
into this:
Jun 4 14:52:25 localhost kernel: bcm43xx: set security called, .level = 0,
.enabled = 0, .encrypt = 0
Jun 4 14:52:25 localhost last message repeated 9 times
Jun 4 14:52:25 localhost kernel: bcm43xx: set security called, .active_key =
0, .level = 4, .enabled = 1, .encrypt = 1
Jun 4 14:52:25 localhost kernel: bcm43xx: set security called, .enabled = 1,
.encrypt = 1
Signed-off-by: Jason Lunz [EMAIL PROTECTED]
diff -ur linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c
linux-2.6.17-rc5-git11.quiet/drivers/net/wireless/bcm43xx/bcm43xx_main.c
--- linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c
2006-05-29 12:33:56.0 -0400
+++ linux-2.6.17-rc5-git11.quiet/drivers/net/wireless/bcm43xx/bcm43xx_main.c
2006-06-04 14:51:09.0 -0400
@@ -3568,7 +3568,7 @@
unsigned long flags;
int keyidx;
- dprintk(KERN_INFO PFX set security called\n);
+ dprintk(KERN_INFO PFX set security called);
bcm43xx_lock_mmio(bcm, flags);
@@ -3581,24 +3581,25 @@
if (sec-flags SEC_ACTIVE_KEY) {
secinfo-active_key = sec-active_key;
- dprintk(KERN_INFO PFX.active_key = %d\n, sec-active_key);
+ dprintk(, .active_key = %d, sec-active_key);
}
if (sec-flags SEC_UNICAST_GROUP) {
secinfo-unicast_uses_group = sec-unicast_uses_group;
- dprintk(KERN_INFO PFX.unicast_uses_group = %d\n,
sec-unicast_uses_group);
+ dprintk(, .unicast_uses_group = %d, sec-unicast_uses_group);
}
if (sec-flags SEC_LEVEL) {
secinfo-level = sec-level;
- dprintk(KERN_INFO PFX.level = %d\n, sec-level);
+ dprintk(, .level = %d, sec-level);
}
if (sec-flags SEC_ENABLED) {
secinfo-enabled = sec-enabled;
- dprintk(KERN_INFO PFX.enabled = %d\n, sec-enabled);
+ dprintk(, .enabled = %d, sec-enabled);
}
if (sec-flags SEC_ENCRYPT) {
secinfo-encrypt = sec-encrypt;
- dprintk(KERN_INFO PFX.encrypt = %d\n, sec-encrypt);
+ dprintk(, .encrypt = %d, sec-encrypt);
}
+ dprintk(\n);
if (bcm-initialized !bcm-ieee-host_encrypt) {
if (secinfo-enabled) {
/* upload WEP keys to hardware */
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RFT] bcm43xx: export radio disabled by hardware bits to sysfs
In gmane.linux.drivers.bcm54xx.devel, you wrote: This patch exports the hardware rfkill bits to sysfs, as Joe Jezak suggested. I tested it on my bcm4318, but it seems that those bits can't be set, so this shouldn't solve any issue with radio buttons. Please tell me if it gives different behaviour on laptops with a radio button switch. With this patch applied, the file /sys/class/net/bcm/device/rfkill appears in sysfs. Pressing the radio button on my laptop toggles the content of that file between 0 (Radio not disabled by hardware) and 1 (Radio disabled by hardware). This corresponds to the actual state of the radio - if you press the button while a ping is going, for example, rfkill reports the radio is disabled, and the pings stop. The softmac stack continues to think the card is associated. in other words, this behaves just as you'd expect. Is there anything else you want tested? I tried echo 1 /sys/class/net/bcm/device/rfkill and echo -n1 /sys/class/net/bcm/device/rfkill, but this had no effect and catting rfkill showed the value remained at 0. lspci reports my card as: :02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) and it's detected by the driver as: bcm43xx: Chip ID 0x4306, rev 0x3 bcm43xx: Number of cores: 5 bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) interestingly, on this laptop the button is on the minipci card itself - it's mounted beneath the keyboard, and the external button is physically connected to the minipci card. The LED is inside the button. Jason ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work
Ok, I'm back with a completely rewritten version of the
preemptible periodic work patch.
For this I had to completely redesign driver locking. We have
two different locks now. One for general purpose and one
to protect against IRQ concurrency.
(Yes, the final patch will be splitted, but for now I have
a convenient all-in-one patch here)
As we don't take the IRQ lock while executing preemptible
periodic work (We don't need to, as IRQs are disabled), we
can not deadlock anymore.
I am currently stressing the patch on one of my machines and
it seems to work as expected here.
I also wrote a dscape patch and also stressed that.
(I will publish the dscape patch later, if nobody is able
to find a regression in the softmac patch ;) )
So, here we go. Preemptible Periodic Work for bcm43xx-softmac.
Please stress-test with all methods which come to your minds.
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx.h2006-06-03
21:04:17.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx.h 2006-06-03
21:15:23.0 +0200
@@ -647,9 +647,9 @@
void __iomem *mmio_addr;
unsigned int mmio_len;
- /* Do not use the lock directly. Use the bcm43xx_lock* helper
-* functions, to be MMIO-safe. */
- spinlock_t _lock;
+ /* Locking, see theory of locking text below. */
+ spinlock_t irq_lock;
+ struct mutex mutex;
/* Driver status flags. */
u32 initialized:1, /* init_board() succeed */
@@ -722,7 +722,7 @@
struct tasklet_struct isr_tasklet;
/* Periodic tasks */
- struct timer_list periodic_tasks;
+ struct work_struct periodic_work;
unsigned int periodic_state;
struct work_struct restart_work;
@@ -747,21 +747,55 @@
#endif
};
-/* bcm43xx_(un)lock() protect struct bcm43xx_private.
- * Note that _NO_ MMIO writes are allowed. If you want to
- * write to the device through MMIO in the critical section, use
- * the *_mmio lock functions.
- * MMIO read-access is allowed, though.
- */
-#define bcm43xx_lock(bcm, flags) spin_lock_irqsave((bcm)-_lock, flags)
-#define bcm43xx_unlock(bcm, flags) spin_unlock_irqrestore((bcm)-_lock,
flags)
-/* bcm43xx_(un)lock_mmio() protect struct bcm43xx_private and MMIO.
- * MMIO write-access to the device is allowed.
- * All MMIO writes are flushed on unlock, so it is guaranteed to not
- * interfere with other threads writing MMIO registers.
+
+/**** THEORY OF LOCKING ***
+ *
+ * We have two different locks in the bcm43xx driver.
+ * = bcm-mutex:General sleeping mutex. Protects struct bcm43xx_private
+ * and the device registers.
+ * = bcm-irq_lock: IRQ spinlock. Protects against IRQ handler concurrency.
+ *
+ * We have three types of helper function pairs to utilize these locks.
+ * (Always use the helper functions.)
+ * 1) bcm43xx_{un}lock_noirq():
+ * Takes bcm-mutex. Does _not_ protect against IRQ concurrency,
+ * so it is almost always unsafe, if device IRQs are enabled.
+ * So only use this, if device IRQs are masked.
+ * Locking may sleep.
+ * You can sleep within the critical section.
+ * 2) bcm43xx_{un}lock_irqonly():
+ * Takes bcm-irq_lock. Does _not_ protect against
+ * bcm43xx_lock_noirq() critical sections.
+ * Does only protect against the IRQ handler path and other
+ * irqonly() critical sections.
+ * Locking does not sleep.
+ * You must not sleep within the critical section.
+ * 3) bcm43xx_{un}lock_irqsafe():
+ * This is the cummulative lock and takes both, mutex and irq_lock.
+ * Protects against noirq() and irqonly() critical sections (and
+ * the IRQ handler path).
+ * Locking may sleep.
+ * You must not sleep within the critical section.
*/
-#define bcm43xx_lock_mmio(bcm, flags) bcm43xx_lock(bcm, flags)
-#define bcm43xx_unlock_mmio(bcm, flags)do { mmiowb();
bcm43xx_unlock(bcm, flags); } while (0)
+
+/* Lock type 1 */
+#define bcm43xx_lock_noirq(bcm)mutex_lock((bcm)-mutex)
+#define bcm43xx_unlock_noirq(bcm) mutex_unlock((bcm)-mutex)
+/* Lock type 2 */
+#define bcm43xx_lock_irqonly(bcm, flags) \
+ spin_lock_irqsave((bcm)-irq_lock, flags)
+#define bcm43xx_unlock_irqonly(bcm, flags) \
+ spin_unlock_irqrestore((bcm)-irq_lock, flags)
+/* Lock type 3 */
+#define bcm43xx_lock_irqsafe(bcm, flags) do { \
+ bcm43xx_lock_noirq(bcm);\
+ bcm43xx_lock_irqonly(bcm, flags); \
+ } while (0)
+#define bcm43xx_unlock_irqsafe(bcm, flags) do {\
+ bcm43xx_unlock_irqonly(bcm, flags); \
+ bcm43xx_unlock_noirq(bcm); \
+ } while (0)
+
static inline
struct bcm43xx_private * bcm43xx_priv(struct net_device *dev)
Index:
Re: Anyone got a 4306 working properly?
On Sun, 2006-06-04 at 12:14 +0200, Michael Buesch wrote: On Sunday 04 June 2006 10:55, Richard Harman wrote: Ok, how about this :) I'll compile up the latest kernel +bcm/softmac and pull out my debugging stuff to see what revision my 4306 card is. If it's one you want, I'll buy myself a replacement one, and ship you mine. What exactly do I need to look for when I insmod with debugging turned on? Well, that depends on what you want to get working. ;) The problem which is discussed in this thread seems to be related to a wireless core revision 5. Note that I am not 100% sure here, but there is definately much untested code in the driver for wlcore 5 cards. You can find out which revisions are on your card by looking at insmod dmesg: Jun 3 00:56:29 thirtytwo bcm43xx driver Jun 3 00:56:29 thirtytwo bcm43xx: Chip ID 0x4306, rev 0x2 Jun 3 00:56:29 thirtytwo bcm43xx: Number of cores: 6 Jun 3 00:56:29 thirtytwo bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, enabled ^ ^^^ 0x812 is a wireless core and 0x4 is the revision here. As you can see it is 5. Jun 3 00:56:29 thirtytwo bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled Jun 3 00:56:29 thirtytwo bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled Jun 3 00:56:29 thirtytwo bcm43xx: Ignoring additional 802.11 core. Jun 3 00:56:29 thirtytwo bcm43xx: PHY connected Jun 3 00:56:29 thirtytwo bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 Jun 3 00:56:29 thirtytwo bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off Jun 3 00:56:29 thirtytwo bcm43xx: Radio turned off There might be other revisions accounting here, too. For example, we often check radio and PHY revisions. And as you can see PHY and radio revisions are also very low numbers here. Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. I don't find any other bcm card at ebay, yet. But your local computer distributor should also sell those cards. A good list of bcm cards is here: http://bcm43xx.berlios.de/?go=Devices -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sunday 04 June 2006 21:49, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. The airport has a special connector that only fits into apple hardware. You could also buy an ipw2200. That works good, too. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
Michael Buesch wrote: On Sunday 04 June 2006 21:49, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. The airport has a special connector that only fits into apple hardware. You could also buy an ipw2200. That works good, too. I have a spare Linksys WPC54G with the following revision numbers. Jun 4 14:56:13 larrylap kernel: bcm43xx: Chip ID 0x4306, rev 0x2 Jun 4 14:56:13 larrylap kernel: bcm43xx: Number of cores: 6 Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, disabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled Jun 4 14:56:13 larrylap kernel: bcm43xx: Ignoring additional 802.11 core. Jun 4 14:56:13 larrylap kernel: bcm43xx: PHY connected Jun 4 14:56:13 larrylap kernel: bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1 Jun 4 14:56:13 larrylap kernel: bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jun 4 14:56:13 larrylap kernel: bcm43xx: Radio turned off Jun 4 14:56:13 larrylap kernel: bcm43xx: Radio turned off I am willing to donate this device to the project. It has had an accident and the LEDs don't work, but the rest is OK. Please send me the mailing address of the location where you want it. I am located in Kansas City, MO USA. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: A good list of bcm cards is here: http://bcm43xx.berlios.de/?go=Devices Actually my card (as listed by lspci): 0001:10:12.0 0280: 14e4:4320 (rev 02) Subsystem: 106b:004e is listed on that page, but is obviously not working properly. So you might want to mark it as possibly non-working. Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sun, 2006-06-04 at 21:52 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:49, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. The airport has a special connector that only fits into apple hardware. You could also buy an ipw2200. That works good, too. I'll order one of the newer airport extreme cards (as these are probably the only ones to fit into the powerbook) and see how it works out. That will probably also be a 0x4318. What issues do these have? Mattias ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work
On Sun, Jun 04, 2006 at 09:26:47PM +0200, Michael Buesch wrote: Ok, I'm back with a completely rewritten version of the preemptible periodic work patch. Your patch applies against 2.6.17-rc5-git11, but compilation fails with: CC [M] drivers/net/wireless/bcm43xx/bcm43xx_main.o drivers/net/wireless/bcm43xx/bcm43xx_main.c: In function 'disable_irqs_sync_bottomhalf': drivers/net/wireless/bcm43xx/bcm43xx_main.c:510: error: too few arguments to function 'synchronize_irq' Jason ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] bcm43xx: quiet down log spam from set_security
John, please queue for 2.6.18.
--
From: Jason Lunz [EMAIL PROTECTED]
The debug logging in bcm43xx_ieee80211_set_security() is pretty noisy.
Make it more silent.
Signed-off-by: Jason Lunz [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
diff -ur linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c
linux-2.6.17-rc5-git11.quiet/drivers/net/wireless/bcm43xx/bcm43xx_main.c
--- linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c
2006-05-29 12:33:56.0 -0400
+++ linux-2.6.17-rc5-git11.quiet/drivers/net/wireless/bcm43xx/bcm43xx_main.c
2006-06-04 14:51:09.0 -0400
@@ -3568,7 +3568,7 @@
unsigned long flags;
int keyidx;
- dprintk(KERN_INFO PFX set security called\n);
+ dprintk(KERN_INFO PFX set security called);
bcm43xx_lock_mmio(bcm, flags);
@@ -3581,24 +3581,25 @@
if (sec-flags SEC_ACTIVE_KEY) {
secinfo-active_key = sec-active_key;
- dprintk(KERN_INFO PFX.active_key = %d\n, sec-active_key);
+ dprintk(, .active_key = %d, sec-active_key);
}
if (sec-flags SEC_UNICAST_GROUP) {
secinfo-unicast_uses_group = sec-unicast_uses_group;
- dprintk(KERN_INFO PFX.unicast_uses_group = %d\n,
sec-unicast_uses_group);
+ dprintk(, .unicast_uses_group = %d, sec-unicast_uses_group);
}
if (sec-flags SEC_LEVEL) {
secinfo-level = sec-level;
- dprintk(KERN_INFO PFX.level = %d\n, sec-level);
+ dprintk(, .level = %d, sec-level);
}
if (sec-flags SEC_ENABLED) {
secinfo-enabled = sec-enabled;
- dprintk(KERN_INFO PFX.enabled = %d\n, sec-enabled);
+ dprintk(, .enabled = %d, sec-enabled);
}
if (sec-flags SEC_ENCRYPT) {
secinfo-encrypt = sec-encrypt;
- dprintk(KERN_INFO PFX.encrypt = %d\n, sec-encrypt);
+ dprintk(, .encrypt = %d, sec-encrypt);
}
+ dprintk(\n);
if (bcm-initialized !bcm-ieee-host_encrypt) {
if (secinfo-enabled) {
/* upload WEP keys to hardware */
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work
I guess maybe you never compiled for smp? synchronize_irq() is just
barrier() for !CONFIG_SMP.
Did you mean this?
Jason
---
drivers/net/wireless/bcm43xx/bcm43xx_main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.17-rc5-git11.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -507,7 +507,7 @@
static void disable_irqs_sync_bottomhalf(struct bcm43xx_private *bcm)
{
- synchronize_irq();
+ synchronize_irq(bcm-irq);
tasklet_disable(bcm-isr_tasklet);
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Sunday 04 June 2006 23:01, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:52 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:49, Mattias Nissler wrote: On Sun, 2006-06-04 at 21:44 +0200, Michael Buesch wrote: On Sunday 04 June 2006 21:30, Mattias Nissler wrote: Well, mine is a mini-PCI. I'd replace mine by one of a newer rev and donate the old one if somebody can tell me where to buy a new mini-PCI card for my laptop. http://cgi.ebay.de/Broadcom-miniPCI-WLAN-64-Mbit-802-11b-g_W0QQitemZ9734722753QQcategoryZ79510QQrdZ1QQcmdZViewItem Seems to be a 4318. Keep in mind that this is not 100% supported, too. What about a new airport extreme card from apple? I'll check whether it fits and go for that if it does. The airport has a special connector that only fits into apple hardware. You could also buy an ipw2200. That works good, too. I'll order one of the newer airport extreme cards (as these are probably the only ones to fit into the powerbook) and see how it works out. That will probably also be a 0x4318. What issues do these have? Ah, you have a powerbook. Well, that makes choice narrow. ;) The newest Airports are 4318, afaik. (Or are they atheros now?) 4318 has some issues, but often works. We know where the issues are and are working to fix them. It's a matter of time. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work
On Sunday 04 June 2006 23:13, Jason Lunz wrote:
I guess maybe you never compiled for smp? synchronize_irq() is just
barrier() for !CONFIG_SMP.
Did you mean this?
Yes, this is a typo.
Jason
---
drivers/net/wireless/bcm43xx/bcm43xx_main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.17-rc5-git11.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -507,7 +507,7 @@
static void disable_irqs_sync_bottomhalf(struct bcm43xx_private *bcm)
{
- synchronize_irq();
+ synchronize_irq(bcm-irq);
tasklet_disable(bcm-isr_tasklet);
}
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work
On Sunday 04 June 2006 23:20, Jason Lunz wrote: I got this after modules built. The acpi and jffs ones aren't new -- I don't know whether the bcm43xx ones are new or not: Building modules, stage 2. MODPOST WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0x114c) and 'acpi_safe_halt' WARNING: fs/jffs2/jffs2.o - Section mismatch: reference to .init.text:jffs2_zlib_init from .text between 'jffs2_compressors_init' (at offset 0x17) and 'jffs2_free_comprbuf' WARNING: bcm43xx_lock_mmio [drivers/net/wireless/bcm43xx/bcm43xx.ko] undefined! WARNING: bcm43xx_unlock_mmio [drivers/net/wireless/bcm43xx/bcm43xx.ko] undefined! I am wondering why I did not get these warnings... You won't be able to insmod the module. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work
On Sun, Jun 04, 2006 at 11:20:35PM +0200, Michael Buesch wrote: I am wondering why I did not get these warnings... You won't be able to insmod the module. yes, I noticed. it was my fault - i still had Stefano's rfkill button patch applied. Jason ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work
On Sunday 04 June 2006 23:31, Jason Lunz wrote:
On Sun, Jun 04, 2006 at 11:20:35PM +0200, Michael Buesch wrote:
I am wondering why I did not get these warnings...
You won't be able to insmod the module.
yes, I noticed.
it was my fault - i still had Stefano's rfkill button patch applied.
Ah, ok. :)
the bcm43xx_{un}lock_mmio can be replaced by bcm43xx_{un}lock_irqsafe
in that patch.
--
Greetings Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
Michael, I have a 4306 in a 15-inch PowerBook G4 (purchased new, in the US, in the last week of June 2005). I'm running vanilla linux-2.6.17-rc5 obtained from kernel.org which I built myself. The system is Debian etch now, though more than a week ago I was running Debian sarge, and earlier kernel versions in the linux-2.6.17-rc? series. I've not tried to use the wireless much in the last few weeks, for I do not yet have an access point at home. In the middle of last month (May 2006) while running Debian sarge and linux-2.6.17-rc3 (or maybe -rc4) I was traveling and staying in a home that had an access point, and I discovered that it would barely work (if at all) from my bedroom there (about 10 or 15 meters away on the same floor), but would work just fine if I sat on the couch next to the access point. When anywhere other than within 2 or 3 meters of the access pont, the symptoms were much like what Mattias is describing. Within 2 or 3 meters from the access point, it would work very well. In my bedroom (10 or 15 meters away), if I carefully positioned it on the table moving it a centimeter or three in various directions until I found a spot that worked better, then I could use it from the bedroom, but I would still see some outages and when I tried pinging the default router I would see DUPs like Mattias reports. The 15-inch PowerBook has two antennas, one on either side of the screen. I noticed that covering the left one with my hand would completely prevent it from working, while covering the right antenna with my hand never had any effect. iwlist eth1 scan always reported that it had seen the access point beacon recently (50 to 100 ms). So I came to the conclusion that the access point is having trouble hearing my computer's transmissions (since my computer can apparently hear the access point reliably). If I booted MacOS X it would work just fine from anywhere in the house, including much further away. And while I could sometimes interfere with pinging a little bit by gripping the screen with both hands (covering both antennas), leaving either antenna uncovered while covering the other as best I could with my hand would always leave the pinging solid. I believe the access point was supporting both 802.11B and 802.11G. I did not think to try restricting the bcm43xx to one mode or the other, or set it to a lower speed (which sometimes helps with madwifi interfaces). I'm not sure yet how to do that with this driver. I think the problem is feeble transmissions (or transmissions that for some reason only work when I'm very near the access point), and perhaps not making use of both antennas (since only covering the left antenna had any effect at all). Below is some more info about my computer and kernel. I cannot really do any more experiments until I get an access point, or unless I'm away from home and have one nearby that I can use. I hope this report helps with improving the bcm43xx driver. Thanks to everyone who has contributed to this driver. -Tim Shepard [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - bash5$ lspci :00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI 0001:10:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) 0001:10:13.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller 0001:10:17.0 ff00: Apple Computer Inc. KeyLargo/Intrepid Mac I/O 0001:10:19.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB 0001:10:1a.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB 0001:10:1b.0 USB Controller: NEC Corporation USB (rev 43) 0001:10:1b.1 USB Controller: NEC Corporation USB (rev 43) 0001:10:1b.2 USB Controller: NEC Corporation USB 2.0 (rev 04) 0002:24:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI 0002:24:0d.0 ff00: Apple Computer Inc. UniNorth/Intrepid ATA/100 0002:24:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth 2 FireWire (rev 81) 0002:24:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun GEM) (rev 80) bash6$ dmesg | grep bcm43xx bcm43xx driver bcm43xx: Chip ID 0x4306, rev 0x3 bcm43xx: Number of cores: 5 bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled bcm43xx: PHY connected bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2 bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) bcm43xx: Radio turned off bcm43xx: Radio turned off bash7$ lsmod Module Size Used by snd_powermac 50908 0 snd_pcm_oss
Re: Anyone got a 4306 working properly?
||-|| || Cuando: Sun, Jun 04, 2006 at 06:06:29PM -0400 || || Quién: Tim Shepard || || Què: Re: Anyone got a 4306 working properly? ||-|| I have one in a powerbook 17' working with diferent kernels , now 2.6.17-rc3 , and no problem with it , i discover that sometimes its disconnect from AP , and the RTS help a lot to resolve it iwconfig eth0 rts 250 . ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Anyone got a 4306 working properly?
On Monday 05 June 2006 00:28, linuxx wrote: ||-|| || Cuando: Sun, Jun 04, 2006 at 06:06:29PM -0400 || || Quién: Tim Shepard || || Què: Re: Anyone got a 4306 working properly? ||-|| I have one in a powerbook 17' working with diferent kernels , now 2.6.17-rc3 , and no problem with it , i discover that sometimes its disconnect from AP , and the RTS help a lot to resolve it iwconfig eth0 rts 250 . You know that RTS is not supported out of the box on softmac? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work
On Sun, Jun 04, 2006 at 09:26:47PM +0200, Michael Buesch wrote: So, here we go. Preemptible Periodic Work for bcm43xx-softmac. Please stress-test with all methods which come to your minds. I tested with the same configuration that I could always crash before (smp/preempt/debug kernel, then run iperf load tests for an hour or so). I couldn't get it to crash this time. I saw no problems at all. This was the non-shared interrupt case - /proc/interrupts looked like this when I gave up (i lost the beginning): 8: 0IO-APIC-edge rtc 9: 9185 IO-APIC-level acpi 12: 5305IO-APIC-edge i8042 14: 62265IO-APIC-edge ide0 15: 40518IO-APIC-edge ide1 16: 4 IO-APIC-level yenta, ohci1394 17: 1 IO-APIC-level yenta, rtk 18:435 IO-APIC-level ohci_hcd:usb1, NVidia nForce3 Modem 19: 36 IO-APIC-level ohci_hcd:usb2, NVidia nForce3 20: 0 IO-APIC-level ehci_hcd:usb3 21: 11233681 IO-APIC-level bcm43xx NMI: 1419 LOC:1157643 ERR: 0 MIS: 6251 21 9149 So I decided to test the shared interrupt case. When I boot this machine with 'noapic', I get a /proc/interrupts that looks like this: CPU0 0: 209671 XT-PIC timer 1: 1648 XT-PIC i8042 2: 0 XT-PIC cascade 7: 42 XT-PIC parport0 8: 0 XT-PIC rtc 9:472 XT-PIC acpi 10:575 XT-PIC yenta, ohci_hcd:usb2, ehci_hcd:usb3, NVidia nForce3 Modem, rtk 11: 904239 XT-PIC yenta, ohci1394, ohci_hcd:usb1, NVidia nForce3, bcm43xx 12:120 XT-PIC i8042 14: 54296 XT-PIC ide0 15: 6822 XT-PIC ide1 NMI:113 LOC: 209646 ERR: 0 MIS: 0 I found out which of the usb ports was on irq 11, plugged in a usb mouse, and checked that it generated interrupts. (I had to do cat /dev/input/mice /dev/null). Then I repeated the network load tests on the shared bcm43xx irq. Still no problems. looks good! send it upstream. :) Jason ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
