[PATCH 1/3] ps3: vuart: fix error path locking

[PATCH 1/3] ps3: vuart: fix error path locking

[Daniel Walker]

[-- Attachment #1: ps3-vuart-locking-fix.patch --]
[-- Type: text/plain, Size: 770 bytes --]

This stray down would cause a permanent sleep which doesn't seem correct. 
The other uses of this semaphore appear fairly mutex like it's even initialized
with init_MUTEX() ..  So here a patch for removing this one down().

Signed-off-by: Daniel Walker <dwalker@mvista.com>

---
 drivers/ps3/ps3-vuart.c |    1 -
 1 file changed, 1 deletion(-)

Index: linux-2.6.23/drivers/ps3/ps3-vuart.c
===================================================================
--- linux-2.6.23.orig/drivers/ps3/ps3-vuart.c
+++ linux-2.6.23/drivers/ps3/ps3-vuart.c
@@ -1072,7 +1072,6 @@ static int ps3_vuart_probe(struct ps3_sy
 	if (result) {
 		dev_dbg(&dev->core, "%s:%d: drv->probe failed\n",
 			__func__, __LINE__);
-		down(&vuart_bus_priv.probe_mutex);
 		goto fail_probe;
 	}
 

-- 

[PATCH 2/3] driver base: memory: semaphore to mutex

[Daniel Walker]

[-- Attachment #1: base-memory-semaphore-to-mutex.patch --]
[-- Type: text/plain, Size: 1994 bytes --]

Signed-off-by: Daniel Walker <dwalker@mvista.com>

---
 drivers/base/memory.c  |    7 ++++---
 include/linux/memory.h |    5 ++---
 2 files changed, 6 insertions(+), 6 deletions(-)

Index: linux-2.6.23/drivers/base/memory.c
===================================================================
--- linux-2.6.23.orig/drivers/base/memory.c
+++ linux-2.6.23/drivers/base/memory.c
@@ -20,6 +20,7 @@
 #include <linux/kobject.h>
 #include <linux/memory_hotplug.h>
 #include <linux/mm.h>
+#include <linux/mutex.h>
 #include <asm/atomic.h>
 #include <asm/uaccess.h>
 
@@ -220,7 +221,7 @@ static int memory_block_change_state(str
 		unsigned long to_state, unsigned long from_state_req)
 {
 	int ret = 0;
-	down(&mem->state_sem);
+	mutex_lock(&mem->state_mutex);
 
 	if (mem->state != from_state_req) {
 		ret = -EINVAL;
@@ -232,7 +233,7 @@ static int memory_block_change_state(str
 		mem->state = to_state;
 
 out:
-	up(&mem->state_sem);
+	mutex_unlock(&mem->state_mutex);
 	return ret;
 }
 
@@ -357,7 +358,7 @@ static int add_memory_block(unsigned lon
 
 	mem->phys_index = __section_nr(section);
 	mem->state = state;
-	init_MUTEX(&mem->state_sem);
+	mutex_init(&mem->state_mutex);
 	mem->phys_device = phys_device;
 
 	ret = register_memory(mem, section, NULL);
Index: linux-2.6.23/include/linux/memory.h
===================================================================
--- linux-2.6.23.orig/include/linux/memory.h
+++ linux-2.6.23/include/linux/memory.h
@@ -18,8 +18,7 @@
 #include <linux/sysdev.h>
 #include <linux/node.h>
 #include <linux/compiler.h>
-
-#include <asm/semaphore.h>
+#include <linux/mutex.h>
 
 struct memory_block {
 	unsigned long phys_index;
@@ -30,7 +29,7 @@ struct memory_block {
 	 * created long after the critical areas during
 	 * initialization.
 	 */
-	struct semaphore state_sem;
+	struct mutex state_mutex;
 	int phys_device;		/* to which fru does this belong? */
 	void *hw;			/* optional pointer to fw/hw data */
 	int (*phys_callback)(struct memory_block *);

-- 

[PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Daniel Walker]

[-- Attachment #1: bcm43xx-semaphore-to-mutex.patch --]
[-- Type: text/plain, Size: 4170 bytes --]


Signed-Off-By: Daniel Walker <dwalker@mvista.com>

---
 drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c |   30 ++++++++++++-------------
 1 file changed, 15 insertions(+), 15 deletions(-)

Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
===================================================================
--- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
+++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
@@ -43,7 +43,7 @@
 
 static struct bcm43xx_debugfs fs;
 static char really_big_buffer[REALLY_BIG_BUFFER_SIZE];
-static DECLARE_MUTEX(big_buffer_sem);
+static DEFINE_MUTEX(big_buffer_mutex);
 
 
 static ssize_t write_file_dummy(struct file *file, const char __user *buf,
@@ -75,7 +75,7 @@ static ssize_t devinfo_read_file(struct 
 	u16 tmp16;
 	int i;
 
-	down(&big_buffer_sem);
+	mutex_lock(&big_buffer_mutex);
 
 	mutex_lock(&bcm->mutex);
 	spin_lock_irqsave(&bcm->irq_lock, flags);
@@ -125,7 +125,7 @@ out:
 	spin_unlock_irqrestore(&bcm->irq_lock, flags);
 	mutex_unlock(&bcm->mutex);
 	res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
-	up(&big_buffer_sem);
+	mutex_unlock(&big_buffer_mutex);
 	return res;
 }
 
@@ -138,14 +138,14 @@ static ssize_t drvinfo_read_file(struct 
 	size_t pos = 0;
 	ssize_t res;
 
-	down(&big_buffer_sem);
+	mutex_lock(&big_buffer_mutex);
 
 	/* This is where the information is written to the "driver" file */
 	fappend(KBUILD_MODNAME " driver\n");
 	fappend("Compiled at: %s %s\n", __DATE__, __TIME__);
 
 	res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
-	up(&big_buffer_sem);
+	mutex_unlock(&big_buffer_mutex);
 	return res;
 }
 
@@ -160,7 +160,7 @@ static ssize_t spromdump_read_file(struc
 	ssize_t res;
 	unsigned long flags;
 
-	down(&big_buffer_sem);
+	mutex_lock(&big_buffer_mutex);
 	mutex_lock(&bcm->mutex);
 	spin_lock_irqsave(&bcm->irq_lock, flags);
 	if (bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED) {
@@ -175,7 +175,7 @@ out:
 	spin_unlock_irqrestore(&bcm->irq_lock, flags);
 	mutex_unlock(&bcm->mutex);
 	res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
-	up(&big_buffer_sem);
+	mutex_unlock(&big_buffer_mutex);
 	return res;
 }
 
@@ -191,7 +191,7 @@ static ssize_t tsf_read_file(struct file
 	unsigned long flags;
 	u64 tsf;
 
-	down(&big_buffer_sem);
+	mutex_lock(&big_buffer_mutex);
 	mutex_lock(&bcm->mutex);
 	spin_lock_irqsave(&bcm->irq_lock, flags);
 	if (bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED) {
@@ -207,7 +207,7 @@ out:
 	spin_unlock_irqrestore(&bcm->irq_lock, flags);
 	mutex_unlock(&bcm->mutex);
 	res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
-	up(&big_buffer_sem);
+	mutex_unlock(&big_buffer_mutex);
 	return res;
 }
 
@@ -222,7 +222,7 @@ static ssize_t tsf_write_file(struct fil
 	unsigned long long tsf;
 
 	buf_size = min(count, sizeof (really_big_buffer) - 1);
-	down(&big_buffer_sem);
+	mutex_lock(&big_buffer_mutex);
 	if (copy_from_user(buf, user_buf, buf_size)) {
 	        res = -EFAULT;
 		goto out_up;
@@ -247,7 +247,7 @@ out_unlock:
 	spin_unlock_irqrestore(&bcm->irq_lock, flags);
 	mutex_unlock(&bcm->mutex);
 out_up:
-	up(&big_buffer_sem);
+	mutex_unlock(&big_buffer_mutex);
 	return res;
 }
 
@@ -265,7 +265,7 @@ static ssize_t txstat_read_file(struct f
 	struct bcm43xx_xmitstatus *status;
 	int i, cnt, j = 0;
 
-	down(&big_buffer_sem);
+	mutex_lock(&big_buffer_mutex);
 	mutex_lock(&bcm->mutex);
 	spin_lock_irqsave(&bcm->irq_lock, flags);
 
@@ -312,7 +312,7 @@ static ssize_t txstat_read_file(struct f
 	}
 	spin_unlock_irqrestore(&bcm->irq_lock, flags);
 	mutex_unlock(&bcm->mutex);
-	up(&big_buffer_sem);
+	mutex_unlock(&big_buffer_mutex);
 	return res;
 }
 
@@ -326,7 +326,7 @@ static ssize_t restart_write_file(struct
 	unsigned long flags;
 
 	buf_size = min(count, sizeof (really_big_buffer) - 1);
-	down(&big_buffer_sem);
+	mutex_lock(&big_buffer_mutex);
 	if (copy_from_user(buf, user_buf, buf_size)) {
 	        res = -EFAULT;
 		goto out_up;
@@ -348,7 +348,7 @@ out_unlock:
 	spin_unlock_irqrestore(&(bcm)->irq_lock, flags);
 	mutex_unlock(&(bcm)->mutex);
 out_up:
-	up(&big_buffer_sem);
+	mutex_unlock(&big_buffer_mutex);
 	return res;
 }
 

-- 

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Wednesday 12 December 2007 09:00:03 Daniel Walker wrote:
> 
> Signed-Off-By: Daniel Walker <dwalker@mvista.com>
> 
> ---
>  drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c |   30 ++++++++++++-------------
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> ===================================================================
> --- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> +++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> @@ -43,7 +43,7 @@
>  
>  static struct bcm43xx_debugfs fs;
>  static char really_big_buffer[REALLY_BIG_BUFFER_SIZE];
> -static DECLARE_MUTEX(big_buffer_sem);
> +static DEFINE_MUTEX(big_buffer_mutex);

This driver is scheduled for removal, so I'd not touch it anymore
to avoid the possibility to introduce a lastminute regression.
The new drivers (b43 and b43legacy) have this fixed (in a different
way by completely removing it).

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 12, 2007 4:48 PM, Michael Buesch <mb@bu3sch.de> wrote:
> This driver is scheduled for removal, so I'd not touch it anymore
> to avoid the possibility to introduce a lastminute regression.
> The new drivers (b43 and b43legacy) have this fixed (in a different
> way by completely removing it).

Uhm, hijacking the thread a bit here, but which driver is supposed to
be supporting my 4309? Neither b43 nor b43legacy found my wireless,
and I'm not seeing its PCI ID anywhere either of those...

$ lspci -s 02:02 -v;  lspci -n -s 02:02 -v -x
02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03)
        Subsystem: Hewlett-Packard Company Unknown device 12f9
        Flags: bus master, fast devsel, latency 64, IRQ 22
        Memory at d0010000 (32-bit, non-prefetchable) [size=8K]

02:02.0 0280: 14e4:4324 (rev 03)
        Subsystem: 103c:12f9
        Flags: bus master, fast devsel, latency 64, IRQ 22
        Memory at d0010000 (32-bit, non-prefetchable) [size=8K]
00: e4 14 24 43 06 00 00 00 03 00 80 02 00 40 00 00
10: 00 00 01 d0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 f9 12
30: 00 00 00 00 00 00 00 00 00 00 00 00 05 01 00 00

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Daniel Walker]

On Thu, 2007-12-13 at 01:48 +0100, Michael Buesch wrote:
> On Wednesday 12 December 2007 09:00:03 Daniel Walker wrote:
> > 
> > Signed-Off-By: Daniel Walker <dwalker@mvista.com>
> > 
> > ---
> >  drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c |   30 ++++++++++++-------------
> >  1 file changed, 15 insertions(+), 15 deletions(-)
> > 
> > Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> > ===================================================================
> > --- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> > +++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> > @@ -43,7 +43,7 @@
> >  
> >  static struct bcm43xx_debugfs fs;
> >  static char really_big_buffer[REALLY_BIG_BUFFER_SIZE];
> > -static DECLARE_MUTEX(big_buffer_sem);
> > +static DEFINE_MUTEX(big_buffer_mutex);
> 
> This driver is scheduled for removal, so I'd not touch it anymore
> to avoid the possibility to introduce a lastminute regression.
> The new drivers (b43 and b43legacy) have this fixed (in a different
> way by completely removing it).

When is the removal scheduled?

Daniel

Re: [PATCH 1/3] ps3: vuart: fix error path locking

[Geoff Levand]

> This stray down would cause a permanent sleep which doesn't seem correct. 
> The other uses of this semaphore appear fairly mutex like it's even initialized
> with init_MUTEX() ..  So here a patch for removing this one down().
> 
> Signed-off-by: Daniel Walker <dwalker@mvista.com>
> 
> ---
>  drivers/ps3/ps3-vuart.c |    1 -
>  1 file changed, 1 deletion(-)


Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>


Looks, good. 
Andrew, Please apply.

-Geoff 

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.com> wrote:

> > This driver is scheduled for removal, so I'd not touch it anymore to 
> > avoid the possibility to introduce a lastminute regression. The new 
> > drivers (b43 and b43legacy) have this fixed (in a different way by 
> > completely removing it).
> 
> When is the removal scheduled?

$ grep -i bcm Documentation/feature-removal-schedule.txt
$

might make sense to update this file.

	Ingo

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Thursday 13 December 2007 11:13:27 Ingo Molnar wrote:
> 
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > > This driver is scheduled for removal, so I'd not touch it anymore to 
> > > avoid the possibility to introduce a lastminute regression. The new 
> > > drivers (b43 and b43legacy) have this fixed (in a different way by 
> > > completely removing it).
> > 
> > When is the removal scheduled?
> 
> $ grep -i bcm Documentation/feature-removal-schedule.txt
> $
> 
> might make sense to update this file.

Patches are on their way.
I think it's scheduled to be removed after 2.6.25 was released.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Thursday 13 December 2007 02:17:16 Ray Lee wrote:
> On Dec 12, 2007 4:48 PM, Michael Buesch <mb@bu3sch.de> wrote:
> > This driver is scheduled for removal, so I'd not touch it anymore
> > to avoid the possibility to introduce a lastminute regression.
> > The new drivers (b43 and b43legacy) have this fixed (in a different
> > way by completely removing it).
> 
> Uhm, hijacking the thread a bit here, but which driver is supposed to
> be supporting my 4309? Neither b43 nor b43legacy found my wireless,
> and I'm not seeing its PCI ID anywhere either of those...
> 
> $ lspci -s 02:02 -v;  lspci -n -s 02:02 -v -x
> 02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03)
>         Subsystem: Hewlett-Packard Company Unknown device 12f9
>         Flags: bus master, fast devsel, latency 64, IRQ 22
>         Memory at d0010000 (32-bit, non-prefetchable) [size=8K]
> 
> 02:02.0 0280: 14e4:4324 (rev 03)

The device is supported by b43.
The PCI ID is in the SSB PCI bridge code

static const struct pci_device_id b43_pci_bridge_tbl[] = {
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4301) },
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4307) },
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4311) },
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4312) },
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4318) },
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4319) },
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4320) },
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4321) },
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4325) },
        { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4328) },
        { 0, },
};
MODULE_DEVICE_TABLE(pci, b43_pci_bridge_tbl);

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[John W. Linville]

On Thu, Dec 13, 2007 at 12:11:32PM +0100, Michael Buesch wrote:
> On Thursday 13 December 2007 11:13:27 Ingo Molnar wrote:
> > 
> > * Daniel Walker <dwalker@mvista.com> wrote:
> > 
> > > > This driver is scheduled for removal, so I'd not touch it anymore to 
> > > > avoid the possibility to introduce a lastminute regression. The new 
> > > > drivers (b43 and b43legacy) have this fixed (in a different way by 
> > > > completely removing it).
> > > 
> > > When is the removal scheduled?
> > 
> > $ grep -i bcm Documentation/feature-removal-schedule.txt
> > $
> > 
> > might make sense to update this file.
> 
> Patches are on their way.
> I think it's scheduled to be removed after 2.6.25 was released.

A patch w/ subject "bcm43xx: mark as obsolete and schedule for removal"
is queued in net-2.6.25 and waiting for the 2.6.25 merge window.
It includes this hunk:

--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -333,3 +333,12 @@ Why:	This driver has been marked obsolete for many years.
 Who:	Stephen Hemminger <shemminger@linux-foundation.org>
 
 ---------------------------
+
+What:	bcm43xx wireless network driver
+When:	2.6.26
+Files:	drivers/net/wireless/bcm43xx
+Why:	This driver's functionality has been replaced by the
+	mac80211-based b43 and b43legacy drivers.
+Who:	John W. Linville <linville@tuxdriver.com>
+
+---------------------------

