On Saturday 26 May 2007 02:24:31 Stephen Hemminger wrote:
Something is broken with the b44 driver in 2.6.22-rc1 or later. Now bisecting.
The performance (with iperf) for receiving is normally 94Mbits or more.
But something happened that dropped performance to less than 1Mbit,
probably
On Saturday 26 May 2007 10:58:15 Andreas Schwab wrote:
A switch on long long causes gcc to generate a reference to __ucmpdi2 on
ppc32. Avoid that by casting to int, since the value is only a small
integer anyway.
Signed-off-by: Andreas Schwab [EMAIL PROTECTED]
---
drivers/net/s2io.c |
On Sunday 27 May 2007 01:00:04 [EMAIL PROTECTED] wrote:
From: Divy Le Ray [EMAIL PROTECTED]
Bump FW version to 4.1.
Modify chip tuning in consequence.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
@@ -2496,11 +2500,11 @@ static void __devinit init_mtus(unsigned
* it can
This reset wasn't there in the old b44 driver
and I don't think it's needed for the 47xx either.
If it later turns out that this is really needed for
some weird 47xx, we can re-add it with a special case
branch for that particular device.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index
Some people have difficulties in understanding that the
option Broadcom 440x PCI device support is for PCI devices,
so they disable it and complain that it doesn't work anymore.
Try to prevent that with this patch.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: bu3sch-wireless-dev
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
2.6.22-rc3:
[ 5] local 192.168.1.2 port 46557 connected with 192.168.1.1 port 5001
[ 5] 0.0-60.4 sec 58.9 MBytes 8.18 Mbits/sec
[ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 51633
[ 4] 0.0-63.1 sec 7.27
On Sunday 27 May 2007 22:36:39 Maximilian Engelhardt wrote:
When I ran 2.6.21.1 or 2.6.22-rc3 without any debugging tools just in normal
use I didn't notice any problems. It did work fine as I would expect it.
I think the wget and ping tests here are as they should be.
With 2.6.22-rc2-mm1 I
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
2.6.21.1:
[ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
[ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
[ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 57837
[ 4] 0.0-63.1 sec 2.82
On Sunday 27 May 2007 23:13:32 Michael Buesch wrote:
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
2.6.21.1:
[ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
[ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
[ 4] local 192.168.1.2 port 5001 connected
This fixes a bug introduced by me with the ssb porting.
A u32 integer is casted to a u16* pointer, which
is gonna break, obviously.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: bu3sch-wireless-dev/drivers/net/b44.c
Ok, another question: On which CPU architecture are you?
--
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Can you give 2.6.16 a try? The diff is not that big and we might
be able to find out what broke if you find out 2.6.16 works.
You can also try later kernels like .17, .18, .19 to further
reduce the patch. (You could also git-bisect, if you have the time).
git-diff v2.6.16..v2.6.22-rc3
Can you also test the following patch?
I think there's a bug in b44 that is doesn't properly discard
shared IRQs, so it might possibly generate a NAPI storm, dunno.
Worth a try.
Index: linux-2.6.22-rc3/drivers/net/b44.c
===
---
On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
On Monday 28 May 2007, Michael Buesch wrote:
Can you also test the following patch?
I think there's a bug in b44 that is doesn't properly discard
shared IRQs, so it might possibly generate a NAPI storm, dunno.
Worth a try
On Monday 28 May 2007 16:09:46 Maximilian Engelhardt wrote:
On Monday 28 May 2007, Michael Buesch wrote:
Can you give 2.6.16 a try? The diff is not that big and we might
be able to find out what broke if you find out 2.6.16 works.
You can also try later kernels like .17, .18, .19 to further
On Monday 28 May 2007 17:32:51 Thomas Gleixner wrote:
On Mon, 2007-05-28 at 17:14 +0200, Michael Buesch wrote:
The -oldconfig1 is the kernel that had no problems and the other shows
the b44
problem. So if High Resolution Timer Support is disabled everything works
fine and if I
On Tuesday 29 May 2007 16:14:35 Gary Zambrano wrote:
On Mon, 2007-05-28 at 16:55 +0200, Michael Buesch wrote:
On Monday 28 May 2007 16:12:12 Maximilian Engelhardt wrote:
On Monday 28 May 2007, Michael Buesch wrote:
Can you also test the following patch?
I think there's a bug in b44
On Tuesday 29 May 2007 23:36:51 Gary Zambrano wrote:
On Tue, 2007-05-29 at 18:39 -0400, Jeff Garzik wrote:
We check for 0x because that is often how a fault is indicated,
when the memory location is read during or immediately after hotplug (or
if the PCI bus is truly faulty).
On Wednesday 30 May 2007 04:47:09 Laurent Chavey wrote:
proposed change.
--- 2.6.20/drivers/net/bonding/bond_main.c 2007-05-29
19:43:39.010565000 -0700
+++ 2.6.20.fix/drivers/net/bonding/bond_main.c 2007-05-29
19:46:12.37698 -0700
@@ -1227,7 +1227,14 @@
int i;
On Friday 01 June 2007 13:14:35 Mithlesh Thukral wrote:
NetXen: Add multicast filter code
This patch will add manage the multicast filter from driver.
It will add capability to write multicast addresses to hardware.
Signed-by: Mithlesh Thukral [EMAIL PROTECTED]
---
On Saturday 02 June 2007 23:48:31 Ulrich Drepper wrote:
Take two: I forgot to change the compat code. This has now happened. Only
one
additional line changed.
Everything else from the first patch remains the same. I try to avoid
clogging
the list unnecessarily by not resending the
On Monday 04 June 2007 22:25:37 Stephen Hemminger wrote:
Make the PHY and statistic timer run on one second boundary
for powersaving.
On resume, the driver should check for link up immediately, to
get online faster (rather than waiting for the next second).
Signed-off-by: Stephen
On Wednesday 06 June 2007 23:04:07 Stephen Hemminger wrote:
I don't think we need +1, if you need to fire immediately
(on the next tick). The timer core will always fire
timers that are in the past immediately.
Thanks, but is it worth bothering to change it again?
No, I don't think so.
On Thursday 07 June 2007 13:34:37 Mithlesh Thukral wrote:
NetXen: Add multi cast filter code
This patch adds multi cast filter code to NetXen NIC driver.
It also adds capabilities to setup the multicast address in hardware
from the host side.
+int netxen_nic_enable_mcast_filter(struct
On Sunday 10 June 2007 11:54:11 Michael Buesch wrote:
+int netxen_nic_set_mcast_addr(struct netxen_adapter *adapter, int index,
+ u8 *addr)
+{
+ u32 hi = 0;
+ u32 lo = 0;
+ u16 port = physical_port[adapter-portnum];
+
+ hi = (u32) addr[0
On Friday 15 June 2007 13:26:03 Keir Fraser wrote:
On 15/6/07 11:46, Kieran Mansley [EMAIL PROTECTED] wrote:
This is a repost of some earlier patches to the xen-devel mailing list,
with a number of changes thanks to some useful suggestions from others.
The coding style needs fixing in
On Friday 15 June 2007 14:20:34 Keir Fraser wrote:
On 15/6/07 13:11, Michael Buesch [EMAIL PROTECTED] wrote:
No use of the following please:
If (foo) return 1; else return 0;
Is clearer as:
Return foo;
But it's not the same.
return !!foo;
would be the same. And yes, it does
On Sunday 17 June 2007 02:42:18 Maximilian Engelhardt wrote:
I did build a kernel without the three mentioned above but the problem is
still the same. I also did remove everything but eth0 on interrupt 10 so the
only device using that interrupt is eth0 and then the card completely stopped
On Saturday 16 June 2007 23:27:43 Maximilian Engelhardt wrote:
[...]
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI Interrupt :02:02.0[A] - Link [LNKD] - GSI 10 (level, low) -
IRQ 10
ssb: Sonics Silicon Backplane found on PCI device :02:02.0
b44.c:v2.0
eth0: Broadcom
On Sunday 17 June 2007 12:55:39 Michael Buesch wrote:
On Saturday 16 June 2007 23:27:43 Maximilian Engelhardt wrote:
[...]
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI Interrupt :02:02.0[A] - Link [LNKD] - GSI 10 (level, low)
-
IRQ 10
ssb: Sonics Silicon Backplane
This bug was introduced by me.
val is 16bit, but the read value is 32bit.
Seems like I was smoking crack when porting that part of the driver.
I guess that's the last stupid bug in these 4 lines of code.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: bu3sch-wireless-dev/drivers/net/b44.c
On Sunday 17 June 2007 14:03:30 Maximilian Engelhardt wrote:
On Sunday 17 June 2007, Michael Buesch wrote:
On Saturday 16 June 2007 23:27:43 Maximilian Engelhardt wrote:
[...]
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI Interrupt :02:02.0[A] - Link [LNKD] - GSI 10
b44 driver.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Maximilian Engelhardt [EMAIL PROTECTED]
Cc: Gary Zambrano [EMAIL PROTECTED]
Index: bu3sch-wireless-dev/drivers/ssb/driver_pcicore.c
===
--- bu3sch-wireless-dev.orig
On Friday 22 June 2007 10:42:38 Mithlesh Thukral wrote:
diff --git a/drivers/net/netxen/netxen_nic_hw.c
b/drivers/net/netxen/netxen_nic_hw.c
index 4e958c9..f0df6fb 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -378,6 +378,7 @@ int
On Friday 22 June 2007 10:40:41 Mithlesh Thukral wrote:
NetXen: Fix issue of MSI not working correctly
NetXen driver uses PCI function 0 to provide the functionality of MSI.
The patch makes driver check the bus master bit for function 0 and
enable it after the card initialization.
On Saturday 23 June 2007 01:26:19 C. Scott Ananian wrote:
Attached is my first draft of a patch to implement RDNSS-in-Router
Advertisements support for IPv6 (
http://tools.ietf.org/html/draft-jeong-dnsop-ipv6-dns-discovery-12 )
as implemented in radvd ( http://www.litech.org/radvd/ ). It
On Saturday 23 June 2007 01:26:19 C. Scott Ananian wrote:
+struct rdns6_info {
+ rwlock_tlock;
+ struct timer_list expiry_timer;
+ struct rdns6_entry *rdnss_list;
+ struct inet6_dev * in6_dev; /* back pointer for netlink notify */
+
On Saturday 23 June 2007 02:09:18 C. Scott Ananian wrote:
diff -ruHpN -X dontdiff linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h
linux-2.6.22-rc5/include/net/ip6_rdnss.h
--- linux-2.6.22-rc5-orig/include/net/ip6_rdnss.h1969-12-31
19:00:00.0 -0500
+++
On Saturday 30 June 2007 13:47:35 Török Edvin wrote:
When the interface is down (or driver removed), the BroadCom 44xx card remains
powered on, and both its MAC and PHY is using up power.
This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
is halted, and does a partial
On Saturday 30 June 2007 22:38:46 [EMAIL PROTECTED] wrote:
This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix problems related to working of different ports in
multi Port card.
Signed-off by:
On Saturday 30 June 2007 22:38:47 [EMAIL PROTECTED] wrote:
These changes allow driver close routine to be called during module unload,
to clean-up buffers and other software resources, flush queues etc. Also,
hardware is reset to pristine state.
Signed-off-by: Dhananjay Phadke [EMAIL
On Sunday 01 July 2007 00:03:01 Lennert Buytenhek wrote:
On Sat, Jun 30, 2007 at 11:53:25PM +0200, Michael Buesch wrote:
When the interface is down (or driver removed), the BroadCom 44xx card
remains
powered on, and both its MAC and PHY is using up power.
This patch makes
On Sunday 01 July 2007 04:43:27 [EMAIL PROTECTED] wrote:
This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix problems related to working of different ports in
multi Port card.
Signed-off by:
On Sunday 01 July 2007 01:17:34 Lennert Buytenhek wrote:
More or less. You can't add the resistances like that, since the
bus isolation chip buffers the IDSEL signal, but it is correct that
if the host's IDSEL resistor is larger than a certain value, the
combination of the resistive coupling
On Sunday 01 July 2007 14:49:23 Török Edvin wrote:
On 6/30/07, Stephen Hemminger [EMAIL PROTECTED] wrote:
This is a non-standard formatting for comments, please follow
Coding style:
Thanks, I have updated the patch.
When the interface is down (or driver removed), the BroadCom 44xx
On Sunday 01 July 2007 17:00:06 Lennert Buytenhek wrote:
On Sun, Jul 01, 2007 at 12:23:16PM +0200, Michael Buesch wrote:
More or less. You can't add the resistances like that, since the
bus isolation chip buffers the IDSEL signal, but it is correct that
if the host's IDSEL resistor
On Sunday 01 July 2007 17:00:06 Lennert Buytenhek wrote:
A multimeter should do the trick, but I would advise against this
if you're not totally comfortable with hacking hardware.
Ok, the resistor on the board is 100ohm, which is too big
according to the docs of the extender.
So what I tried is
On Sunday 01 July 2007 20:56:01 [EMAIL PROTECTED] wrote:
These changes allow driver close routine to be called during module unload,
to clean-up buffers and other software resources, flush queues etc. Also,
hardware is reset to pristine state.
Signed-off-by: Dhananjay Phadke [EMAIL
On Tuesday 03 July 2007 00:02:57 Kok, Auke wrote:
well, FWIW when I started looking at adding these flags I looked in various
subsystems in the kernel and picked an implementation that suited. Guess what
pci.h has? ...:
unsigned int msi_enabled:1;
unsigned int msix_enabled:1;
On Thursday 31 August 2006 19:12, Jean Tourrilhes wrote:
On Thu, Aug 31, 2006 at 03:32:18PM +0200, Johannes Berg wrote:
On Tue, 2006-08-29 at 17:56 -0700, Jean Tourrilhes wrote:
o modulation
o long/short retry
o relative power saving.
I strongly
On Friday 01 September 2006 17:28, Larry Finger wrote:
Michael,
This patch includes the board revision in the chip_id printk for the ssb
version of bcm43xx-d80211
and is meant to be applied to wireless-dev. As we have seen, behavior of the
chips can be dependent
on the rev level, thus
On Saturday 02 September 2006 00:10, Jean Tourrilhes wrote:
On Fri, Sep 01, 2006 at 08:55:48PM +0200, Michael Buesch wrote:
Note that one thing that worry me with your approach is
footprint. I've used various embedded devices over the years, such as
the Gumstix (4MB Flash
On Tuesday 05 September 2006 19:58, Larry Finger wrote:
Michael,
Based on user reports and my own experiences, the current problems with
NETDEV WATCHDOG tx timeouts,
and the device just falling over do not happen when periodic work is not
preemptible. These problems
seem to affect
Hi John,
Please do
git pull git://bu3sch.de/wireless-dev.git fixes-for-linville
This will pull a ssb fix I forgot to send upstream
via patches.
http://bu3sch.de/git?p=wireless-dev.git;a=commitdiff;h=e29495e14131be28da4fb8bf8a2615fd3f625764
drivers/misc/ssb.c |
On Wednesday 06 September 2006 22:55, John W. Linville wrote:
On Thu, Aug 31, 2006 at 04:00:05PM +0200, Johannes Berg wrote:
On Thu, 2006-08-31 at 06:51 -0700, Jouni Malinen wrote:
I don't know about the others, but long/short retry limits have users
(e.g., Host AP driver) and these
On Thursday 07 September 2006 03:34, Larry Finger wrote:
John,
Please apply this patch by Martin Langer to wireless-2.6. It must follow the
patch to Add firmware
version printout to wireless-2.6 (bcm43xx-softmac). As originally submitted,
the patch was
appropriate for an obsolete
On Friday 08 September 2006 11:42, Erik Mouw wrote:
On Thu, Sep 07, 2006 at 01:17:05PM -0500, Larry Finger wrote:
I think I have a fix for the bcm43xx bug that leads to NETDEV WATCHDOG tx
timeouts and would like it
to get as much testing as possible as this bug affects V2.6.18-rcX. If the
On Thursday 07 September 2006 20:17, Larry Finger wrote:
Hi all,
I think I have a fix for the bcm43xx bug that leads to NETDEV WATCHDOG tx
timeouts and would like it
to get as much testing as possible as this bug affects V2.6.18-rcX. If the
problem is truly
fixed, I hope to get the fix
On Thursday 07 September 2006 15:21, Larry Finger wrote:
Michael Buesch wrote:
On Thursday 07 September 2006 03:34, Larry Finger wrote:
+ return -EPERM;
+
you want to take the spinlock lock here, too.
Obviously, I copied the wrong model. Is it correct that one should take
for hours at the moment!
I tested this patch and it works. Thanks very much, you saved me hours. ;)
John (Jiri), please apply this one.
Acked-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/wep.c
===
--- wireless
On Friday 08 September 2006 15:25, Larry Finger wrote:
Michael Buesch wrote:
On Thursday 07 September 2006 20:17, Larry Finger wrote:
Hi all,
I think I have a fix for the bcm43xx bug that leads to NETDEV WATCHDOG tx
timeouts and would like it
to get as much testing as possible
On Tuesday 12 September 2006 01:59, John W. Linville wrote:
+ value16 = bcm43xx_shm_read16(bcm, BCM43xx_SHM_SHARED,
+ BCM43xx_UCODE_REVISION);
+
+ dprintk(KERN_INFO PFX Microcode rev 0x%x, pl 0x%x
+ (20%.2i-%.2i-%.2i %.2i:%.2i:%.2i)\n,
On Wednesday 13 September 2006 04:51, Daniel Drake wrote:
Hi,
I'm working on support for hardware-based frame decryption in zd1211rw.
While doing so I encountered some strange behaviour in ieee80211 which
I'm wondering if someone can clarify. Alternatively if someone could
just confirm
On Wednesday 13 September 2006 00:06, Larry Finger wrote:
Martin Langer wrote:
Why not writing both (ucode rev and driver version)? Something like
from version 4.x binary drivers (rev0x128).\n
BTW, if anybody needs the relationship between ucode revsion and driver
version
On Wednesday 13 September 2006 04:25, Larry Finger wrote:
Michael,
I still have not gotten a network guru to answer any questions about
synchronize_net, but I have been testing the patch below:
I'd say this is racy.
Did you test this on SMP?
Index:
On Wednesday 13 September 2006 15:25, Larry Finger wrote:
Michael Buesch wrote:
On Wednesday 13 September 2006 04:25, Larry Finger wrote:
Michael,
I still have not gotten a network guru to answer any questions about
synchronize_net, but I have been testing the patch below:
I'd say
On Wednesday 13 September 2006 15:49, Michael Buesch wrote:
On Wednesday 13 September 2006 15:25, Larry Finger wrote:
Michael Buesch wrote:
On Wednesday 13 September 2006 04:25, Larry Finger wrote:
Michael,
I still have not gotten a network guru to answer any questions about
On Thursday 14 September 2006 00:35, Daniel Drake wrote:
Michael Buesch wrote:
Does it strip ICV and FCS?
The driver always strips FCS (unconditionally).
The device does not strip ICV even when hardware decryption is in use,
it gets included at the end of the frame, and I guess we
On Saturday 16 September 2006 01:50, mabbas wrote:
I see your point here, although some one will file some bugs against the
driver about showing G while associating with B-mode AP. By the way how
can you figure if the AP is B/G other than the rates?
I don't think this will happen.
This never
On Saturday 23 September 2006 06:08, Larry Finger wrote:
Recent changes in the setup for preemptible periodic work fixed most
of the problems with NETDEV watchdog timeouts; however, some variants
of the bcm43xx device still had the problem. These were fixed by setting
the parameter
On Saturday 23 September 2006 21:06, Larry Finger wrote:
Michael Buesch wrote:
On Saturday 23 September 2006 06:08, Larry Finger wrote:
Recent changes in the setup for preemptible periodic work fixed most
of the problems with NETDEV watchdog timeouts; however, some variants
of the bcm43xx
On Saturday 23 September 2006 22:05, Larry Finger wrote:
Michael Buesch wrote:
Well, even _if_ mac_suspend takes a few milliseconds (which it
does not), it would not trigger the watchdog.
I measured the time it takes to execute the various works
and based the badness selection
On Sunday 24 September 2006 08:18, Benjamin Herrenschmidt wrote:
On Sat, 2006-09-23 at 23:45 -0400, Daniel Drake wrote:
Benjamin Herrenschmidt wrote:
Oh and I don't care about it works in dscape stack sort of crap I
regulary get. I want something that
works with upstream kernels. That
On Sunday 24 September 2006 10:12, Benjamin Herrenschmidt wrote:
So what are the chances of getting this dscape stack merged, let's
say... for 2.6.19 ? Or we'll get yet another full release with barely
working wireless ?
I don't think it's possible to happen for 2.6.19.
Ealiest
On Sunday 24 September 2006 17:34, Daniel Drake wrote:
Michael Buesch wrote:
Well. Works For Me (tm).
If there is some bug for you in current mainline, it needs to
be fixed. But I can't fix something I am not able to reproduce and
don't know what happens.
Take a look at the logs
On Monday 25 September 2006 00:43, Daniel Drake wrote:
This patch adds a host_strip_iv_icv flag to ieee80211 which indicates that
ieee80211_rx should strip the IV/ICV/other security features from the payload.
This saves on some memmove() calls in the driver and seems like something that
On Tuesday 26 September 2006 01:59, Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
From: Michael Buesch [EMAIL PROTECTED]
This fixes eeprom read on big-endian architectures.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton
On Tuesday 26 September 2006 17:59, Jeff Garzik wrote:
Michael Buesch wrote:
On Tuesday 26 September 2006 01:59, Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
From: Michael Buesch [EMAIL PROTECTED]
This fixes eeprom read on big-endian architectures.
Signed-off-by: Michael Buesch
On Tuesday 26 September 2006 18:08, Jeff Garzik wrote:
Michael Buesch wrote:
No it isn't. There are lots of other parameters in the ssb SPROM.
And most of them are _not_ in bigendian.
I think we also read the PHYport or something in b44.
See bcm43xx or the ssb module for the rest
On Tuesday 26 September 2006 19:00, Jeff Garzik wrote:
Michael Buesch wrote:
#ifdef BIG_ENDIAN
bp-phy_addr = eeprom[91] 0x1f;
#else
bp-phy_addr = eeprom[90] 0x1f;
#endif
False. It's already fixed endian. It's just not the endian you like.
Jeff, come on...
Read Johannes
On Tuesday 26 September 2006 19:49, Francois Romieu wrote:
Johannes Berg [EMAIL PROTECTED] :
[...]
Now, arguably the correct fix would be to make the b44_read_eeprom
routine read an array of u16 as stored, and then use byte shifting
everywhere to fix up for the fact that Broadcom stores
This fixes some race conditions in the WirelessExtension
handling and association handling code.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
Hi John,
Please apply this fo wireless-2.6 and push it with your
next push of bugfixes.
There are other theoretical raceconditions possible
On Wednesday 27 September 2006 18:18, Larry Finger wrote:
Michael Buesch wrote:
This fixes some race conditions in the WirelessExtension
handling and association handling code.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This patch doesn't apply.
Oh, linville merged
On Thursday 28 September 2006 06:09, Larry Finger wrote:
Michael Buesch wrote:
On Wednesday 27 September 2006 18:18, Larry Finger wrote:
Michael Buesch wrote:
This fixes some race conditions in the WirelessExtension
handling and association handling code.
Signed-off-by: Michael Buesch
On Thursday 28 September 2006 16:37, Dan Williams wrote:
On Thu, 2006-09-28 at 16:27 +0200, Johannes Berg wrote:
On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote:
I'd buy that argument. When the driver gets the deauth message,
shouldn't it be sending an IWAP 00:00:00:00:00:00
On Thursday 28 September 2006 16:52, Dan Williams wrote:
On Thu, 2006-09-28 at 16:43 +0200, Michael Buesch wrote:
On Thursday 28 September 2006 16:37, Dan Williams wrote:
On Thu, 2006-09-28 at 16:27 +0200, Johannes Berg wrote:
On Thu, 2006-09-28 at 10:19 -0400, Dan Williams wrote
On Thursday 28 September 2006 17:16, Larry Finger wrote:
Dan Williams wrote:
On Thu, 2006-09-28 at 16:43 +0200, Michael Buesch wrote:
On Thursday 28 September 2006 16:37, Dan Williams wrote:
On Thu, 2006-09-28 at 16:27 +0200, Johannes Berg wrote:
On Thu, 2006-09-28 at 10:19 -0400, Dan
On Wednesday 27 September 2006 15:55, Johannes Berg wrote:
On Wed, 2006-09-27 at 15:57 +0200, [EMAIL PROTECTED] wrote:
Also I wonder what should be the max mtu.
2304, I think, as that's
synonym sMaxMsduLng Integer = 2304; /* max octets in an MSDU */
But maybe I'm interpreting the spec
On Thursday 28 September 2006 19:04, Larry Finger wrote:
Jason Lunz wrote:
On Thu, Sep 28, 2006 at 10:52:24AM -0500, Larry Finger wrote:
I had very good luck with my first AP, a Linksys WRT54G V1, that I
bought a second when the power supply failed in the first. Little did
I know that a
features include support for the new v4 firmware.
I also did my homework to get better support for OpenWRT
devices in ssb.
The list of pulled changesets is:
Michael Buesch:
ssb: Abstract bus accesses.
bcm43xx-d80211: convert to ssb abstract bus access API
bcm43xx-d80211: Don't
On Tuesday 03 October 2006 05:44, Larry Finger wrote:
Michael Buesch wrote:
Hi John,
Please pull from my tree
git pull http://bu3sch.de/git/wireless-dev.git for-linville
This will pull various bugfixes and feature improvements.
Most noteably it will pull a bugfix for a crash
On Tuesday 03 October 2006 14:36, Martin Langer wrote:
On Tue, Oct 03, 2006 at 01:58:33PM +0200, Michael Buesch wrote:
On Tuesday 03 October 2006 05:44, Larry Finger wrote:
kernel: ssb: Core 0 found: cc 0800, rev 02, vendor 4243
kernel: ssb: Core 1 found: cc 0812, rev 04, vendor 4243
On Tuesday 03 October 2006 16:36, Larry Finger wrote:
Michael Buesch wrote:
kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date
2000-14-248
29:46:18
Uhm, which firmware are you running?
The softmac version reports the following (The loaded messages
On Tuesday 03 October 2006 17:12, Martin Langer wrote:
On Tue, Oct 03, 2006 at 04:48:04PM +0200, Michael Buesch wrote:
On Tuesday 03 October 2006 16:36, Larry Finger wrote:
Michael Buesch wrote:
kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date
2000-14-248
Hi John,
I updated the for-linville branch of my tree with one important
bugfix and a small cleanup.
In case you didn't pull, yet, this will pull all changes of my previous
pull request plus the following two.
bcm43xx-d80211: Wait for the firmware to respond, before we read revision codes.
On Monday 09 October 2006 19:03, David Kimdon wrote:
This flag is unused by all in tree drivers. Furthermore, the way that
it is documented is not consistent with the way it is actually used by
ieee80211.c. The original attempt appears to be something to do with
adding extra header room for
On Tuesday 10 October 2006 05:14, Jory A. Pratt wrote:
http://home.nctv.com/anarchy/dscape-clean.jpg
That's hardly readable.
But which firmware are you running? v4.x by chance?
--
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
On Tuesday 10 October 2006 15:45, David Kimdon wrote:
On Tue, Oct 10, 2006 at 12:00:12PM +0200, Michael Buesch wrote:
On Monday 09 October 2006 19:03, David Kimdon wrote:
This flag is unused by all in tree drivers. Furthermore, the way that
it is documented is not consistent with the way
On Tuesday 10 October 2006 16:23, Jory A. Pratt wrote:
Michael Buesch wrote:
On Tuesday 10 October 2006 05:14, Jory A. Pratt wrote:
http://home.nctv.com/anarchy/dscape-clean.jpg
That's hardly readable.
But which firmware are you running? v4.x by chance?
Just
Extend ieee80211_hw's extra_hdr_room to be a bytecount for
a device specific TX header instead of being a hardcoded
0/2 byte choice.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
diff --git a/include/net/d80211.h b/include/net/d80211.h
index a80f48b..9e9709f 100644
--- a/include/net/d80211.h
1 - 100 of 529 matches
Mail list logo
