nsmits, it may override the wishes of a driver
that may have very good reasons for disabling transmits. No specific
problems can be blamed directly on this bug, but it may be responsible
for some unexplained behavior.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Fi
processing.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ wireless-2.6/drivers/net/wi
us run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus handling code.
Cc: "John W. Linville" <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-
Ray Lee wrote:
Larry Finger wrote:
Johannes Berg wrote:
Hah, that's a lot more plausible than bcm43xx's drain patch actually
causing this. So maybe somehow interrupts for bcm43xx aren't routed
properly or something...
Ray, please check /proc/interrupts when this happens.
Whe
Johannes Berg wrote:
On Sat, 2006-11-18 at 06:24 -0500, Joseph Fannin wrote:
This sounds like what my laptop was doing in -rc5, though mine
didn't take hours to start acting up.
I *think* it was the MSI troubles, causing interrupts to get
lost forever. Anyway, it went away in -rc6.
Ray Lee wrote:
First off, thanks for all your help.
Second off,
On 11/16/06, Larry Finger <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
>
> If I could figure out a way to make it repeatable, I'd happily do a
blind
> bisect.
[...]
> I'm open to suggestions on how
dev watchdog TX timeouts
changeset: 40965:f5021f3521c2
user:Larry Finger <[EMAIL PROTECTED]>
date:Wed Nov 01 08:15:41 2006 +0500
summary: [PATCH] bcm43xx: fix unexpected LED control values in BCM4303 sprom
I think we can safely rule out a #include addition. The LED cont
Ray Lee wrote:
Larry Finger wrote:
Ray Lee wrote:
Michael Buesch wrote:
On Wednesday 15 November 2006 20:01, Ray Lee wrote:
Suggestions? Requests for even more info?
Yeah, enable bcm43xx debugging.
Sigh, didn't even think to look for that. Okay, enabled and compiling
a new kernel.
us run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus handling code.
Cc: "John W. Linville" <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-
Ray Lee wrote:
Michael Buesch wrote:
On Wednesday 15 November 2006 20:01, Ray Lee wrote:
Suggestions? Requests for even more info?
Yeah, enable bcm43xx debugging.
Sigh, didn't even think to look for that. Okay, enabled and compiling a new
kernel. This will take a few days to trigger, if the
my current copy of wireless-2.6.git does not contain this line, I am
(re)submitting a patch to restore that line.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
==
Adrian Bunk wrote:
The Coverity checker noted that these "if (err)"'s couldn't ever be
true.
It seems the intention was to check the return values of the
bcm43xx_pci_write_config32()'s?
Exactly. This patch sent to wireless-2.6.
Thanks,
Larry
-
To unsubscribe from this list: send the line "
From: Adrian Bunk <[EMAIL PROTECTED]>
The Coverity checker noted that these "if (err)"'s couldn't ever be
true.
It seems the intention was to check the return values of the
bcm43xx_pci_write_config32()'s?
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
g code.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
Please apply this to wireless-2.6 and push it to 2.6.19. It has already
been sent to -stable for inclusion in 2.6.18.3. This patch replaces one
with the same name that was
g code.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: linux-2.6.18/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.18.orig/drivers/net/wireless/bcm4
SoftMAC contains a number of debug-type messages that continue to print
even when debugging is turned off. This patch substitutes dprintkl for
printkl for those lines.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_
Jouni Malinen wrote:
On Thu, Nov 02, 2006 at 09:45:46AM +0100, Johannes Berg wrote:
On Wed, 2006-11-01 at 23:46 -0600, Larry Finger wrote:
Has anyone used this patch, particularly with WPA encryption? When I try it, wpa_supplicant
immediately uses 90+% of the cpu and never actually
Udayan Singh wrote:
Hi,
I wanted to understand the code of d80211 (thanks to James Ketrenos
for the info he provided) and also work in it.
I found that I can get the latest patches regarding the same from :
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
Wireless-2.6 con
In the softmac version of bcm43xx, the core scan logs whether each core is
enabled or disabled. This information is useless as one of the next steps
is to enable all cores. This patch removes this output from the log.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
These ar
These patches modify the rt2x00-d80211 family of drivers to use
the wireless statics added in patch 1.
Signed-Off-By: Larry [EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
===
--- wireless-dev.ori
These patches modify bcm43xx-d80211 to use the wireless statics added in patch
1.
Signed-Off-By: Larry [EMAIL PROTECTED]>
---
Please apply to wireless-dev
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===
--- w
These patches modify adm8211-d80211 to use the wireless statics added in patch
1.
Signed-Off-By: Larry [EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
===
--- wireless-dev.orig/drivers/net/wireles
This patch modifies d80211 to support wireless statistics.
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
---
John,
Please add to wireless-dev.
Larry
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/inclu
This set of patches modifies the d80211 stack and the drivers that use it to support wireless
statistics.
1. Adds the necessary data and code to the d80211 routines.
2. Modifies bcm43xx-d80211 to conform.
3. Modifies adm8211-d80211 to conform.
4. Modifies the rt2x00-d80211 drivers to conform.
Michael Buesch wrote:
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus handling code.
Signed-off-by: Michael
was quite useful
while debugging of periodic work was in progress. Now that this routine
seems to be working correctly, it is time to simplify the code. This
patch keeps the functionality intact, but simplifies the code.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
Plea
In kernel 2.6.19, there is a configuration option that enables the _must_check
logic. This patch adds a check and removes the warning for a pci_enable_device
call in the ipw2200 driver.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/drivers/net/wireless/ipw
In kernel 2.6.19, there is a configuration option that enables the _must_check
logic. This patch adds a check and removes the warning for a pci_enable_device
call in the ipw2100 driver.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/drivers/net/wireless/ipw
John,
I had not responded to Michael's comments as I heard from another user with thousands of these
assertions in his logs, and I have been waiting for his sprom values and hoped to make a single
patch. It is good, however, that you pushed the patch upstream.
John W. Linville wrote:
On Wed,
than
5secs (which is the case for low or no traffic), it will fire
a TX timeout.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
Please apply this patch to wireless-2.6, and push it upstream to 2.6.19.
It seems to have cured _
Michael Buesch wrote:
On Wednesday 18 October 2006 01:12, Daniel Drake wrote:
Larry Finger pointed out a problem with my ieee80211 IV/ICV stripping patch,
which I forgot about. Sorry about that.
The patch readds the frame_ctl assignment which was accidently dropped.
Signed-off-by: Daniel
case of a following switch statement. This patch makes the leds
on the above mentioned interface behave correctly. In addition, it limits
the number of logged messages to 20 for the case of unexpected values in
the sprom locations.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
bcm43xx_
lt;[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
If possible, this patch should be pushed into 2.6.19.
Larry
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 109 +-
wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h | 29 +++
wi
Stefan Rompf wrote:
Am Montag, 9. Oktober 2006 13:49 schrieb Johannes Berg:
Yeah, probably makes sense. Though, maybe not just the band but a set of
channels instead?
Yes, this would allow us to keep the definition of a band out of kernel. But
to distinguish between 802.11 b and g, we'd need
Bin Zhang wrote:
CC [M] drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.o
LD [M] drivers/net/wireless/d80211/bcm43xx/bcm43xx-d80211.o
LD drivers/net/wireless/built-in.o
ld: drivers/net/wireless/d80211/built-in.o: No such file: No such file
or directory
make[3]: *** [drivers/net/wireless
The latest set of changes/fixes for bcm43xx-d80211 are now available as a patch to v2.6.18 code from
ftp://lwfinger.dynalias.org/.
The patch file contains Michael Buesch's changes of 05-Oct-2006. This version can use either V3 or
V4 firmware. It has been compiled and tested on my system.
The
ical. This change adds a new
variable to the ieee80211_device structure that holds the 'seq_ctl' value for
the previous frame. When a new frame repeats the value, the frame is dropped and
the appropriate counter is incremented.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
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
29:46:18
Uhm, which firmware are you running?
The softmac version reports the following (The "l
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 are something
I'm trying.):
kernel: bcm43xx: Firmware: Microcode "bcm43xx
The bcm43xx-softmac software currently fails when running on x86_64 systems
with more than 1GB RAM and one of the card variants with 30-bit DMA addressing.
This patch uses the address extension bits in the hardware to set the correct
DMA mask for the specific card in use.
Signed-off-by: Larry
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 introduced
by an earlier patch to d80211 which changed RX status informat
Jouni Malinen wrote:
TKIP/CCMP are required to use incrementing TSC/PN for each frame. When a
directed IEEE 802.11 frame is not acknowledged, it will be retransmitted
(up to a certain limit). This retransmitted frame will use the same
TSC/PN. However, the duplicate detection routine in the recei
Michael Buesch wrote:
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
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 VxWorks license costs less than the extra memory needed
to run
Michael Wu wrote:
On Thursday 28 September 2006 11:16, Larry Finger wrote:
First of all, my problem is quite likely caused by a buggy AP. It is a
Linksys WRT54G V5, which is one of those with a VxWorks kernel, not Linux.
I have already reported one bug to Linksys, which they have neither
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:
I'd buy that argument. When the driver gets th
Ian McDonald wrote:
On 9/28/06, Larry Finger <[EMAIL PROTECTED]> wrote:
Linus's tree now has a configuration option that prints a warning
whenever
the returned value of any routine is ignored. This patch fixes the
only such
warning for bcm43xx.
Can you tell me how to make this c
Linus's tree now has a configuration option that prints a warning whenever
the returned value of any routine is ignored. This patch fixes the only such
warning for bcm43xx.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm
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 <[EMAIL PROTECTED]>
---
This patch doesn't
Benjamin Herrenschmidt wrote:
I won't try some random other git tree to test things, it's simply not
feasible for me and we need something we can give to distros to backport
so they have something remotely stable (I'm thinking for example about
the upcoming ubuntu edgy which is coming out soon
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.
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_wx.c
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
belongs in the stack as it can be used by bc
From: Michael Buesch <[EMAIL PROTECTED]>
There is a potential race condition in the periodic_work_handler routine
of bcm43xx-softmac. In addition to fixing this condition, the size of code is
reduced by moving the mutex lock outside the if.
Signed-off-by: Larry Finger <[EMAIL
The bcm43xx-softmac driver fails to set two quantities needed for
iwlist to compute wireless quality when scanning. As a result, userland
programs using the quality to determine the best connection fail.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
This patch is intended for wirele
Matthieu CASTET wrote:
Hi,
On Mon, 25 Sep 2006 10:50:00 -0400, John W. Linville wrote:
On Sun, Sep 24, 2006 at 12:40:53PM +0200, Elimar Riesebieter wrote:
My sylog is filled up with thousands of:
Sep 21 18:18:00 aragorn kernel: TKIP: replay detected: \
STA=XX:XX:BB:LL:KK:00 previous TSC
x27;s.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/net/ieee80211/ieee80211_crypt_tkip.c
===
--- wireless-2.6.orig/net/ieee80211/ieee80211_crypt_tkip.c
+++ wireless-2.6/net/ieee80211/ieee80211_crypt_tkip.
David Miller wrote:
From: Larry Finger <[EMAIL PROTECTED]>
Date: Sat, 23 Sep 2006 16:40:15 -0500
The maximum value for MTU is set in include/linux/if_ether.h for all
ethernet-type communications, not in softmac or ieee80211. I doubt
that one could easily change the number. It may be th
Matthieu CASTET wrote:
Hi,
why softmac (and maybe device using linux 80211 stack) can't increase
their mtu above 1500 ?
IRRC 802.11 allow to send bigger frame. Moreover some driver like airo
allow to use mtu biger than 2000.
The maximum value for MTU is set in include/linux/if_ether.h for all
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 the results.
If the 15 or 30 second work is really able to trigger a wa
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 device still had the problem. These were fixed by setting
the
Ray Lee wrote:
Rafael J. Wysocki wrote:
2.6.18 vanilla and 2.6.18 with your patch both lock my system hard
with bcm43xx. I've got an HP/Compaq nx6125 laptop. Symptoms are that
it will associate fine on its own and send traffic to/fro upon ifup,
but when I do an iwconfig, ifdown, ifup to change t
calculating the 'badness' of the upcoming periodic work
is no longer needed; therefore it is removed.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This patch relies on "[PATCH] bcm43xx: fix netdev watchdog timeouts", which
was submitted on 9/14/06. It is
Erik Mouw wrote:
On Fri, Sep 22, 2006 at 08:20:08AM -0500, Larry Finger wrote:
This patch, which was originally sent to John Linville on 9/14/06,
has been taken against 2.6.18. It changes more lines
than would be absolutely necessary to affect the fix; however, it
ends up with this section
Johannes Berg wrote:
On Fri, 2006-09-22 at 08:24 -0500, Larry Finger wrote:
That project is on hold now, but I'm willing to share the information I have and to participate in
further developments.
The database seems useful, maybe nl80211 could subsume the userspace
interface?
That s
Jiri Benc wrote:
Thu, 21 Sep 2006 15:39:40 -0700, mabbas pise:
if the stack handle it then no need to know. When I call
ieee80211_register_hw with driver's channel, rate and txpower info. the
txpower values are overwritten by ieee80211_init_client. I get all the
txpower info from EEPROMin the
compared with 2.6.17.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
This patch, which was originally sent to John Linville on 9/14/06,
has been taken against 2.6.18. It changes more lines
than would be absolutely necessary to affect the fix; however, it
ends up with this section looking e
Andrew Hall wrote:
Unfortunately I spoke too soon.. :-(
The driver no longer appears to fail under load but still fails randomly
with relatively light load:
I don't know if this will help, but NETDEV watchdog timeouts in the bcm43xx driver were fixed by
changing a netif_stop_queue call int
In 2.6.18-rc7, the section that prepares for preemptible periodic work
has two bugs. The first is due to an improper locking sequence that leads
to frozen systems. The second causes netdev watchdog timeouts. Both
are fixed.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This
Erik Mouw wrote:
On Thu, Sep 14, 2006 at 08:28:54AM -0500, Larry Finger wrote:
Please apply this to wireless-2.6. It would be great if this patch were to be
included in 2.6.19.
I suppose you mean 2.6.18?
It would also be nice if your "bcm43xx locks up machine" patch were to
be i
The setup for running long periodic work has a bug that leads to
netdev watchdog tx timeouts. This change eliminates the timeouts.
systems.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Acked-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
Please apply this to wireless-2.6. It wo
Stephen Hemminger wrote:
On Wed, 13 Sep 2006 21:04:02 -0500
Larry Finger <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
On Wed, 13 Sep 2006 15:49:23 +0200
Michael Buesch <[EMAIL PROTECTED]> wrote:
Simple. Reading the code of synchronize_net() and
netif_stop_queue() and th
Stephen Hemminger wrote:
On Wed, 13 Sep 2006 15:49:23 +0200
Michael Buesch <[EMAIL PROTECTED]> wrote:
Simple. Reading the code of synchronize_net() and
netif_stop_queue() and thinking about why it breaks, instead
of committing bugfixes that only substitute one bug by another. ;)
I'll take a look
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 this is racy.
Did you test this on SMP?
No - I don'
Michael,
I still have not gotten a network guru to answer any questions about
synchronize_net, but I have been testing the patch below:
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/driv
Martin Langer wrote:
Why not writing both (ucode rev and driver version)? Something like
"from version 4.x binary drivers (rev>0x128).\n"
BTW, if anybody needs the relationship between ucode revsion and driver
version then he should look at the table here:
http://www.langerland.de
An error message is changed to a printk as the original dprintk would
be optimized away if debugging were not enabled. If the error is triggered,
a more meaningful message is returned.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This patch incorporates Michael's comme
noise
processing in bcm43xx_rx have been completed, and as unused one
is removed.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-2.6.orig/drivers/n
Jeff,
I need help with a networking problem and I hope you can direct me to a guru.
As part of the changes in the bcm43xx driver just prior to 2.6.18, some sections
that are executed periodically were made preemptible to reduce latency. For the
most part, the effort was successful; however the
John W. Linville wrote:
On Sat, Sep 09, 2006 at 11:04:59AM -0500, Larry Finger wrote:
John W. Linville wrote:
OK, I see now. The patch won't apply to the upstream branch at all
due to the open-coded locking patch applied previously.
The problem now is that if I send this up for 2.6.18
ch has
already been applied, thus this one only moves the call to
bcm43xx_periodic_tasks_setup.
Larry
===
This patch fixes an out of sequence step in the bcm43xx_init_board
routine for bcm43xx-softmac.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Index:
John W. Linville wrote:
Either move bcm43xx_periodic_tasks_setup after rng_init, or
delete the periodic work again, if rng_init fails.
Larry, will you be posting another patch to account for these comments?
Yes - coming right after this message.
Larry
-
To unsubscribe from this list: send th
Erik Mouw wrote:
On Fri, Sep 08, 2006 at 08:36:36AM -0500, Larry Finger wrote:
Erik Mouw wrote:
Thanks for the information, pulled wireless-2.6 and recompiling kernel.
If this really fixes the problem, can we try to get it merged before
2.6.18 closes? I don't know if vanilla 2.6.18-rc6
the initial coding was done.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ wireless-2.6/d
John W. Linville wrote:
On Fri, Sep 08, 2006 at 08:47:54PM -0500, Larry Finger wrote:
PLease send this upstream for inclusion in 2.6.18, if possible. This patch
will not work for
wireless-2.6. That patch will be sent to you soon.
Are you saying this will break the upstream branch of
In the bcm43xx driver, the code snippet shown below has a problem. When the synchronize_net
statement is included, once every 200-300 passes through the code, the system will report a NETDEV
WATCHDOG tx timeout for bcm43xx, even when the watchdog timeout is set to 30 sec. When the
synchronize st
-by: Larry Finger <[EMAIL PROTECTED]>
==
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drive
Erik Mouw wrote:
On Fri, Sep 08, 2006 at 11:45:27AM +0200, Michael Buesch wrote:
The crash is fixed in wireless-2.6.
The actual cause of the controller restart not. So at least it
does not crash anymore.
Thanks for the information, pulled wireless-2.6 and recompiling kernel.
If this really fix
Michael Buesch wrote:
The real question is: Why does this patch help?
Let's explain it. We don't stop networking just for fun there.
While executing long preemptible periodic work, we must ensure
that the TX path into the driver is not entered. It's the same
reason why we disable IRQs in the fi
Michael Buesch wrote:
In general, no.
But, for some sysfs attrs it is sufficient to only take
the mutex, because:
* We don't access hardware.
* We don't modify this data in a spinlock-only critical section.
Yes, I know that having two locks does not really fit the
"lock data, not code" model. B
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 into mainline before release of the bug into the
stable series.
& 1161
Remove some dead code from bcm43xx_sysfs.c in 2.6.18-rc6
Signed-off-by: Darren Jenkins <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
=
Index: wireless-2.6/drivers/net/wireless/bcm43xx
d. This version incorporates the
locking revision comments of Michael Buesch.
Thanks,
Larry
This patch prints out the ucode debug status to sysfs. So, users can
watch the microcode status of their hardware.
Signed-off-by: Martin Langer <[EMAIL PROTECTED]>
Signed-off-by: Larry Fin
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 both locks if your code will
touch the hardware, but the
.
Thanks,
Larry
This patch prints out the ucode debug status to sysfs. So, users can
watch the microcode status of their hardware.
Signed-off-by: Martin Langer <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
=
diff --git
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 drivers are currently forced to use a
hack to do
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 BCM4306 rev 2 & 3 chips. Since I changed BADNESS_LIMIT to 20 to disab
ned-off-by: Martin Langer <[EMAIL PROTECTED]>
Acked by Michael Buesch
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/w
in
bcm43xx-softmac were
changed, but was overlooked at that time. The value of bcm->stats.link_quality
computed here is
never used, so it is removed as well.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43
Michael Buesch wrote:
On Monday 04 September 2006 06:38, Larry Finger wrote:
John,
Please queue the following patch for wireless-2.6. It removes some code that was made obsolete by
the wireless statistics changes of several weeks ago, but was not noticed them.
Thanks,
Larry
statistics in bcm43xx-softmac were
changed, but was overlooked at that time. The value of bcm->stats.link_quality computed here is
never used.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43
301 - 400 of 523 matches
Mail list logo