Hth!

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 13, 2007 5:45 AM, Michael Buesch <mb@bu3sch.de> wrote:
> On Thursday 13 December 2007 02:17:16 Ray Lee wrote:
> > Uhm, hijacking the thread a bit here, but which driver is supposed to
> > be supporting my 4309? Neither b43 nor b43legacy found my wireless,
> > and I'm not seeing its PCI ID anywhere either of those...
> >
> > 02:02.0 0280: 14e4:4324 (rev 03)
>
> The device is supported by b43.
> The PCI ID is in the SSB PCI bridge code
>
> static const struct pci_device_id b43_pci_bridge_tbl[] = {
...
>         { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },

Ah, thanks, so it is. Well, doing an `rmmod bcm43xx ; modprobe ssb
b43` gives me nothing in dmesg other than lines related to the bcm43xx
driver. iwconfig/ifconfig do not see the interface either.

<goes and reads bcm43xx-dev archives>

Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
realize that. Hopefully that'll be automatic soon. Regardless, upon
doing so, and loading ssb and b43, it sees my card, but is still not
fully functional. iwconfig sees:

lo        no wireless extensions.
eth0      no wireless extensions.
tun0      no wireless extensions.
eth1      no wireless extensions.
wlan0_rename  IEEE 802.11g  ESSID:""
          Mode:Managed  Channel:0  Access Point: Not-Associated
          Tx-Power=0 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2346 B
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

(eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)

`ifconfig` doesn't see eth1 or wlan0_rename.

What else might I be doing wrong? Regardless, perhaps scheduling
bcm43xx for removal in 2.6.26 is a bit premature.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 01:05:00 Ray Lee wrote:
> Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
> realize that. Hopefully that'll be automatic soon. Regardless, upon
> doing so, and loading ssb and b43, it sees my card, but is still not
> fully functional. iwconfig sees:
> 
> lo        no wireless extensions.
> eth0      no wireless extensions.
> tun0      no wireless extensions.
> eth1      no wireless extensions.
> wlan0_rename  IEEE 802.11g  ESSID:""
>           Mode:Managed  Channel:0  Access Point: Not-Associated
>           Tx-Power=0 dBm
>           Retry min limit:7   RTS thr:off   Fragment thr=2346 B
>           Link Quality:0  Signal level:0  Noise level:0
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> 
> (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
> 
> `ifconfig` doesn't see eth1 or wlan0_rename.
> 
> What else might I be doing wrong?

I don't know. Try ifconfig -a
Or tell udev to not crap up your device names.

> Regardless, perhaps scheduling 
> bcm43xx for removal in 2.6.26 is a bit premature.

Oh come on. b43 is more than a year old now. How long should we wait?
Two or three? Forever?

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Harvey Harrison]

On Fri, 2007-12-14 at 01:43 +0100, Michael Buesch wrote:
> Oh come on. b43 is more than a year old now. How long should we wait?
> Two or three? Forever?
> 

Any pointers to the advantages of b43?

Harvey

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 13, 2007 4:43 PM, Michael Buesch <mb@bu3sch.de> wrote:
> On Friday 14 December 2007 01:05:00 Ray Lee wrote:
> > Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
> > realize that. Hopefully that'll be automatic soon. Regardless, upon
> > doing so, and loading ssb and b43, it sees my card, but is still not
> > fully functional. iwconfig sees:
> >
> > lo        no wireless extensions.
> > eth0      no wireless extensions.
> > tun0      no wireless extensions.
> > eth1      no wireless extensions.
> > wlan0_rename  IEEE 802.11g  ESSID:""
> >           Mode:Managed  Channel:0  Access Point: Not-Associated
> >           Tx-Power=0 dBm
> >           Retry min limit:7   RTS thr:off   Fragment thr=2346 B
> >           Link Quality:0  Signal level:0  Noise level:0
> >           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
> >           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> >
> > (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
> >
> > `ifconfig` doesn't see eth1 or wlan0_rename.
> >
> > What else might I be doing wrong?
>
> I don't know. Try ifconfig -a
> Or tell udev to not crap up your device names.

Uhm, I haven't had to tell udev to not crap up any of my *other*
devices, why is b43 special? I'm using an up-to-date userspace, so I'm
not going to be the only one hitting this problem. And ifconfig -a
does indeed show it, sorry about that. But my understanding is that
udev renames interfaces based on MAC address, so I wouldn't suspect
udev to be at fault here.

Digging a little farther into it, it looks like b43 is barfing partway
through init as the firmware file it's looking for has changed names.
Perhaps that's the issue. I'll take a longer look at this all
tomorrow.

> > Regardless, perhaps scheduling
> > bcm43xx for removal in 2.6.26 is a bit premature.
>
> Oh come on. b43 is more than a year old now. How long should we wait?
> Two or three? Forever?

Well, it only hit the main kernel October 10th. That means no final
point release of the kernel.org kernel has even had it included! So
testing-wise, you still haven't hit the hordes yet. Scheduling a
removal of bcm43xx (as painful as that code is [*]), seems either
premature or very optimistic. So, how about scheduling the removal
once you get a feel for the bug reports that'll come in once 2.6.24 is
released.

   [*] Yeah, even as a user the code is painful. It *still* locks my
keyboard if I happen to disable the wireless while it's scanning. The
sooner bcm43xx is dead, the better. But b43 is quite obviously not a
full replacement for everyone.

I don't mean to come off harsh, I know you put an amazing amount of
work into both b43 and bcm43xx, and I'm thankful for that. But
requiring the end-user to go scan bcm43xx-dev archives to find out
that the b43 module isn't correctly autoloading all of its
dependencies is a sign that the code still hasn't had a lot of
testing, no?

In the meantime I'll keep plugging away at trying to figure out what's wrong.

Ray

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Larry Finger]

Michael Buesch wrote:
> On Friday 14 December 2007 01:05:00 Ray Lee wrote:
>> Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
>> realize that. Hopefully that'll be automatic soon. Regardless, upon
>> doing so, and loading ssb and b43, it sees my card, but is still not
>> fully functional. iwconfig sees:
>>
>> lo        no wireless extensions.
>> eth0      no wireless extensions.
>> tun0      no wireless extensions.
>> eth1      no wireless extensions.
>> wlan0_rename  IEEE 802.11g  ESSID:""
>>           Mode:Managed  Channel:0  Access Point: Not-Associated
>>           Tx-Power=0 dBm
>>           Retry min limit:7   RTS thr:off   Fragment thr=2346 B
>>           Link Quality:0  Signal level:0  Noise level:0
>>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>>           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
>>
>> (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
>>
>> `ifconfig` doesn't see eth1 or wlan0_rename.
>>
>> What else might I be doing wrong?

Your udev rules are screwed up. In /etc/udev/rules.d/70-persistent-net.rules, you should have a line 
that looks like

SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1a:73:6b:28:5a", ATTR{type}=="1", NAME="eth1"

with the MAC address for your device. You probably have the ATTR{type}=="1" clause missing.

Larry

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 01:55:50 Harvey Harrison wrote:
> On Fri, 2007-12-14 at 01:43 +0100, Michael Buesch wrote:
> > Oh come on. b43 is more than a year old now. How long should we wait?
> > Two or three? Forever?
> > 
> 
> Any pointers to the advantages of b43?

http://www.linuxwireless.org/en/users/Drivers/b43

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 02:12:25 Ray Lee wrote:
> Digging a little farther into it, it looks like b43 is barfing partway
> through init as the firmware file it's looking for has changed names.
> Perhaps that's the issue. I'll take a longer look at this all
> tomorrow.

http://www.linuxwireless.org/en/users/Drivers/b43#firmwareinstallation

> Well, it only hit the main kernel October 10th. That means no final
> point release of the kernel.org kernel has even had it included! So
> testing-wise, you still haven't hit the hordes yet. Scheduling a
> removal of bcm43xx (as painful as that code is [*]), seems either
> premature or very optimistic. So, how about scheduling the removal
> once you get a feel for the bug reports that'll come in once 2.6.24 is
> released.

So you volunteer to maintain bcm43xx? Fine. Thanks a lot.

>    [*] Yeah, even as a user the code is painful. It *still* locks my
> keyboard if I happen to disable the wireless while it's scanning. The
> sooner bcm43xx is dead, the better. But b43 is quite obviously not a
> full replacement for everyone.

I'm pretty sure it is.
Please carefully read the instructions on
http://www.linuxwireless.org/en/users/Drivers/b43
especially for firmware installation.
It will work very well.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ingo Molnar]

* Michael Buesch <mb@bu3sch.de> wrote:

> > (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
> > 
> > `ifconfig` doesn't see eth1 or wlan0_rename.
> > 
> > What else might I be doing wrong?
> 
> I don't know. Try ifconfig -a Or tell udev to not crap up your device 
> names.
> 
> > Regardless, perhaps scheduling bcm43xx for removal in 2.6.26 is a 
> > bit premature.
> 
> Oh come on. b43 is more than a year old now. How long should we wait? 
> Two or three? Forever?

possibly forever, if you dont get obvious regressions like "my wlan does 
not work" (reported in this very thread), resolved. Pushing the blame to 
udev (in a rather unfriendly way) wont give users a working system and 
wont get you many new testers for the new driver either.

	Ingo

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ingo Molnar]

* Michael Buesch <mb@bu3sch.de> wrote:

> On Friday 14 December 2007 02:12:25 Ray Lee wrote:
> > Digging a little farther into it, it looks like b43 is barfing partway
> > through init as the firmware file it's looking for has changed names.
> > Perhaps that's the issue. I'll take a longer look at this all
> > tomorrow.
> 
> http://www.linuxwireless.org/en/users/Drivers/b43#firmwareinstallation
> 
> > Well, it only hit the main kernel October 10th. That means no final
> > point release of the kernel.org kernel has even had it included! So
> > testing-wise, you still haven't hit the hordes yet. Scheduling a
> > removal of bcm43xx (as painful as that code is [*]), seems either
> > premature or very optimistic. So, how about scheduling the removal
> > once you get a feel for the bug reports that'll come in once 2.6.24 is
> > released.
> 
> So you volunteer to maintain bcm43xx? Fine. Thanks a lot.

it's sad that you are trying to force testers to upgrade to your new 
driver by threatening to unsupport the old driver. The testers who did 
nothing but reported that the new driver did not work on their hardware.

You can write new drivers but you must not break existing users. That's 
true for every single piece of the kernel. It is _your_ responsibility 
to get that rule right - and if it does not work out of box (no matter 
whom to blame, udev or the driver) you dont get to remove the driver 
from the upstream kernel.

Yes, you can then "unsupport it" in spite and be a prick about it in 
general but that will only talk of your own personal qualities and will 
sharply reduce your credibility as a maintainer (and eventually hinder 
your ability to introduce new code) - users will still have the code 
available and will have a chance to fix the driver that happens to work. 
(and perhaps another, capable, but friendler maintainer arises.) And 
that old code will be a clot to drag around, hindering your 'new' 
wireless code all along.

I really dont know why it's so hard to understand: new is totally 
useless if it does not work for old setups 100% of the time. And people 
_WANT_ to use your new code, so it's not like you have to pull their 
hairs to get your stuff tested. And YOU wrote the old code in large 
part:

 $ git-authors drivers/net/wireless/bcm43xx/ | tail -10
      2  Sam Ravnborg
      3  David Howells
      3  David Woodhouse
      3  Joe Perches
      4  Jeff Garzik
      5  Daniel Drake
      6  Stefano Brivio
      9  John W. Linville
     48  Larry Finger
     80  Michael Buesch

so it's not like "someone else messed it up" and that you would be 
incapable of getting it all work nicely and make the migration of users 
smoother. And if udev is a hindrance to you, reduce your driver's 
dependence on udev breakages.

	Ingo

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 12:15:34 Ingo Molnar wrote:
> > So you volunteer to maintain bcm43xx? Fine. Thanks a lot.
> 
> it's sad that you are trying to force testers to upgrade to your new 
> driver by threatening to unsupport the old driver.

I dropped maintainance for bcm43xx over a year ago.
So I am not going to catch it up again. b43 works fine.
I don't see a reason to support bcm43xx anymore.
Currently bcm43xx is orphaned, as Larry couldn't support it
anymore due to other issues.

> The testers who did  
> nothing but reported that the new driver did not work on their hardware.

Which testers?
Ray Lee didn't even install the firmware. So it can't work by definition.
That is not my fault.

> You can write new drivers but you must not break existing users. That's 
> true for every single piece of the kernel. It is _your_ responsibility 
> to get that rule right - and if it does not work out of box (no matter 
> whom to blame, udev or the driver) you dont get to remove the driver 
> from the upstream kernel.

Ok. So we have to live with an orphaned driver. I am fine with that, too.

> Yes, you can then "unsupport it" in spite and be a prick about it in 
> general but that will only talk of your own personal qualities and will 
> sharply reduce your credibility as a maintainer (and eventually hinder 
> your ability to introduce new code) - users will still have the code 
> available and will have a chance to fix the driver that happens to work. 
> (and perhaps another, capable, but friendler maintainer arises.) And 
> that old code will be a clot to drag around, hindering your 'new' 
> wireless code all along.

So new code is included in the Linux kernel based only on political
considerations instead on technical?
I'm not sure what's the matter. Show me _one_ person for whom
bcm43xx works and b43/legacy does not. And I will immediately stop
removal of that driver and fix b43.

> I really dont know why it's so hard to understand: new is totally 
> useless if it does not work for old setups 100% of the time. And people 
> _WANT_ to use your new code, so it's not like you have to pull their 
> hairs to get your stuff tested. And YOU wrote the old code in large 
> part:
> 
>  $ git-authors drivers/net/wireless/bcm43xx/ | tail -10
>       2  Sam Ravnborg
>       3  David Howells
>       3  David Woodhouse
>       3  Joe Perches
>       4  Jeff Garzik
>       5  Daniel Drake
>       6  Stefano Brivio
>       9  John W. Linville
>      48  Larry Finger
>      80  Michael Buesch
> 
> so it's not like "someone else messed it up" and that you would be 
> incapable of getting it all work nicely and make the migration of users 
> smoother. And if udev is a hindrance to you, reduce your driver's 
> dependence on udev breakages.

I'm not sure what you are talking about.
If udev renames the device to something stupid (like wlan0_rename)
that is not my fault. That is the fault of a big Linux Distribution
messing udev config up.

Let's summarise it:
I don't know a single user for whom bcm43xx works but b43 does not.
In most cases b43 does work a _lot_ better than bcm43xx.
If you show me one person for whom bcm43xx works but b43 does not I
will stop removal of the driver.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ingo Molnar]

* Michael Buesch <mb@bu3sch.de> wrote:

> > The testers who did nothing but reported that the new driver did not 
> > work on their hardware.
> 
> Which testers?

right in this thread Ray Lee is reporting:

| | Digging a little farther into it, it looks like b43 is barfing 
| | partway through init as the firmware file it's looking for has 
| | changed names. Perhaps that's the issue. I'll take a longer look at 
| | this all tomorrow.

you are really in denial of reality. Just re-read this thread. Upon 
re-reading this thread, try to imagine that you are in place of Ray Lee 
(might be hard), that you had a working bcm43xx driver and that now you 
try to get b43 to work. You are not a kernel hacker who knows this 
driver, just an advanced user who'd like to give you some more feedback 
about your shiny new code. From that perspective, do you think your 
replies were fine, constructive and involved the tester? I sure read 
them as dismissive, they had an annoyed tone (i'm not sure why - he was 
trying to get _YOUR_ code to work) and were borderline arrogant. Looking 
at the replies from Ray Lee it sure seemed to me he had a similar 
impression. In place of Ray Lee, would you report new bugs to the 
maintainer of b43? I sure as hell would avoid it if i could. Do you 
think such incidents help Linux in the long run?

and you even claim:

> Ray Lee didn't even install the firmware. So it can't work by 
> definition. That is not my fault.

which questions your basic skills of reading or of empathy. Why is a 
reasonable firmware blob not included in the kernel? If not, why doesnt 
the b43 driver warn in the dmesg (where Ray Lee did look) that no 
firmware was loaded? These are basic driver usability issues, and of 
course they are your fault too.

> > Yes, you can then "unsupport it" in spite and be a prick about it in 
> > general but that will only talk of your own personal qualities and 
> > will sharply reduce your credibility as a maintainer (and eventually 
> > hinder your ability to introduce new code) - users will still have 
> > the code available and will have a chance to fix the driver that 
> > happens to work. (and perhaps another, capable, but friendler 
> > maintainer arises.) And that old code will be a clot to drag around, 
> > hindering your 'new' wireless code all along.
>
> So new code is included in the Linux kernel based only on political 
> considerations instead on technical?

huh? This is nothing "political". It's the basic rule of maintenance: 
try to be a good maintainer, involve people, forgive their newbie 
mistakes. It's like the driving principle of Intenret protocols: be 
conservative at what you xmit and be liberal at what you rx.

	Ingo

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 13:16:17 Ingo Molnar wrote:
> 
> * Michael Buesch <mb@bu3sch.de> wrote:
> 
> > > The testers who did nothing but reported that the new driver did not 
> > > work on their hardware.
> > 
> > Which testers?
> 
> right in this thread Ray Lee is reporting:
> 
> | | Digging a little farther into it, it looks like b43 is barfing 
> | | partway through init as the firmware file it's looking for has 
> | | changed names. Perhaps that's the issue. I'll take a longer look at 
> | | this all tomorrow.
> 
> you are really in denial of reality. Just re-read this thread. Upon 
> re-reading this thread, try to imagine that you are in place of Ray Lee 
> (might be hard), that you had a working bcm43xx driver and that now you 
> try to get b43 to work. You are not a kernel hacker who knows this 
> driver, just an advanced user who'd like to give you some more feedback 
> about your shiny new code.

This user did get the following messages in dmesg:

b43err(dev->wl, "Firmware file \"%s\" not found "
       "or load failed.\n", path);
b43err(wl, "You must go to "
       "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
       "and download the correct firmware (version 4).\n");

I'm not sure how I can improve that even more. There is a full URL
describing how to get the device workin in _full_ detail.

Yes. I know people don't read messages and immediately report
a "regression". But that is not my fault. Not in this case.

It's not rocket science to get b43 working. The way firmware is
installed did not change at all. (b43-fwcutter is still used).
So it's the very same procedure that user X already successfully
did when installing bcm43xx.

What should I do to improve the situation? Writing the message
all in uppercase? Maybe. I can do a patch, if people finally start reading
it then.

> > Ray Lee didn't even install the firmware. So it can't work by 
> > definition. That is not my fault.
> 
> which questions your basic skills of reading or of empathy. Why is a 
> reasonable firmware blob not included in the kernel?

Because it's closed source.

> If not, why doesnt  
> the b43 driver warn in the dmesg (where Ray Lee did look) that no 
> firmware was loaded? These are basic driver usability issues, and of 
> course they are your fault too.

This is a proven false statement.

> > So new code is included in the Linux kernel based only on political 
> > considerations instead on technical?
> 
> huh? This is nothing "political". It's the basic rule of maintenance: 
> try to be a good maintainer, involve people, forgive their newbie 
> mistakes. It's like the driving principle of Intenret protocols: be 
> conservative at what you xmit and be liberal at what you rx.

That's not what my problem is here.
The problem is that every now and then people come up and say that
b43 is crap and doesn't work for them while bcm43xx does. In _every_
single case it was the user's fault. Mostly not reading the kernel
message I quoted above.

So I'm not sure what I have to do now? Defer removal of an obsolete
and unstable piece of junk because some people don't read kernel
logs in case something doesn't work?

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ingo Molnar]

* Michael Buesch <mb@bu3sch.de> wrote:

> This user did get the following messages in dmesg:
> 
> b43err(dev->wl, "Firmware file \"%s\" not found "
>        "or load failed.\n", path);
> b43err(wl, "You must go to "
>        "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
>        "and download the correct firmware (version 4).\n");
> 
> I'm not sure how I can improve that even more. There is a full URL 
> describing how to get the device workin in _full_ detail.

well i dont have this hardware, but the following description in this 
thread seems to contradict that:

|| Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in 
|| dmesg other than lines related to the bcm43xx driver. 
|| iwconfig/ifconfig do not see the interface either.

	Ingo

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Simon Holm Thøgersen]

fre, 14 12 2007 kl. 13:31 +0100, skrev Michael Buesch:
> On Friday 14 December 2007 13:16:17 Ingo Molnar wrote:
> > 
> > * Michael Buesch <mb@bu3sch.de> wrote:
> > 
> > > > The testers who did nothing but reported that the new driver did not 
> > > > work on their hardware.
> > > 
> > > Which testers?
> > 
> > right in this thread Ray Lee is reporting:
> > 
> > | | Digging a little farther into it, it looks like b43 is barfing 
> > | | partway through init as the firmware file it's looking for has 
> > | | changed names. Perhaps that's the issue. I'll take a longer look at
        ^^^^^^^^^^^^^^
Ray probably has version 3 of the firmware.

> > | | this all tomorrow.
> > 
> > you are really in denial of reality. Just re-read this thread. Upon 
> > re-reading this thread, try to imagine that you are in place of Ray Lee 
> > (might be hard), that you had a working bcm43xx driver and that now you 
> > try to get b43 to work. You are not a kernel hacker who knows this 
> > driver, just an advanced user who'd like to give you some more feedback 
> > about your shiny new code.
> 
> This user did get the following messages in dmesg:
> 
> b43err(dev->wl, "Firmware file \"%s\" not found "
>        "or load failed.\n", path);

So the question seems to be why b43 needs version 4, when b43legacy and
bcm43x uses version 3?


Simon Holm Thøgersen

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
> > This user did get the following messages in dmesg:
> > 
> > b43err(dev->wl, "Firmware file \"%s\" not found "
> >        "or load failed.\n", path);
> 
> So the question seems to be why b43 needs version 4, when b43legacy and
> bcm43x uses version 3?

That's really a question, right?

Well. linux-2.4 doesn't work with the linux-2.6 modutils.
Windows Vista doesn't work with Windows 98 device drivers.
That leads to this assumption:
b43 doesn't work with version 3 firmware but needs version 4.

Newer drivers supporting newer hardware need newer firmware.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 13:53:27 Ingo Molnar wrote:
> 
> * Michael Buesch <mb@bu3sch.de> wrote:
> 
> > This user did get the following messages in dmesg:
> > 
> > b43err(dev->wl, "Firmware file \"%s\" not found "
> >        "or load failed.\n", path);
> > b43err(wl, "You must go to "
> >        "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
> >        "and download the correct firmware (version 4).\n");
> > 
> > I'm not sure how I can improve that even more. There is a full URL 
> > describing how to get the device workin in _full_ detail.
> 
> well i dont have this hardware, but the following description in this 
> thread seems to contradict that:
> 
> || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in 
> || dmesg other than lines related to the bcm43xx driver. 
> || iwconfig/ifconfig do not see the interface either.

Let's quote another of Ray's statements:
"And ifconfig -a does indeed show it, sorry about that."

So if he did then try to initialize that device, that clearly
_did_ show up in a standard place where network devices are
expected to show up, he did see the message I quoted.
Well, what if he did not try to initialize the device by doing
an "ifconfig wlanX up"? That can hardly be my fault, right?

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[John W. Linville]

On Fri, Dec 14, 2007 at 11:56:24AM +0100, Ingo Molnar wrote:
> 
> * Michael Buesch <mb@bu3sch.de> wrote:

> > Oh come on. b43 is more than a year old now. How long should we wait? 
> > Two or three? Forever?
> 
> possibly forever, if you dont get obvious regressions like "my wlan does 
> not work" (reported in this very thread), resolved. Pushing the blame to 
> udev (in a rather unfriendly way) wont give users a working system and 
> wont get you many new testers for the new driver either.

It is true that Michael can be a little unpleasant at times.
The colloquialism that comes to mind is that he "does not suffer fools
lightly".  Hopefully he will take your counseling to heart and learn
to be a bit more moderate in his tone.  FWIW, he is still young. :-)

That said, it is also true that the b43[legacy] driver[s] do a more
than adequate job of replacing the old bcm43xx driver provided that
one (re-)installs the proper firmware.  And I know of no other driver
that goes to more trouble to tell you how to get the proper firmware
installed than this one.

The bcm43xx driver will be added to the feature removal schedule
in 2.6.25.  Proper judgment will be used in deciding the actual date
of its removal.  In the meantime hopefully every distribution will
have or obtain a working udev configuration.  If things don't work
out as planned then we will re-evaluate.

Let's stop this now please.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[stefano.brivio]

