stupid, printing a warning seems appropriate (even if a stack trace is
not needed any more).
--
Will Dyson
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
;
- list-max_val = 8;
+ list-max_val = 11;
}
static void bcm43xx_shm_clear_tssi(struct bcm43xx_wldev *dev)
--
Will Dyson
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Fix bcm43xx_mac_suspend to flush the status register that we wrote to,
instead of the register where the result will appear. Improve the comment.
I was getting many mac suspend failures, now it only happens occasionally.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
---
.../net/wireless/bcm43xx
On 7/16/07, Will Dyson [EMAIL PROTECTED] wrote:
When calculating transmission power for boards without hardware power
control, we fail to set the phy parameters to the new values we have
calculated.
I've been running my box with this patch for the last 24 hours or so,
on top of Michael's git
When calculating transmission power for boards without hardware power
control, we fail to set the phy parameters to the new values we have
calculated.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_phy.c
b/drivers/net/wireless/mac80211
On 5/26/07, Will Dyson [EMAIL PROTECTED] wrote:
On 5/26/07, Michael Wu [EMAIL PROTECTED] wrote:
On Friday 25 May 2007 21:10, Will Dyson wrote:
On 5/25/07, Michael Wu [EMAIL PROTECTED] wrote:
On Friday 25 May 2007 16:37, Will Dyson wrote:
But I've got ton's of these in my log
On 5/26/07, Michael Wu [EMAIL PROTECTED] wrote:
On Friday 25 May 2007 21:10, Will Dyson wrote:
On 5/25/07, Michael Wu [EMAIL PROTECTED] wrote:
On Friday 25 May 2007 16:37, Will Dyson wrote:
But I've got ton's of these in my log:
BUG: at net/mac80211/ieee80211.c:1280 ieee80211_tx
/0x170
[80286fa0] sys_write+0x50/0x90
[8020a1ae] system_call+0x7e/0x83
Kernel: wireless-dev latest from git
Arch: x86-64
My boot log is attached for full hardware information.
--
Will Dyson
[0.00] Linux version 2.6.22-rc2-wifidev0 ([EMAIL PROTECTED]) (gcc
version 4.1.3
On 5/25/07, Michael Wu [EMAIL PROTECTED] wrote:
On Friday 25 May 2007 16:37, Will Dyson wrote:
But I've got ton's of these in my log:
BUG: at net/mac80211/ieee80211.c:1280 ieee80211_tx()
Do you have CONFIG_NET_SCHED on?
I do not have it set in this kernel. Should I?
--
Will Dyson
. Udev will then create a new rule
for the new driver.
Either way, the change will take effect when the driver is reloaded.
This will bite almost everyone who switches drivers. Do we have a FAQ
I can add this to?
--
Will Dyson
___
Bcm43xx-dev mailing list
When doing setup for the dma ring, the txhdr_cache must be freed if there is an
error after it is allocated.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c|4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net
When DMA mapping for RX fails because of the limitation, retry the allocation
in ZONE_DMA. When the network stack passes us TX buffers that cannot be mapped
because of the limitation, allocate a bounce buffer in ZONE_DMA and copy the
packet there.
Signed-off-by: Will Dyson [EMAIL PROTECTED
On 4/5/07, Michael Buesch [EMAIL PROTECTED] wrote:
On Thursday 05 April 2007 06:03, Will Dyson wrote:
@@ -1052,8 +1059,10 @@ static void dma_tx_fragment(struct bcm43xx_dmaring
*ring,
memcpy(meta-txstat.control, ctl, sizeof(*ctl));
meta-skb = skb;
- meta-dmaaddr
From: will [EMAIL PROTECTED](none)
Check result of dma_map_single(), print warnings and propagate errors up the
call stack.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c| 39 +++-
1 files changed, 30 insertions(+), 9
From: Will Dyson [EMAIL PROTECTED]
When DMA mapping for RX fails because of the limitation, retry the allocation
in ZONE_DMA. When the network stack passes us TX buffers that cannot be mapped
because of the limitation, allocate a bounce buffer in ZONE_DMA and copy the
packet there.
Signed-off
On 4/5/07, Will Dyson [EMAIL PROTECTED] wrote:
From: Will Dyson [EMAIL PROTECTED]
Well. Looks like I generated these with a typo in my email. You'd
think I'd learn not to do this stuff late at night
Anyway, this should address the previous comments. It'll always try
GFP_KERNEL first
From: Will Dyson [EMAIL PROTECTED]
When doing setup for the dma ring, the txhdr_cache must be freed if there is an
error after it is allocated.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c|4 +++-
1 files changed, 3 insertions(+), 1
?
Ehm, no. This would always allocate in the DMA zone, even if there
is no requirement to do so (on i386 for example).
Oops. That'll teach me to hurry a patch before I go away. Less than 1G
low memory is the norm.
I'll fix the word-wrap and make sure to run indent as well.
--
Will Dyson
dollars
--
Will Dyson
http://www.lucidts.com/
Linux/Mac/Win consulting
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On 3/28/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Er, are you sure? AFAIR all of the K8 CPUs have something called GART IOMMU,
which is not a real IOMMU, but still it can do its job (to a limited extent,
though).
Current Intel x86_64 chips have no such thing, however.
--
Will Dyson
Check result of dma_map_single(), print warnings and propagate errors up the
call stack.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c| 39
+++-
1 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/net
When the chip is limited to 30bit DMA, allocate RX buffers in ZONE_DMA. When
the network stack passes us TX buffers that cannot be mapped because of the
limitation (with an address 1GB), allocate a bounce buffer in ZONE_DMA and
copy the packet there.
Signed-off-by: Will Dyson [EMAIL PROTECTED
for 30bit dma
without
keeping separate track of it.
Signed-off-by: Will Dyson [EMAIL PROTECTED]
---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c| 70
+---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.h| 49 +++---
2 files changed, 70 insertions(+), 49 deletions
On 3/15/07, Will Dyson [EMAIL PROTECTED] wrote:
On 3/15/07, Michael Buesch [EMAIL PROTECTED] wrote:
On Thursday 15 March 2007 06:09, Will Dyson wrote:
ssb: Sonics Silicon Backplane found on PCI device :02:07.0
bcm43xx_mac80211: Broadcom 4306 WLAN found
Please also turn on ssb
On 1/18/07, Larry Finger [EMAIL PROTECTED] wrote:
For those of you with cards having 30-bit DMA and 1 GB RAM, I think I have
good news.
Hi Larry,
I just tried the patch, and I can confirm that it allows me to run
with my full 3GB!
You rock!
--
Will Dyson
http://www.lucidts.com/
Linux/Mac
On 1/19/07, Larry Finger [EMAIL PROTECTED] wrote:
Will Dyson wrote:
Hi Larry,
I just tried the patch, and I can confirm that it allows me to run
with my full 3GB!
No criticism of your efforts are implied, but it was a lot easier to debug
with a machine having the
problem on my desk
On 11/17/06, Larry Finger [EMAIL PROTECTED] wrote:
Will Dyson wrote:
On 11/15/06, Larry Finger [EMAIL PROTECTED] wrote:
My records show a patch sent for testing on 9/22/06, but I have no record of
when it went to
wireless-2.6; however, on my system it is in wireless-2.6 (Linville
(struct bcm43xx_private *bcm)
--
Will Dyson
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
from the one addressed by your patch from 10/3/06?
--
Will Dyson
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
console setup and can
provide any additional info that would be helpful.
--
Will Dyson
bcm43xx: PHY connected
bcm43xx: PHY disconnected
bcm43xx: PHY connected
bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18 02:36:27)
bcm43xx: Radio turned on
bcm43xx: Chip initialized
bcm43xx: 30-bit DMA
30 matches
Mail list logo
