* [PATCH 1/3] ps3: vuart: fix error path locking [not found] <20071213003023.117964080@mvista.com> @ 2007-12-12 8:00 ` Daniel Walker 2007-12-13 2:00 ` Geoff Levand 2007-12-12 8:00 ` [PATCH 2/3] driver base: memory: semaphore to mutex Daniel Walker 2007-12-12 8:00 ` [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem " Daniel Walker 2 siblings, 1 reply; 92+ messages in thread From: Daniel Walker @ 2007-12-12 8:00 UTC (permalink / raw) To: akpm Cc: mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, linuxppc-dev [-- 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; } -- ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] ps3: vuart: fix error path locking 2007-12-12 8:00 ` [PATCH 1/3] ps3: vuart: fix error path locking Daniel Walker @ 2007-12-13 2:00 ` Geoff Levand 2007-12-19 1:10 ` Andrew Morton 0 siblings, 1 reply; 92+ messages in thread From: Geoff Levand @ 2007-12-13 2:00 UTC (permalink / raw) To: akpm Cc: Daniel Walker, matthias.kaehlcke, linux-kernel, linux, linuxppc-dev, mingo, kjwinchester > 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] ps3: vuart: fix error path locking 2007-12-13 2:00 ` Geoff Levand @ 2007-12-19 1:10 ` Andrew Morton 2007-12-19 1:54 ` Daniel Walker 2007-12-19 3:04 ` Geoff Levand 0 siblings, 2 replies; 92+ messages in thread From: Andrew Morton @ 2007-12-19 1:10 UTC (permalink / raw) To: Geoff Levand Cc: dwalker, matthias.kaehlcke, linux-kernel, linux, linuxppc-dev, mingo, kjwinchester 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] ps3: vuart: fix error path locking 2007-12-19 1:10 ` Andrew Morton @ 2007-12-19 1:54 ` Daniel Walker 2007-12-19 3:04 ` Geoff Levand 1 sibling, 0 replies; 92+ messages in thread From: Daniel Walker @ 2007-12-19 1:54 UTC (permalink / raw) To: Andrew Morton Cc: Geoff Levand, matthias.kaehlcke, linux-kernel, linux, linuxppc-dev, mingo, kjwinchester 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] ps3: vuart: fix error path locking 2007-12-19 1:10 ` Andrew Morton 2007-12-19 1:54 ` Daniel Walker @ 2007-12-19 3:04 ` Geoff Levand 2007-12-20 19:32 ` Daniel Walker 1 sibling, 1 reply; 92+ messages in thread From: Geoff Levand @ 2007-12-19 3:04 UTC (permalink / raw) To: Andrew Morton Cc: dwalker, matthias.kaehlcke, linux-kernel, linux, linuxppc-dev, mingo, kjwinchester 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] ps3: vuart: fix error path locking 2007-12-19 3:04 ` Geoff Levand @ 2007-12-20 19:32 ` Daniel Walker 2007-12-20 20:06 ` Andrew Morton 0 siblings, 1 reply; 92+ messages in thread From: Daniel Walker @ 2007-12-20 19:32 UTC (permalink / raw) To: Geoff Levand Cc: Andrew Morton, matthias.kaehlcke, linux-kernel, linux, linuxppc-dev, mingo, kjwinchester 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] ps3: vuart: fix error path locking 2007-12-20 19:32 ` Daniel Walker @ 2007-12-20 20:06 ` Andrew Morton 2007-12-20 20:13 ` Daniel Walker 0 siblings, 1 reply; 92+ messages in thread From: Andrew Morton @ 2007-12-20 20:06 UTC (permalink / raw) To: Daniel Walker Cc: Geoff Levand, matthias.kaehlcke, linux-kernel, linux, linuxppc-dev, mingo, kjwinchester 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 1/3] ps3: vuart: fix error path locking 2007-12-20 20:06 ` Andrew Morton @ 2007-12-20 20:13 ` Daniel Walker 0 siblings, 0 replies; 92+ messages in thread From: Daniel Walker @ 2007-12-20 20:13 UTC (permalink / raw) To: Andrew Morton Cc: Geoff Levand, matthias.kaehlcke, linux-kernel, linux, linuxppc-dev, mingo, kjwinchester 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH 2/3] driver base: memory: semaphore to mutex [not found] <20071213003023.117964080@mvista.com> 2007-12-12 8:00 ` [PATCH 1/3] ps3: vuart: fix error path locking Daniel Walker @ 2007-12-12 8:00 ` Daniel Walker 2007-12-12 8:00 ` [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem " Daniel Walker 2 siblings, 0 replies; 92+ messages in thread From: Daniel Walker @ 2007-12-12 8:00 UTC (permalink / raw) To: akpm Cc: mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester [-- 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 *); -- ^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex [not found] <20071213003023.117964080@mvista.com> 2007-12-12 8:00 ` [PATCH 1/3] ps3: vuart: fix error path locking Daniel Walker 2007-12-12 8:00 ` [PATCH 2/3] driver base: memory: semaphore to mutex Daniel Walker @ 2007-12-12 8:00 ` Daniel Walker 2007-12-13 0:48 ` Michael Buesch 2 siblings, 1 reply; 92+ messages in thread From: Daniel Walker @ 2007-12-12 8:00 UTC (permalink / raw) To: akpm Cc: mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch [-- 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; } -- ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-12 8:00 ` [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem " Daniel Walker @ 2007-12-13 0:48 ` Michael Buesch 2007-12-13 1:17 ` Ray Lee 2007-12-13 1:20 ` Daniel Walker 0 siblings, 2 replies; 92+ messages in thread From: Michael Buesch @ 2007-12-13 0:48 UTC (permalink / raw) To: Daniel Walker Cc: akpm, mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-13 0:48 ` Michael Buesch @ 2007-12-13 1:17 ` Ray Lee 2007-12-13 13:45 ` Michael Buesch 2007-12-13 1:20 ` Daniel Walker 1 sibling, 1 reply; 92+ messages in thread From: Ray Lee @ 2007-12-13 1:17 UTC (permalink / raw) To: Michael Buesch Cc: Daniel Walker, akpm, mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-13 1:17 ` Ray Lee @ 2007-12-13 13:45 ` Michael Buesch 2007-12-14 0:05 ` Ray Lee 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-13 13:45 UTC (permalink / raw) To: Ray Lee Cc: Daniel Walker, akpm, mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-13 13:45 ` Michael Buesch @ 2007-12-14 0:05 ` Ray Lee 2007-12-14 0:43 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: Ray Lee @ 2007-12-14 0:05 UTC (permalink / raw) To: Michael Buesch, bcm43xx-dev Cc: Daniel Walker, akpm, mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch, John Linville 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 0:05 ` Ray Lee @ 2007-12-14 0:43 ` Michael Buesch 2007-12-14 0:55 ` Harvey Harrison ` (3 more replies) 0 siblings, 4 replies; 92+ messages in thread From: Michael Buesch @ 2007-12-14 0:43 UTC (permalink / raw) To: Ray Lee Cc: bcm43xx-dev, Daniel Walker, akpm, mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch, John Linville 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 0:43 ` Michael Buesch @ 2007-12-14 0:55 ` Harvey Harrison 2007-12-14 10:45 ` Michael Buesch 2007-12-14 1:12 ` Ray Lee ` (2 subsequent siblings) 3 siblings, 1 reply; 92+ messages in thread From: Harvey Harrison @ 2007-12-14 0:55 UTC (permalink / raw) To: Michael Buesch Cc: Ray Lee, bcm43xx-dev, Daniel Walker, akpm, mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch, John Linville 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 0:55 ` Harvey Harrison @ 2007-12-14 10:45 ` Michael Buesch 0 siblings, 0 replies; 92+ messages in thread From: Michael Buesch @ 2007-12-14 10:45 UTC (permalink / raw) To: Harvey Harrison Cc: Ray Lee, bcm43xx-dev, Daniel Walker, akpm, mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch, John Linville 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 0:43 ` Michael Buesch 2007-12-14 0:55 ` Harvey Harrison @ 2007-12-14 1:12 ` Ray Lee 2007-12-14 10:49 ` Michael Buesch 2007-12-14 2:09 ` Larry Finger 2007-12-14 10:56 ` Ingo Molnar 3 siblings, 1 reply; 92+ messages in thread From: Ray Lee @ 2007-12-14 1:12 UTC (permalink / raw) To: Michael Buesch Cc: bcm43xx-dev, Daniel Walker, akpm, mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch, John Linville 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 1:12 ` Ray Lee @ 2007-12-14 10:49 ` Michael Buesch 2007-12-14 11:15 ` Ingo Molnar 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-14 10:49 UTC (permalink / raw) To: Ray Lee Cc: bcm43xx-dev, Daniel Walker, akpm, mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch, John Linville 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 10:49 ` Michael Buesch @ 2007-12-14 11:15 ` Ingo Molnar 2007-12-14 11:39 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: Ingo Molnar @ 2007-12-14 11:15 UTC (permalink / raw) To: Michael Buesch Cc: Ray Lee, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch, John Linville * 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 11:15 ` Ingo Molnar @ 2007-12-14 11:39 ` Michael Buesch 2007-12-14 12:16 ` Ingo Molnar 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-14 11:39 UTC (permalink / raw) To: Ingo Molnar Cc: Ray Lee, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch, John Linville 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 11:39 ` Michael Buesch @ 2007-12-14 12:16 ` Ingo Molnar 2007-12-14 12:31 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: Ingo Molnar @ 2007-12-14 12:16 UTC (permalink / raw) To: Michael Buesch Cc: Ray Lee, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch, John Linville * 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 12:16 ` Ingo Molnar @ 2007-12-14 12:31 ` Michael Buesch 2007-12-14 12:53 ` Ingo Molnar 2007-12-14 12:59 ` Simon Holm Thøgersen 0 siblings, 2 replies; 92+ messages in thread From: Michael Buesch @ 2007-12-14 12:31 UTC (permalink / raw) To: Ingo Molnar Cc: Ray Lee, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 12:31 ` Michael Buesch @ 2007-12-14 12:53 ` Ingo Molnar 2007-12-14 13:08 ` Michael Buesch 2007-12-14 12:59 ` Simon Holm Thøgersen 1 sibling, 1 reply; 92+ messages in thread From: Ingo Molnar @ 2007-12-14 12:53 UTC (permalink / raw) To: Michael Buesch Cc: Ray Lee, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville * 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 12:53 ` Ingo Molnar @ 2007-12-14 13:08 ` Michael Buesch 2007-12-14 16:06 ` Ray Lee 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-14 13:08 UTC (permalink / raw) To: Ingo Molnar Cc: Ray Lee, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 13:08 ` Michael Buesch @ 2007-12-14 16:06 ` Ray Lee 2007-12-14 16:49 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: Ray Lee @ 2007-12-14 16:06 UTC (permalink / raw) To: Michael Buesch Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 16:06 ` Ray Lee @ 2007-12-14 16:49 ` Michael Buesch 2007-12-14 18:01 ` Ray Lee 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-14 16:49 UTC (permalink / raw) To: Ray Lee Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 16:49 ` Michael Buesch @ 2007-12-14 18:01 ` Ray Lee 2007-12-14 18:11 ` Ingo Molnar 2007-12-14 18:22 ` Michael Buesch 0 siblings, 2 replies; 92+ messages in thread From: Ray Lee @ 2007-12-14 18:01 UTC (permalink / raw) To: Michael Buesch Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 18:01 ` Ray Lee @ 2007-12-14 18:11 ` Ingo Molnar 2007-12-14 18:47 ` Ray Lee 2007-12-14 18:22 ` Michael Buesch 1 sibling, 1 reply; 92+ messages in thread From: Ingo Molnar @ 2007-12-14 18:11 UTC (permalink / raw) To: Ray Lee Cc: Michael Buesch, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger * 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 18:11 ` Ingo Molnar @ 2007-12-14 18:47 ` Ray Lee 0 siblings, 0 replies; 92+ messages in thread From: Ray Lee @ 2007-12-14 18:47 UTC (permalink / raw) To: Ingo Molnar Cc: Michael Buesch, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 18:01 ` Ray Lee 2007-12-14 18:11 ` Ingo Molnar @ 2007-12-14 18:22 ` Michael Buesch 2007-12-14 18:45 ` Ray Lee 1 sibling, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-14 18:22 UTC (permalink / raw) To: Ray Lee Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 18:22 ` Michael Buesch @ 2007-12-14 18:45 ` Ray Lee 2007-12-14 19:05 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: Ray Lee @ 2007-12-14 18:45 UTC (permalink / raw) To: Michael Buesch Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 18:45 ` Ray Lee @ 2007-12-14 19:05 ` Michael Buesch 2007-12-14 19:25 ` Ray Lee 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-14 19:05 UTC (permalink / raw) To: Ray Lee Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 19:05 ` Michael Buesch @ 2007-12-14 19:25 ` Ray Lee 2007-12-14 19:38 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: Ray Lee @ 2007-12-14 19:25 UTC (permalink / raw) To: Michael Buesch Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger 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? ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 19:25 ` Ray Lee @ 2007-12-14 19:38 ` Michael Buesch 2007-12-14 19:55 ` Ray Lee 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-14 19:38 UTC (permalink / raw) To: Ray Lee Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 19:38 ` Michael Buesch @ 2007-12-14 19:55 ` Ray Lee 2007-12-14 20:13 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: Ray Lee @ 2007-12-14 19:55 UTC (permalink / raw) To: Michael Buesch Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 19:55 ` Ray Lee @ 2007-12-14 20:13 ` Michael Buesch 2007-12-14 21:39 ` Ray Lee 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-14 20:13 UTC (permalink / raw) To: Ray Lee Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 20:13 ` Michael Buesch @ 2007-12-14 21:39 ` Ray Lee 0 siblings, 0 replies; 92+ messages in thread From: Ray Lee @ 2007-12-14 21:39 UTC (permalink / raw) To: Michael Buesch Cc: Ingo Molnar, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville, Larry Finger 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 12:31 ` Michael Buesch 2007-12-14 12:53 ` Ingo Molnar @ 2007-12-14 12:59 ` Simon Holm Thøgersen 2007-12-14 13:04 ` Michael Buesch 1 sibling, 1 reply; 92+ messages in thread From: Simon Holm Thøgersen @ 2007-12-14 12:59 UTC (permalink / raw) To: Michael Buesch Cc: Ingo Molnar, Ray Lee, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 12:59 ` Simon Holm Thøgersen @ 2007-12-14 13:04 ` Michael Buesch 2007-12-15 0:51 ` Rafael J. Wysocki 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-14 13:04 UTC (permalink / raw) To: Simon Holm Thøgersen Cc: Ingo Molnar, Ray Lee, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, John Linville 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 13:04 ` Michael Buesch @ 2007-12-15 0:51 ` Rafael J. Wysocki 2007-12-15 0:58 ` Larry Finger 2007-12-15 10:57 ` Michael Buesch 0 siblings, 2 replies; 92+ messages in thread From: Rafael J. Wysocki @ 2007-12-15 0:51 UTC (permalink / raw) To: Michael Buesch Cc: bcm43xx-dev, Simon Holm Thøgersen, Daniel Walker, akpm, Ray Lee, matthias.kaehlcke, linux-kernel, linux, kjwinchester, jonathan, Ingo Molnar 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 0:51 ` Rafael J. Wysocki @ 2007-12-15 0:58 ` Larry Finger 2007-12-15 1:59 ` mvtodevnull 2007-12-15 10:57 ` Michael Buesch 1 sibling, 1 reply; 92+ messages in thread From: Larry Finger @ 2007-12-15 0:58 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 0:58 ` Larry Finger @ 2007-12-15 1:59 ` mvtodevnull 2007-12-15 2:27 ` Larry Finger 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-15 1:59 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 1:59 ` mvtodevnull @ 2007-12-15 2:27 ` Larry Finger 2007-12-15 4:37 ` mvtodevnull 0 siblings, 1 reply; 92+ messages in thread From: Larry Finger @ 2007-12-15 2:27 UTC (permalink / raw) To: mvtodevnull Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 2:27 ` Larry Finger @ 2007-12-15 4:37 ` mvtodevnull 2007-12-15 4:39 ` mvtodevnull 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-15 4:37 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 4:37 ` mvtodevnull @ 2007-12-15 4:39 ` mvtodevnull 2007-12-15 7:18 ` Larry Finger 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-15 4:39 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev [-- 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" ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 4:39 ` mvtodevnull @ 2007-12-15 7:18 ` Larry Finger 2007-12-15 12:38 ` mvtodevnull 0 siblings, 1 reply; 92+ messages in thread From: Larry Finger @ 2007-12-15 7:18 UTC (permalink / raw) To: mvtodevnull Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 7:18 ` Larry Finger @ 2007-12-15 12:38 ` mvtodevnull 2007-12-17 2:17 ` mvtodevnull 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-15 12:38 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 12:38 ` mvtodevnull @ 2007-12-17 2:17 ` mvtodevnull 2007-12-17 6:52 ` Larry Finger 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-17 2:17 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 2:17 ` mvtodevnull @ 2007-12-17 6:52 ` Larry Finger 2007-12-17 7:17 ` mvtodevnull 0 siblings, 1 reply; 92+ messages in thread From: Larry Finger @ 2007-12-17 6:52 UTC (permalink / raw) To: mvtodevnull Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 6:52 ` Larry Finger @ 2007-12-17 7:17 ` mvtodevnull 2007-12-17 9:49 ` Michael Buesch 2007-12-18 1:16 ` Larry Finger 0 siblings, 2 replies; 92+ messages in thread From: mvtodevnull @ 2007-12-17 7:17 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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). ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 7:17 ` mvtodevnull @ 2007-12-17 9:49 ` Michael Buesch 2007-12-17 10:15 ` mvtodevnull 2007-12-18 1:16 ` Larry Finger 1 sibling, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-17 9:49 UTC (permalink / raw) To: mvtodevnull Cc: Larry Finger, Rafael J. Wysocki, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 9:49 ` Michael Buesch @ 2007-12-17 10:15 ` mvtodevnull 2007-12-17 10:35 ` mvtodevnull 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-17 10:15 UTC (permalink / raw) To: Michael Buesch Cc: Larry Finger, Rafael J. Wysocki, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 10:15 ` mvtodevnull @ 2007-12-17 10:35 ` mvtodevnull 2007-12-17 22:04 ` mvtodevnull 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-17 10:35 UTC (permalink / raw) To: Michael Buesch Cc: Larry Finger, Rafael J. Wysocki, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 10:35 ` mvtodevnull @ 2007-12-17 22:04 ` mvtodevnull 2007-12-17 22:45 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-17 22:04 UTC (permalink / raw) To: Michael Buesch Cc: Larry Finger, Rafael J. Wysocki, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 22:04 ` mvtodevnull @ 2007-12-17 22:45 ` Michael Buesch 2007-12-17 23:12 ` mvtodevnull 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-17 22:45 UTC (permalink / raw) To: mvtodevnull Cc: Larry Finger, Rafael J. Wysocki, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 22:45 ` Michael Buesch @ 2007-12-17 23:12 ` mvtodevnull 2007-12-17 23:18 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-17 23:12 UTC (permalink / raw) To: Michael Buesch Cc: Larry Finger, Rafael J. Wysocki, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 23:12 ` mvtodevnull @ 2007-12-17 23:18 ` Michael Buesch 2007-12-17 23:27 ` mvtodevnull 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-17 23:18 UTC (permalink / raw) To: mvtodevnull Cc: Larry Finger, Rafael J. Wysocki, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 23:18 ` Michael Buesch @ 2007-12-17 23:27 ` mvtodevnull 0 siblings, 0 replies; 92+ messages in thread From: mvtodevnull @ 2007-12-17 23:27 UTC (permalink / raw) To: Michael Buesch Cc: Larry Finger, Rafael J. Wysocki, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-17 7:17 ` mvtodevnull 2007-12-17 9:49 ` Michael Buesch @ 2007-12-18 1:16 ` Larry Finger 2007-12-18 2:34 ` mvtodevnull 1 sibling, 1 reply; 92+ messages in thread From: Larry Finger @ 2007-12-18 1:16 UTC (permalink / raw) To: mvtodevnull Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-18 1:16 ` Larry Finger @ 2007-12-18 2:34 ` mvtodevnull 2007-12-19 2:12 ` mvtodevnull 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-18 2:34 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-18 2:34 ` mvtodevnull @ 2007-12-19 2:12 ` mvtodevnull 2007-12-19 8:11 ` Larry Finger 0 siblings, 1 reply; 92+ messages in thread From: mvtodevnull @ 2007-12-19 2:12 UTC (permalink / raw) To: Larry Finger Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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? ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-19 2:12 ` mvtodevnull @ 2007-12-19 8:11 ` Larry Finger [not found] ` <200712191046.54147.mb@bu3sch.de> 0 siblings, 1 reply; 92+ messages in thread From: Larry Finger @ 2007-12-19 8:11 UTC (permalink / raw) To: mvtodevnull Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
[parent not found: <200712191046.54147.mb@bu3sch.de>]
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex [not found] ` <200712191046.54147.mb@bu3sch.de> @ 2007-12-19 13:48 ` Ingo Molnar 0 siblings, 0 replies; 92+ messages in thread From: Ingo Molnar @ 2007-12-19 13:48 UTC (permalink / raw) To: Michael Buesch Cc: bcm43xx-dev, Larry Finger, mvtodevnull, Daniel Walker, akpm, Ray Lee, n, SimonHolm=?iso-8859-1?q?Th=F8gerse?=, matthias.kaehlcke, linux-kernel, jonathan, kjwinchester, linux * 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 0:51 ` Rafael J. Wysocki 2007-12-15 0:58 ` Larry Finger @ 2007-12-15 10:57 ` Michael Buesch 2007-12-15 23:18 ` Rafael J. Wysocki 1 sibling, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-15 10:57 UTC (permalink / raw) To: Rafael J. Wysocki Cc: bcm43xx-dev, Simon Holm Thøgersen, Daniel Walker, akpm, Ray Lee, matthias.kaehlcke, linux-kernel, linux, kjwinchester, jonathan, Ingo Molnar 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 10:57 ` Michael Buesch @ 2007-12-15 23:18 ` Rafael J. Wysocki 2007-12-15 23:27 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: Rafael J. Wysocki @ 2007-12-15 23:18 UTC (permalink / raw) To: Michael Buesch Cc: bcm43xx-dev, Simon Holm Thøgersen, Daniel Walker, akpm, Ray Lee, matthias.kaehlcke, linux-kernel, linux, kjwinchester, jonathan, Ingo Molnar 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 23:18 ` Rafael J. Wysocki @ 2007-12-15 23:27 ` Michael Buesch 2007-12-16 2:30 ` Larry Finger 2007-12-16 13:56 ` Johannes Berg 0 siblings, 2 replies; 92+ messages in thread From: Michael Buesch @ 2007-12-15 23:27 UTC (permalink / raw) To: bcm43xx-dev Cc: Rafael J. Wysocki, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 23:27 ` Michael Buesch @ 2007-12-16 2:30 ` Larry Finger 2007-12-16 11:13 ` Michael Buesch 2007-12-16 13:56 ` Johannes Berg 1 sibling, 1 reply; 92+ messages in thread From: Larry Finger @ 2007-12-16 2:30 UTC (permalink / raw) To: Michael Buesch Cc: bcm43xx-dev, Daniel Walker, akpm, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, jonathan, Ingo Molnar, kjwinchester, linux 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-16 2:30 ` Larry Finger @ 2007-12-16 11:13 ` Michael Buesch 0 siblings, 0 replies; 92+ messages in thread From: Michael Buesch @ 2007-12-16 11:13 UTC (permalink / raw) To: Larry Finger Cc: bcm43xx-dev, Daniel Walker, akpm, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, jonathan, Ingo Molnar, kjwinchester, linux 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 23:27 ` Michael Buesch 2007-12-16 2:30 ` Larry Finger @ 2007-12-16 13:56 ` Johannes Berg 2007-12-16 14:35 ` Rafael J. Wysocki 1 sibling, 1 reply; 92+ messages in thread From: Johannes Berg @ 2007-12-16 13:56 UTC (permalink / raw) To: Michael Buesch Cc: bcm43xx-dev, Daniel Walker, akpm, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, jonathan, Ingo Molnar, kjwinchester, linux [-- 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 --] ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-16 13:56 ` Johannes Berg @ 2007-12-16 14:35 ` Rafael J. Wysocki 2007-12-16 14:18 ` Johannes Berg 0 siblings, 1 reply; 92+ messages in thread From: Rafael J. Wysocki @ 2007-12-16 14:35 UTC (permalink / raw) To: bcm43xx-dev Cc: Johannes Berg, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-16 14:35 ` Rafael J. Wysocki @ 2007-12-16 14:18 ` Johannes Berg 0 siblings, 0 replies; 92+ messages in thread From: Johannes Berg @ 2007-12-16 14:18 UTC (permalink / raw) To: Rafael J. Wysocki Cc: bcm43xx-dev, Michael Buesch, Daniel Walker, Ray Lee, Simon Holm Thøgersen, matthias.kaehlcke, linux-kernel, linux, Ingo Molnar, kjwinchester, jonathan, akpm [-- 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 --] ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 0:43 ` Michael Buesch 2007-12-14 0:55 ` Harvey Harrison 2007-12-14 1:12 ` Ray Lee @ 2007-12-14 2:09 ` Larry Finger 2007-12-14 10:56 ` Ingo Molnar 3 siblings, 0 replies; 92+ messages in thread From: Larry Finger @ 2007-12-14 2:09 UTC (permalink / raw) To: Michael Buesch Cc: Ray Lee, Daniel Walker, matthias.kaehlcke, mbuesch, linux-kernel, bcm43xx-dev, linux, kjwinchester, jonathan, akpm, mingo 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 0:43 ` Michael Buesch ` (2 preceding siblings ...) 2007-12-14 2:09 ` Larry Finger @ 2007-12-14 10:56 ` Ingo Molnar 2007-12-14 14:14 ` John W. Linville 3 siblings, 1 reply; 92+ messages in thread From: Ingo Molnar @ 2007-12-14 10:56 UTC (permalink / raw) To: Michael Buesch Cc: Ray Lee, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch, John Linville * 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 10:56 ` Ingo Molnar @ 2007-12-14 14:14 ` John W. Linville 2007-12-14 14:40 ` stefano.brivio 0 siblings, 1 reply; 92+ messages in thread From: John W. Linville @ 2007-12-14 14:14 UTC (permalink / raw) To: Ingo Molnar Cc: Michael Buesch, Ray Lee, bcm43xx-dev, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 14:14 ` John W. Linville @ 2007-12-14 14:40 ` stefano.brivio 2007-12-14 16:27 ` Ray Lee 0 siblings, 1 reply; 92+ messages in thread From: stefano.brivio @ 2007-12-14 14:40 UTC (permalink / raw) To: John W. Linville Cc: Ingo Molnar, Daniel Walker, Ray Lee, matthias.kaehlcke, linux-kernel, mbuesch, linux, Michael Buesch, kjwinchester, jonathan, akpm, bcm43xx-dev "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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 14:40 ` stefano.brivio @ 2007-12-14 16:27 ` Ray Lee 2007-12-14 16:45 ` Ray Lee 0 siblings, 1 reply; 92+ messages in thread From: Ray Lee @ 2007-12-14 16:27 UTC (permalink / raw) To: stefano.brivio Cc: John W. Linville, Ingo Molnar, Daniel Walker, matthias.kaehlcke, linux-kernel, mbuesch, linux, Michael Buesch, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 16:27 ` Ray Lee @ 2007-12-14 16:45 ` Ray Lee 2007-12-14 16:59 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: Ray Lee @ 2007-12-14 16:45 UTC (permalink / raw) To: stefano.brivio, Linus Torvalds Cc: John W. Linville, Ingo Molnar, Daniel Walker, matthias.kaehlcke, linux-kernel, mbuesch, linux, Michael Buesch, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 16:45 ` Ray Lee @ 2007-12-14 16:59 ` Michael Buesch 2007-12-14 17:22 ` Ray Lee 2007-12-14 17:59 ` Ingo Molnar 0 siblings, 2 replies; 92+ messages in thread From: Michael Buesch @ 2007-12-14 16:59 UTC (permalink / raw) To: Ray Lee Cc: stefano.brivio, Linus Torvalds, John W. Linville, Ingo Molnar, Daniel Walker, matthias.kaehlcke, linux-kernel, mbuesch, linux, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 16:59 ` Michael Buesch @ 2007-12-14 17:22 ` Ray Lee 2007-12-14 17:59 ` Ingo Molnar 1 sibling, 0 replies; 92+ messages in thread From: Ray Lee @ 2007-12-14 17:22 UTC (permalink / raw) To: Michael Buesch Cc: stefano.brivio, Linus Torvalds, John W. Linville, Ingo Molnar, Daniel Walker, matthias.kaehlcke, linux-kernel, mbuesch, linux, kjwinchester, jonathan, akpm, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 16:59 ` Michael Buesch 2007-12-14 17:22 ` Ray Lee @ 2007-12-14 17:59 ` Ingo Molnar 2007-12-14 18:38 ` Michael Buesch 1 sibling, 1 reply; 92+ messages in thread From: Ingo Molnar @ 2007-12-14 17:59 UTC (permalink / raw) To: Michael Buesch Cc: Ray Lee, stefano.brivio, Linus Torvalds, John W. Linville, Daniel Walker, matthias.kaehlcke, linux-kernel, mbuesch, linux, kjwinchester, jonathan, akpm, bcm43xx-dev * 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 17:59 ` Ingo Molnar @ 2007-12-14 18:38 ` Michael Buesch 2007-12-15 1:25 ` Rafael J. Wysocki 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-14 18:38 UTC (permalink / raw) To: Ingo Molnar Cc: Ray Lee, stefano.brivio, Linus Torvalds, John W. Linville, Daniel Walker, matthias.kaehlcke, linux-kernel, mbuesch, linux, kjwinchester, jonathan, akpm, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-14 18:38 ` Michael Buesch @ 2007-12-15 1:25 ` Rafael J. Wysocki 2007-12-15 21:43 ` John W. Linville 0 siblings, 1 reply; 92+ messages in thread From: Rafael J. Wysocki @ 2007-12-15 1:25 UTC (permalink / raw) To: Michael Buesch Cc: bcm43xx-dev, Ingo Molnar, Daniel Walker, akpm, stefano.brivio, Ray Lee, matthias.kaehlcke, linux-kernel, linux, jonathan, kjwinchester, Linus Torvalds, mbuesch 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 1:25 ` Rafael J. Wysocki @ 2007-12-15 21:43 ` John W. Linville 2007-12-15 23:26 ` Rafael J. Wysocki 2007-12-16 9:22 ` Ingo Molnar 0 siblings, 2 replies; 92+ messages in thread From: John W. Linville @ 2007-12-15 21:43 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Michael Buesch, Daniel Walker, akpm, stefano.brivio, Ray Lee, matthias.kaehlcke, linux-kernel, mbuesch, linux, kjwinchester, jonathan, Ingo Molnar, Linus Torvalds, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 21:43 ` John W. Linville @ 2007-12-15 23:26 ` Rafael J. Wysocki 2007-12-16 3:20 ` Stefan Lippers-Hollmann 2007-12-16 9:22 ` Ingo Molnar 1 sibling, 1 reply; 92+ messages in thread From: Rafael J. Wysocki @ 2007-12-15 23:26 UTC (permalink / raw) To: John W. Linville Cc: Michael Buesch, Daniel Walker, akpm, stefano.brivio, Ray Lee, matthias.kaehlcke, linux-kernel, mbuesch, linux, kjwinchester, jonathan, Ingo Molnar, Linus Torvalds, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 23:26 ` Rafael J. Wysocki @ 2007-12-16 3:20 ` Stefan Lippers-Hollmann 0 siblings, 0 replies; 92+ messages in thread From: Stefan Lippers-Hollmann @ 2007-12-16 3:20 UTC (permalink / raw) To: Rafael J. Wysocki Cc: John W. Linville, Michael Buesch, Daniel Walker, akpm, stefano.brivio, Ray Lee, matthias.kaehlcke, linux-kernel, mbuesch, linux, kjwinchester, jonathan, Ingo Molnar, Linus Torvalds, bcm43xx-dev 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-15 21:43 ` John W. Linville 2007-12-15 23:26 ` Rafael J. Wysocki @ 2007-12-16 9:22 ` Ingo Molnar 2007-12-16 11:23 ` Michael Buesch 1 sibling, 1 reply; 92+ messages in thread From: Ingo Molnar @ 2007-12-16 9:22 UTC (permalink / raw) To: John W. Linville Cc: Rafael J. Wysocki, Michael Buesch, Daniel Walker, akpm, stefano.brivio, Ray Lee, matthias.kaehlcke, linux-kernel, mbuesch, linux, kjwinchester, jonathan, Linus Torvalds, bcm43xx-dev * 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-16 9:22 ` Ingo Molnar @ 2007-12-16 11:23 ` Michael Buesch 0 siblings, 0 replies; 92+ messages in thread From: Michael Buesch @ 2007-12-16 11:23 UTC (permalink / raw) To: Ingo Molnar Cc: John W. Linville, Rafael J. Wysocki, Daniel Walker, akpm, stefano.brivio, Ray Lee, matthias.kaehlcke, linux-kernel, mbuesch, linux, kjwinchester, jonathan, Linus Torvalds, bcm43xx-dev 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-13 0:48 ` Michael Buesch 2007-12-13 1:17 ` Ray Lee @ 2007-12-13 1:20 ` Daniel Walker 2007-12-13 10:13 ` Ingo Molnar 1 sibling, 1 reply; 92+ messages in thread From: Daniel Walker @ 2007-12-13 1:20 UTC (permalink / raw) To: Michael Buesch Cc: akpm, mingo, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-13 1:20 ` Daniel Walker @ 2007-12-13 10:13 ` Ingo Molnar 2007-12-13 11:11 ` Michael Buesch 0 siblings, 1 reply; 92+ messages in thread From: Ingo Molnar @ 2007-12-13 10:13 UTC (permalink / raw) To: Daniel Walker Cc: Michael Buesch, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch * 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-13 10:13 ` Ingo Molnar @ 2007-12-13 11:11 ` Michael Buesch 2007-12-13 14:23 ` John W. Linville 0 siblings, 1 reply; 92+ messages in thread From: Michael Buesch @ 2007-12-13 11:11 UTC (permalink / raw) To: Ingo Molnar Cc: Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch 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. ^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex 2007-12-13 11:11 ` Michael Buesch @ 2007-12-13 14:23 ` John W. Linville 0 siblings, 0 replies; 92+ messages in thread From: John W. Linville @ 2007-12-13 14:23 UTC (permalink / raw) To: Michael Buesch Cc: Ingo Molnar, Daniel Walker, akpm, linux-kernel, linux, jonathan, matthias.kaehlcke, kjwinchester, mbuesch 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 ^ permalink raw reply [flat|nested] 92+ messages in thread
end of thread, other threads:[~2007-12-20 20:14 UTC | newest] Thread overview: 92+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20071213003023.117964080@mvista.com> 2007-12-12 8:00 ` [PATCH 1/3] ps3: vuart: fix error path locking Daniel Walker 2007-12-13 2:00 ` Geoff Levand 2007-12-19 1:10 ` Andrew Morton 2007-12-19 1:54 ` Daniel Walker 2007-12-19 3:04 ` Geoff Levand 2007-12-20 19:32 ` Daniel Walker 2007-12-20 20:06 ` Andrew Morton 2007-12-20 20:13 ` Daniel Walker 2007-12-12 8:00 ` [PATCH 2/3] driver base: memory: semaphore to mutex Daniel Walker 2007-12-12 8:00 ` [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem " Daniel Walker 2007-12-13 0:48 ` Michael Buesch 2007-12-13 1:17 ` Ray Lee 2007-12-13 13:45 ` Michael Buesch 2007-12-14 0:05 ` Ray Lee 2007-12-14 0:43 ` Michael Buesch 2007-12-14 0:55 ` Harvey Harrison 2007-12-14 10:45 ` Michael Buesch 2007-12-14 1:12 ` Ray Lee 2007-12-14 10:49 ` Michael Buesch 2007-12-14 11:15 ` Ingo Molnar 2007-12-14 11:39 ` Michael Buesch 2007-12-14 12:16 ` Ingo Molnar 2007-12-14 12:31 ` Michael Buesch 2007-12-14 12:53 ` Ingo Molnar 2007-12-14 13:08 ` Michael Buesch 2007-12-14 16:06 ` Ray Lee 2007-12-14 16:49 ` Michael Buesch 2007-12-14 18:01 ` Ray Lee 2007-12-14 18:11 ` Ingo Molnar 2007-12-14 18:47 ` Ray Lee 2007-12-14 18:22 ` Michael Buesch 2007-12-14 18:45 ` Ray Lee 2007-12-14 19:05 ` Michael Buesch 2007-12-14 19:25 ` Ray Lee 2007-12-14 19:38 ` Michael Buesch 2007-12-14 19:55 ` Ray Lee 2007-12-14 20:13 ` Michael Buesch 2007-12-14 21:39 ` Ray Lee 2007-12-14 12:59 ` Simon Holm Thøgersen 2007-12-14 13:04 ` Michael Buesch 2007-12-15 0:51 ` Rafael J. Wysocki 2007-12-15 0:58 ` Larry Finger 2007-12-15 1:59 ` mvtodevnull 2007-12-15 2:27 ` Larry Finger 2007-12-15 4:37 ` mvtodevnull 2007-12-15 4:39 ` mvtodevnull 2007-12-15 7:18 ` Larry Finger 2007-12-15 12:38 ` mvtodevnull 2007-12-17 2:17 ` mvtodevnull 2007-12-17 6:52 ` Larry Finger 2007-12-17 7:17 ` mvtodevnull 2007-12-17 9:49 ` Michael Buesch 2007-12-17 10:15 ` mvtodevnull 2007-12-17 10:35 ` mvtodevnull 2007-12-17 22:04 ` mvtodevnull 2007-12-17 22:45 ` Michael Buesch 2007-12-17 23:12 ` mvtodevnull 2007-12-17 23:18 ` Michael Buesch 2007-12-17 23:27 ` mvtodevnull 2007-12-18 1:16 ` Larry Finger 2007-12-18 2:34 ` mvtodevnull 2007-12-19 2:12 ` mvtodevnull 2007-12-19 8:11 ` Larry Finger [not found] ` <200712191046.54147.mb@bu3sch.de> 2007-12-19 13:48 ` Ingo Molnar 2007-12-15 10:57 ` Michael Buesch 2007-12-15 23:18 ` Rafael J. Wysocki 2007-12-15 23:27 ` Michael Buesch 2007-12-16 2:30 ` Larry Finger 2007-12-16 11:13 ` Michael Buesch 2007-12-16 13:56 ` Johannes Berg 2007-12-16 14:35 ` Rafael J. Wysocki 2007-12-16 14:18 ` Johannes Berg 2007-12-14 2:09 ` Larry Finger 2007-12-14 10:56 ` Ingo Molnar 2007-12-14 14:14 ` John W. Linville 2007-12-14 14:40 ` stefano.brivio 2007-12-14 16:27 ` Ray Lee 2007-12-14 16:45 ` Ray Lee 2007-12-14 16:59 ` Michael Buesch 2007-12-14 17:22 ` Ray Lee 2007-12-14 17:59 ` Ingo Molnar 2007-12-14 18:38 ` Michael Buesch 2007-12-15 1:25 ` Rafael J. Wysocki 2007-12-15 21:43 ` John W. Linville 2007-12-15 23:26 ` Rafael J. Wysocki 2007-12-16 3:20 ` Stefan Lippers-Hollmann 2007-12-16 9:22 ` Ingo Molnar 2007-12-16 11:23 ` Michael Buesch 2007-12-13 1:20 ` Daniel Walker 2007-12-13 10:13 ` Ingo Molnar 2007-12-13 11:11 ` Michael Buesch 2007-12-13 14:23 ` John W. Linville
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).