"John W. Linville" <linville@tuxdriver.com> wrote:

> On Fri, Dec 14, 2007 at 11:56:24AM +0100, Ingo Molnar wrote:
>>
>> * Michael Buesch <mb@bu3sch.de> wrote:
>
>> > Oh come on. b43 is more than a year old now. How long should we wait?
>> > Two or three? Forever?
>>
>> possibly forever, if you dont get obvious regressions like "my wlan does
>> not work" (reported in this very thread), resolved. Pushing the blame to
>> udev (in a rather unfriendly way) wont give users a working system and
>> wont get you many new testers for the new driver either.
>
> It is true that Michael can be a little unpleasant at times.
> The colloquialism that comes to mind is that he "does not suffer fools
> lightly".  Hopefully he will take your counseling to heart and learn
> to be a bit more moderate in his tone.  FWIW, he is still young. :-)

No way. He's just inhuman. :P

> That said, it is also true that the b43[legacy] driver[s] do a more
> than adequate job of replacing the old bcm43xx driver provided that
> one (re-)installs the proper firmware.  And I know of no other driver
> that goes to more trouble to tell you how to get the proper firmware
> installed than this one.
>
> The bcm43xx driver will be added to the feature removal schedule
> in 2.6.25.  Proper judgment will be used in deciding the actual date
> of its removal.  In the meantime hopefully every distribution will
> have or obtain a working udev configuration.  If things don't work
> out as planned then we will re-evaluate.
>
> Let's stop this now please.

Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo  
suggests other ways to smooth out the transition. I haven't read  
proposals yet.


--
Ciao
Stefano

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

Hi all. Perhaps I can inject some facts into this?

On Dec 14, 2007 5:08 AM, Michael Buesch <mb@bu3sch.de> wrote:
> > > This user did get the following messages in dmesg:
> > >
> > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > >        "or load failed.\n", path);
> > > b43err(wl, "You must go to "
> > >        "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
> > >        "and download the correct firmware (version 4).\n");
> > >
> > > I'm not sure how I can improve that even more. There is a full URL
> > > describing how to get the device workin in _full_ detail.

Yes, but only if you load rfkill-input and rfkill by hand, prior.
Without those, dmesg is entirely silent, and nothing works even to the
stage that I got it to last night. I had to search the bcm43xx-dev
archives to find that out, and it was a message from Larry saying that
he'd finally tracked down why it was working for some people and not
others -- some of us build fully modular kernels.

That I'm one of the first people to hit that makes me think that your
testing base so far has been miniscule.

Once I did that, the dmesg after loading did indeed contain the URL,
and thank you for that.

> > well i dont have this hardware, but the following description in this
> > thread seems to contradict that:
> >
> > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in
> > || dmesg other than lines related to the bcm43xx driver.
> > || iwconfig/ifconfig do not see the interface either.

See above. Without a modprobe of rfkill, rfkill-input that is the case.

> Let's quote another of Ray's statements:
> "And ifconfig -a does indeed show it, sorry about that."
>
> So if he did then try to initialize that device, that clearly
> _did_ show up in a standard place where network devices are
> expected to show up, he did see the message I quoted.
> Well, what if he did not try to initialize the device by doing
> an "ifconfig wlanX up"? That can hardly be my fault, right?

Heeeeellooooo? I tried that. It failed. What *I'm* talking about here
is that this everyone needs to be aware that this is *not* a drop in
replacement for bcm43xx, and if I'm having problems (not a kernel
hacker, but I make my living writing code), then sheesh, you're gonna
have a flood of people needing hand-holding on this.

I still don't understand why bcm43xx is sane enough to create an eth1
entry, and b43 needs more handholding, but I'm going to hold off on
commenting farther on that until I download the newer firmware. As it
stands, I haven't given b43 an honest test yet.

Please keep in mind that I'm really just trying to report my issues
with the code before others hit the same thing, and trying to do this
in a way that's productive for you all. I actually do understand what
an amazing amount of effort you've poured into bcm43xx and the b43's,
and again, I am thankful. I understand that bcm43xx is effectively
dead, and it has architectural problems (locking, at minimum), that
have been a problem for at least the past two years that *I've* been
using it, probably more.

The goal here is to make sure that your shiny new code will *work* for
everyone, okay? Not to attack you, as I don't think you in any way
deserve an attack. If I come off that way, I'm sorry. But likewise, if
you could give me the benefit of the doubt, this conversation would go
a lot smoother.

Thanks.

Ray

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 14, 2007 6:40 AM,  <stefano.brivio@polimi.it> wrote:
> Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo
> suggests other ways to smooth out the transition. I haven't read
> proposals yet.

This isn't rocket science guys. Put a file in somewhere in your tree
called ReleaseAnnouncement or something, and ask Linus to adjust his
kernel release process to include the contents of `cat $( find . -name
ReleaseAnnouncement )` in the release message he sends out. Clear out
the file after the release.

Include things such as "bcm43xx is scheduled for removal. build both
b43 and b43legacy as a replacement. Be sure to download the latest
firmware from $URL and follow the instructions there to extract the
correct latest firmware necessary for your chip. There are known
incompatibilities with old udev versions, please ensure blah blah
blah."

Ray

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 14, 2007 8:27 AM, Ray Lee <ray-lk@madrabbit.org> wrote:
> On Dec 14, 2007 6:40 AM,  <stefano.brivio@polimi.it> wrote:
> > Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo
> > suggests other ways to smooth out the transition. I haven't read
> > proposals yet.
>
> This isn't rocket science guys. Put a file in somewhere in your tree
> called ReleaseAnnouncement or something, and ask Linus to adjust his
> kernel release process to include the contents of `cat $( find . -name
> ReleaseAnnouncement )` in the release message he sends out. Clear out
> the file after the release.
>
> Include things such as "bcm43xx is scheduled for removal. build both
> b43 and b43legacy as a replacement. Be sure to download the latest
> firmware from $URL and follow the instructions there to extract the
> correct latest firmware necessary for your chip. There are known
> incompatibilities with old udev versions, please ensure blah blah
> blah."

Or even better, keep the history, and show the diff of the old versus
new in the release announcement, with an appropriate sed 's/+/ /' or
somesuch.

<shrug> I'm sure you all will figure something out. Regardless, my
point is a higher level changelog that is human readable would be
helpful. (There are thousands of per-commit changelog entries to read,
it's beyond what I have the time to do when testing a new kernel).
Also, it seems distributing the release announcement work would be as
helpful as distributing the code development work.

Ray

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 17:06:39 Ray Lee wrote:
> Hi all. Perhaps I can inject some facts into this?
> 
> On Dec 14, 2007 5:08 AM, Michael Buesch <mb@bu3sch.de> wrote:
> > > > This user did get the following messages in dmesg:
> > > >
> > > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > >        "or load failed.\n", path);
> > > > b43err(wl, "You must go to "
> > > >        "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
> > > >        "and download the correct firmware (version 4).\n");
> > > >
> > > > I'm not sure how I can improve that even more. There is a full URL
> > > > describing how to get the device workin in _full_ detail.
> 
> Yes, but only if you load rfkill-input and rfkill by hand, prior.

I'm not sure what you are doing there.
Do you have module autoloading disabled?
This all works perfectly well on all of my systems. And I never heared
such a problem before.

If you have a PCI device probing works as follows:
The PCI table is in ssb. So as soon as your kernel detects the PCI device
it will load ssb. ssb will register the PCI device. That will trigger
an udev event for the contained 802.11 core to get probed. This will load
b43.

So, I'm not sure where's the issue with my code here.

> That I'm one of the first people to hit that makes me think that your
> testing base so far has been miniscule.

The driver is shipped by Fedora since quite some time.

> > > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in
> > > || dmesg other than lines related to the bcm43xx driver.
> > > || iwconfig/ifconfig do not see the interface either.
> 
> See above. Without a modprobe of rfkill, rfkill-input that is the case.

You can't do
modprobe ssb b43
This will be interpreted as modprobe of "ssb" with the module
parameter "b43". At least by my modutils.

If you do
modprobe b43
it will automatically load _all_ required modules.
It works perfectly well on my systems.
Try it. Simply type "modprobe b43". It will also work for you.

> Heeeeellooooo? I tried that. It failed. What *I'm* talking about here
> is that this everyone needs to be aware that this is *not* a drop in
> replacement for bcm43xx, and if I'm having problems (not a kernel
> hacker, but I make my living writing code), then sheesh, you're gonna
> have a flood of people needing hand-holding on this.

All problems so far were not related to the b43 sourcecode at all.
And I think I can not be held responsible for unrelated code or bugs
in the operating system scripts.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 17:45:52 Ray Lee wrote:
> On Dec 14, 2007 8:27 AM, Ray Lee <ray-lk@madrabbit.org> wrote:
> > On Dec 14, 2007 6:40 AM,  <stefano.brivio@polimi.it> wrote:
> > > Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo
> > > suggests other ways to smooth out the transition. I haven't read
> > > proposals yet.
> >
> > This isn't rocket science guys. Put a file in somewhere in your tree
> > called ReleaseAnnouncement or something, and ask Linus to adjust his
> > kernel release process to include the contents of `cat $( find . -name
> > ReleaseAnnouncement )` in the release message he sends out. Clear out
> > the file after the release.
> >
> > Include things such as "bcm43xx is scheduled for removal. build both
> > b43 and b43legacy as a replacement. Be sure to download the latest
> > firmware from $URL and follow the instructions there to extract the
> > correct latest firmware necessary for your chip. There are known
> > incompatibilities with old udev versions, please ensure blah blah
> > blah."
> 
> Or even better, keep the history, and show the diff of the old versus
> new in the release announcement, with an appropriate sed 's/+/ /' or
> somesuch.
> 
> <shrug> I'm sure you all will figure something out. Regardless, my
> point is a higher level changelog that is human readable would be
> helpful. (There are thousands of per-commit changelog entries to read,
> it's beyond what I have the time to do when testing a new kernel).
> Also, it seems distributing the release announcement work would be as
> helpful as distributing the code development work.

In my opinion this all is the work of the distributions and not the
work of the kernel developers. Distributions have to make sure that
everything works after a kernel update. Yes I know that this is difficult
with b43, as the firmware is closed source. But this can be worked
around by explicitely prompting the user when the kernel is updated.
This is all distribution stuff.

What if you want to compile your own kernel? Well, then you are on
your own anyway. You have to track kernel changes anyway.
And I am pretty sure that it really is simple to track kernel changes.
Get your favourite kernel news site. It will tell you the changes
without this magic ReleaseAnnouncement file stuff.
I mean. There are news sites (even not specific ones for the kernel)
that reported the bcm43xx->b43 change weeks ago. There must be some
place where they get this information from without magic files. ;)

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 14, 2007 8:59 AM, Michael Buesch <mb@bu3sch.de> wrote:
> What if you want to compile your own kernel? Well, then you are on
> your own anyway. You have to track kernel changes anyway.

I'm trying to help you test your code before it goes out to the
unsuspecting masses. Do you think I do this for *fun*? Sheesh. No, fun
is leaving my system exactly as it is not putting my brain into ADD
(Attention Deficit Disorder) mode to track the latest rc and look for
bugs.

I'm trying to point out issues that are going to to come up once the
full release hits. Testing, you know? Because I guarantee you that I'm
a nicer and more competent tester than a lot of the people you'll have
to deal with if there's a bug. (I, at least, have been writing
software for 20+ years, and have been on all sides of the process.)

If you *don't* want testing of b43, then I'm happy to leave it alone
and go back to bcm43xx, and point out that it shouldn't be removed
from the tree. None of us want that, as bcm43xx is a pile of junk. (I
just tried rmmod'ing it twice. First time, it oopsed my system. I was
in X, so no backtrace, just a blinking caps lock LED. Second time was
a hard lock, no oops. Have I mentioned that I'm not doing this for
fun?)

> There are news sites (even not specific ones for the kernel)
> that reported the bcm43xx->b43 change weeks ago.

Perhaps so. It didn't hit kerneltrap or lwn, both of which I follow
via RSS, so not sure what I should have been looking at instead.

Regardless, I'm asking for three sentences to be added to the kernel
release announcement. Hell, maybe Linus would even *like* to have you
guys supply part of the release announcement. He's a nice guy, how
about we ask?

Look, this really isn't all that much about bcm43xx/b43 here. I'm
trying to say that there are things that can help get more testers. If
you don't care about that, then fine, ignore this message.

Ray

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ingo Molnar]

* Michael Buesch <mb@bu3sch.de> wrote:

> In my opinion this all is the work of the distributions and not the 
> work of the kernel developers. Distributions have to make sure that 
> everything works after a kernel update. [...]

actually, not. The the task of kernel developers is to KEEP OLD 
DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around 
until eternity, because the new one is just BROKEN.

Take a look at CONFIG_COMPAT_VDSO for example - one single version of 
glibc was released in a distro that depended on a kernel vDSO bug. So 
we'll keep that aspect of the vDSO perhaps forever. Simple as that. 
Stuff must just work. Whatever it takes. Best is if you add in new stuff 
without the user noticing _ANYTHING_ but that the kernel version bumped. 
If the maintainers of the other 7 million lines of kernel code can get 
this right then the wireless code should be able to do it too. Ok?

all this "distributors will have to sort out the mess" talk is nonsense, 
and i really hope you do not truly believe in that crap. If your 
attitude is prevalent in the wireless development community then it's in 
worse shape than i thought :-(

	Ingo

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 14, 2007 8:49 AM, Michael Buesch <mb@bu3sch.de> wrote:
> On Friday 14 December 2007 17:06:39 Ray Lee wrote:
> > Hi all. Perhaps I can inject some facts into this?
> >
> > On Dec 14, 2007 5:08 AM, Michael Buesch <mb@bu3sch.de> wrote:
> > > > > This user did get the following messages in dmesg:
> > > > >
> > > > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > > >        "or load failed.\n", path);
> > > > > b43err(wl, "You must go to "
> > > > >        "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
> > > > >        "and download the correct firmware (version 4).\n");
> > > > >
> > > > > I'm not sure how I can improve that even more. There is a full URL
> > > > > describing how to get the device workin in _full_ detail.
> >
> > Yes, but only if you load rfkill-input and rfkill by hand, prior.
>
> I'm not sure what you are doing there.
> Do you have module autoloading disabled?

No, I don't have module autoloading disabled. modprobe-ing b43
automatically loads ssb. Neither, however, will load rfkill or
rfkill-input. And if they aren't loaded, then b43/ssb are *completely*
silent during load. Nothing to dmesg at all.

> This all works perfectly well on all of my systems. And I never heared
> such a problem before.

WTF? Please read *YOUR OWN MESSAGE* to the bcm43xx-dev list:

https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006456.html

I'm going to blame this on you being tired or something, okay? But in
the meantime, could you *PLEASE* start giving me the benefit of the
doubt?

> If you have a PCI device probing works as follows:
> The PCI table is in ssb. So as soon as your kernel detects the PCI device
> it will load ssb. ssb will register the PCI device. That will trigger
> an udev event for the contained 802.11 core to get probed. This will load
> b43.
>
> So, I'm not sure where's the issue with my code here.

There's a patch from Larry Finger to address this and other issues. It
hasn't made it's way fully upstream yet. Please read your message
here, in particular item number seven on Larry's list:

https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html

> > That I'm one of the first people to hit that makes me think that your
> > testing base so far has been miniscule.
>
> The driver is shipped by Fedora since quite some time.

<shrug> Well, then they've made changes to udev or something else to
make this work okay for mere mortals such as myself, and haven't
pushed those changes upstream so that others can benefit from it.

> > > > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in
> > > > || dmesg other than lines related to the bcm43xx driver.
> > > > || iwconfig/ifconfig do not see the interface either.
> >
> > See above. Without a modprobe of rfkill, rfkill-input that is the case.
>
> You can't do
> modprobe ssb b43
> This will be interpreted as modprobe of "ssb" with the module
> parameter "b43". At least by my modutils.

Yes, I know. I'm sorry I was unclear.

> If you do
> modprobe b43
> it will automatically load _all_ required modules.
> It works perfectly well on my systems.
> Try it. Simply type "modprobe b43". It will also work for you.

As I've said multiple times earlier in this thread, I did try that and
it didn't work. Do you believe me now?

> > Heeeeellooooo? I tried that. It failed. What *I'm* talking about here
> > is that this everyone needs to be aware that this is *not* a drop in
> > replacement for bcm43xx, and if I'm having problems (not a kernel
> > hacker, but I make my living writing code), then sheesh, you're gonna
> > have a flood of people needing hand-holding on this.
>
> All problems so far were not related to the b43 sourcecode at all.
> And I think I can not be held responsible for unrelated code or bugs
> in the operating system scripts.

So, do you want a scorecard on this?

One problem related to b43 source code, patch exists, has yet to be
merged upstream.

One problem related to udev rules, that may or may not be fixed in the
latest udev. I have udev version 113, which is the latest shipped in
Ubuntu's nightly development snapshots (hardy heron). I see that
version 117 of udev is available on kernel.org, but mine is from the
end of June. One would think that wouldn't be so old as to be a
complete deal breaker. Especially as bcm43xx works fine with my udev.

The b43 code requires the latest firmware, something that isn't quite
obvious from skimming the changelogs. But is in dmesg, so thanks for
that.

With udev rules hand-edited to include the ATTRS{type}==1 Larry
pointed out (thanks Larry), b43 also seems to create an odd extra
device, wmaster0. Same MAC as eth1, my wireless. It's just an odd
thing that wasn't there before with bcm43xx. May be good, may be bad,
dunno.

And yeah, in my opinion, making the kernel play well with up-to-date
userspace actually *is* part of your job, but then again, what do I
know.

Michael, you're a good guy, I believe that. You're doing unglamorous
and mostly thankless work, and I am thankful for it. I'm afraid the
only way I could make it glamorous is to offer to send you a fancy
feathered outfit to wear while coding :-). But try to meet us testers
halfway, okay? Please keep in mind that I'm really only trying to
help.

Now I'm going to go off, sit in the sun, sip some coffee, and think
happy thoughts of kittens playing with yarn for a while.

Ray

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ingo Molnar]

* Ray Lee <ray-lk@madrabbit.org> wrote:

> Now I'm going to go off, sit in the sun, sip some coffee, and think 
> happy thoughts of kittens playing with yarn for a while.

ok, and given the time-shift and apparent season-shift i'll sit in the 
evening, watch the snowfall and think happy thoughts of kittens fetching 
nuclear-tipped uzis and hunting ueber-elite wireless developers to beat 
some humanity and compassion into them, ok? ;-)

	Ingo

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 19:01:51 Ray Lee wrote:
> No, I don't have module autoloading disabled. modprobe-ing b43
> automatically loads ssb. Neither, however, will load rfkill or
> rfkill-input. And if they aren't loaded, then b43/ssb are *completely*
> silent during load. Nothing to dmesg at all.

That is a bug in your distribution. I cannot fix this.
Maybe the module is blacklisted or whatever. This is _not_ a b43 bug.

> > This all works perfectly well on all of my systems. And I never heared
> > such a problem before.
> 
> WTF? Please read *YOUR OWN MESSAGE* to the bcm43xx-dev list:
> 
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006456.html
> 
> I'm going to blame this on you being tired or something, okay? But in
> the meantime, could you *PLEASE* start giving me the benefit of the
> doubt?

The message you quote describes a _completely_ unrelated bug.
Besides that the bug described in the message does _not_ prevent
the device from working. It does _just_ prevent some random LED from
blinking. I'd not call that a big issue.
To say it again: This message was about loading "rfkill-input" _after_
b43 was loaded successfully.

Please carefully read the messages before using them to prove me wrong.

> > If you have a PCI device probing works as follows:
> > The PCI table is in ssb. So as soon as your kernel detects the PCI device
> > it will load ssb. ssb will register the PCI device. That will trigger
> > an udev event for the contained 802.11 core to get probed. This will load
> > b43.
> >
> > So, I'm not sure where's the issue with my code here.
> 
> There's a patch from Larry Finger to address this and other issues. It
> hasn't made it's way fully upstream yet. Please read your message
> here, in particular item number seven on Larry's list:
> 
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html

1) I sent this patch out today for inclusion in the kernel
2) This is a _completely_ unrelated issue.
   It is about "rfkill-input" being not loaded. NOT about
   "b43" or "rfkill" not being loaded.

> > If you do
> > modprobe b43
> > it will automatically load _all_ required modules.
> > It works perfectly well on my systems.
> > Try it. Simply type "modprobe b43". It will also work for you.
> 
> As I've said multiple times earlier in this thread, I did try that and
> it didn't work. Do you believe me now?

Ok, Please find out why it doesn't work.

