Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
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 :00:05.0 PCI: Cannot allocate resource region 8 of bridge :00:05.0 or could tsc being marked as unstable have anything to do with the speed of network transfers? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
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 :00:05.0 PCI: Cannot allocate resource region 8 of bridge :00:05.0 or could tsc being marked as unstable have anything to do with the speed of network transfers? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 8:16 PM, Larry Finger <[EMAIL PROTECTED]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 6:18 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] 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 :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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 5:45 PM, Michael Buesch <[EMAIL PROTECTED]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 5:35 AM, <[EMAIL PROTECTED]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 4:49 AM, Michael Buesch <[EMAIL PROTECTED]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 4:49 AM, Michael Buesch [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 5:35 AM, [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 5:45 PM, Michael Buesch [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 6:18 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] 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 :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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 8:16 PM, Larry Finger [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 1:52 AM, Larry Finger <[EMAIL PROTECTED]> 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). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 15, 2007 7:38 AM, <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 15, 2007 7:38 AM, [EMAIL PROTECTED] 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 17, 2007 1:52 AM, Larry Finger [EMAIL PROTECTED] 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). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 15, 2007 2:18 AM, Larry Finger <[EMAIL PROTECTED]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 15, 2007 2:18 AM, Larry Finger [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 9:27 PM, Larry Finger <[EMAIL PROTECTED]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 7:58 PM, Larry Finger <[EMAIL PROTECTED]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 7:58 PM, Larry Finger [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 9:27 PM, Larry Finger [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
