Re: Kernel NULL pointer when loading bcm43xx-mac80211 with fwpostfix = .fw4
On Sat, 2007-04-07 at 12:44 -0500, Larry Finger wrote: My bad. As shown above, I had white space around the equals - a no-no. Removing it fixed the problem. The examples both of you showed gave me the clue. Interesting. So you really had three parameters: fwpostfix, = and .fw4. I guess that it fell over parsing the = one but I'm not inclined to try right now. Maybe I'll look later. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
On Sun, 2007-04-08 at 03:42 -0500, John H. wrote: What do I do? Apply Larry's patches. I don't remember the URL and can't find it easily right now, you'll find it with some searching on this mailing list. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
On Sun, 2007-04-08 at 04:05 -0500, John H. wrote: Thanks. http://www.mail-archive.com/bcm43xx-dev@lists.berlios.de/msg03201.html That's not the one I was thinking of, does it apply? Look for his combined patches. I am assuming that one is enough for the speed difference? Don't really know. Will these patches be in next kernel releases? Yeah, should already be if you use .21-rc6 or so. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
Johannes Berg wrote: On Sun, 2007-04-08 at 03:42 -0500, John H. wrote: What do I do? Apply Larry's patches. I don't remember the URL and can't find it easily right now, you'll find it with some searching on this mailing list. johannes ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ftp://lwfinger.dynalias.org/patches this is where you can find all the patches that you should be using at any given time that are not included in mainline kernel or will not be included into mainline before final is released for 2.6.21. Jory ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Kernel NULL pointer when loading bcm43xx-mac80211 with fwpostfix = .fw4
Johannes Berg wrote: On Sat, 2007-04-07 at 12:44 -0500, Larry Finger wrote: My bad. As shown above, I had white space around the equals - a no-no. Removing it fixed the problem. The examples both of you showed gave me the clue. Interesting. So you really had three parameters: fwpostfix, = and .fw4. I guess that it fell over parsing the = one but I'm not inclined to try right now. Maybe I'll look later. I posted the oops on LKML at 7:27PM CST on Saturday and received a fix 2.5 hours later (http://www.ussg.iu.edu/hypermail/linux/kernel/0704.0/2750.html). With that change, it generates an error and refuses to load the offending module, but no oops. I'm not surprised that a solution was prepared; however, the timing was very surprising. Imagine how long it would have taken Micro$oft to produce a fix! Too bad Open Source is such a problem for the world. ;-) Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: OpenBSD bcw: Possible GPL license violation issues
On Sunday 08 April 2007 15:27, Reyk Floeter wrote: You either totally misinterpreted my statements or you just want to spread the FUD that every OpenBSD developer is mind-controlled by Theo. I involved Theo _after_ I denied the various requests to change the license of my driver because the various people didn't stop to repeat their requests. You involved lawyers to question my code. Instead of attacking developers of non-GPL free software, you should point your lawyers into another direction to think about ways to include GPL-compatible BSD/ISC code in the Linux kernel without the need for relicensing it. Talk to the Linux maintainers to change this stupid Dual GPL/* policy. It is your choice, you can also rewrite the OpenHAL and take my code as a reference. The copyright does not protect the idea of the implementation or the algorithms. Feel free to read my code, interpret it and express it differently. Excuse my ignorance, please, but I don't see where the real problem is. What's the problem with taking openHAL and putting it into the yet to be written GPLed linux atheros driver, while preserving your copyright notices. I don't see how this could violate the BSD license. Such stuff is going on day by day. One good example of BSD code put into code with another license was MS with the NT TCP stack. At least of my knowledge that was the FreeBSD stack, until they rewrote it. So, what's the problem, really? Create a derivative work, where the original openHAL parts are still de-facto BSD licensed, but the rest is GPLed. From my point of view GPL software is non-free because I cannot simply reuse it in my code. It may work within the Linux world, but everybody else is restricted from using it. This is especially a problem when we depend on the Linux drivers as the only reference to write drivers for OpenBSD. Well, so is the license. Put your work under the GPL and you are free to use the code. (Or alternatively ask the copyright holder(s) to relicense). -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: OpenBSD bcw: Possible GPL license violation issues
Hello, Reyk! Quoting Reyk Floeter [EMAIL PROTECTED]: I'm sure that somebody forwarded the mails from our private discussions to you where I clearly denied the requests to change the license of my driver. I do not believe in dual licensing, and it would make my driver less free. It does not add a benefit for us but it does introduce additional problems. I don't want to take care of GPL licensing issues, and I do not want to distinguish between BSD/ISC code on the one hand and GPL code on the other hand. [skip] But you make an idiot out of me You either totally misinterpreted my statements or you just want to spread the FUD that every OpenBSD developer is mind-controlled by Theo. I involved Theo _after_ I denied the various requests to change the license of my driver because the various people didn't stop to repeat their requests. You involved lawyers to question my code. OK, I appreciate your explanation. Indeed, I knew only a part of the story, and what I knew is very different from what you are writing now. I did avoid your name and the words like mind-controlled in the original post. I'm sorry that your name was mentioned in the discussion and that you are feeling uneasy about my comments. If you re-read my post, you'll see that I was actually sympathizing with you. I would really like to stop this thread, because it's watched by too many people, and any wrong word can do more damage. I do hope that we'll cooperate on the blob-free Atheros driver. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] mac80211: Report correct wireless statistics
Michael Wu wrote: On Sunday 08 April 2007 18:26, Larry Finger wrote: Link Quality=216/146 Signal level=-197 dBm Noise level=-63 dBm Is this before or after your bcm43xx-mac80211: Fix error in initiallizing max RSSI and max signal patch? -Michael Wu This is after that patch. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] mac80211: Report correct wireless statistics
Michael Wu wrote: On Sunday 08 April 2007 19:32, Larry Finger wrote: Michael Wu wrote: Is this before or after your bcm43xx-mac80211: Fix error in initiallizing max RSSI and max signal patch? This is after that patch. So what do the statistics look like without that patch? Link Quality=219/60 Signal level=-200 dBm Noise level=-69 dBm Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
John H. wrote: Thanks. I was looking for some binary solution for now, as my fedora kernel is Linux laptop 2.6.20-1.2933.fc6 #1 SMP Mon Mar 19 11:38:26 EDT 2007 i686 i686 i386 GNU/Linux And I have stopped compiling own kernels due to lack of time. However, it seems that is not possible. Within the rules of new kernel releases - no. If you don't build new kernels, you will have to wait until Fedora issues a 2.6.21 kernel. Did you try the 'iwconfig eth1 rate 1M' trick? It should make the performance be usable. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
On Sun, 2007-04-08 at 11:17 -0500, John H. wrote: I was looking for some binary solution for now, as my fedora kernel is Linux laptop 2.6.20-1.2933.fc6 #1 SMP Mon Mar 19 11:38:26 EDT 2007 i686 i686 i386 GNU/Linux And I have stopped compiling own kernels due to lack of time. Why would you rebuild the whole kernel and not just the bcm43xx driver? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: OpenBSD bcw: Possible GPL license violation issues
Your argument has hit slashdot. http://bsd.slashdot.org/article.pl?sid=07/04/07/1618239from=rss -- http://www.coe.neu.edu/~efoss/ http://evanfoss.googlepages.com/ ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[RFC] PHY setup in v4 specs implementation
I'm going to move all v4 workarounds needed for the A and G PHY setup into a
separate file (draft inlined here), as it'll easily get to ~1000 lines, and
I wouldn't really want to make a mess out of _phy.c. These workarounds
are strictly needed for A PHY support (which I'm currently working on)
and could yield as well better performances for G PHY. I'm developing
this just for mac80211, and when I'm done with this patchset I'll drop
my bcm43xx-softmac MAINTAINERS line. Please comment on that before I do. ;)
--
Ciao
Stefano
Index: wireless-dev/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_wa.c
===
--- /dev/null
+++ wireless-dev/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_wa.c
@@ -0,0 +1,398 @@
+/*
+
+ Broadcom BCM43xx wireless driver
+
+ Copyright (c) 2005 Martin Langer [EMAIL PROTECTED],
+ Copyright (c) 2005, 2006, 2007 Stefano Brivio [EMAIL PROTECTED]
+ Copyright (c) 2005, 2006, 2007 Michael Buesch [EMAIL PROTECTED]
+ Copyright (c) 2005, 2006 Danny van Dyk [EMAIL PROTECTED]
+ Copyright (c) 2005, 2006 Andreas Jaggi [EMAIL PROTECTED]
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; see the file COPYING. If not, write to
+ the Free Software Foundation, Inc., 51 Franklin Steet, Fifth Floor,
+ Boston, MA 02110-1301, USA.
+
+*/
+
+static void bcm43xx_wa_papd(struct bcm43xx_wldev *dev)
+{
+ u16 backup;
+
+ backup = bcm43xx_ofdmtab_read16(dev, 0x000E, 12);
+ bcm43xx_ofdmtab_write16(dev, 0x000E, 12, 7);
+ bcm43xx_ofdmtab_write16(dev, 0x000F, 7, 0);
+ bcm43xx_dummy_transmission(dev);
+ bcm43xx_ofdmtab_write16(dev, 0x000E, 12, backup);
+}
+
+static void bcm43xx_wa_auxclipthr(struct bcm43xx_wldev *dev)
+{
+ bcm43xx_phy_write(dev, 0x008E | BCM43xx_PHYROUTE_OFDM_GPHY, 0x3800);
+}
+
+static void bcm43xx_wa_afcdac(struct bcm43xx_wldev *dev)
+{
+ bcm43xx_phy_write(dev, 0x0035, 0x03FF);
+ bcm43xx_phy_write(dev, 0x0036, 0x0400);
+}
+
+static void bcm43xx_wa_txdc_offset(struct bcm43xx_wldev *dev)
+{
+ bcm43xx_ofdmtab_write16(dev, 0x000E, 0x0051);
+}
+
+static void bcm43xx_wa_initgains(struct bcm43xx_wldev *dev)
+{
+ bcm43xx_phy_write(dev, 0x001C | BCM43xx_PHYROUTE_OFDM_GPHY, 0x);
+ bcm43xx_phy_write(dev, 0x0020 | BCM43xx_PHYROUTE_OFDM_GPHY,
+ bcm43xx_phy_read(dev, 0x0020 | BCM43xx_PHYROUTE_OFDM_GPHY)
0xFF0F);
+ if (dev-phy-rev = 2)
+ bcm43xx_ofdmtab_write16(dev, 0x000F, 0x000C, 0x1FBF);
+ bcm43xx_radio_write16(dev, 0x0002, 0x1FBF);
+}
+
+static void bcm43xx_wa_divider(struct bcm43xx_wldev *dev)
+{
+ bcm43xx_phy_write(dev, 0x002B, bcm43xx_phy_read(dev, 0x002B) ~ 0x0100);
+ bcm43xx_phy_write(dev, 0x008E, 0x58C1);
+}
+
+static void bcm43xx_wa_gt(struct bcm43xx_wldev *dev)
+{
+ if (dev-phy-rev = 2) {
+ bcm43xx_ofdmtab_write16(dev, 0x0002, 3, 15);
+ bcm43xx_ofdmtab_write16(dev, 0x0002, 4, 31);
+ bcm43xx_ofdmtab_write16(dev, 0x0002, 5, 42);
+ bcm43xx_ofdmtab_write16(dev, 0x0002, 6, 48);
+ bcm43xx_ofdmtab_write16(dev, 0x0002, 7, 58);
+ bcm43xx_ofdmtab_write16(dev, 0x, 0, 19);
+ bcm43xx_ofdmtab_write16(dev, 0x, 1, 19);
+ bcm43xx_ofdmtab_write16(dev, 0x, 2, 19);
+ bcm43xx_ofdmtab_write16(dev, 0x, 3, 19);
+ bcm43xx_ofdmtab_write16(dev, 0x, 4, 21);
+ bcm43xx_ofdmtab_write16(dev, 0x, 5, 21);
+ bcm43xx_ofdmtab_write16(dev, 0x, 6, 25);
+ bcm43xx_ofdmtab_write16(dev, 0x0001, 4, 3);
+ bcm43xx_ofdmtab_write16(dev, 0x0001, 5, 3);
+ bcm43xx_ofdmtab_write16(dev, 0x0001, 6, 7);
+ } else {
+ bcm43xx_ofdmtab_write16(dev, 0x, 0, 19);
+ bcm43xx_ofdmtab_write16(dev, 0x, 1, 19);
+ bcm43xx_ofdmtab_write16(dev, 0x, 2, 19);
+ bcm43xx_ofdmtab_write16(dev, 0x, 3, 19);
+ bcm43xx_ofdmtab_write16(dev, 0x, 4, 21);
+ bcm43xx_ofdmtab_write16(dev, 0x, 5, 21);
+ bcm43xx_ofdmtab_write16(dev, 0x, 6, 25);
+ }
+}
+
+static void bcm43xx_wa_analog(struct bcm43xx_wldev *dev)
+{
+ struct bcm43xx_phy *phy = dev-phy;
+
+ if (phy-rev 2) {
+ if (phy-type == BCM43xx_PHYTYPE_G)
+
Re: [PATCH] mac80211: Report correct wireless statistics
Michael Wu wrote: On Sunday 08 April 2007 20:02, Larry Finger wrote: Link Quality=219/60 Signal level=-200 dBm Noise level=-69 dBm Try the attached patch without your bcm43xx-mac80211: Fix error in initiallizing max RSSI and max signal patch. -Michael Wu Why would I want to do this? If the community agrees on anything, it is that the signal is given in dBm (i.e. a negative number) and that the rssi is a positive number. The firmware in the bcm43xx chips return a quantity that looks like an rssi with a received packet, and bcm43xx_rssi_postprocess turns that into a quantity that looks like dBm. Your patch reverses those designations and mixes up the two quantities. Again I ask Why? Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH 2/3] bcm43xx-mac80211: Fix error path memory leak
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/wireless/mac80211/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c index c0f83b7..d93e219 100644 --- a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c +++ b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c @@ -777,7 +777,7 @@ struct bcm43xx_dmaring * bcm43xx_setup_dmaring(struct bcm43xx_wldev *dev, err = alloc_ringmemory(ring); if (err) - goto err_kfree_meta; + goto err_kfree_txhdr_cache; err = dmacontroller_setup(ring); if (err) goto err_free_ringmemory; @@ -787,6 +787,8 @@ out: err_free_ringmemory: free_ringmemory(ring); +err_kfree_txhdr_cache: + kfree(ring-txhdr_cache); err_kfree_meta: kfree(ring-meta); err_kfree_ring: -- 1.5.1 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH 3/3] bcm43xx-mac80211: Work around 30bit DMA limitation
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]
---
.../net/wireless/mac80211/bcm43xx/bcm43xx_dma.c| 71 ++-
1 files changed, 67 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
index d93e219..51a2def 100644
--- a/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/mac80211/bcm43xx/bcm43xx_dma.c
@@ -525,8 +525,23 @@ static int setup_rx_descbuffer(struct bcm43xx_dmaring
*ring,
return -ENOMEM;
dmaaddr = map_descbuffer(ring, skb-data,
ring-rx_buffersize, 0);
- if (dma_mapping_error(dmaaddr))
+ if (dma_mapping_error(dmaaddr)) {
+ /* ugh. try to realloc in zone_dma */
+ gfp_flags |= GFP_DMA;
+
+ dev_kfree_skb_any(skb);
+
+ skb = __dev_alloc_skb(ring-rx_buffersize, gfp_flags);
+ if (unlikely(!skb))
+ return -ENOMEM;
+ dmaaddr = map_descbuffer(ring, skb-data,
+ring-rx_buffersize, 0);
+ }
+
+ if (dma_mapping_error(dmaaddr)) {
+ dev_kfree_skb_any(skb);
return -EIO;
+ }
meta-skb = skb;
meta-dmaaddr = dmaaddr;
@@ -731,6 +746,7 @@ struct bcm43xx_dmaring * bcm43xx_setup_dmaring(struct
bcm43xx_wldev *dev,
struct bcm43xx_dmaring *ring;
int err;
int nr_slots;
+ dma_addr_t dma_test;
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
if (!ring)
@@ -750,6 +766,32 @@ struct bcm43xx_dmaring * bcm43xx_setup_dmaring(struct
bcm43xx_wldev *dev,
GFP_KERNEL);
if (!ring-txhdr_cache)
goto err_kfree_meta;
+
+ /* test for ability to dma to txhdr_cache */
+ dma_test = dma_map_single(dev-dev-dev,
+ ring-txhdr_cache, sizeof(struct
bcm43xx_txhdr_fw4),
+ DMA_TO_DEVICE);
+
+ if (dma_mapping_error(dma_test)) {
+ /* ugh realloc */
+ kfree(ring-txhdr_cache);
+ ring-txhdr_cache = kcalloc(nr_slots,
+ sizeof(struct
bcm43xx_txhdr_fw4),
+ GFP_KERNEL | GFP_DMA);
+ if (!ring-txhdr_cache)
+ goto err_kfree_meta;
+
+ dma_test = dma_map_single(dev-dev-dev,
+ ring-txhdr_cache, sizeof(struct
bcm43xx_txhdr_fw4),
+ DMA_TO_DEVICE);
+
+ if (dma_mapping_error(dma_test))
+ goto err_kfree_txhdr_cache;
+ }
+
+ dma_unmap_single(dev-dev-dev,
+ dma_test, sizeof(struct bcm43xx_txhdr_fw4),
+ DMA_TO_DEVICE);
}
ring-dev = dev;
@@ -1030,9 +1072,11 @@ static int dma_tx_fragment(struct bcm43xx_dmaring *ring,
const struct bcm43xx_dma_ops *ops = ring-ops;
u8 *header;
int slot;
+ int err;
struct bcm43xx_dmadesc_generic *desc;
struct bcm43xx_dmadesc_meta *meta;
struct bcm43xx_dmadesc_meta *meta_hdr;
+ struct sk_buff *bounce_skb;
#define SLOTS_PER_PACKET 2
assert(skb_shinfo(skb)-nr_frags == 0);
@@ -1062,9 +1106,26 @@ static int dma_tx_fragment(struct bcm43xx_dmaring *ring,
memcpy(meta-txstat.control, ctl, sizeof(*ctl));
meta-skb = skb;
meta-is_last_fragment = 1;
+
meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
- if (dma_mapping_error(meta-dmaaddr))
- goto out_unmap_hdr;
+ /* create a bounce buffer in zone_dma on mapping failure. */
+ if (dma_mapping_error(meta-dmaaddr)) {
+ bounce_skb = __dev_alloc_skb(skb-len, GFP_ATOMIC | GFP_DMA);
+ if (!bounce_skb) {
+ err = -ENOMEM;
+ goto out_unmap_hdr;
+ }
+
+ memcpy(skb_put(bounce_skb, skb-len), skb-data, skb-len);
+ dev_kfree_skb_any(skb);
+ skb = bounce_skb;
+ meta-skb = skb;
+ meta-dmaaddr = map_descbuffer(ring, skb-data, skb-len, 1);
+ if (dma_mapping_error(meta-dmaaddr)) {
+ err = -EIO;
+ goto out_free_bounce;
+ }
+ }
ops-fill_descriptor(ring, desc, meta-dmaaddr,
Re: [PATCH] mac80211: Report correct wireless statistics
Michael Wu wrote: On Sunday 08 April 2007 23:54, Larry Finger wrote: Why would I want to do this? Did it fix the output? With that patch as the only one applied to wireless-dev, I get Link Quality=69/60 Signal level=-37 dBm Noise level=-70 dBm Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Good news on Dell Mini-PCI 1390
Tonight I downloaded the 2.6.20.6 kernel and the combined patch from ftp://lwfinger.dynalias.org/patches . Patched the kernel source and rebooted into the new kernel. I used to get decent speeds with just a regular 2.6.20.5 kernel, but I still used my LAN cable. I dont need it anymore, that patch works great. Thanks to everyone in the bcm43xx devel team. You guys are good =D -Dan ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: bcm-43xx HORRIBLY slow with 4311 card and 2.6.20
I ended up just using the following... http://www.howtoforge.com/kernel_compilation_fedora Can I get a patched version of the bcm43xx source and just compile that? On 4/8/07, David Woodhouse [EMAIL PROTECTED] wrote: On Sun, 2007-04-08 at 11:17 -0500, John H. wrote: I was looking for some binary solution for now, as my fedora kernel is Linux laptop 2.6.20-1.2933.fc6 #1 SMP Mon Mar 19 11:38:26 EDT 2007 i686 i686 i386 GNU/Linux And I have stopped compiling own kernels due to lack of time. Why would you rebuild the whole kernel and not just the bcm43xx driver? -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