> > > Heeeeellooooo? I tried that. It failed. What *I'm* talking about here
> > > is that this everyone needs to be aware that this is *not* a drop in
> > > replacement for bcm43xx, and if I'm having problems (not a kernel
> > > hacker, but I make my living writing code), then sheesh, you're gonna
> > > have a flood of people needing hand-holding on this.
> >
> > All problems so far were not related to the b43 sourcecode at all.
> > And I think I can not be held responsible for unrelated code or bugs
> > in the operating system scripts.
> 
> So, do you want a scorecard on this?
> 
> One problem related to b43 source code, patch exists, has yet to be
> merged upstream.

Yeah. A problem preventing a LED from blinking.
That's a real regression.... Come on. Stop that bullshit.

> One problem related to udev rules, that may or may not be fixed in the
> latest udev. I have udev version 113, which is the latest shipped in
> Ubuntu's nightly development snapshots (hardy heron). I see that
> version 117 of udev is available on kernel.org, but mine is from the
> end of June. One would think that wouldn't be so old as to be a
> complete deal breaker. Especially as bcm43xx works fine with my udev.

How can I fix that?

> With udev rules hand-edited to include the ATTRS{type}==1 Larry
> pointed out (thanks Larry), b43 also seems to create an odd extra
> device, wmaster0.

That's not b43 specific. And it is not a bug. Ignore wmaster.
It is not useful for anything from userspace.

> Same MAC as eth1, my wireless. It's just an odd 
> thing that wasn't there before with bcm43xx. May be good, may be bad,
> dunno.

Blame your distribution, please.

> And yeah, in my opinion, making the kernel play well with up-to-date
> userspace actually *is* part of your job, but then again, what do I
> know.

How the hell do I workaround broken udev scripts from within the kernel?

> Michael, you're a good guy, I believe that. You're doing unglamorous
> and mostly thankless work, and I am thankful for it. I'm afraid the
> only way I could make it glamorous is to offer to send you a fancy
> feathered outfit to wear while coding :-). But try to meet us testers
> halfway, okay? Please keep in mind that I'm really only trying to
> help.

Yeah. So PLEASE point out real bugs in MY code and do not bother
me with other peoples bugs that I simply can not fix.
In the list above there was exactly one bug for which I am responsible.
And I already sent a fix for this one.

> Now I'm going to go off, sit in the sun, sip some coffee, and think
> happy thoughts of kittens playing with yarn for a while.

Have fun.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 18:59:10 Ingo Molnar wrote:
> 
> * Michael Buesch <mb@bu3sch.de> wrote:
> 
> > In my opinion this all is the work of the distributions and not the 
> > work of the kernel developers. Distributions have to make sure that 
> > everything works after a kernel update. [...]
> 
> actually, not. The the task of kernel developers is to KEEP OLD 
> DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around 
> until eternity, because the new one is just BROKEN.

What exactly prevents an old distribution from using new b43
given that they fix their broken udev scripts first?

(I cannot fix their broken scripts from within the kernel.)

> Take a look at CONFIG_COMPAT_VDSO for example - one single version of 
> glibc was released in a distro that depended on a kernel vDSO bug. So 
> we'll keep that aspect of the vDSO perhaps forever. Simple as that. 
> Stuff must just work. Whatever it takes. Best is if you add in new stuff 
> without the user noticing _ANYTHING_ but that the kernel version bumped. 
> If the maintainers of the other 7 million lines of kernel code can get 
> this right then the wireless code should be able to do it too. Ok?
> 
> all this "distributors will have to sort out the mess" talk is nonsense, 
> and i really hope you do not truly believe in that crap. If your 
> attitude is prevalent in the wireless development community then it's in 
> worse shape than i thought :-(

Sorry if I didn't chose my wording correctly. But I was only talking
about the development of drivers. It is correct that userspace ABI has
to be preserved, but that is not an issue at all to drivers.
I was talking about things like installing the right firmware for
the new driver. It is the job of the distributors to install the new
firmware when they introduce a new driver. It is the job of the distributors
to test their userland scripts and configuration stuff with that driver
and fix their stuff. It is _not_ my job to fix random distribution
udev scripts or explaining over and over again to people how the firmware
is installed. Either distributions have to install it automatically
or people simply have to read one or two lines of documentation.
That's just what I wanted to say.

Of course it is _my_ job to preserve ABI. I did never want to question that.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

I've run out of time to donate to the kernel today, so I'll keep this short.

On Dec 14, 2007 10:22 AM, Michael Buesch <mb@bu3sch.de> wrote:
> > > If you have a PCI device probing works as follows:
> > > The PCI table is in ssb. So as soon as your kernel detects the PCI device
> > > it will load ssb. ssb will register the PCI device. That will trigger
> > > an udev event for the contained 802.11 core to get probed. This will load
> > > b43.
> > >
> > > So, I'm not sure where's the issue with my code here.
> >
> > There's a patch from Larry Finger to address this and other issues. It
> > hasn't made it's way fully upstream yet. Please read your message
> > here, in particular item number seven on Larry's list:
> >
> > https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
>
> 1) I sent this patch out today for inclusion in the kernel
> 2) This is a _completely_ unrelated issue.
>    It is about "rfkill-input" being not loaded. NOT about
>    "b43" or "rfkill" not being loaded.
[...]
> > So, do you want a scorecard on this?
> >
> > One problem related to b43 source code, patch exists, has yet to be
> > merged upstream.
>
> Yeah. A problem preventing a LED from blinking.
> That's a real regression.... Come on. Stop that bullshit.

I'm going to say this one last time. If rfkill and rfkill-input aren't
manually loaded before sb and b43, not one damn thing comes out in
dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to
find out that those modules had to be loaded by hand was to go read
the bcm43xx-dev archives. Once those were loaded, messages came out in
dmesg pointing me to the URL for updated firmware.

I have complete current userspace as of yesterday's Ubuntu Hardy Heron
development archives.

One last thing. I've been nice to you. Please be nice to me. If you
can't manage that, then let another wireless developer take over.

You apparently think I'm an idiot. I'm not, and if necessary I could
supply a long list of credentials to prove I'm not an idiot. I'd
rather you just accepted my emails at face value and spent more effort
on trying to see how the bugs could be occurring rather than spending
effort on trying to prove that I'm an idiot.

Thanks.

Ray

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 14, 2007 10:11 AM, Ingo Molnar <mingo@elte.hu> wrote:
> * Ray Lee <ray-lk@madrabbit.org> wrote:
>
> > Now I'm going to go off, sit in the sun, sip some coffee, and think
> > happy thoughts of kittens playing with yarn for a while.
>
> ok, and given the time-shift and apparent season-shift i'll sit in the
> evening, watch the snowfall and think happy thoughts of kittens

Heh :-). Sometimes I feel guilty living in coastal California. But our
seasons are more along the lines of fire, flood, earthquake, and riot
:-).

Ray

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 19:45:02 Ray Lee wrote:
> > > One problem related to b43 source code, patch exists, has yet to be
> > > merged upstream.
> >
> > Yeah. A problem preventing a LED from blinking.
> > That's a real regression.... Come on. Stop that bullshit.
> 
> I'm going to say this one last time. If rfkill and rfkill-input aren't
> manually loaded before sb and b43, not one damn thing comes out in
> dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to
> find out that those modules had to be loaded by hand was to go read
> the bcm43xx-dev archives. Once those were loaded, messages came out in
> dmesg pointing me to the URL for updated firmware.

I'm sorry. The patch that _you_ quoted fixes a blinking LED
and nothing else. It does _not_ fix loading of rfkill or b43 in any way.
It does, however, fix loading of rfkill-input. But the b43 module
operation does _not_ depend in any way on the rfkill-input module, except
the tiny LED that doesn't blink if it's not loaded.
I hope you understood now that the thread on bcm43xx-dev was NOT about
your requirement to load rfkill before b43.

> I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> development archives.

Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
reproduce this.
However the fact that this does not happen on older Ubuntu platforms
and does not happen on Fedora leads to the conclusion that it
is a bug in Hardy Heron that I am not responsible for.

And you also do realise that Hardy Heron is the current development
version of Ubuntu? Development versions have bugs.

> One last thing. I've been nice to you. Please be nice to me.

If you simply stop blaming bugs on me that I am not responsible for
at all, that is a deal. What about filing a bug at the ubuntu bugzilla?

PS:
Note that Ubuntu is known to break the broadcom driver every now and then.
But I can not change that.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 14, 2007 11:05 AM, Michael Buesch <mb@bu3sch.de> wrote:
> On Friday 14 December 2007 19:45:02 Ray Lee wrote:
> > > > One problem related to b43 source code, patch exists, has yet to be
> > > > merged upstream.
> > >
> > > Yeah. A problem preventing a LED from blinking.
> > > That's a real regression.... Come on. Stop that bullshit.
> >
> > I'm going to say this one last time. If rfkill and rfkill-input aren't
> > manually loaded before sb and b43, not one damn thing comes out in
> > dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to
> > find out that those modules had to be loaded by hand was to go read
> > the bcm43xx-dev archives. Once those were loaded, messages came out in
> > dmesg pointing me to the URL for updated firmware.
>
> I'm sorry. The patch that _you_ quoted fixes a blinking LED
> and nothing else.

Well, you're wrong. Sorry, but that's just the way it is. See below.

> It does _not_ fix loading of rfkill or b43 in any way.
> It does, however, fix loading of rfkill-input. But the b43 module
> operation does _not_ depend in any way on the rfkill-input module, except
> the tiny LED that doesn't blink if it's not loaded.
> I hope you understood now that the thread on bcm43xx-dev was NOT about
> your requirement to load rfkill before b43.

*AGAIN*, please read your message here, in particular item number
seven on Larry's list:

https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html

For the last fscking time, if rfkill and rfkill-input are not loaded,
not one line comes out in dmesg when b43 and ssb are loaded. In
particular, your pretty little message about needing newer firmware
also does not print. So, yeah, not loading rfkill{,-input} *does*
cause issues with b43 working, as there's no damn way to find out
what's broken!

> > I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> > development archives.
>
> Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
> reproduce this.

I'm not asking you to do that, this particular bug will be fixed by
Larry's patch, whether you believe that or not.

> However the fact that this does not happen on older Ubuntu platforms
> and does not happen on Fedora leads to the conclusion that it
> is a bug in Hardy Heron that I am not responsible for.

The kernel does not exist in a vacuum. It's the kernel's job to make
sure it works with properly written userspace. Broken userspace, sure,
then we can talk about breaking it.

> And you also do realise that Hardy Heron is the current development
> version of Ubuntu? Development versions have bugs.

Oy vay. I'm not an idiot. Yes, it's the current develoment version.
But tracking the latest kernel.org kernel has in the past required the
latest develoment version of the distribution, so I upgrade it as
well.

> > One last thing. I've been nice to you. Please be nice to me.
>
> If you simply stop blaming bugs on me that I am not responsible for
> at all, that is a deal. What about filing a bug at the ubuntu bugzilla?

I'm not blaming it on you. I'm merely reporting a fucking
incompatibility. Read my messages again from the top, and stop taking
this all so damn personally, will you?

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 20:25:39 Ray Lee wrote:
> > I'm sorry. The patch that _you_ quoted fixes a blinking LED
> > and nothing else.
> 
> Well, you're wrong. Sorry, but that's just the way it is. See below.
> 
> > It does _not_ fix loading of rfkill or b43 in any way.
> > It does, however, fix loading of rfkill-input. But the b43 module
> > operation does _not_ depend in any way on the rfkill-input module, except
> > the tiny LED that doesn't blink if it's not loaded.
> > I hope you understood now that the thread on bcm43xx-dev was NOT about
> > your requirement to load rfkill before b43.
> 
> *AGAIN*, please read your message here, in particular item number
> seven on Larry's list:
> 
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
> 
> For the last fscking time, if rfkill and rfkill-input are not loaded,
> not one line comes out in dmesg when b43 and ssb are loaded. In
> particular, your pretty little message about needing newer firmware
> also does not print. So, yeah, not loading rfkill{,-input} *does*
> cause issues with b43 working, as there's no damn way to find out
> what's broken!

Guy... .
I KNOW what the patch above does.
What do you think does the following line?
	err = request_module("rfkill-input");
Does it load the "rfkill-input" or the "rfkill" module.
That's the million dollar question. You only have one try.

This patch is NOT about the "rfkill" module. I don't know how
often I have to say that. It is _obvious_.

Let's also quote Larry's sevenths point here, that you referred to
now for the second time:
" (7) If rfkill-input is built as a module, it is not automatically loaded."

I am not sure how I can make this any more clear.
It does load the "rfkill-input" module from within b43.
It does NOT load "rfkill"
It does NOT load "rfkill-input" BEFORE b43 was loaded.

This patch does exactly ONE thing. It does make sure a LED does blink.
Nothing more.
I signed this patch off. So you can be 100% sure I know what it does.
I do NOT sign off patches for which I don't know what they do.

> > > I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> > > development archives.
> >
> > Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
> > reproduce this.
> 
> I'm not asking you to do that, this particular bug will be fixed by
> Larry's patch, whether you believe that or not.

Did you try that?
How can b43 load get fixed by a patch that adds a request_module()
to the b43 module? That is a chicken and egg problem!

> > However the fact that this does not happen on older Ubuntu platforms
> > and does not happen on Fedora leads to the conclusion that it
> > is a bug in Hardy Heron that I am not responsible for.
> 
> The kernel does not exist in a vacuum. It's the kernel's job to make
> sure it works with properly written userspace. Broken userspace, sure,
> then we can talk about breaking it.

yes properly written userspace.

> > And you also do realise that Hardy Heron is the current development
> > version of Ubuntu? Development versions have bugs.
> 
> Oy vay. I'm not an idiot. Yes, it's the current develoment version.
> But tracking the latest kernel.org kernel has in the past required the
> latest develoment version of the distribution, so I upgrade it as
> well.

I am running wireless-2.6 on feisty. So the kernel does _not_ require
an update of the distribution.
q.e.d.

> I'm not blaming it on you. I'm merely reporting a fucking
> incompatibility. Read my messages again from the top, and stop taking
> this all so damn personally, will you?

You are telling me that I don't understand patches that I sign off
and I should not take this personally?
That is challenging.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 14, 2007 11:38 AM, Michael Buesch <mb@bu3sch.de> wrote:
> On Friday 14 December 2007 20:25:39 Ray Lee wrote:
> > > I'm sorry. The patch that _you_ quoted fixes a blinking LED
> > > and nothing else.
> >
> > Well, you're wrong. Sorry, but that's just the way it is. See below.
> >
> > > It does _not_ fix loading of rfkill or b43 in any way.
> > > It does, however, fix loading of rfkill-input. But the b43 module
> > > operation does _not_ depend in any way on the rfkill-input module, except
> > > the tiny LED that doesn't blink if it's not loaded.
> > > I hope you understood now that the thread on bcm43xx-dev was NOT about
> > > your requirement to load rfkill before b43.
> >
> > *AGAIN*, please read your message here, in particular item number
> > seven on Larry's list:
> >
> > https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
> >
> > For the last fscking time, if rfkill and rfkill-input are not loaded,
> > not one line comes out in dmesg when b43 and ssb are loaded. In
> > particular, your pretty little message about needing newer firmware
> > also does not print. So, yeah, not loading rfkill{,-input} *does*
> > cause issues with b43 working, as there's no damn way to find out
> > what's broken!
>
> Guy... .
> I KNOW what the patch above does.
> What do you think does the following line?
>         err = request_module("rfkill-input");
> Does it load the "rfkill-input" or the "rfkill" module.
> That's the million dollar question. You only have one try.

Oh. My. God.

Michael. I have a degree in Physics. I placed sixth in the world
finals of the ACM Collegiate programming contest in 1999, Cal Poly
Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html
, I'm the guy all the way to the right. ) I ported the 2.4 kernel to a
custom ppc platform, including writing drivers for various hardware on
it ( http://patinc.com ). I'm the guy who did all the software for a
linux-based Voice over IP call center (
http://broncocommunications.com/ ).

So, *now* do you believe I'm not an idiot?

To answer your question, it requests the rfkill-input module. But
under the version I'm trying, rfkill-input is not automatically
loaded. I've pointed to the mailing list URL that proves that. So, I
loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't
necessary, I don't know, and I don't care. But once I did that, *then
and only then* did your damn b43 driver start printing out any
messages to dmesg at all, which then let me download the latest
firmware, and continue moving forward.

> You are telling me that I don't understand patches that I sign off
> and I should not take this personally?
> That is challenging.

I'm saying the patch you signed off on has a side-effect that will fix
my issue. And even if I *were* saying that, the most you should take
from it is that you are human and sometimes may make mistakes, just
like the rest of us. There's nothing challenging in that statement.

I've provided the bug report as many ways as I can think to. If you
don't agree, then I guess you'll just have to get the bug report from
someone else who can figure out exactly how to sugar coat the message
so that you'll listen to it.

Me, I'm done.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Friday 14 December 2007 20:55:43 Ray Lee wrote:
> Oh. My. God.
> 
> Michael. I have a degree in Physics. I placed sixth in the world
> finals of the ACM Collegiate programming contest in 1999, Cal Poly
> Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html
> , I'm the guy all the way to the right. ) I ported the 2.4 kernel to a
> custom ppc platform, including writing drivers for various hardware on
> it ( http://patinc.com ). I'm the guy who did all the software for a
> linux-based Voice over IP call center (
> http://broncocommunications.com/ ).

Nice. I am one of the main b43 developers and I wrote most of the code.
I know most of the code from the top of my head.
Besides that my weiner is bigger than yours. :P

> To answer your question, it requests the rfkill-input module. But
> under the version I'm trying, rfkill-input is not automatically
> loaded.

It is not an issue. You can even rmmod rfkill-input in FULL operation.
It will not disturb the operation, except that an LED stops working.
Try it! (I _did_ try it).

> I've pointed to the mailing list URL that proves that. So, I 
> loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't
> necessary, I don't know, and I don't care. But once I did that, *then
> and only then* did your damn b43 driver start printing out any
> messages to dmesg at all, which then let me download the latest
> firmware, and continue moving forward.

The b43 does print _nothing_ on modprobe. That is _correct_ behaviour.
b43 does print the firmware message after "ifconfig up".
Might it be possible that this was coincidence and you messed
with modprobe rfkill and ifconfig up and finally saw the message?

> > You are telling me that I don't understand patches that I sign off
> > and I should not take this personally?
> > That is challenging.
> 
> I'm saying the patch you signed off on has a side-effect that will fix
> my issue. And even if I *were* saying that, the most you should take

Ok. So please revert that patch and try to reproduce the breakage.
Does that work?

> from it is that you are human and sometimes may make mistakes, just

I am inhuman. We all know that.
(That was a joke that you probably don't understand. But you can google
for "bcw vs. bcm43xx" :) )

Ray, I _do_ want to understand what is going on in your machine.
I _have_ to understand it. But I currently do not understand how the
quoted patch could fix modprobe of b43 or rfkill. I'd simply call that
impossible.
Impossible because the patch does change a few function called _inside_
of the b43 module. How could that fix load of the b43 module? (Note that
we are not changing some modprobe magic like the ID table).

So could you please try to reproduce the breakage by reverting that
patch again? Just to make really sure it is this patch fixing the issue
and not just some coincidence.

Thanks for your help.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 14, 2007 12:13 PM, Michael Buesch <mb@bu3sch.de> wrote:
> Ray, I _do_ want to understand what is going on in your machine.
> I _have_ to understand it. But I currently do not understand how the
> quoted patch could fix modprobe of b43 or rfkill. I'd simply call that
> impossible.

Then perhaps it is. Perhaps it's a race condition in my userspace
where something NetworkManager related is trying to up the interface,
I don't know. More below.

Regardless, I'm going to have to put off doing more debugging until
tomorrow. I've rebooted back into 2.6.23.0 as wireshark doesn't show
any packets using 2.6.24-rc3 (the version I've been testing), reported
elsewhere, and that's preventing me from doing actual work with my
system, as I'm in the middle of trying to enhance a network server for
a client.

Note, the wireshark issue is very much not a bcm43xx/b43 issue; I'm
not trying to lay that at your feet.

> So could you please try to reproduce the breakage by reverting that
> patch again? Just to make really sure it is this patch fixing the issue
> and not just some coincidence.

I don't have the patch applied, so that's at least part of the
misunderstanding here. All I have is my sequence of "load b43, ssb,
nothing happens, unload them, load rfkill, rfkill-input, ssb, b43 and
something happens." I could very well be wrong. But I'm at the limit
of what I care to know about the b43 driver, and this is where I'm
asking for your help.

Hopefully tomorrow, I'll be able to build current tip and try this all
again, and I'll also try to do it with NetworkManager killed in the
background in case it was trying to bring the interfaces up behind my
back.

> Thanks for your help.

Thanks for treating me like an adult.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Rafael J. Wysocki]

On Friday, 14 of December 2007, Michael Buesch wrote:
> On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
> > > This user did get the following messages in dmesg:
> > > 
> > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > >        "or load failed.\n", path);
> > 
> > So the question seems to be why b43 needs version 4, when b43legacy and
> > bcm43x uses version 3?
> 
> That's really a question, right?
> 
> Well. linux-2.4 doesn't work with the linux-2.6 modutils.
> Windows Vista doesn't work with Windows 98 device drivers.
> That leads to this assumption:
> b43 doesn't work with version 3 firmware but needs version 4.
> 
> Newer drivers supporting newer hardware need newer firmware.

Actually, can you explain why, from the technical point of view, the version 4
firware is better than version 3, please?

Rafael

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Larry Finger]

Rafael J. Wysocki wrote:
> 
> Actually, can you explain why, from the technical point of view, the version 4
> firware is better than version 3, please?

I will be very interested in Michael's answer to this question; however, my experience is that it 
doesn't make much difference if your device is supported by both V3 and V4 firmware. This impression 
was obtained by comparing BCM4318 and BCM4311/1 devices with b43 and b43legacy.

Note that 802.11b and early BCM4306 devices are not supported by V4 firmware. Similarly, with 
BCM4311/2 and newer devices V3 firmware fails. As Michael said "newer drivers supporting newer 
hardware need newer firmware".

Larry

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Rafael J. Wysocki]

On Friday, 14 of December 2007, Michael Buesch wrote:
> On Friday 14 December 2007 18:59:10 Ingo Molnar wrote:
> > 
> > * Michael Buesch <mb@bu3sch.de> wrote:
> > 
> > > In my opinion this all is the work of the distributions and not the 
> > > work of the kernel developers. Distributions have to make sure that 
> > > everything works after a kernel update. [...]
> > 
> > actually, not. The the task of kernel developers is to KEEP OLD 
> > DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around 
> > until eternity, because the new one is just BROKEN.
> 
> What exactly prevents an old distribution from using new b43
> given that they fix their broken udev scripts first?
> 
> (I cannot fix their broken scripts from within the kernel.)

Well, we talked about that some time ago, didn't we?

The rule is this: if one uses kernel 2.6.x from kernel.org _successfully_
with certain distribution (whatever it is), then one is supposed to be able to
take the kernel 2.6.(x+1), install it on that distribution and use it without
any major configuration changes.  If this rule is not followed, people will
stop testing kernel.org kernels and we'll all suffer from that.

Now, in my not so humble opinion, switching from bcm43xx to b43 _is_ a major
configuration change (I did it, so please don't try to discuss with my
experience) and forcing users to do that breaks the rule above.

> > Take a look at CONFIG_COMPAT_VDSO for example - one single version of 
> > glibc was released in a distro that depended on a kernel vDSO bug. So 
> > we'll keep that aspect of the vDSO perhaps forever. Simple as that. 
> > Stuff must just work. Whatever it takes. Best is if you add in new stuff 
> > without the user noticing _ANYTHING_ but that the kernel version bumped. 
> > If the maintainers of the other 7 million lines of kernel code can get 
> > this right then the wireless code should be able to do it too. Ok?
> > 
> > all this "distributors will have to sort out the mess" talk is nonsense, 
> > and i really hope you do not truly believe in that crap. If your 
> > attitude is prevalent in the wireless development community then it's in 
> > worse shape than i thought :-(
> 
> Sorry if I didn't chose my wording correctly. But I was only talking
> about the development of drivers. It is correct that userspace ABI has
> to be preserved, but that is not an issue at all to drivers.
> I was talking about things like installing the right firmware for
> the new driver. It is the job of the distributors to install the new
> firmware when they introduce a new driver.

Yes, as far as new distributions are concerned.  However, we _want_ kernel.org
kernels to work with the old ones too.  Yes, WE DO.

> It is the job of the distributors to test their userland scripts and
> configuration stuff with that driver and fix their stuff. It is _not_ my job
> to fix random distribution udev scripts or explaining over and over again to
> people how the firmware is installed.

Given specific software environment (it may be a home-made system compiled
from sources or whatever), if installing a new kernel forces me to reconfigure
it in any significant way to obtain the functionality that I previously had,
the problem is with the kernel.  No less, no more.

> Either distributions have to install it automatically or people simply have
> to read one or two lines of documentation.  That's just what I wanted to say.

It's not that simple.  For example, regression testing will be a major PITA
if one needs to switch back and forth from the new driver to the old one in the
process.

> Of course it is _my_ job to preserve ABI. I did never want to question that.

Greetings,
Rafael

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 14, 2007 7:58 PM, Larry Finger <larry.finger@lwfinger.net> wrote:
> Rafael J. Wysocki wrote:
> >
> > Actually, can you explain why, from the technical point of view, the version 4
> > firware is better than version 3, please?
>
> I will be very interested in Michael's answer to this question; however, my experience is that it
> doesn't make much difference if your device is supported by both V3 and V4 firmware. This impression
> was obtained by comparing BCM4318 and BCM4311/1 devices with b43 and b43legacy.
>
> Note that 802.11b and early BCM4306 devices are not supported by V4 firmware.

Could this be the reason my BCM94311MCG rev 1 receives such terrible
performance with b43 but works well with bcm43xx? The device is
802.11b/g but my router is 802.11b. I filed a report on this issue
here: https://bugzilla.redhat.com/show_bug.cgi?id=413291

I was told by Michael that I would have to fix it myself, and I am
trying, but the learning curve is a little steep. If this is relevant,
I might at least have some direction to go in.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Larry Finger]

mvtodevnull@gmail.com wrote:
> 
> Could this be the reason my BCM94311MCG rev 1 receives such terrible
> performance with b43 but works well with bcm43xx? The device is
> 802.11b/g but my router is 802.11b. I filed a report on this issue
> here: https://bugzilla.redhat.com/show_bug.cgi?id=413291

No. On my BCM4311/1, my transfer rate peaked at about 12 Mbs with bcm43xx, but increased to 20 Mbs 
with b43. These tests were done with iperf with a server running running on a second computer 
connected by wire to my router. These rates are for 802.11g. When my interface was locked at 11 Mbs, 
the transfer rate was the expected 5.3-5.5 Mbs with both drivers.

> I was told by Michael that I would have to fix it myself, and I am
> trying, but the learning curve is a little steep. If this is relevant,
> I might at least have some direction to go in.

I suspect that mac80211 is doing something that your router does not like. Do you have any chance to 
capture the traffic between your computer and the router by using a second wireless computer running 
kismet or wireshark? A look at the differences between b43 and bcm43xx should show the reason.

Larry

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 14, 2007 9:27 PM, Larry Finger <larry.finger@lwfinger.net> wrote:
>
> I suspect that mac80211 is doing something that your router does not like. Do you have any chance to
> capture the traffic between your computer and the router by using a second wireless computer running
> kismet or wireshark? A look at the differences between b43 and bcm43xx should show the reason.
>

Hi Larry, thanks for replying.

I have to admit, I've never used either of these before, so I'm not
sure if I did this correctly.

I created two different packet dumps using kismet, one when my laptop
was using b43 and the other when it was using bcm43xx. While my
desktop was logging, I used my laptop to go to kernel.org and download
patch-2.6.23.11.bz2 (both times the browser started at
http://www.kernel.org/pub/linux/kernel/). Then I used tshark to parse
the dump files and create two new readable logs.

I'll attach these logs since I can't read much into them. The only
strange difference I noticed is that with b43, I got messages like
ICMP Destination unreachable (Host administratively prohibited), which
I didn't get with bcm43xx.

There's about 5 machines connected to this network -- the laptop with
the broadcom card has internal ip 192.168.0.3.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

[-- Attachment #1: Type: text/plain, Size: 147 bytes --]

On Dec 14, 2007 11:37 PM,  <mvtodevnull@gmail.com> wrote:
>
> I'll attach these logs since I can't read much into them.

I should do what I say...

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: b43.log --]
[-- Type: text/x-log; name=b43.log, Size: 14219 bytes --]

  1   0.000000 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2028,FN=0,BI=100, SSID: "NETGEAR"
  2   0.102833 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2029,FN=0,BI=100, SSID: "NETGEAR"
  3   0.184297 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=280,FN=0, SSID: "NETGEAR"
  4   0.184611              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
  5   2.866618 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2060,FN=0,BI=100, SSID: "NETGEAR"
  6   2.968996 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2061,FN=0,BI=100, SSID: "NETGEAR"
  7   3.015146 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=282,FN=0, SSID: "NETGEAR"
  8   5.836409 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2090,FN=0,BI=100, SSID: "NETGEAR"
  9   5.849611 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=284,FN=0, SSID: "NETGEAR"
 10   5.849916              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 11   5.854992  192.168.0.5 -> 192.168.0.1  DNS Standard query A ps3tw08.ea.com
 12   5.855202              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 13   5.921523  192.168.0.1 -> 192.168.0.5  DNS Standard query response A 159.153.251.178
 14   5.921735              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 15   5.935186  192.168.0.5 -> 159.153.251.178 TCP 49612 > 20271 [SYN] Seq=0 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
 16   5.935395              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 17   5.938049 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2092,FN=0,BI=100, SSID: "NETGEAR"
 18   5.958096 159.153.251.178 -> 192.168.0.5  TCP 20271 > 49612 [SYN, ACK] Seq=0 Ack=1 Win=5648 Len=0 MSS=1412 WS=2
 19   5.958307              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 20   5.958942  192.168.0.5 -> 159.153.251.178 TCP 49612 > 20271 [ACK] Seq=1 Ack=1 Win=65535 Len=0
 21   5.959151              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 22   5.973091  192.168.0.5 -> 159.153.251.178 TCP 49612 > 20271 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=52
 23   5.973295              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 24   5.995152 159.153.251.178 -> 192.168.0.5  TCP 20271 > 49612 [ACK] Seq=1 Ack=53 Win=5648 Len=0
 25   5.995367              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 26   5.998172              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 27   6.029394  192.168.0.5 -> 159.153.251.178 TCP [TCP ACKed lost segment] 49612 > 20271 [PSH, ACK] Seq=53 Ack=1104 Win=65535 Len=137
 28   8.599963 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2148,FN=0,BI=100, SSID: "NETGEAR"
 29   8.685462 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=313,FN=0, SSID: "NETGEAR"
 30   8.685767              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 31   8.702339 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2149,FN=0,BI=100, SSID: "NETGEAR"
 32  11.467144 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2177,FN=0,BI=100, SSID: "NETGEAR"
 33  11.525092 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=316,FN=0, SSID: "NETGEAR"
 34  11.525403              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 35  11.569043 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2178,FN=0,BI=100, SSID: "NETGEAR"
 36  14.128542 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2203,FN=0,BI=100, SSID: "NETGEAR"
 37  14.230923 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2204,FN=0,BI=100, SSID: "NETGEAR"
 38  17.199979 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2233,FN=0,BI=100, SSID: "NETGEAR"
 39  17.216419 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=322,FN=0, SSID: "NETGEAR"
 40  17.216725              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 41  17.302712 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2234,FN=0,BI=100, SSID: "NETGEAR"
 42  20.066650 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2261,FN=0,BI=100, SSID: "NETGEAR"
 43  20.067224 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=325,FN=0, SSID: "NETGEAR"
 44  20.067541              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 45  20.169031 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2262,FN=0,BI=100, SSID: "NETGEAR"
 46  23.035731 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2290,FN=0,BI=100, SSID: "NETGEAR"
 47  23.138082 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2291,FN=0,BI=100, SSID: "NETGEAR"
 48  25.799993 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2317,FN=0,BI=100, SSID: "NETGEAR"
 49  25.902379 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2318,FN=0,BI=100, SSID: "NETGEAR"
 50  26.705841 AsustekC_c1:0f:d1 -> Broadcast    IEEE 802.11 Probe Request,SN=5,FN=0, SSID: Broadcast
 51  27.188746 AsustekC_c1:0f:d1 -> Broadcast    IEEE 802.11 Probe Request,SN=12,FN=0, SSID: Broadcast
 52  27.258802              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 53  28.461903 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2345,FN=0,BI=100, SSID: "NETGEAR"
 54  28.541004 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=334,FN=0, SSID: "NETGEAR"
 55  28.541307              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 56  28.564731 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2346,FN=0,BI=100, SSID: "NETGEAR"
 57  31.226367 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2372,FN=0,BI=100, SSID: "NETGEAR"
 58  31.328572 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2373,FN=0,BI=100, SSID: "NETGEAR"
 59  31.370955 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=337,FN=0, SSID: "NETGEAR"
 60  31.371264              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 61  31.430952 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2374,FN=0,BI=100, SSID: "NETGEAR"
 62  31.507920 AsustekC_c1:0f:d1 -> Broadcast    IEEE 802.11 Probe Request,SN=16,FN=0, SSID: Broadcast
 63  31.852870 AsustekC_c1:0f:d1 -> Broadcast    IEEE 802.11 Probe Request,SN=21,FN=0, SSID: Broadcast
 64  33.990483 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2414,FN=0,BI=100, SSID: "NETGEAR"
 65  34.092866 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2415,FN=0,BI=100, SSID: "NETGEAR"
 66  36.959537 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2444,FN=0,BI=100, SSID: "NETGEAR"
 67  37.050955 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=339,FN=0, SSID: "NETGEAR"
 68  37.051265              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
 69  37.061918 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2445,FN=0,BI=100, SSID: "NETGEAR"
 70  39.723830 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2474,FN=0,BI=100, SSID: "NETGEAR"
 71  39.761157 217.98.72.61 -> 192.168.0.3  UDP Source port: 10212  Destination port: 6881
 72  39.761371              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 73  39.762863  192.168.0.3 -> 217.98.72.61 ICMP Destination unreachable (Host administratively prohibited)
 74  39.763180              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
 75  39.826208 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2476,FN=0,BI=100, SSID: "NETGEAR"
 76  41.890426  192.168.0.3 -> 204.152.191.5 TCP 60221 > http [ACK] Seq=0 Ack=0 Win=586 Len=0 TSV=8425721 TSER=721675770
 77  41.896327              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
 78  42.564134 fe80::21b:fcff:fec1:fd1 -> ff02::2      ICMPv6 Router solicitation
 79  42.565652 fe80::21b:fcff:fec1:fd1 -> ff02::2      ICMPv6 Router solicitation
 80  42.565961              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
 81  42.566265 fe80::21b:fcff:fec1:fd1 -> ff02::2      ICMPv6 Router solicitation
 82  42.590502 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2537,FN=0,BI=100, SSID: "NETGEAR"
 83  42.613272 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
 84  42.613487              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 85  42.614925  192.168.0.3 -> 204.152.191.5 TCP 60221 > http [ACK] Seq=0 Ack=17280 Win=946 Len=0 TSV=8426451 TSER=721676500
 86  42.615244              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
 87  42.692878 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2539,FN=0,BI=100, SSID: "NETGEAR"
 88  42.736318 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
 89  42.736530              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 90  45.354789 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2610,FN=0,BI=100, SSID: "NETGEAR"
 91  45.408602 204.152.191.5 -> 192.168.0.3  HTTP [TCP Previous segment lost] Continuation or non-HTTP traffic
 92  45.408811              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 93  45.409411  192.168.0.3 -> 204.152.191.5 TCP 60221 > http [ACK] Seq=0 Ack=69120 Win=994 Len=0 TSV=8429247 TSER=721679296
 94  45.409659              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
 95  45.411994  192.168.0.3 -> 204.152.191.5 TCP [TCP ACKed lost segment] 60221 > http [ACK] Seq=0 Ack=70560 Win=994 Len=0 TSV=8429249 TSER=721679296
 96  45.412250              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
 97  45.457171 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2613,FN=0,BI=100, SSID: "NETGEAR"
 98  45.473130 151.43.8.215 -> 192.168.0.3  UDP Source port: 50362  Destination port: 6881
 99  45.474059 151.43.8.215 -> 192.168.0.3  UDP Source port: 50362  Destination port: 6881
100  45.475377 151.43.8.215 -> 192.168.0.3  UDP Source port: 50362  Destination port: 6881
101  45.479527 151.43.8.215 -> 192.168.0.3  UDP Source port: 50362  Destination port: 6881
102  45.479737              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
103  45.480759  192.168.0.3 -> 151.43.8.215 ICMP Destination unreachable (Host administratively prohibited)
104  45.481014              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
105  45.528409 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
106  45.528612              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
107  45.529209  192.168.0.3 -> 204.152.191.5 TCP 60221 > http [ACK] Seq=0 Ack=72000 Win=994 Len=0 TSV=8429367 TSER=721679416
108  45.529461              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
109  45.530931 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
110  45.531148              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
111  45.531968  192.168.0.3 -> 204.152.191.5 TCP 60221 > http [ACK] Seq=0 Ack=73440 Win=994 Len=0 TSV=8429369 TSER=721679416
112  45.532223              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
113  45.543172 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
114  45.543390              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
115  48.221461 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2690,FN=0,BI=100, SSID: "NETGEAR"
116  48.323841 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2691,FN=0,BI=100, SSID: "NETGEAR"
117  48.417095 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=348,FN=0, SSID: "NETGEAR"
118  51.242129 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=351,FN=0, SSID: "NETGEAR"
119  51.242439              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
120  51.292894 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2772,FN=0,BI=100, SSID: "NETGEAR"
121  51.395274 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2773,FN=0,BI=100, SSID: "NETGEAR"
122  54.261949 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2811,FN=0,BI=100, SSID: "NETGEAR"
123  54.364329 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2812,FN=0,BI=100, SSID: "NETGEAR"
124  57.026238 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2843,FN=0,BI=100, SSID: "NETGEAR"
125  57.128619 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2844,FN=0,BI=100, SSID: "NETGEAR"
126  59.995293 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2872,FN=0,BI=100, SSID: "NETGEAR"
127  62.964517 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2905,FN=0,BI=100, SSID: "NETGEAR"
128  63.066725 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2906,FN=0,BI=100, SSID: "NETGEAR"
129  65.831018 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2934,FN=0,BI=100, SSID: "NETGEAR"
130  65.933402 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2935,FN=0,BI=100, SSID: "NETGEAR"
131  68.697690 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2962,FN=0,BI=100, SSID: "NETGEAR"
132  68.800217 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2963,FN=0,BI=100, SSID: "NETGEAR"
133  71.871578 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2993,FN=0,BI=100, SSID: "NETGEAR"
134  71.973883 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=2994,FN=0,BI=100, SSID: "NETGEAR"
135  72.054135 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=373,FN=0, SSID: "NETGEAR"
136  75.045320 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3025,FN=0,BI=100, SSID: "NETGEAR"
137  75.147699 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3026,FN=0,BI=100, SSID: "NETGEAR"
138  75.182905 189.145.248.29 -> 192.168.0.3  UDP Source port: 34147  Destination port: 6881
139  75.183116              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
140  75.183501  192.168.0.3 -> 189.145.248.29 ICMP Destination unreachable (Host administratively prohibited)
141  75.183710              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
142  75.250083 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3028,FN=0,BI=100, SSID: "NETGEAR"

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: bcm43xx.log --]
[-- Type: text/x-log; name=bcm43xx.log, Size: 31000 bytes --]

  1   0.000000 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3704,FN=0,BI=100, SSID: "NETGEAR"
  2   0.102671 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3705,FN=0,BI=100, SSID: "NETGEAR"
  3   3.071371 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3734,FN=0,BI=100, SSID: "NETGEAR"
  4   3.173751 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3735,FN=0,BI=100, SSID: "NETGEAR"
  5   6.040424 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3767,FN=0,BI=100, SSID: "NETGEAR"
  6   6.142803 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3768,FN=0,BI=100, SSID: "NETGEAR"
  7   8.907096 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3795,FN=0,BI=100, SSID: "NETGEAR"
  8   9.009475 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3796,FN=0,BI=100, SSID: "NETGEAR"
  9   9.111855 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3797,FN=0,BI=100, SSID: "NETGEAR"
 10  11.671578 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3822,FN=0,BI=100, SSID: "NETGEAR"
 11  11.773768 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3823,FN=0,BI=100, SSID: "NETGEAR"
 12  14.640440 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3851,FN=0,BI=100, SSID: "NETGEAR"
 13  14.742866 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3852,FN=0,BI=100, SSID: "NETGEAR"
 14  17.404730 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3878,FN=0,BI=100, SSID: "NETGEAR"
 15  17.507108 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3879,FN=0,BI=100, SSID: "NETGEAR"
 16  19.452353 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3898,FN=0,BI=100, SSID: "NETGEAR"
 17  20.169021 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3905,FN=0,BI=100, SSID: "NETGEAR"
 18  20.271400 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3906,FN=0,BI=100, SSID: "NETGEAR"
 19  22.933312 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3932,FN=0,BI=100, SSID: "NETGEAR"
 20  23.035892 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3933,FN=0,BI=100, SSID: "NETGEAR"
 21  25.799985 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3961,FN=0,BI=100, SSID: "NETGEAR"
 22  25.902363 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3962,FN=0,BI=100, SSID: "NETGEAR"
 23  28.461894 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3987,FN=0,BI=100, SSID: "NETGEAR"
 24  28.564276 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3988,FN=0,BI=100, SSID: "NETGEAR"
 25  31.124218 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=4014,FN=0,BI=100, SSID: "NETGEAR"
 26  31.226186 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=4015,FN=0,BI=100, SSID: "NETGEAR"
 27  33.990477 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=4042,FN=0,BI=100, SSID: "NETGEAR"
 28  34.092858 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=4043,FN=0,BI=100, SSID: "NETGEAR"
 29  36.754766 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=4070,FN=0,BI=100, SSID: "NETGEAR"
 30  36.857149 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=4071,FN=0,BI=100, SSID: "NETGEAR"
 31  39.723822 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=3,FN=0,BI=100, SSID: "NETGEAR"
 32  39.826203 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=4,FN=0,BI=100, SSID: "NETGEAR"
 33  42.590491 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=31,FN=0,BI=100, SSID: "NETGEAR"
 34  42.693360 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=32,FN=0,BI=100, SSID: "NETGEAR"
 35  45.252402 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=57,FN=0,BI=100, SSID: "NETGEAR"
 36  45.355257 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=58,FN=0,BI=100, SSID: "NETGEAR"
 37  48.221454 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=86,FN=0,BI=100, SSID: "NETGEAR"
 38  50.985745 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=113,FN=0,BI=100, SSID: "NETGEAR"
 39  51.088641 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=114,FN=0,BI=100, SSID: "NETGEAR"
 40  53.647656 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=139,FN=0,BI=100, SSID: "NETGEAR"
 41  53.750041 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=140,FN=0,BI=100, SSID: "NETGEAR"
 42  56.411944 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=166,FN=0,BI=100, SSID: "NETGEAR"
 43  56.514322 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=167,FN=0,BI=100, SSID: "NETGEAR"
 44  59.380999 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=195,FN=0,BI=100, SSID: "NETGEAR"
 45  59.483376 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=196,FN=0,BI=100, SSID: "NETGEAR"
 46  62.247671 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=223,FN=0,BI=100, SSID: "NETGEAR"
 47  62.350053 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=224,FN=0,BI=100, SSID: "NETGEAR"
 48  65.114340 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=251,FN=0,BI=100, SSID: "NETGEAR"
 49  65.216719 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=252,FN=0,BI=100, SSID: "NETGEAR"
 50  67.878632 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=279,FN=0,BI=100, SSID: "NETGEAR"
 51  67.981015 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=280,FN=0,BI=100, SSID: "NETGEAR"
 52  70.950068 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=312,FN=0,BI=100, SSID: "NETGEAR"
 53  73.149349              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 54  73.714358 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=341,FN=0,BI=100, SSID: "NETGEAR"
 55  73.816737 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=342,FN=0,BI=100, SSID: "NETGEAR"
 56  76.581028 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=370,FN=0,BI=100, SSID: "NETGEAR"
 57  76.683407 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=371,FN=0,BI=100, SSID: "NETGEAR"
 58  79.550082 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=403,FN=0,BI=100, SSID: "NETGEAR"
 59  79.652461 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=404,FN=0,BI=100, SSID: "NETGEAR"
 60  82.826286 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=435,FN=0,BI=100, SSID: "NETGEAR"
 61  85.488190 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=461,FN=0,BI=100, SSID: "NETGEAR"
 62  85.590569 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=462,FN=0,BI=100, SSID: "NETGEAR"
 63  85.692950 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=463,FN=0,BI=100, SSID: "NETGEAR"
 64  88.252478 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=488,FN=0,BI=100, SSID: "NETGEAR"
 65  88.354860 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=489,FN=0,BI=100, SSID: "NETGEAR"
 66  91.016769 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=515,FN=0,BI=100, SSID: "NETGEAR"
 67  91.119151 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=516,FN=0,BI=100, SSID: "NETGEAR"
 68  93.883443 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=543,FN=0,BI=100, SSID: "NETGEAR"
 69  94.088204 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=545,FN=0,BI=100, SSID: "NETGEAR"
 70  96.033444 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=564,FN=0,BI=100, SSID: "NETGEAR"
 71  96.750115 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=571,FN=0,BI=100, SSID: "NETGEAR"
 72  96.852498 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=572,FN=0,BI=100, SSID: "NETGEAR"
 73  98.900116 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=592,FN=0,BI=100, SSID: "NETGEAR"
 74  99.719169 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=600,FN=0,BI=100, SSID: "NETGEAR"
 75  99.821545 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=601,FN=0,BI=100, SSID: "NETGEAR"
 76 102.509427  192.168.0.1 -> 192.168.0.3  DNS Standard query response CNAME pub.kernel.org
 77 102.509680              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 78 102.510094  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 79 102.511165  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 80 102.512578  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 81 102.515461  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 82 102.518682  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 83 102.528505  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 84 102.528722              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
 85 102.585836 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=629,FN=0,BI=100, SSID: "NETGEAR"
 86 102.663430  192.168.0.1 -> 192.168.0.3  DNS Standard query response CNAME pub.kernel.org A 204.152.191.37 A 204.152.191.5
 87 102.663684              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
 88 102.664158  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 89 102.665130  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 90 102.665919  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 91 102.668323  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 92 102.670264  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 93 102.677322  192.168.0.3 -> 192.168.0.1  DNS Standard query A www.kernel.org
 94 102.677543              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
 95 102.688217 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=631,FN=0,BI=100, SSID: "NETGEAR"
 96 104.735841 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=668,FN=0,BI=100, SSID: "NETGEAR"
 97 105.436173  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=0 Win=994 Len=0 TSV=8292046 TSER=721542081
 98 105.437037  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 97#1] 33067 > http [ACK] Seq=0 Ack=0 Win=994 Len=0 TSV=8292046 TSER=721542081
 99 105.438506  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 97#2] 33067 > http [ACK] Seq=0 Ack=0 Win=994 Len=0 TSV=8292046 TSER=721542081
100 105.443022  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 97#3] 33067 > http [ACK] Seq=0 Ack=0 Win=994 Len=0 TSV=8292046 TSER=721542081
101 105.446942 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
102 105.447150              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
103 105.451797  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 97#4] 33067 > http [ACK] Seq=0 Ack=0 Win=994 Len=0 TSV=8292046 TSER=721542081
104 105.453513 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=735,FN=0,BI=100, SSID: "NETGEAR"
105 105.459981  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 97#5] 33067 > http [ACK] Seq=0 Ack=0 Win=994 Len=0 TSV=8292046 TSER=721542081
106 105.460547  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=2880 Win=994 Len=0 TSV=8292072 TSER=721542089
107 105.461494  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 106#1] 33067 > http [ACK] Seq=0 Ack=2880 Win=994 Len=0 TSV=8292072 TSER=721542089
108 105.462281  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 106#2] 33067 > http [ACK] Seq=0 Ack=2880 Win=994 Len=0 TSV=8292072 TSER=721542089
109 105.463724  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 106#3] 33067 > http [ACK] Seq=0 Ack=2880 Win=994 Len=0 TSV=8292072 TSER=721542089
110 105.467324 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
111 105.467536              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
112 105.469862 204.152.191.5 -> 192.168.0.3  HTTP [TCP Fast Retransmission] Continuation or non-HTTP traffic
113 105.470071              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
114 105.472022  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 106#4] 33067 > http [ACK] Seq=0 Ack=2880 Win=994 Len=0 TSV=8292072 TSER=721542089
115 105.473871  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 106#5] 33067 > http [ACK] Seq=0 Ack=2880 Win=994 Len=0 TSV=8292072 TSER=721542089
116 105.474092              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
117 105.488927 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
118 105.489137              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
119 105.489443  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=5760 Win=994 Len=0 TSV=8292114 TSER=721542135
120 105.490049  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 119#1] 33067 > http [ACK] Seq=0 Ack=5760 Win=994 Len=0 TSV=8292114 TSER=721542135
121 105.491816  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 119#2] 33067 > http [ACK] Seq=0 Ack=5760 Win=994 Len=0 TSV=8292114 TSER=721542135
122 105.493925  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 119#3] 33067 > http [ACK] Seq=0 Ack=5760 Win=994 Len=0 TSV=8292114 TSER=721542135
123 105.494145              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
124 105.501884 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
125 105.502095              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
126 105.502401  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=7200 Win=1047 Len=0 TSV=8292127 TSER=721542170
127 105.503366  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 126#1] 33067 > http [ACK] Seq=0 Ack=7200 Win=1047 Len=0 TSV=8292127 TSER=721542170
128 105.504033  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 126#2] 33067 > http [ACK] Seq=0 Ack=7200 Win=1047 Len=0 TSV=8292127 TSER=721542170
129 105.506482  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 126#3] 33067 > http [ACK] Seq=0 Ack=7200 Win=1047 Len=0 TSV=8292127 TSER=721542170
130 105.506702              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
131 105.519556 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
132 105.519767              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
133 105.520072  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=8640 Win=1092 Len=0 TSV=8292145 TSER=721542187
134 105.521925 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
135 105.522137              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
136 105.522642  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 133#1] 33067 > http [ACK] Seq=0 Ack=8640 Win=1092 Len=0 TSV=8292145 TSER=721542187
137 105.522852              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
138 105.523198  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=10080 Win=1137 Len=0 TSV=8292147 TSER=721542187
139 105.523410              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
140 105.527623 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
141 105.527833              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
142 105.528139  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=11520 Win=1182 Len=0 TSV=8292153 TSER=721542195
143 105.528349              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
144 105.529778 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
145 105.529990              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
146 105.530356  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=12960 Win=1227 Len=0 TSV=8292155 TSER=721542195
147 105.531042  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 146#1] 33067 > http [ACK] Seq=0 Ack=12960 Win=1227 Len=0 TSV=8292155 TSER=721542195
148 105.531253              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
149 105.547035 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
150 105.547252              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
151 105.547550  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=14400 Win=1272 Len=0 TSV=8292172 TSER=721542215
152 105.547760              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
153 105.549230 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
154 105.549441              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
155 105.549826  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=15840 Win=1317 Len=0 TSV=8292174 TSER=721542215
156 105.550036              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
157 105.555036 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
158 105.555252              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
159 105.556090 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=746,FN=0,BI=100, SSID: "NETGEAR"
160 105.557618 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
161 105.557829              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
162 105.558235  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=17280 Win=1319 Len=0 TSV=8292180 TSER=721542223
163 105.558445              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
164 105.593284 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
165 105.593497              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
166 105.593800  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=20160 Win=1319 Len=0 TSV=8292218 TSER=721542223
167 105.595753 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
168 105.595965              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
169 105.597378 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
170 105.597588              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
171 105.597972  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 166#1] 33067 > http [ACK] Seq=0 Ack=20160 Win=1319 Len=0 TSV=8292218 TSER=721542223
172 105.599947 204.152.191.5 -> 192.168.0.3  HTTP [TCP Out-Of-Order] Continuation or non-HTTP traffic
173 105.600155              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
174 105.600600  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 166#2] 33067 > http [ACK] Seq=0 Ack=20160 Win=1319 Len=0 TSV=8292218 TSER=721542223
175 105.601771  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 166#3] 33067 > http [ACK] Seq=0 Ack=20160 Win=1319 Len=0 TSV=8292218 TSER=721542223
176 105.601990              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
177 105.602477  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=23040 Win=1319 Len=0 TSV=8292222 TSER=721542261
178 105.603172  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 177#1] 33067 > http [ACK] Seq=0 Ack=23040 Win=1319 Len=0 TSV=8292222 TSER=721542261
179 105.603899  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 177#2] 33067 > http [ACK] Seq=0 Ack=23040 Win=1319 Len=0 TSV=8292222 TSER=721542261
180 105.606848  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 177#3] 33067 > http [ACK] Seq=0 Ack=23040 Win=1319 Len=0 TSV=8292222 TSER=721542261
181 105.607068              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
182 105.613776 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
183 105.613987              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
184 105.616340 204.152.191.5 -> 192.168.0.3  HTTP [TCP Fast Retransmission] Continuation or non-HTTP traffic
185 105.616550              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
186 105.617959 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
187 105.618170              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
188 105.618477  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=25920 Win=1319 Len=0 TSV=8292243 TSER=721542282
189 105.620440 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
190 105.620651              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
191 105.621217  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 188#1] 33067 > http [ACK] Seq=0 Ack=25920 Win=1319 Len=0 TSV=8292243 TSER=721542282
192 105.622443  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 188#2] 33067 > http [ACK] Seq=0 Ack=25920 Win=1319 Len=0 TSV=8292243 TSER=721542282
193 105.622653              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
194 105.625613 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
195 105.625822              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
196 105.626136  192.168.0.3 -> 204.152.191.5 TCP 33067 > http [ACK] Seq=0 Ack=28800 Win=1319 Len=0 TSV=8292251 TSER=721542282
197 105.627897 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
198 105.628109              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
199 105.628634  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 196#1] 33067 > http [ACK] Seq=0 Ack=28800 Win=1319 Len=0 TSV=8292251 TSER=721542282
200 105.628844              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
201 105.630212 204.152.191.5 -> 192.168.0.3  HTTP [TCP Out-Of-Order] Continuation or non-HTTP traffic
202 105.630424              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
203 105.643246 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
204 105.643457              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
205 107.500133 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=831,FN=0,BI=100, SSID: "NETGEAR"
206 108.114421 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=837,FN=0,BI=100, SSID: "NETGEAR"
207 108.216802 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=838,FN=0,BI=100, SSID: "NETGEAR"
208 110.776330 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=864,FN=0,BI=100, SSID: "NETGEAR"
209 110.878713 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=865,FN=0,BI=100, SSID: "NETGEAR"
210 113.540618 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=891,FN=0,BI=100, SSID: "NETGEAR"
211 113.642999 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=892,FN=0,BI=100, SSID: "NETGEAR"
212 116.612053 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=922,FN=0,BI=100, SSID: "NETGEAR"
213 116.714433 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=923,FN=0,BI=100, SSID: "NETGEAR"
214 119.478727 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=952,FN=0,BI=100, SSID: "NETGEAR"
215 119.581105 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=953,FN=0,BI=100, SSID: "NETGEAR"
216 122.345397 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=981,FN=0,BI=100, SSID: "NETGEAR"
217 122.447779 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=982,FN=0,BI=100, SSID: "NETGEAR"
218 125.519214 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1013,FN=0,BI=100, SSID: "NETGEAR"
219 125.621592 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1014,FN=0,BI=100, SSID: "NETGEAR"
220 126.662558 HonHaiPr_a6:17:e5 -> Broadcast    IEEE 802.11 Probe Request,SN=14,FN=0, SSID: "NETGEAR"
221 127.132753 HonHaiPr_a6:17:e5 -> Broadcast    IEEE 802.11 Probe Request,SN=19,FN=0, SSID: "NETGEAR"
222 128.181123 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1044,FN=0,BI=100, SSID: "NETGEAR"
223 128.283502 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1045,FN=0,BI=100, SSID: "NETGEAR"
224 128.347030 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=24,FN=0, SSID: "NETGEAR"
225 128.347340              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
226 131.150175 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1087,FN=0,BI=100, SSID: "NETGEAR"
227 134.017199 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1118,FN=0,BI=100, SSID: "NETGEAR"
228 134.119227 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1119,FN=0,BI=100, SSID: "NETGEAR"
229 136.679222 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1147,FN=0,BI=100, SSID: "NETGEAR"
230 136.781143 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1148,FN=0,BI=100, SSID: "NETGEAR"
231 136.829633 SonyComp_83:23:0f -> Netgear_70:2d:68 IEEE 802.11 Probe Request,SN=41,FN=0, SSID: "NETGEAR"
232 136.829937              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
233 136.883520 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1149,FN=0,BI=100, SSID: "NETGEAR"
234 139.638111 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
235 139.638353              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
236 139.644746 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
237 139.644981              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
238 139.651421 204.152.191.5 -> 192.168.0.3  HTTP Continuation or non-HTTP traffic
239 139.651667              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
240 139.652507 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1185,FN=0,BI=100, SSID: "NETGEAR"
241 139.652853  192.168.0.3 -> 204.152.191.5 TCP 33069 > http [ACK] Seq=0 Ack=1440 Win=271 Len=0 TSV=8326270 TSER=721576309
242 139.653064              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
243 139.660265  192.168.0.3 -> 204.152.191.5 TCP 33069 > http [ACK] Seq=0 Ack=2880 Win=316 Len=0 TSV=8326276 TSER=721576309
244 139.660467              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
245 139.660993  192.168.0.3 -> 204.152.191.5 TCP 33069 > http [ACK] Seq=0 Ack=4320 Win=361 Len=0 TSV=8326283 TSER=721576309
246 139.661203              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
247 139.661548  192.168.0.3 -> 204.152.191.5 TCP [TCP ACKed lost segment] 33069 > http [ACK] Seq=0 Ack=5760 Win=406 Len=0 TSV=8326291 TSER=721576309
248 139.662407  192.168.0.3 -> 204.152.191.5 TCP [TCP Dup ACK 247#1] 33069 > http [ACK] Seq=0 Ack=5760 Win=406 Len=0 TSV=8326291 TSER=721576309
249 139.662617              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
250 139.750197 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1187,FN=0,BI=100, SSID: "NETGEAR"
251 139.778997  192.168.0.3 -> 204.152.191.5 TCP [TCP ACKed lost segment] 33069 > http [ACK] Seq=0 Ack=7200 Win=451 Len=0 TSV=8326410 TSER=721576449
252 139.779200              -> AsustekC_c1:0f:d1 (RA) IEEE 802.11 Acknowledgement
253 142.530961 199.108.4.73 -> 192.168.0.5  SSLv3 Encrypted Alert
254 142.531176              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
255 142.531841  192.168.0.5 -> 199.108.4.73 TCP 49624 > https [RST] Seq=0 Len=0
256 142.532053              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
257 142.532447 199.108.4.73 -> 192.168.0.5  TCP https > 49624 [FIN, ACK] Seq=29 Ack=0 Win=2264 Len=0
258 142.532663              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
259 142.533185  192.168.0.5 -> 199.108.4.73 TCP 49624 > https [RST] Seq=0 Len=0
260 142.533395              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
261 142.537557 199.108.4.73 -> 192.168.0.5  TCP [TCP ACKed lost segment] https > 49624 [ACK] Seq=30 Ack=1 Win=2264 Len=0
262 142.537773              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
263 142.538319  192.168.0.5 -> 199.108.4.73 TCP 49624 > https [RST] Seq=1 Len=0
264 142.538529              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
265 142.598802  192.168.0.5 -> 192.168.0.1  DNS Standard query A getprof.us.np.community.playstation.net
266 142.599007              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
267 142.616860 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1289,FN=0,BI=100, SSID: "NETGEAR"
268 142.649911  192.168.0.1 -> 192.168.0.5  DNS Standard query response A 198.107.156.146
269 142.650126              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
270 142.651199  192.168.0.5 -> 198.107.156.146 TCP 49623 > https [SYN] Seq=0 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
271 142.651395              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
272 142.719244 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1291,FN=0,BI=100, SSID: "NETGEAR"
273 142.744816 198.107.156.146 -> 192.168.0.5  TCP https > 49623 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 WS=0 TSV=1103862762 TSER=0
274 142.745029              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
275 145.483535 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1437,FN=0,BI=100, SSID: "NETGEAR"
276 145.518320 198.107.158.128 -> 192.168.0.5  TCP 5223 > 49622 [PSH, ACK] Seq=0 Ack=0 Win=5925 Len=114 TSV=1107408848 TSER=6
277 145.518532              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
278 145.585914 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1439,FN=0,BI=100, SSID: "NETGEAR"
279 148.350207 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1488,FN=0,BI=100, SSID: "NETGEAR"
280 148.452586 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1489,FN=0,BI=100, SSID: "NETGEAR"
281 151.176656 198.107.157.133 -> 192.168.0.5  STUN Message: Binding Response
282 151.176862              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
283 151.177638  192.168.0.5 -> 198.107.157.134 STUN Message: Binding Request
284 151.177848              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
285 151.217048 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1517,FN=0,BI=100, SSID: "NETGEAR"
286 151.266496 198.107.157.134 -> 192.168.0.5  STUN Message: Binding Response
287 151.266709              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
288 151.267573  192.168.0.5 -> {Real IP} UDP Source port: 57977  Destination port: 57977
289 151.267776              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
290 151.270515 {Real IP} -> 192.168.0.5  UDP Source port: 57977  Destination port: 57977
291 151.270729              -> Netgear_70:2d:68 (RA) IEEE 802.11 Acknowledgement
292 151.279376  192.168.0.5 -> 192.168.0.1  DNS Standard query A us.np.stun.playstation.net
293 151.279586              -> SonyComp_83:23:0f (RA) IEEE 802.11 Acknowledgement
294 151.319258 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1520,FN=0,BI=100, SSID: "NETGEAR"
295 154.083552 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1551,FN=0,BI=100, SSID: "NETGEAR"
296 154.185929 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1552,FN=0,BI=100, SSID: "NETGEAR"
297 157.154985 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1581,FN=0,BI=100, SSID: "NETGEAR"
298 160.226421 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1614,FN=0,BI=100, SSID: "NETGEAR"
299 160.328806 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1615,FN=0,BI=100, SSID: "NETGEAR"
300 162.990711 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1663,FN=0,BI=100, SSID: "NETGEAR"
301 163.093199 Netgear_70:2d:68 -> Broadcast    IEEE 802.11 Beacon frame,SN=1664,FN=0,BI=100, SSID: "NETGEAR"

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Larry Finger]

mvtodevnull@gmail.com wrote:
> On Dec 14, 2007 11:37 PM,  <mvtodevnull@gmail.com> wrote:
>> I'll attach these logs since I can't read much into them.
> 
> I should do what I say...
> 

It will take a while to finish looking over those logs, but are you using ipv6? If not, please 
blacklist the ipv6 module to prevent it from loading - add the line 'blacklist ipv6' to file 
/etc/modprobe.d/blacklist. In some cases, ipv6 can cause timeouts even though you do not have any 
ipv6 routers.

Larry

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote:
> On Friday, 14 of December 2007, Michael Buesch wrote:
> > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
> > > > This user did get the following messages in dmesg:
> > > > 
> > > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > >        "or load failed.\n", path);
> > > 
> > > So the question seems to be why b43 needs version 4, when b43legacy and
> > > bcm43x uses version 3?
> > 
> > That's really a question, right?
> > 
> > Well. linux-2.4 doesn't work with the linux-2.6 modutils.
> > Windows Vista doesn't work with Windows 98 device drivers.
> > That leads to this assumption:
> > b43 doesn't work with version 3 firmware but needs version 4.
> > 
> > Newer drivers supporting newer hardware need newer firmware.
> 
> Actually, can you explain why, from the technical point of view, the version 4
> firware is better than version 3, please?

version 4 is the new firmware released by broadcom. They obviously won't
support and write any version 3 firmware anymore. So we are forced to
switch to version 4 firmware to support the newest hardware (like N-PHY
in the future). It's really as simple as that.
The difference between v3 and v4 is basically the driver API. It changed
a lot and it is nontrivial to support both v3 and v4 in one driver.
So we decided to stay with v3 for legacy devices and take v4 for any newer
devices. We have to live with that crap until someone comes up
with an opensource firmware. :)

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 15, 2007 2:18 AM, Larry Finger <larry.finger@lwfinger.net> wrote:
>
> It will take a while to finish looking over those logs, but are you using ipv6? If not, please
> blacklist the ipv6 module to prevent it from loading - add the line 'blacklist ipv6' to file
> /etc/modprobe.d/blacklist. In some cases, ipv6 can cause timeouts even though you do not have any
> ipv6 routers.

I'll be gone all day today, so it may take me awhile to test. I tried
real quick to blacklist it, but fedora isn't making it easy,
apparently it's depended on by quite a few things and I can't even
force unload them. I'll build latest wireless git without ipv6 late
tonight. Also, the logs may be incomplete, they're probably missing
when the device first associates with the router. Not sure if I should
include that.

I'm thankful that at least we're moving in some direction to solve
this bug, thanks again.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[John W. Linville]

On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote:
> On Friday, 14 of December 2007, Michael Buesch wrote:

> > Either distributions have to install it automatically or people simply have
> > to read one or two lines of documentation.  That's just what I wanted to say.
> 
> It's not that simple.  For example, regression testing will be a major PITA
> if one needs to switch back and forth from the new driver to the old one in the
> process.

Not really true -- a single system can easily have firmware installed
for b43, b43legacy, and bcm43xx at the same time and switch back and
forth between them.

Given a functioning udev configuration, the persistent naming even
works so that your device stays as 'eth1' when switching to and
fro bcm43xx.  I really think everyone is overstating the problem.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Rafael J. Wysocki]

On Saturday, 15 of December 2007, Michael Buesch wrote:
> On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote:
> > On Friday, 14 of December 2007, Michael Buesch wrote:
> > > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
> > > > > This user did get the following messages in dmesg:
> > > > > 
> > > > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > > >        "or load failed.\n", path);
> > > > 
> > > > So the question seems to be why b43 needs version 4, when b43legacy and
> > > > bcm43x uses version 3?
> > > 
> > > That's really a question, right?
> > > 
> > > Well. linux-2.4 doesn't work with the linux-2.6 modutils.
> > > Windows Vista doesn't work with Windows 98 device drivers.
> > > That leads to this assumption:
> > > b43 doesn't work with version 3 firmware but needs version 4.
> > > 
> > > Newer drivers supporting newer hardware need newer firmware.
> > 
> > Actually, can you explain why, from the technical point of view, the version 4
> > firware is better than version 3, please?
> 
> version 4 is the new firmware released by broadcom. They obviously won't
> support and write any version 3 firmware anymore. So we are forced to
> switch to version 4 firmware to support the newest hardware (like N-PHY
> in the future). It's really as simple as that.

I see, thanks.

> The difference between v3 and v4 is basically the driver API. It changed
> a lot and it is nontrivial to support both v3 and v4 in one driver.
> So we decided to stay with v3 for legacy devices and take v4 for any newer
> devices.

This is reasonable, yes.

> We have to live with that crap until someone comes up with an opensource
> firmware. :) 

Well, the only problem with that is I suspect there are some "newer" cards that
work better with v3 firmware, although they are supposed to support both.

Greetings,
Rafael

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Rafael J. Wysocki]

On Saturday, 15 of December 2007, John W. Linville wrote:
> On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote:
> > On Friday, 14 of December 2007, Michael Buesch wrote:
> 
> > > Either distributions have to install it automatically or people simply have
> > > to read one or two lines of documentation.  That's just what I wanted to say.
> > 
> > It's not that simple.  For example, regression testing will be a major PITA
> > if one needs to switch back and forth from the new driver to the old one in the
> > process.
> 
> Not really true -- a single system can easily have firmware installed
> for b43, b43legacy, and bcm43xx at the same time and switch back and
> forth between them.
> 
> Given a functioning udev configuration, the persistent naming even
> works so that your device stays as 'eth1' when switching to and
> fro bcm43xx.

Well, this last bit doesn't work on my openSUSE 10.3.  Honest, guv. ;-)

> I really think everyone is overstating the problem.

You might be right.

Greetings,
Rafael
 

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> Well, the only problem with that is I suspect there are some "newer" cards that
> work better with v3 firmware, although they are supposed to support both.

And I suspect that you are wrong until you show me one. :)

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Larry Finger]

Michael Buesch wrote:
> On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
>> Well, the only problem with that is I suspect there are some "newer" cards that
>> work better with v3 firmware, although they are supposed to support both.
> 
> And I suspect that you are wrong until you show me one. :)

The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power 
control problem was "solved" in b43, there is very little difference. When I built my special system 
to use the BCM4311 with b43legacy, there was no difference.

I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing 
SoftMAC with mac80211. There is, of course, no comparison.

Larry

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Stefan Lippers-Hollmann]

On Sonntag, 16. Dezember 2007, Rafael J. Wysocki wrote:
> On Saturday, 15 of December 2007, John W. Linville wrote:
> > On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote:
> > > On Friday, 14 of December 2007, Michael Buesch wrote:
> > 
> > > > Either distributions have to install it automatically or people simply have
> > > > to read one or two lines of documentation.  That's just what I wanted to say.
> > > 
> > > It's not that simple.  For example, regression testing will be a major PITA
> > > if one needs to switch back and forth from the new driver to the old one in the
> > > process.
> > 
> > Not really true -- a single system can easily have firmware installed
> > for b43, b43legacy, and bcm43xx at the same time and switch back and
> > forth between them.
> > 
> > Given a functioning udev configuration, the persistent naming even
> > works so that your device stays as 'eth1' when switching to and
> > fro bcm43xx.
> 
> Well, this last bit doesn't work on my openSUSE 10.3.  Honest, guv. ;-)

The persistent interface naming rules of udev, at least up to 0.114-2 
(current debian unstable), seem to be easily confused if the driver names 
change for the same MAC address. This issue seems not to be b43 specific, 
it happens with zd1211rw --> zd1211rw_mac80211 (this one won't show up in 
mainline kernels), prism54 --> p54pci/ p54usb, out-of-tree RaLink legacy/ 
serialmonkey (which ignore interface renames through udev completely) --> 
rt2x00 just as well and I assume that it might also affect sk98lin --> 
skge/ sky and the upcomming e1000 --> e1000e transitions and similar 
situations.

> > I really think everyone is overstating the problem.
> 
> You might be right.

It is of course confusing to the user and might affect remote updates, but 
it's also easily fixed by removing the generated MAC address mappings and 
letting udev generate new ones (+ post processing, if needed) during the 
next boot.

> Greetings,
> Rafael

Regards
	Stefan Lippers-Hollmann

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ingo Molnar]

* John W. Linville <linville@tuxdriver.com> wrote:

> > It's not that simple.  For example, regression testing will be a 
> > major PITA if one needs to switch back and forth from the new driver 
> > to the old one in the process.
> 
> Not really true -- a single system can easily have firmware installed 
> for b43, b43legacy, and bcm43xx at the same time and switch back and 
> forth between them.

as long as the version 4 firmware blob is present in the system, will 
testers have a fully fluid test- and work-flow when migrating across 
from bcm43xx to b43, without any other changes to an existing Linux 
installation? (i.e. no udev tweaks, no forced upgrades of components, 
etc.)

Will it Just Work in bisection as well, when a tester's kernel 
flip/flops between bcm43xx and b43 - like it does for the other 3000+ 
drivers in the kernel?

Note that we are _NOT_ interested in "might" or "can" scenarios. We are 
interested in preserving the _existing_ bcm43xx installed base and how 
much of a seemless migration the b43 transition will be. _THAT_ is what 
the "no regressions" upstream rule is about, not the "ideal distro" 
scenario you outline above. It is YOUR total obligation as a kernel 
maintainer to ensure that you dont break old installations. How hard is 
that to understand? This is not rocket science.

	Ingo

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Sunday 16 December 2007 03:30:16 Larry Finger wrote:
> Michael Buesch wrote:
> > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> >> Well, the only problem with that is I suspect there are some "newer" cards that
> >> work better with v3 firmware, although they are supposed to support both.
> > 
> > And I suspect that you are wrong until you show me one. :)
> 
> The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power 
> control problem was "solved" in b43, there is very little difference. When I built my special system 
> to use the BCM4311 with b43legacy, there was no difference.
> 
> I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing 
> SoftMAC with mac80211. There is, of course, no comparison.

This was about version 3 firmware vs version 4 firmware.
I doubt the firmware makes any difference at all.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Sunday 16 December 2007 10:22:43 Ingo Molnar wrote:
> 
> * John W. Linville <linville@tuxdriver.com> wrote:
> 
> > > It's not that simple.  For example, regression testing will be a 
> > > major PITA if one needs to switch back and forth from the new driver 
> > > to the old one in the process.
> > 
> > Not really true -- a single system can easily have firmware installed 
> > for b43, b43legacy, and bcm43xx at the same time and switch back and 
> > forth between them.
> 
> as long as the version 4 firmware blob is present in the system, will 
> testers have a fully fluid test- and work-flow when migrating across 
> from bcm43xx to b43, without any other changes to an existing Linux 
> installation? (i.e. no udev tweaks, no forced upgrades of components, 
> etc.)
> 
> Will it Just Work in bisection as well, when a tester's kernel 
> flip/flops between bcm43xx and b43 - like it does for the other 3000+ 
> drivers in the kernel?
> 
> Note that we are _NOT_ interested in "might" or "can" scenarios. We are 
> interested in preserving the _existing_ bcm43xx installed base and how 
> much of a seemless migration the b43 transition will be. _THAT_ is what 
> the "no regressions" upstream rule is about, not the "ideal distro" 
> scenario you outline above. It is YOUR total obligation as a kernel 
> maintainer to ensure that you dont break old installations. How hard is 
> that to understand? This is not rocket science.

I see no reason for b43 to break, if the firmware is properly installed.
In fact, almost all installation related bugreports we receive are
caused by missing or incorrectly installed firmware.
I would really _like_ to make installing firmware easier or make the
whole need for it vanish, but I simply can not at this point.
But anyway, installing it is not rocket science, either. The only thing
you have to know is where your distribution stores the firmware image files.
If you know that it's a matter of invoking one b43-fwcutter command
to install it. This process can be automated in the distribution's rpm
or deb package scripts.

b43lagacy/ssb is completely featured with module autoload support.
So if you have firmware installed it will automatically load all required
modules and create the network device(s) for it without any user interaction.

If that doesn't work, then stupid distributions are shipping braindamaged
udev scripts that pin a mac address to a specific driver name (see another
mail in this thread). I can _not_ fix this from within the kernel and
I will absolutely shift all responsibility and blame for this to the
maintainers of the distribution's udev scripts.
That's not a b43 specific problem then. Other drivers do break with these
scripts, too.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]


On Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote:
> On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> > Well, the only problem with that is I suspect there are some "newer" cards that
> > work better with v3 firmware, although they are supposed to support both.

Impossible. The firmware is only the MAC.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]


> > On Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote:
> > > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> > > > Well, the only problem with that is I suspect there are some "newer" cards that
> > > > work better with v3 firmware, although they are supposed to support both.
> > 
> > Impossible. The firmware is only the MAC.
> 
> OK

I should probably mention though that of course it is (in theory!)
possible that the card works better with bcm43xx, it just never has
happened for all I know.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Rafael J. Wysocki]

On Sunday, 16 of December 2007, Johannes Berg wrote:
> 
> On Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote:
> > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> > > Well, the only problem with that is I suspect there are some "newer" cards that
> > > work better with v3 firmware, although they are supposed to support both.
> 
> Impossible. The firmware is only the MAC.

OK

Thanks,
Rafael

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 15, 2007 7:38 AM,  <mvtodevnull@gmail.com> wrote:
>
> I'll build latest wireless git without ipv6 late tonight.

Ok, built and tested, and it's actually faster! Although still not as
fast as bcm43xx or softmac or whatever the problem is, I was getting a
steady 200 kB/s (as opposed to 500 kB/s for bcm43xx with the same
file/server). I'm not sure if it was the absence of ipv6 or the
commits included in updating my git repository though. Either way, I'm
fairly happy that I'm out of dial-up speed territory.

It'd be nice to be able to fully shake loose whatever is causing the
speed drain - and I call it a drain since sometimes the connection
starts out much faster, but slowly throttles down to whatever speed
it'll stick at (used to be 40 kB/s, but now is 200 kB/s). It does seem
to be like a cap or limit, as in if I download two files, each one
will download at 100 kB/s.

If anyone can help I'd really appreciate it. I know that bcm43xx will
someday be dropped, and when that day comes, it'd be nice if people
with this hardware have at least similar performance with b43 (myself
especially).

Thanks again,
Rob

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Larry Finger]

mvtodevnull@gmail.com wrote:
> On Dec 15, 2007 7:38 AM,  <mvtodevnull@gmail.com> wrote:
>> I'll build latest wireless git without ipv6 late tonight.
> 
> Ok, built and tested, and it's actually faster! Although still not as
> fast as bcm43xx or softmac or whatever the problem is, I was getting a
> steady 200 kB/s (as opposed to 500 kB/s for bcm43xx with the same
> file/server). I'm not sure if it was the absence of ipv6 or the
> commits included in updating my git repository though. Either way, I'm
> fairly happy that I'm out of dial-up speed territory.
> 
> It'd be nice to be able to fully shake loose whatever is causing the
> speed drain - and I call it a drain since sometimes the connection
> starts out much faster, but slowly throttles down to whatever speed
> it'll stick at (used to be 40 kB/s, but now is 200 kB/s). It does seem
> to be like a cap or limit, as in if I download two files, each one
> will download at 100 kB/s.
> 
> If anyone can help I'd really appreciate it. I know that bcm43xx will
> someday be dropped, and when that day comes, it'd be nice if people
> with this hardware have at least similar performance with b43 (myself
> especially).

One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the former always used a fixed
rate; whereas mac80211 tries to adjust the bit rate according to the transmission conditions.
Perhaps it isn't working quite right in your case because of some peculiarity of your AP. IIRC, you
have an 802.11b AP. If so, you will get the same bit speed behavior for mac80211 as for bcdm43xx by
issuing a 'sudo iwconfig eth1 rate 11M' command.

Larry

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 17, 2007 1:52 AM, Larry Finger <larry.finger@lwfinger.net> wrote:
>
> One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the former always used a fixed
> rate; whereas mac80211 tries to adjust the bit rate according to the transmission conditions.
> Perhaps it isn't working quite right in your case because of some peculiarity of your AP. IIRC, you
> have an 802.11b AP. If so, you will get the same bit speed behavior for mac80211 as for bcdm43xx by
> issuing a 'sudo iwconfig eth1 rate 11M' command.

I don't know what happened before, but after a reboot, I can't repeat
the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
didn't move the laptop, or the ap, the only thing I can think of that
might have changed is the noise level. FWIW, link quality is
consistently the same or better with b43.

Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and
quickly scales to 11 Mb/s, but I tried setting it manually anyway and
didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as
1 Mb/s and the download speed was the same with all three (around
30-40 kB/s).

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Monday 17 December 2007 08:17:58 mvtodevnull@gmail.com wrote:
> On Dec 17, 2007 1:52 AM, Larry Finger <larry.finger@lwfinger.net> wrote:
> >
> > One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the former always used a fixed
> > rate; whereas mac80211 tries to adjust the bit rate according to the transmission conditions.
> > Perhaps it isn't working quite right in your case because of some peculiarity of your AP. IIRC, you
> > have an 802.11b AP. If so, you will get the same bit speed behavior for mac80211 as for bcdm43xx by
> > issuing a 'sudo iwconfig eth1 rate 11M' command.
> 
> I don't know what happened before, but after a reboot, I can't repeat
> the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
> didn't move the laptop, or the ap, the only thing I can think of that
> might have changed is the noise level. FWIW, link quality is
> consistently the same or better with b43.
> 
> Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and
> quickly scales to 11 Mb/s, but I tried setting it manually anyway and
> didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as
> 1 Mb/s and the download speed was the same with all three (around
> 30-40 kB/s).

Are you working with wireless-2.6's #everything branch?

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 17, 2007 4:49 AM, Michael Buesch <mb@bu3sch.de> wrote:
>
> Are you working with wireless-2.6's #everything branch?

I've been working with vanilla wireless-2.6, but I've also tried the
everything branch as well as other trees. Just for good measure, I
just rebuilt the everything branch and it shows the same behavior.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

If this is a mac80211 related problem, then other systems connecting
to the same ap and using mac80211 would also be affected? Like I said
earlier, there are five machines connecting to this ap, and I just
realized one of them has a ralink card that uses the rt2x00 driver,
which I believe is mac80211. That system doesn't have this problem,
which leads me to believe it may not be mac80211 after all, although I
wouldn't rule it out.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 17, 2007 5:35 AM,  <mvtodevnull@gmail.com> wrote:
> If this is a mac80211 related problem, then other systems connecting
> to the same ap and using mac80211 would also be affected? Like I said
> earlier, there are five machines connecting to this ap, and I just
> realized one of them has a ralink card that uses the rt2x00 driver,
> which I believe is mac80211. That system doesn't have this problem,
> which leads me to believe it may not be mac80211 after all, although I
> wouldn't rule it out.
>

This also doesn't seem to be related to firmware version. I forced my
device to use b43legacy, and the results were identical with the
version 3 firmware.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Monday 17 December 2007 23:04:37 mvtodevnull@gmail.com wrote:
> On Dec 17, 2007 5:35 AM,  <mvtodevnull@gmail.com> wrote:
> > If this is a mac80211 related problem, then other systems connecting
> > to the same ap and using mac80211 would also be affected? Like I said
> > earlier, there are five machines connecting to this ap, and I just
> > realized one of them has a ralink card that uses the rt2x00 driver,
> > which I believe is mac80211. That system doesn't have this problem,
> > which leads me to believe it may not be mac80211 after all, although I
> > wouldn't rule it out.
> >
> 
> This also doesn't seem to be related to firmware version. I forced my
> device to use b43legacy, and the results were identical with the
> version 3 firmware.

Ehm, excuse me.
What are you doing exactly? In this thread you told me you have
a device which requires b43:

> I don't know what happened before, but after a reboot, I can't repeat
> the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
> didn't move the laptop, or the ap, the only thing I can think of that
> might have changed is the noise level. FWIW, link quality is
> consistently the same or better with b43.

How the hell can you now "force it to use b43legacy"??

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 17, 2007 5:45 PM, Michael Buesch <mb@bu3sch.de> wrote:
>
> Ehm, excuse me.
> What are you doing exactly? In this thread you told me you have
> a device which requires b43:
>

Well, I'm not sure what you mean by "requires" b43, but I did say that
the device uses the b43 driver.

> > I don't know what happened before, but after a reboot, I can't repeat
> > the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
> > didn't move the laptop, or the ap, the only thing I can think of that
> > might have changed is the noise level. FWIW, link quality is
> > consistently the same or better with b43.
>
> How the hell can you now "force it to use b43legacy"??
>

Sorry, I should have been more specific. I figured since the device
could use bcm43xx, it could also use b43legacy, so I copied the
entries in b43_ssb_tbl[] to b43legacy_ssb_tbl[] and rebuilt the
b43legacy driver. I removed the b43 and ssb modules, and inserted the
b43legacy module. Afterwards, I noticed b43 had still been autoloaded,
so I removed it (I checked dmesg and only b43legacy had initialized
anyway) , and proceeded to use the b43legacy driver with the version 3
firmware. And like I said, it works exactly like the b43 driver with
the version 4 firmware.

I'm not sure if it was the best way to go about it, but it worked.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Michael Buesch]

On Tuesday 18 December 2007 00:12:30 mvtodevnull@gmail.com wrote:
> On Dec 17, 2007 5:45 PM, Michael Buesch <mb@bu3sch.de> wrote:
> >
> > Ehm, excuse me.
> > What are you doing exactly? In this thread you told me you have
> > a device which requires b43:
> >
> 
> Well, I'm not sure what you mean by "requires" b43, but I did say that
> the device uses the b43 driver.

Requires means requires.

> Sorry, I should have been more specific. I figured since the device
> could use bcm43xx, it could also use b43legacy, so I copied the
> entries in b43_ssb_tbl[] to b43legacy_ssb_tbl[] and rebuilt the
> b43legacy driver. I removed the b43 and ssb modules, and inserted the
> b43legacy module. Afterwards, I noticed b43 had still been autoloaded,
> so I removed it (I checked dmesg and only b43legacy had initialized
> anyway) , and proceeded to use the b43legacy driver with the version 3
> firmware. And like I said, it works exactly like the b43 driver with
> the version 4 firmware.

I'm not sure what you are trying to show with this hack.
It's been said several times in this thread that the firmware has
nothing to do with the device radio.
So it won't affect the transmit rate or something like that.

Note that the difference between b43 and b43legacy is NOT that the
driver is "legacy". It is called legacy because it does _only_ support
legacy _devices_. So if you hack it to drive a new card it will only
work by luck (luck as in there might be some code left over which
is able to initialize the device somehow.). My point being, we removed
code for new devices from b43legacy and are probably going to remove
even more stuff in the future. So there is simply no point in testing
any new device with b43legacy.

-- 
Greetings Michael.

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 17, 2007 6:18 PM, Michael Buesch <mb@bu3sch.de> wrote:
> On Tuesday 18 December 2007 00:12:30 mvtodevnull@gmail.com wrote:
> >
> > Well, I'm not sure what you mean by "requires" b43, but I did say that
> > the device uses the b43 driver.
>
> Requires means requires.
>

Ok, noted.

> > Sorry, I should have been more specific. I figured since the device
> > could use bcm43xx, it could also use b43legacy, so I copied the
> > entries in b43_ssb_tbl[] to b43legacy_ssb_tbl[] and rebuilt the
> > b43legacy driver. I removed the b43 and ssb modules, and inserted the
> > b43legacy module. Afterwards, I noticed b43 had still been autoloaded,
> > so I removed it (I checked dmesg and only b43legacy had initialized
> > anyway) , and proceeded to use the b43legacy driver with the version 3
> > firmware. And like I said, it works exactly like the b43 driver with
> > the version 4 firmware.
>
> I'm not sure what you are trying to show with this hack.
> It's been said several times in this thread that the firmware has
> nothing to do with the device radio.
> So it won't affect the transmit rate or something like that.
>
> Note that the difference between b43 and b43legacy is NOT that the
> driver is "legacy". It is called legacy because it does _only_ support
> legacy _devices_. So if you hack it to drive a new card it will only
> work by luck (luck as in there might be some code left over which
> is able to initialize the device somehow.). My point being, we removed
> code for new devices from b43legacy and are probably going to remove
> even more stuff in the future. So there is simply no point in testing
> any new device with b43legacy.
>

At the start of my discussion with Larry, I asked if the firmware
could cause such a difference. Larry said no, and I believed him, but
I'm very lost as to what could be causing such a difference between
bcm43xx and b43. I figured it was at least worth testing, I mean, it
wasn't like I was recommending others do the same.

I'm actually still using the b43legacy driver right now, and it really
does work exactly the same as b43. If you're interested, here's the
relevant section of dmesg from when I loaded the b43legacy driver:

ssb: SPROM revision 2 detected.
ssb: Sonics Silicon Backplane found on PCI device 0000:05:00.0
b43legacy-phy1: Broadcom 4311 WLAN found
b43legacy-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8
b43legacy-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
b43legacy-phy1 debug: Radio initialized
phy1: Selected rate control algorithm 'simple'
b43legacy-phy1 debug: Loading firmware version 0x127, patch level 14
(2005-04-18 02:36:27)
Registered led device: b43legacy-phy1:tx
Registered led device: b43legacy-phy1:rx
b43legacy-phy1 debug: Chip initialized
b43legacy-phy1 debug: 32-bit DMA initialized
b43legacy-phy1 debug: Wireless interface started
b43legacy-phy1 debug: Adding Interface type 2
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:09:5b:70:2d:68
wlan0: RX authentication from 00:09:5b:70:2d:68 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:09:5b:70:2d:68
wlan0: RX AssocResp from 00:09:5b:70:2d:68 (capab=0x5 status=0 aid=86)
wlan0: associated
b43legacy-phy1 debug: Removing Interface type 2
b43legacy-phy1 debug: Wireless interface stopped
b43legacy-phy1 debug: DMA-32 0x0200 (RX) max used slots: 1/64
b43legacy-phy1 debug: DMA-32 0x02A0 (TX) max used slots: 0/128
b43legacy-phy1 debug: DMA-32 0x0280 (TX) max used slots: 0/128
b43legacy-phy1 debug: DMA-32 0x0260 (TX) max used slots: 0/128
b43legacy-phy1 debug: DMA-32 0x0240 (TX) max used slots: 0/128
b43legacy-phy1 debug: DMA-32 0x0220 (TX) max used slots: 2/128
b43legacy-phy1 debug: DMA-32 0x0200 (TX) max used slots: 0/128
b43legacy-phy1 debug: Radio initialized
b43legacy-phy1 debug: Radio initialized
b43legacy-phy1 debug: Loading firmware version 0x127, patch level 14
(2005-04-18 02:36:27)
Registered led device: b43legacy-phy1:tx
Registered led device: b43legacy-phy1:rx
b43legacy-phy1 debug: Chip initialized
b43legacy-phy1 debug: 32-bit DMA initialized
b43legacy-phy1 debug: Wireless interface started
b43legacy-phy1 debug: Adding Interface type 2
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:09:5b:70:2d:68
wlan0: RX authentication from 00:09:5b:70:2d:68 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:09:5b:70:2d:68
wlan0: RX AssocResp from 00:09:5b:70:2d:68 (capab=0x5 status=0 aid=86)
wlan0: associated
wlan0: disassociate(reason=3)
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:09:5b:70:2d:68
wlan0: RX authentication from 00:09:5b:70:2d:68 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:09:5b:70:2d:68
wlan0: RX ReassocResp from 00:09:5b:70:2d:68 (capab=0x5 status=0 aid=87)
wlan0: associated

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Larry Finger]

mvtodevnull@gmail.com wrote:
> 
> I don't know what happened before, but after a reboot, I can't repeat
> the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
> didn't move the laptop, or the ap, the only thing I can think of that
> might have changed is the noise level. FWIW, link quality is
> consistently the same or better with b43.
> 
> Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and
> quickly scales to 11 Mb/s, but I tried setting it manually anyway and
> didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as
> 1 Mb/s and the download speed was the same with all three (around
> 30-40 kB/s).

I hope that you have now convinced yourself that you should be using b43 and not messing around
forcing b43legacy to use a device for which it was not intended. I left that back door in the code
because I wanted to test b43legacy on a computer that could build a kernel in 20 minutes, as
compared to the 12 hours that my old laptop with the device that needs b43legacy. I forgot to clean
up the code as I should have.

You should concentrate on what in your environment changed when you rebooted. If you can get the 200
kBs rate back, please note the noise and signal levels as compared to the values when you are
restricted to 40 kBs.

Is it possible for you to test your laptop on another AP?

Larry

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

On Dec 17, 2007 8:16 PM, Larry Finger <larry.finger@lwfinger.net> wrote:
>
> I hope that you have now convinced yourself that you should be using b43 and not messing around
> forcing b43legacy to use a device for which it was not intended.
>

I was convinced the moment I realized it worked exactly the same as
b43 (if they work the same, I'd rather use the intended driver). The
b43legacy test was more out of desperation than anything serious. I
thought I should share though, since my original question was about
the firmware and because the difference between versions (or lack
thereof) had been discussed in this thread.

> You should concentrate on what in your environment changed when you rebooted. If you can get the 200
> kBs rate back, please note the noise and signal levels as compared to the values when you are
> restricted to 40 kBs.
>

Really, the only thing that might have changed is some things that may
have caused noise were turned off -- in other words, there should have
been more noise with the 200 kB/s, but of course that doesn't make
sense. It should be noted though that even at 200 kB/s, the b43 driver
was operating at less than half the speed of bcm43xx. That being said,
I've been trying very hard to repeat this, but cannot. I'll keep
trying though, and make sure to note everything possible if it ever
happens again.

> Is it possible for you to test your laptop on another AP?
>

Not currently, but I'll try to find a way to do so -- not sure how
long it'll take.

Re: [PATCH 1/3] ps3: vuart: fix error path locking

[Andrew Morton]

On Wed, 12 Dec 2007 18:00:12 -0800
Geoff Levand <geoffrey.levand@am.sony.com> wrote:

> > This stray down would cause a permanent sleep which doesn't seem correct. 
> > The other uses of this semaphore appear fairly mutex like it's even initialized
> > with init_MUTEX() ..  So here a patch for removing this one down().
> > 
> > Signed-off-by: Daniel Walker <dwalker@mvista.com>
> > 
> > ---
> >  drivers/ps3/ps3-vuart.c |    1 -
> >  1 file changed, 1 deletion(-)
> 
> 
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> 
> 
> Looks, good. 

Looks bad to me.

> Andrew, Please apply.

The current code:

	if (result) {
		dev_dbg(&dev->core, "%s:%d: drv->probe failed\n",
			__func__, __LINE__);
		down(&vuart_bus_priv.probe_mutex);
		goto fail_probe;
	}

	up(&vuart_bus_priv.probe_mutex);

	return result;

fail_probe:
	ps3_vuart_set_interrupt_mask(dev, 0);
	kfree(dev->driver_priv);
	dev->driver_priv = NULL;
fail_dev_malloc:
	vuart_bus_priv.devices[dev->port_number] = NULL;
fail_busy:
	ps3_vuart_bus_interrupt_put();
fail_setup_interrupt:
	up(&vuart_bus_priv.probe_mutex);
	dev_dbg(&dev->core, "%s:%d: failed\n", __func__, __LINE__);
	return result;
}

is correct.  Although not exactly a thing of beauty.

Re: [PATCH 1/3] ps3: vuart: fix error path locking

[Daniel Walker]

On Tue, 2007-12-18 at 17:10 -0800, Andrew Morton wrote:

> is correct.  Although not exactly a thing of beauty.

This isn't the worst I've seen ;( .. Do you think the ending should fall
through instead of having two returns?

Daniel

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[mvtodevnull]

Larry, thanks for being so patient so far. Tomorrow I plan to take my
laptop to somewhere with coffee and a wireless network. For now
though, can you tell me if these messages could be related:
PCI: Cannot allocate resource region 7 of bridge 0000:00:05.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:05.0

or could tsc being marked as unstable have anything to do with the
speed of network transfers?

Re: [PATCH 1/3] ps3: vuart: fix error path locking

[Geoff Levand]

On 12/18/2007 05:10 PM, Andrew Morton wrote:
> On Wed, 12 Dec 2007 18:00:12 -0800
> Geoff Levand <geoffrey.levand@am.sony.com> wrote:
> 
>> > This stray down would cause a permanent sleep which doesn't seem correct. 
>> > The other uses of this semaphore appear fairly mutex like it's even initialized
>> > with init_MUTEX() ..  So here a patch for removing this one down().
>> > 
>> > Signed-off-by: Daniel Walker <dwalker@mvista.com>
>> > 
>> > ---
>> >  drivers/ps3/ps3-vuart.c |    1 -
>> >  1 file changed, 1 deletion(-)
>> 
>> 
>> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>> 
>> 
>> Looks, good. 
> 
> Looks bad to me.

Hi Andrew,

Unfortunately there wasn't enough context in the patch to see
that there is a down() earlier in the routine, and that the patch
does indeed remove an incorrectly placed down().  Here is the
entire routine, marked with what the patch removes.

static int ps3_vuart_probe(struct ps3_system_bus_device *dev)
{
	int result;
	struct ps3_vuart_port_driver *drv;
	struct ps3_vuart_port_priv *priv = NULL;

	dev_dbg(&dev->core, "%s:%d\n", __func__, __LINE__);

	drv = ps3_system_bus_dev_to_vuart_drv(dev);

	dev_dbg(&dev->core, "%s:%d: (%s)\n", __func__, __LINE__,
		drv->core.core.name);

	BUG_ON(!drv);

	if (dev->port_number >= PORT_COUNT) {
		BUG();
		return -EINVAL;
	}

	down(&vuart_bus_priv.probe_mutex);

	result = ps3_vuart_bus_interrupt_get();

	if (result)
		goto fail_setup_interrupt;

	if (vuart_bus_priv.devices[dev->port_number]) {
		dev_dbg(&dev->core, "%s:%d: port busy (%d)\n", __func__,
			__LINE__, dev->port_number);
		result = -EBUSY;
		goto fail_busy;
	}

	vuart_bus_priv.devices[dev->port_number] = dev;

	/* Setup dev->driver_priv. */

	dev->driver_priv = kzalloc(sizeof(struct ps3_vuart_port_priv),
		GFP_KERNEL);

	if (!dev->driver_priv) {
		result = -ENOMEM;
		goto fail_dev_malloc;
	}

	priv = to_port_priv(dev);

	INIT_LIST_HEAD(&priv->tx_list.head);
	spin_lock_init(&priv->tx_list.lock);

	INIT_LIST_HEAD(&priv->rx_list.head);
	spin_lock_init(&priv->rx_list.lock);

	INIT_WORK(&priv->rx_list.work.work, NULL);
	priv->rx_list.work.trigger = 0;
	priv->rx_list.work.dev = dev;

	/* clear stale pending interrupts */

	ps3_vuart_clear_rx_bytes(dev, 0);

	ps3_vuart_set_interrupt_mask(dev, INTERRUPT_MASK_RX);

	ps3_vuart_set_triggers(dev, 1, 1);

	if (drv->probe)
		result = drv->probe(dev);
	else {
		result = 0;
		dev_info(&dev->core, "%s:%d: no probe method\n", __func__,
			__LINE__);
	}

	if (result) {
		dev_dbg(&dev->core, "%s:%d: drv->probe failed\n",
			__func__, __LINE__);
removed >>>>>>	down(&vuart_bus_priv.probe_mutex); <<<<<<<<<<<
		goto fail_probe;
	}

	up(&vuart_bus_priv.probe_mutex);

	return result;

fail_probe:
	ps3_vuart_set_interrupt_mask(dev, 0);
	kfree(dev->driver_priv);
	dev->driver_priv = NULL;
fail_dev_malloc:
	vuart_bus_priv.devices[dev->port_number] = NULL;
fail_busy:
	ps3_vuart_bus_interrupt_put();
fail_setup_interrupt:
	up(&vuart_bus_priv.probe_mutex);
	dev_dbg(&dev->core, "%s:%d: failed\n", __func__, __LINE__);
	return result;
}

Thanks for taking the time to scrutinize.

-Geoff

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Larry Finger]

mvtodevnull@gmail.com wrote:
> Larry, thanks for being so patient so far. Tomorrow I plan to take my
> laptop to somewhere with coffee and a wireless network. For now
> though, can you tell me if these messages could be related:
> PCI: Cannot allocate resource region 7 of bridge 0000:00:05.0
> PCI: Cannot allocate resource region 8 of bridge 0000:00:05.0

I don't know what these regions are, but I doubt if they have any relation to your problem.
> 
> or could tsc being marked as unstable have anything to do with the
> speed of network transfers?

Absolutely not.

Larry

Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ingo Molnar]

* Michael Buesch <mb@bu3sch.de> wrote:

> On Wednesday 19 December 2007 09:11:02 Larry Finger wrote:
> > > 
> > > or could tsc being marked as unstable have anything to do with the
> > > speed of network transfers?
> > 
> > Absolutely not.
> 
> Well, if the clocksource of the machine is unstable it _can_ cause all 
> kinds of weird things. If you think something is broken in the tsc 
> stuff, please switch to using another clocksource.

also, if it gets marked unstable (which is typical on laptops) then the 
kernel switches to a more stable, non-TSC clocksource automatically. 
(hpet or pit)

	Ingo

Re: [PATCH 1/3] ps3: vuart: fix error path locking

[Daniel Walker]

On Tue, 2007-12-18 at 19:04 -0800, Geoff Levand wrote:

> Unfortunately there wasn't enough context in the patch to see
> that there is a down() earlier in the routine, and that the patch
> does indeed remove an incorrectly placed down().  Here is the
> entire routine, marked with what the patch removes.
> 

Andrew have you had a chance to review this?

Daniel

Re: [PATCH 1/3] ps3: vuart: fix error path locking

[Andrew Morton]

On Thu, 20 Dec 2007 11:32:25 -0800 Daniel Walker <dwalker@mvista.com> wrote:

> On Tue, 2007-12-18 at 19:04 -0800, Geoff Levand wrote:
> 
> > Unfortunately there wasn't enough context in the patch to see
> > that there is a down() earlier in the routine, and that the patch
> > does indeed remove an incorrectly placed down().  Here is the
> > entire routine, marked with what the patch removes.
> > 
> 
> Andrew have you had a chance to review this?
> 

Confused.  I did review it: http://lkml.org/lkml/2007/12/18/384

Re: [PATCH 1/3] ps3: vuart: fix error path locking

[Daniel Walker]

On Thu, 2007-12-20 at 12:06 -0800, Andrew Morton wrote:
> On Thu, 20 Dec 2007 11:32:25 -0800 Daniel Walker <dwalker@mvista.com> wrote:
> 
> > On Tue, 2007-12-18 at 19:04 -0800, Geoff Levand wrote:
> > 
> > > Unfortunately there wasn't enough context in the patch to see
> > > that there is a down() earlier in the routine, and that the patch
> > > does indeed remove an incorrectly placed down().  Here is the
> > > entire routine, marked with what the patch removes.
> > > 
> > 
> > Andrew have you had a chance to review this?
> > 
> 
> Confused.  I did review it: http://lkml.org/lkml/2007/12/18/384

Yeah, but Geoff countered http://lkml.org/lkml/2007/12/18/409

Do you still think the patch is wrong, given the whole function?

Daniel