Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
* Michael Buesch <[EMAIL PROTECTED]> wrote: > On Wednesday 19 December 2007 09:11:02 Larry Finger wrote: > > > > > > or could tsc being marked as unstable have anything to do with the > > > speed of network transfers? > > > > Absolutely not. > > Well, if the clocksource of the machine is unstable it _can_ cause all > kinds of weird things. If you think something is broken in the tsc > stuff, please switch to using another clocksource. also, if it gets marked unstable (which is typical on laptops) then the kernel switches to a more stable, non-TSC clocksource automatically. (hpet or pit) Ingo -- 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
[EMAIL PROTECTED] wrote: > 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 I don't know what these regions are, but I doubt if they have any relation to your problem. > > or could tsc being marked as unstable have anything to do with the > speed of network transfers? Absolutely not. Larry -- 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
[EMAIL PROTECTED] wrote: 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 I don't know what these regions are, but I doubt if they have any relation to your problem. or could tsc being marked as unstable have anything to do with the speed of network transfers? Absolutely not. Larry -- 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
* Michael Buesch [EMAIL PROTECTED] wrote: On Wednesday 19 December 2007 09:11:02 Larry Finger wrote: or could tsc being marked as unstable have anything to do with the speed of network transfers? Absolutely not. Well, if the clocksource of the machine is unstable it _can_ cause all kinds of weird things. If you think something is broken in the tsc stuff, please switch to using another clocksource. also, if it gets marked unstable (which is typical on laptops) then the kernel switches to a more stable, non-TSC clocksource automatically. (hpet or pit) Ingo -- 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
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
[EMAIL PROTECTED] wrote: > > 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). 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 left that back door in the code because I wanted to test b43legacy on a computer that could build a kernel in 20 minutes, as compared to the 12 hours that my old laptop with the device that needs b43legacy. I forgot to clean up the code as I should have. 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. Is it possible for you to test your laptop on another AP? Larry -- 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 Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] wrote: > 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. Requires means requires. > 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. -- Greetings Michael. -- 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 Monday 17 December 2007 23:04:37 [EMAIL PROTECTED] wrote: > 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. Ehm, excuse me. What are you doing exactly? In this thread you told me you have a device which requires b43: > 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"?? -- Greetings Michael. -- 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 Monday 17 December 2007 08:17:58 [EMAIL PROTECTED] wrote: > 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). Are you working with wireless-2.6's #everything branch? -- Greetings Michael. -- 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 Monday 17 December 2007 08:17:58 [EMAIL PROTECTED] wrote: 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). Are you working with wireless-2.6's #everything branch? -- Greetings Michael. -- 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 Monday 17 December 2007 23:04:37 [EMAIL PROTECTED] wrote: 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. Ehm, excuse me. What are you doing exactly? In this thread you told me you have a device which requires b43: 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?? -- Greetings Michael. -- 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 Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] wrote: 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. Requires means requires. 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. -- Greetings Michael. -- 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
[EMAIL PROTECTED] wrote: 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). 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 left that back door in the code because I wanted to test b43legacy on a computer that could build a kernel in 20 minutes, as compared to the 12 hours that my old laptop with the device that needs b43legacy. I forgot to clean up the code as I should have. 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. Is it possible for you to test your laptop on another AP? Larry -- 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 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
[EMAIL PROTECTED] wrote: > 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). 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. Larry -- 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 Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote: > > > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: > > > > Well, the only problem with that is I suspect there are some "newer" > > > > cards that > > > > work better with v3 firmware, although they are supposed to support > > > > both. > > > > Impossible. The firmware is only the MAC. > > OK I should probably mention though that of course it is (in theory!) possible that the card works better with bcm43xx, it just never has happened for all I know. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday, 16 of December 2007, Johannes Berg wrote: > > On Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote: > > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: > > > Well, the only problem with that is I suspect there are some "newer" > > > cards that > > > work better with v3 firmware, although they are supposed to support both. > > Impossible. The firmware is only the MAC. OK Thanks, Rafael -- 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 Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote: > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: > > Well, the only problem with that is I suspect there are some "newer" cards > > that > > work better with v3 firmware, although they are supposed to support both. Impossible. The firmware is only the MAC. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday 16 December 2007 10:22:43 Ingo Molnar wrote: > > * John W. Linville <[EMAIL PROTECTED]> wrote: > > > > It's not that simple. For example, regression testing will be a > > > major PITA if one needs to switch back and forth from the new driver > > > to the old one in the process. > > > > Not really true -- a single system can easily have firmware installed > > for b43, b43legacy, and bcm43xx at the same time and switch back and > > forth between them. > > as long as the version 4 firmware blob is present in the system, will > testers have a fully fluid test- and work-flow when migrating across > from bcm43xx to b43, without any other changes to an existing Linux > installation? (i.e. no udev tweaks, no forced upgrades of components, > etc.) > > Will it Just Work in bisection as well, when a tester's kernel > flip/flops between bcm43xx and b43 - like it does for the other 3000+ > drivers in the kernel? > > Note that we are _NOT_ interested in "might" or "can" scenarios. We are > interested in preserving the _existing_ bcm43xx installed base and how > much of a seemless migration the b43 transition will be. _THAT_ is what > the "no regressions" upstream rule is about, not the "ideal distro" > scenario you outline above. It is YOUR total obligation as a kernel > maintainer to ensure that you dont break old installations. How hard is > that to understand? This is not rocket science. I see no reason for b43 to break, if the firmware is properly installed. In fact, almost all installation related bugreports we receive are caused by missing or incorrectly installed firmware. I would really _like_ to make installing firmware easier or make the whole need for it vanish, but I simply can not at this point. But anyway, installing it is not rocket science, either. The only thing you have to know is where your distribution stores the firmware image files. If you know that it's a matter of invoking one b43-fwcutter command to install it. This process can be automated in the distribution's rpm or deb package scripts. b43lagacy/ssb is completely featured with module autoload support. So if you have firmware installed it will automatically load all required modules and create the network device(s) for it without any user interaction. If that doesn't work, then stupid distributions are shipping braindamaged udev scripts that pin a mac address to a specific driver name (see another mail in this thread). I can _not_ fix this from within the kernel and I will absolutely shift all responsibility and blame for this to the maintainers of the distribution's udev scripts. That's not a b43 specific problem then. Other drivers do break with these scripts, too. -- Greetings Michael. -- 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 Sunday 16 December 2007 03:30:16 Larry Finger wrote: > Michael Buesch wrote: > > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: > >> Well, the only problem with that is I suspect there are some "newer" cards > >> that > >> work better with v3 firmware, although they are supposed to support both. > > > > And I suspect that you are wrong until you show me one. :) > > The BCM4311/1 card used to work better with bcm43xx than it did with b43; > however, since the power > control problem was "solved" in b43, there is very little difference. When I > built my special system > to use the BCM4311 with b43legacy, there was no difference. > > I don't know of any cards that work better with bcm43xx than with b43. Of > course, that is comparing > SoftMAC with mac80211. There is, of course, no comparison. This was about version 3 firmware vs version 4 firmware. I doubt the firmware makes any difference at all. -- Greetings Michael. -- 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
* John W. Linville <[EMAIL PROTECTED]> wrote: > > It's not that simple. For example, regression testing will be a > > major PITA if one needs to switch back and forth from the new driver > > to the old one in the process. > > Not really true -- a single system can easily have firmware installed > for b43, b43legacy, and bcm43xx at the same time and switch back and > forth between them. as long as the version 4 firmware blob is present in the system, will testers have a fully fluid test- and work-flow when migrating across from bcm43xx to b43, without any other changes to an existing Linux installation? (i.e. no udev tweaks, no forced upgrades of components, etc.) Will it Just Work in bisection as well, when a tester's kernel flip/flops between bcm43xx and b43 - like it does for the other 3000+ drivers in the kernel? Note that we are _NOT_ interested in "might" or "can" scenarios. We are interested in preserving the _existing_ bcm43xx installed base and how much of a seemless migration the b43 transition will be. _THAT_ is what the "no regressions" upstream rule is about, not the "ideal distro" scenario you outline above. It is YOUR total obligation as a kernel maintainer to ensure that you dont break old installations. How hard is that to understand? This is not rocket science. Ingo -- 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
[EMAIL PROTECTED] wrote: 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). 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. Larry -- 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
* John W. Linville [EMAIL PROTECTED] wrote: It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. as long as the version 4 firmware blob is present in the system, will testers have a fully fluid test- and work-flow when migrating across from bcm43xx to b43, without any other changes to an existing Linux installation? (i.e. no udev tweaks, no forced upgrades of components, etc.) Will it Just Work in bisection as well, when a tester's kernel flip/flops between bcm43xx and b43 - like it does for the other 3000+ drivers in the kernel? Note that we are _NOT_ interested in might or can scenarios. We are interested in preserving the _existing_ bcm43xx installed base and how much of a seemless migration the b43 transition will be. _THAT_ is what the no regressions upstream rule is about, not the ideal distro scenario you outline above. It is YOUR total obligation as a kernel maintainer to ensure that you dont break old installations. How hard is that to understand? This is not rocket science. Ingo -- 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 Sunday 16 December 2007 03:30:16 Larry Finger wrote: Michael Buesch wrote: On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some newer cards that work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power control problem was solved in b43, there is very little difference. When I built my special system to use the BCM4311 with b43legacy, there was no difference. I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing SoftMAC with mac80211. There is, of course, no comparison. This was about version 3 firmware vs version 4 firmware. I doubt the firmware makes any difference at all. -- Greetings Michael. -- 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 Sunday 16 December 2007 10:22:43 Ingo Molnar wrote: * John W. Linville [EMAIL PROTECTED] wrote: It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. as long as the version 4 firmware blob is present in the system, will testers have a fully fluid test- and work-flow when migrating across from bcm43xx to b43, without any other changes to an existing Linux installation? (i.e. no udev tweaks, no forced upgrades of components, etc.) Will it Just Work in bisection as well, when a tester's kernel flip/flops between bcm43xx and b43 - like it does for the other 3000+ drivers in the kernel? Note that we are _NOT_ interested in might or can scenarios. We are interested in preserving the _existing_ bcm43xx installed base and how much of a seemless migration the b43 transition will be. _THAT_ is what the no regressions upstream rule is about, not the ideal distro scenario you outline above. It is YOUR total obligation as a kernel maintainer to ensure that you dont break old installations. How hard is that to understand? This is not rocket science. I see no reason for b43 to break, if the firmware is properly installed. In fact, almost all installation related bugreports we receive are caused by missing or incorrectly installed firmware. I would really _like_ to make installing firmware easier or make the whole need for it vanish, but I simply can not at this point. But anyway, installing it is not rocket science, either. The only thing you have to know is where your distribution stores the firmware image files. If you know that it's a matter of invoking one b43-fwcutter command to install it. This process can be automated in the distribution's rpm or deb package scripts. b43lagacy/ssb is completely featured with module autoload support. So if you have firmware installed it will automatically load all required modules and create the network device(s) for it without any user interaction. If that doesn't work, then stupid distributions are shipping braindamaged udev scripts that pin a mac address to a specific driver name (see another mail in this thread). I can _not_ fix this from within the kernel and I will absolutely shift all responsibility and blame for this to the maintainers of the distribution's udev scripts. That's not a b43 specific problem then. Other drivers do break with these scripts, too. -- Greetings Michael. -- 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 Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote: On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some newer cards that work better with v3 firmware, although they are supposed to support both. Impossible. The firmware is only the MAC. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday, 16 of December 2007, Johannes Berg wrote: On Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote: On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some newer cards that work better with v3 firmware, although they are supposed to support both. Impossible. The firmware is only the MAC. OK Thanks, Rafael -- 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 Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote: On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some newer cards that work better with v3 firmware, although they are supposed to support both. Impossible. The firmware is only the MAC. OK I should probably mention though that of course it is (in theory!) possible that the card works better with bcm43xx, it just never has happened for all I know. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sonntag, 16. Dezember 2007, Rafael J. Wysocki wrote: > On Saturday, 15 of December 2007, John W. Linville wrote: > > On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: > > > On Friday, 14 of December 2007, Michael Buesch wrote: > > > > > > Either distributions have to install it automatically or people simply > > > > have > > > > to read one or two lines of documentation. That's just what I wanted > > > > to say. > > > > > > It's not that simple. For example, regression testing will be a major > > > PITA > > > if one needs to switch back and forth from the new driver to the old one > > > in the > > > process. > > > > Not really true -- a single system can easily have firmware installed > > for b43, b43legacy, and bcm43xx at the same time and switch back and > > forth between them. > > > > Given a functioning udev configuration, the persistent naming even > > works so that your device stays as 'eth1' when switching to and > > fro bcm43xx. > > Well, this last bit doesn't work on my openSUSE 10.3. Honest, guv. ;-) The persistent interface naming rules of udev, at least up to 0.114-2 (current debian unstable), seem to be easily confused if the driver names change for the same MAC address. This issue seems not to be b43 specific, it happens with zd1211rw --> zd1211rw_mac80211 (this one won't show up in mainline kernels), prism54 --> p54pci/ p54usb, out-of-tree RaLink legacy/ serialmonkey (which ignore interface renames through udev completely) --> rt2x00 just as well and I assume that it might also affect sk98lin --> skge/ sky and the upcomming e1000 --> e1000e transitions and similar situations. > > I really think everyone is overstating the problem. > > You might be right. It is of course confusing to the user and might affect remote updates, but it's also easily fixed by removing the generated MAC address mappings and letting udev generate new ones (+ post processing, if needed) during the next boot. > Greetings, > Rafael Regards Stefan Lippers-Hollmann -- 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
Michael Buesch wrote: On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some "newer" cards that work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power control problem was "solved" in b43, there is very little difference. When I built my special system to use the BCM4311 with b43legacy, there was no difference. I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing SoftMAC with mac80211. There is, of course, no comparison. Larry -- 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 Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: > Well, the only problem with that is I suspect there are some "newer" cards > that > work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) -- Greetings Michael. -- 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 Saturday, 15 of December 2007, John W. Linville wrote: > On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: > > On Friday, 14 of December 2007, Michael Buesch wrote: > > > > Either distributions have to install it automatically or people simply > > > have > > > to read one or two lines of documentation. That's just what I wanted to > > > say. > > > > It's not that simple. For example, regression testing will be a major PITA > > if one needs to switch back and forth from the new driver to the old one in > > the > > process. > > Not really true -- a single system can easily have firmware installed > for b43, b43legacy, and bcm43xx at the same time and switch back and > forth between them. > > Given a functioning udev configuration, the persistent naming even > works so that your device stays as 'eth1' when switching to and > fro bcm43xx. Well, this last bit doesn't work on my openSUSE 10.3. Honest, guv. ;-) > I really think everyone is overstating the problem. You might be right. Greetings, Rafael -- 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 Saturday, 15 of December 2007, Michael Buesch wrote: > On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote: > > On Friday, 14 of December 2007, Michael Buesch wrote: > > > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: > > > > > This user did get the following messages in dmesg: > > > > > > > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > > > > >"or load failed.\n", path); > > > > > > > > So the question seems to be why b43 needs version 4, when b43legacy and > > > > bcm43x uses version 3? > > > > > > That's really a question, right? > > > > > > Well. linux-2.4 doesn't work with the linux-2.6 modutils. > > > Windows Vista doesn't work with Windows 98 device drivers. > > > That leads to this assumption: > > > b43 doesn't work with version 3 firmware but needs version 4. > > > > > > Newer drivers supporting newer hardware need newer firmware. > > > > Actually, can you explain why, from the technical point of view, the > > version 4 > > firware is better than version 3, please? > > version 4 is the new firmware released by broadcom. They obviously won't > support and write any version 3 firmware anymore. So we are forced to > switch to version 4 firmware to support the newest hardware (like N-PHY > in the future). It's really as simple as that. I see, thanks. > The difference between v3 and v4 is basically the driver API. It changed > a lot and it is nontrivial to support both v3 and v4 in one driver. > So we decided to stay with v3 for legacy devices and take v4 for any newer > devices. This is reasonable, yes. > We have to live with that crap until someone comes up with an opensource > firmware. :) Well, the only problem with that is I suspect there are some "newer" cards that work better with v3 firmware, although they are supposed to support both. Greetings, Rafael -- 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 Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: > On Friday, 14 of December 2007, Michael Buesch wrote: > > Either distributions have to install it automatically or people simply have > > to read one or two lines of documentation. That's just what I wanted to > > say. > > It's not that simple. For example, regression testing will be a major PITA > if one needs to switch back and forth from the new driver to the old one in > the > process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. Given a functioning udev configuration, the persistent naming even works so that your device stays as 'eth1' when switching to and fro bcm43xx. I really think everyone is overstating the problem. John -- John W. Linville [EMAIL PROTECTED] -- 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 Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote: > On Friday, 14 of December 2007, Michael Buesch wrote: > > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: > > > > This user did get the following messages in dmesg: > > > > > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > > > >"or load failed.\n", path); > > > > > > So the question seems to be why b43 needs version 4, when b43legacy and > > > bcm43x uses version 3? > > > > That's really a question, right? > > > > Well. linux-2.4 doesn't work with the linux-2.6 modutils. > > Windows Vista doesn't work with Windows 98 device drivers. > > That leads to this assumption: > > b43 doesn't work with version 3 firmware but needs version 4. > > > > Newer drivers supporting newer hardware need newer firmware. > > Actually, can you explain why, from the technical point of view, the version 4 > firware is better than version 3, please? version 4 is the new firmware released by broadcom. They obviously won't support and write any version 3 firmware anymore. So we are forced to switch to version 4 firmware to support the newest hardware (like N-PHY in the future). It's really as simple as that. The difference between v3 and v4 is basically the driver API. It changed a lot and it is nontrivial to support both v3 and v4 in one driver. So we decided to stay with v3 for legacy devices and take v4 for any newer devices. We have to live with that crap until someone comes up with an opensource firmware. :) -- Greetings Michael. -- 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 Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote: On Friday, 14 of December 2007, Michael Buesch wrote: On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: This user did get the following messages in dmesg: b43err(dev-wl, Firmware file \%s\ not found or load failed.\n, path); So the question seems to be why b43 needs version 4, when b43legacy and bcm43x uses version 3? That's really a question, right? Well. linux-2.4 doesn't work with the linux-2.6 modutils. Windows Vista doesn't work with Windows 98 device drivers. That leads to this assumption: b43 doesn't work with version 3 firmware but needs version 4. Newer drivers supporting newer hardware need newer firmware. Actually, can you explain why, from the technical point of view, the version 4 firware is better than version 3, please? version 4 is the new firmware released by broadcom. They obviously won't support and write any version 3 firmware anymore. So we are forced to switch to version 4 firmware to support the newest hardware (like N-PHY in the future). It's really as simple as that. The difference between v3 and v4 is basically the driver API. It changed a lot and it is nontrivial to support both v3 and v4 in one driver. So we decided to stay with v3 for legacy devices and take v4 for any newer devices. We have to live with that crap until someone comes up with an opensource firmware. :) -- Greetings Michael. -- 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 Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: On Friday, 14 of December 2007, Michael Buesch wrote: Either distributions have to install it automatically or people simply have to read one or two lines of documentation. That's just what I wanted to say. It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. Given a functioning udev configuration, the persistent naming even works so that your device stays as 'eth1' when switching to and fro bcm43xx. I really think everyone is overstating the problem. John -- John W. Linville [EMAIL PROTECTED] -- 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 Saturday, 15 of December 2007, Michael Buesch wrote: On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote: On Friday, 14 of December 2007, Michael Buesch wrote: On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: This user did get the following messages in dmesg: b43err(dev-wl, Firmware file \%s\ not found or load failed.\n, path); So the question seems to be why b43 needs version 4, when b43legacy and bcm43x uses version 3? That's really a question, right? Well. linux-2.4 doesn't work with the linux-2.6 modutils. Windows Vista doesn't work with Windows 98 device drivers. That leads to this assumption: b43 doesn't work with version 3 firmware but needs version 4. Newer drivers supporting newer hardware need newer firmware. Actually, can you explain why, from the technical point of view, the version 4 firware is better than version 3, please? version 4 is the new firmware released by broadcom. They obviously won't support and write any version 3 firmware anymore. So we are forced to switch to version 4 firmware to support the newest hardware (like N-PHY in the future). It's really as simple as that. I see, thanks. The difference between v3 and v4 is basically the driver API. It changed a lot and it is nontrivial to support both v3 and v4 in one driver. So we decided to stay with v3 for legacy devices and take v4 for any newer devices. This is reasonable, yes. We have to live with that crap until someone comes up with an opensource firmware. :) Well, the only problem with that is I suspect there are some newer cards that work better with v3 firmware, although they are supposed to support both. Greetings, Rafael -- 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 Saturday, 15 of December 2007, John W. Linville wrote: On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: On Friday, 14 of December 2007, Michael Buesch wrote: Either distributions have to install it automatically or people simply have to read one or two lines of documentation. That's just what I wanted to say. It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. Given a functioning udev configuration, the persistent naming even works so that your device stays as 'eth1' when switching to and fro bcm43xx. Well, this last bit doesn't work on my openSUSE 10.3. Honest, guv. ;-) I really think everyone is overstating the problem. You might be right. Greetings, Rafael -- 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 Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some newer cards that work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) -- Greetings Michael. -- 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
Michael Buesch wrote: On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some newer cards that work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power control problem was solved in b43, there is very little difference. When I built my special system to use the BCM4311 with b43legacy, there was no difference. I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing SoftMAC with mac80211. There is, of course, no comparison. Larry -- 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 Sonntag, 16. Dezember 2007, Rafael J. Wysocki wrote: On Saturday, 15 of December 2007, John W. Linville wrote: On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote: On Friday, 14 of December 2007, Michael Buesch wrote: Either distributions have to install it automatically or people simply have to read one or two lines of documentation. That's just what I wanted to say. It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. Given a functioning udev configuration, the persistent naming even works so that your device stays as 'eth1' when switching to and fro bcm43xx. Well, this last bit doesn't work on my openSUSE 10.3. Honest, guv. ;-) The persistent interface naming rules of udev, at least up to 0.114-2 (current debian unstable), seem to be easily confused if the driver names change for the same MAC address. This issue seems not to be b43 specific, it happens with zd1211rw -- zd1211rw_mac80211 (this one won't show up in mainline kernels), prism54 -- p54pci/ p54usb, out-of-tree RaLink legacy/ serialmonkey (which ignore interface renames through udev completely) -- rt2x00 just as well and I assume that it might also affect sk98lin -- skge/ sky and the upcomming e1000 -- e1000e transitions and similar situations. I really think everyone is overstating the problem. You might be right. It is of course confusing to the user and might affect remote updates, but it's also easily fixed by removing the generated MAC address mappings and letting udev generate new ones (+ post processing, if needed) during the next boot. Greetings, Rafael Regards Stefan Lippers-Hollmann -- 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
[EMAIL PROTECTED] wrote: On Dec 14, 2007 11:37 PM, <[EMAIL PROTECTED]> wrote: I'll attach these logs since I can't read much into them. I should do what I say... 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. Larry -- 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
[EMAIL PROTECTED] wrote: 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 No. On my BCM4311/1, my transfer rate peaked at about 12 Mbs with bcm43xx, but increased to 20 Mbs with b43. These tests were done with iperf with a server running running on a second computer connected by wire to my router. These rates are for 802.11g. When my interface was locked at 11 Mbs, the transfer rate was the expected 5.3-5.5 Mbs with both drivers. 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. 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. Larry -- 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 Friday, 14 of December 2007, Michael Buesch wrote: > On Friday 14 December 2007 18:59:10 Ingo Molnar wrote: > > > > * Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > > In my opinion this all is the work of the distributions and not the > > > work of the kernel developers. Distributions have to make sure that > > > everything works after a kernel update. [...] > > > > actually, not. The the task of kernel developers is to KEEP OLD > > DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around > > until eternity, because the new one is just BROKEN. > > What exactly prevents an old distribution from using new b43 > given that they fix their broken udev scripts first? > > (I cannot fix their broken scripts from within the kernel.) Well, we talked about that some time ago, didn't we? The rule is this: if one uses kernel 2.6.x from kernel.org _successfully_ with certain distribution (whatever it is), then one is supposed to be able to take the kernel 2.6.(x+1), install it on that distribution and use it without any major configuration changes. If this rule is not followed, people will stop testing kernel.org kernels and we'll all suffer from that. Now, in my not so humble opinion, switching from bcm43xx to b43 _is_ a major configuration change (I did it, so please don't try to discuss with my experience) and forcing users to do that breaks the rule above. > > Take a look at CONFIG_COMPAT_VDSO for example - one single version of > > glibc was released in a distro that depended on a kernel vDSO bug. So > > we'll keep that aspect of the vDSO perhaps forever. Simple as that. > > Stuff must just work. Whatever it takes. Best is if you add in new stuff > > without the user noticing _ANYTHING_ but that the kernel version bumped. > > If the maintainers of the other 7 million lines of kernel code can get > > this right then the wireless code should be able to do it too. Ok? > > > > all this "distributors will have to sort out the mess" talk is nonsense, > > and i really hope you do not truly believe in that crap. If your > > attitude is prevalent in the wireless development community then it's in > > worse shape than i thought :-( > > Sorry if I didn't chose my wording correctly. But I was only talking > about the development of drivers. It is correct that userspace ABI has > to be preserved, but that is not an issue at all to drivers. > I was talking about things like installing the right firmware for > the new driver. It is the job of the distributors to install the new > firmware when they introduce a new driver. Yes, as far as new distributions are concerned. However, we _want_ kernel.org kernels to work with the old ones too. Yes, WE DO. > It is the job of the distributors to test their userland scripts and > configuration stuff with that driver and fix their stuff. It is _not_ my job > to fix random distribution udev scripts or explaining over and over again to > people how the firmware is installed. Given specific software environment (it may be a home-made system compiled from sources or whatever), if installing a new kernel forces me to reconfigure it in any significant way to obtain the functionality that I previously had, the problem is with the kernel. No less, no more. > Either distributions have to install it automatically or people simply have > to read one or two lines of documentation. That's just what I wanted to say. It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. > Of course it is _my_ job to preserve ABI. I did never want to question that. Greetings, Rafael -- 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
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. Similarly, with BCM4311/2 and newer devices V3 firmware fails. As Michael said "newer drivers supporting newer hardware need newer firmware". Larry -- 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 Friday, 14 of December 2007, Michael Buesch wrote: > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: > > > This user did get the following messages in dmesg: > > > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > > >"or load failed.\n", path); > > > > So the question seems to be why b43 needs version 4, when b43legacy and > > bcm43x uses version 3? > > That's really a question, right? > > Well. linux-2.4 doesn't work with the linux-2.6 modutils. > Windows Vista doesn't work with Windows 98 device drivers. > That leads to this assumption: > b43 doesn't work with version 3 firmware but needs version 4. > > Newer drivers supporting newer hardware need newer firmware. Actually, can you explain why, from the technical point of view, the version 4 firware is better than version 3, please? Rafael -- 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 12:13 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > Ray, I _do_ want to understand what is going on in your machine. > I _have_ to understand it. But I currently do not understand how the > quoted patch could fix modprobe of b43 or rfkill. I'd simply call that > impossible. Then perhaps it is. Perhaps it's a race condition in my userspace where something NetworkManager related is trying to up the interface, I don't know. More below. Regardless, I'm going to have to put off doing more debugging until tomorrow. I've rebooted back into 2.6.23.0 as wireshark doesn't show any packets using 2.6.24-rc3 (the version I've been testing), reported elsewhere, and that's preventing me from doing actual work with my system, as I'm in the middle of trying to enhance a network server for a client. Note, the wireshark issue is very much not a bcm43xx/b43 issue; I'm not trying to lay that at your feet. > So could you please try to reproduce the breakage by reverting that > patch again? Just to make really sure it is this patch fixing the issue > and not just some coincidence. I don't have the patch applied, so that's at least part of the misunderstanding here. All I have is my sequence of "load b43, ssb, nothing happens, unload them, load rfkill, rfkill-input, ssb, b43 and something happens." I could very well be wrong. But I'm at the limit of what I care to know about the b43 driver, and this is where I'm asking for your help. Hopefully tomorrow, I'll be able to build current tip and try this all again, and I'll also try to do it with NetworkManager killed in the background in case it was trying to bring the interfaces up behind my back. > Thanks for your help. Thanks for treating me like an adult. -- 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 Friday 14 December 2007 20:55:43 Ray Lee wrote: > Oh. My. God. > > Michael. I have a degree in Physics. I placed sixth in the world > finals of the ACM Collegiate programming contest in 1999, Cal Poly > Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html > , I'm the guy all the way to the right. ) I ported the 2.4 kernel to a > custom ppc platform, including writing drivers for various hardware on > it ( http://patinc.com ). I'm the guy who did all the software for a > linux-based Voice over IP call center ( > http://broncocommunications.com/ ). Nice. I am one of the main b43 developers and I wrote most of the code. I know most of the code from the top of my head. Besides that my weiner is bigger than yours. :P > To answer your question, it requests the rfkill-input module. But > under the version I'm trying, rfkill-input is not automatically > loaded. It is not an issue. You can even rmmod rfkill-input in FULL operation. It will not disturb the operation, except that an LED stops working. Try it! (I _did_ try it). > I've pointed to the mailing list URL that proves that. So, I > loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't > necessary, I don't know, and I don't care. But once I did that, *then > and only then* did your damn b43 driver start printing out any > messages to dmesg at all, which then let me download the latest > firmware, and continue moving forward. The b43 does print _nothing_ on modprobe. That is _correct_ behaviour. b43 does print the firmware message after "ifconfig up". Might it be possible that this was coincidence and you messed with modprobe rfkill and ifconfig up and finally saw the message? > > You are telling me that I don't understand patches that I sign off > > and I should not take this personally? > > That is challenging. > > I'm saying the patch you signed off on has a side-effect that will fix > my issue. And even if I *were* saying that, the most you should take Ok. So please revert that patch and try to reproduce the breakage. Does that work? > from it is that you are human and sometimes may make mistakes, just I am inhuman. We all know that. (That was a joke that you probably don't understand. But you can google for "bcw vs. bcm43xx" :) ) Ray, I _do_ want to understand what is going on in your machine. I _have_ to understand it. But I currently do not understand how the quoted patch could fix modprobe of b43 or rfkill. I'd simply call that impossible. Impossible because the patch does change a few function called _inside_ of the b43 module. How could that fix load of the b43 module? (Note that we are not changing some modprobe magic like the ID table). So could you please try to reproduce the breakage by reverting that patch again? Just to make really sure it is this patch fixing the issue and not just some coincidence. Thanks for your help. -- Greetings Michael. -- 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 11:38 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Friday 14 December 2007 20:25:39 Ray Lee wrote:
> > > I'm sorry. The patch that _you_ quoted fixes a blinking LED
> > > and nothing else.
> >
> > Well, you're wrong. Sorry, but that's just the way it is. See below.
> >
> > > It does _not_ fix loading of rfkill or b43 in any way.
> > > It does, however, fix loading of rfkill-input. But the b43 module
> > > operation does _not_ depend in any way on the rfkill-input module, except
> > > the tiny LED that doesn't blink if it's not loaded.
> > > I hope you understood now that the thread on bcm43xx-dev was NOT about
> > > your requirement to load rfkill before b43.
> >
> > *AGAIN*, please read your message here, in particular item number
> > seven on Larry's list:
> >
> > https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
> >
> > For the last fscking time, if rfkill and rfkill-input are not loaded,
> > not one line comes out in dmesg when b43 and ssb are loaded. In
> > particular, your pretty little message about needing newer firmware
> > also does not print. So, yeah, not loading rfkill{,-input} *does*
> > cause issues with b43 working, as there's no damn way to find out
> > what's broken!
>
> Guy... .
> I KNOW what the patch above does.
> What do you think does the following line?
> err = request_module("rfkill-input");
> Does it load the "rfkill-input" or the "rfkill" module.
> That's the million dollar question. You only have one try.
Oh. My. God.
Michael. I have a degree in Physics. I placed sixth in the world
finals of the ACM Collegiate programming contest in 1999, Cal Poly
Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html
, I'm the guy all the way to the right. ) I ported the 2.4 kernel to a
custom ppc platform, including writing drivers for various hardware on
it ( http://patinc.com ). I'm the guy who did all the software for a
linux-based Voice over IP call center (
http://broncocommunications.com/ ).
So, *now* do you believe I'm not an idiot?
To answer your question, it requests the rfkill-input module. But
under the version I'm trying, rfkill-input is not automatically
loaded. I've pointed to the mailing list URL that proves that. So, I
loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't
necessary, I don't know, and I don't care. But once I did that, *then
and only then* did your damn b43 driver start printing out any
messages to dmesg at all, which then let me download the latest
firmware, and continue moving forward.
> You are telling me that I don't understand patches that I sign off
> and I should not take this personally?
> That is challenging.
I'm saying the patch you signed off on has a side-effect that will fix
my issue. And even if I *were* saying that, the most you should take
from it is that you are human and sometimes may make mistakes, just
like the rest of us. There's nothing challenging in that statement.
I've provided the bug report as many ways as I can think to. If you
don't agree, then I guess you'll just have to get the bug report from
someone else who can figure out exactly how to sugar coat the message
so that you'll listen to it.
Me, I'm done.
--
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 Friday 14 December 2007 20:25:39 Ray Lee wrote:
> > I'm sorry. The patch that _you_ quoted fixes a blinking LED
> > and nothing else.
>
> Well, you're wrong. Sorry, but that's just the way it is. See below.
>
> > It does _not_ fix loading of rfkill or b43 in any way.
> > It does, however, fix loading of rfkill-input. But the b43 module
> > operation does _not_ depend in any way on the rfkill-input module, except
> > the tiny LED that doesn't blink if it's not loaded.
> > I hope you understood now that the thread on bcm43xx-dev was NOT about
> > your requirement to load rfkill before b43.
>
> *AGAIN*, please read your message here, in particular item number
> seven on Larry's list:
>
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
>
> For the last fscking time, if rfkill and rfkill-input are not loaded,
> not one line comes out in dmesg when b43 and ssb are loaded. In
> particular, your pretty little message about needing newer firmware
> also does not print. So, yeah, not loading rfkill{,-input} *does*
> cause issues with b43 working, as there's no damn way to find out
> what's broken!
Guy... .
I KNOW what the patch above does.
What do you think does the following line?
err = request_module("rfkill-input");
Does it load the "rfkill-input" or the "rfkill" module.
That's the million dollar question. You only have one try.
This patch is NOT about the "rfkill" module. I don't know how
often I have to say that. It is _obvious_.
Let's also quote Larry's sevenths point here, that you referred to
now for the second time:
" (7) If rfkill-input is built as a module, it is not automatically loaded."
I am not sure how I can make this any more clear.
It does load the "rfkill-input" module from within b43.
It does NOT load "rfkill"
It does NOT load "rfkill-input" BEFORE b43 was loaded.
This patch does exactly ONE thing. It does make sure a LED does blink.
Nothing more.
I signed this patch off. So you can be 100% sure I know what it does.
I do NOT sign off patches for which I don't know what they do.
> > > I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> > > development archives.
> >
> > Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
> > reproduce this.
>
> I'm not asking you to do that, this particular bug will be fixed by
> Larry's patch, whether you believe that or not.
Did you try that?
How can b43 load get fixed by a patch that adds a request_module()
to the b43 module? That is a chicken and egg problem!
> > However the fact that this does not happen on older Ubuntu platforms
> > and does not happen on Fedora leads to the conclusion that it
> > is a bug in Hardy Heron that I am not responsible for.
>
> The kernel does not exist in a vacuum. It's the kernel's job to make
> sure it works with properly written userspace. Broken userspace, sure,
> then we can talk about breaking it.
yes properly written userspace.
> > And you also do realise that Hardy Heron is the current development
> > version of Ubuntu? Development versions have bugs.
>
> Oy vay. I'm not an idiot. Yes, it's the current develoment version.
> But tracking the latest kernel.org kernel has in the past required the
> latest develoment version of the distribution, so I upgrade it as
> well.
I am running wireless-2.6 on feisty. So the kernel does _not_ require
an update of the distribution.
q.e.d.
> I'm not blaming it on you. I'm merely reporting a fucking
> incompatibility. Read my messages again from the top, and stop taking
> this all so damn personally, will you?
You are telling me that I don't understand patches that I sign off
and I should not take this personally?
That is challenging.
--
Greetings Michael.
--
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 11:05 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Friday 14 December 2007 19:45:02 Ray Lee wrote:
> > > > One problem related to b43 source code, patch exists, has yet to be
> > > > merged upstream.
> > >
> > > Yeah. A problem preventing a LED from blinking.
> > > That's a real regression Come on. Stop that bullshit.
> >
> > I'm going to say this one last time. If rfkill and rfkill-input aren't
> > manually loaded before sb and b43, not one damn thing comes out in
> > dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to
> > find out that those modules had to be loaded by hand was to go read
> > the bcm43xx-dev archives. Once those were loaded, messages came out in
> > dmesg pointing me to the URL for updated firmware.
>
> I'm sorry. The patch that _you_ quoted fixes a blinking LED
> and nothing else.
Well, you're wrong. Sorry, but that's just the way it is. See below.
> It does _not_ fix loading of rfkill or b43 in any way.
> It does, however, fix loading of rfkill-input. But the b43 module
> operation does _not_ depend in any way on the rfkill-input module, except
> the tiny LED that doesn't blink if it's not loaded.
> I hope you understood now that the thread on bcm43xx-dev was NOT about
> your requirement to load rfkill before b43.
*AGAIN*, please read your message here, in particular item number
seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
For the last fscking time, if rfkill and rfkill-input are not loaded,
not one line comes out in dmesg when b43 and ssb are loaded. In
particular, your pretty little message about needing newer firmware
also does not print. So, yeah, not loading rfkill{,-input} *does*
cause issues with b43 working, as there's no damn way to find out
what's broken!
> > I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> > development archives.
>
> Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
> reproduce this.
I'm not asking you to do that, this particular bug will be fixed by
Larry's patch, whether you believe that or not.
> However the fact that this does not happen on older Ubuntu platforms
> and does not happen on Fedora leads to the conclusion that it
> is a bug in Hardy Heron that I am not responsible for.
The kernel does not exist in a vacuum. It's the kernel's job to make
sure it works with properly written userspace. Broken userspace, sure,
then we can talk about breaking it.
> And you also do realise that Hardy Heron is the current development
> version of Ubuntu? Development versions have bugs.
Oy vay. I'm not an idiot. Yes, it's the current develoment version.
But tracking the latest kernel.org kernel has in the past required the
latest develoment version of the distribution, so I upgrade it as
well.
> > One last thing. I've been nice to you. Please be nice to me.
>
> If you simply stop blaming bugs on me that I am not responsible for
> at all, that is a deal. What about filing a bug at the ubuntu bugzilla?
I'm not blaming it on you. I'm merely reporting a fucking
incompatibility. Read my messages again from the top, and stop taking
this all so damn personally, will you?
--
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 Friday 14 December 2007 19:45:02 Ray Lee wrote: > > > One problem related to b43 source code, patch exists, has yet to be > > > merged upstream. > > > > Yeah. A problem preventing a LED from blinking. > > That's a real regression Come on. Stop that bullshit. > > I'm going to say this one last time. If rfkill and rfkill-input aren't > manually loaded before sb and b43, not one damn thing comes out in > dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to > find out that those modules had to be loaded by hand was to go read > the bcm43xx-dev archives. Once those were loaded, messages came out in > dmesg pointing me to the URL for updated firmware. I'm sorry. The patch that _you_ quoted fixes a blinking LED and nothing else. It does _not_ fix loading of rfkill or b43 in any way. It does, however, fix loading of rfkill-input. But the b43 module operation does _not_ depend in any way on the rfkill-input module, except the tiny LED that doesn't blink if it's not loaded. I hope you understood now that the thread on bcm43xx-dev was NOT about your requirement to load rfkill before b43. > I have complete current userspace as of yesterday's Ubuntu Hardy Heron > development archives. Ok. I will install a copy of Ubuntu Hardy Heron and check if I can reproduce this. However the fact that this does not happen on older Ubuntu platforms and does not happen on Fedora leads to the conclusion that it is a bug in Hardy Heron that I am not responsible for. And you also do realise that Hardy Heron is the current development version of Ubuntu? Development versions have bugs. > One last thing. I've been nice to you. Please be nice to me. If you simply stop blaming bugs on me that I am not responsible for at all, that is a deal. What about filing a bug at the ubuntu bugzilla? PS: Note that Ubuntu is known to break the broadcom driver every now and then. But I can not change that. -- Greetings Michael. -- 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 10:11 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > * Ray Lee <[EMAIL PROTECTED]> wrote: > > > Now I'm going to go off, sit in the sun, sip some coffee, and think > > happy thoughts of kittens playing with yarn for a while. > > ok, and given the time-shift and apparent season-shift i'll sit in the > evening, watch the snowfall and think happy thoughts of kittens Heh :-). Sometimes I feel guilty living in coastal California. But our seasons are more along the lines of fire, flood, earthquake, and riot :-). Ray -- 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
I've run out of time to donate to the kernel today, so I'll keep this short. On Dec 14, 2007 10:22 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > If you have a PCI device probing works as follows: > > > The PCI table is in ssb. So as soon as your kernel detects the PCI device > > > it will load ssb. ssb will register the PCI device. That will trigger > > > an udev event for the contained 802.11 core to get probed. This will load > > > b43. > > > > > > So, I'm not sure where's the issue with my code here. > > > > There's a patch from Larry Finger to address this and other issues. It > > hasn't made it's way fully upstream yet. Please read your message > > here, in particular item number seven on Larry's list: > > > > https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html > > 1) I sent this patch out today for inclusion in the kernel > 2) This is a _completely_ unrelated issue. >It is about "rfkill-input" being not loaded. NOT about >"b43" or "rfkill" not being loaded. [...] > > So, do you want a scorecard on this? > > > > One problem related to b43 source code, patch exists, has yet to be > > merged upstream. > > Yeah. A problem preventing a LED from blinking. > That's a real regression Come on. Stop that bullshit. I'm going to say this one last time. If rfkill and rfkill-input aren't manually loaded before sb and b43, not one damn thing comes out in dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to find out that those modules had to be loaded by hand was to go read the bcm43xx-dev archives. Once those were loaded, messages came out in dmesg pointing me to the URL for updated firmware. I have complete current userspace as of yesterday's Ubuntu Hardy Heron development archives. One last thing. I've been nice to you. Please be nice to me. If you can't manage that, then let another wireless developer take over. You apparently think I'm an idiot. I'm not, and if necessary I could supply a long list of credentials to prove I'm not an idiot. I'd rather you just accepted my emails at face value and spent more effort on trying to see how the bugs could be occurring rather than spending effort on trying to prove that I'm an idiot. Thanks. Ray -- 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 Friday 14 December 2007 18:59:10 Ingo Molnar wrote: > > * Michael Buesch <[EMAIL PROTECTED]> wrote: > > > In my opinion this all is the work of the distributions and not the > > work of the kernel developers. Distributions have to make sure that > > everything works after a kernel update. [...] > > actually, not. The the task of kernel developers is to KEEP OLD > DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around > until eternity, because the new one is just BROKEN. What exactly prevents an old distribution from using new b43 given that they fix their broken udev scripts first? (I cannot fix their broken scripts from within the kernel.) > Take a look at CONFIG_COMPAT_VDSO for example - one single version of > glibc was released in a distro that depended on a kernel vDSO bug. So > we'll keep that aspect of the vDSO perhaps forever. Simple as that. > Stuff must just work. Whatever it takes. Best is if you add in new stuff > without the user noticing _ANYTHING_ but that the kernel version bumped. > If the maintainers of the other 7 million lines of kernel code can get > this right then the wireless code should be able to do it too. Ok? > > all this "distributors will have to sort out the mess" talk is nonsense, > and i really hope you do not truly believe in that crap. If your > attitude is prevalent in the wireless development community then it's in > worse shape than i thought :-( Sorry if I didn't chose my wording correctly. But I was only talking about the development of drivers. It is correct that userspace ABI has to be preserved, but that is not an issue at all to drivers. I was talking about things like installing the right firmware for the new driver. It is the job of the distributors to install the new firmware when they introduce a new driver. It is the job of the distributors to test their userland scripts and configuration stuff with that driver and fix their stuff. It is _not_ my job to fix random distribution udev scripts or explaining over and over again to people how the firmware is installed. Either distributions have to install it automatically or people simply have to read one or two lines of documentation. That's just what I wanted to say. Of course it is _my_ job to preserve ABI. I did never want to question that. -- Greetings Michael. -- 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 Friday 14 December 2007 19:01:51 Ray Lee wrote:
> No, I don't have module autoloading disabled. modprobe-ing b43
> automatically loads ssb. Neither, however, will load rfkill or
> rfkill-input. And if they aren't loaded, then b43/ssb are *completely*
> silent during load. Nothing to dmesg at all.
That is a bug in your distribution. I cannot fix this.
Maybe the module is blacklisted or whatever. This is _not_ a b43 bug.
> > This all works perfectly well on all of my systems. And I never heared
> > such a problem before.
>
> WTF? Please read *YOUR OWN MESSAGE* to the bcm43xx-dev list:
>
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006456.html
>
> I'm going to blame this on you being tired or something, okay? But in
> the meantime, could you *PLEASE* start giving me the benefit of the
> doubt?
The message you quote describes a _completely_ unrelated bug.
Besides that the bug described in the message does _not_ prevent
the device from working. It does _just_ prevent some random LED from
blinking. I'd not call that a big issue.
To say it again: This message was about loading "rfkill-input" _after_
b43 was loaded successfully.
Please carefully read the messages before using them to prove me wrong.
> > If you have a PCI device probing works as follows:
> > The PCI table is in ssb. So as soon as your kernel detects the PCI device
> > it will load ssb. ssb will register the PCI device. That will trigger
> > an udev event for the contained 802.11 core to get probed. This will load
> > b43.
> >
> > So, I'm not sure where's the issue with my code here.
>
> There's a patch from Larry Finger to address this and other issues. It
> hasn't made it's way fully upstream yet. Please read your message
> here, in particular item number seven on Larry's list:
>
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
1) I sent this patch out today for inclusion in the kernel
2) This is a _completely_ unrelated issue.
It is about "rfkill-input" being not loaded. NOT about
"b43" or "rfkill" not being loaded.
> > If you do
> > modprobe b43
> > it will automatically load _all_ required modules.
> > It works perfectly well on my systems.
> > Try it. Simply type "modprobe b43". It will also work for you.
>
> As I've said multiple times earlier in this thread, I did try that and
> it didn't work. Do you believe me now?
Ok, Please find out why it doesn't work.
> > > Hello? I tried that. It failed. What *I'm* talking about here
> > > is that this everyone needs to be aware that this is *not* a drop in
> > > replacement for bcm43xx, and if I'm having problems (not a kernel
> > > hacker, but I make my living writing code), then sheesh, you're gonna
> > > have a flood of people needing hand-holding on this.
> >
> > All problems so far were not related to the b43 sourcecode at all.
> > And I think I can not be held responsible for unrelated code or bugs
> > in the operating system scripts.
>
> So, do you want a scorecard on this?
>
> One problem related to b43 source code, patch exists, has yet to be
> merged upstream.
Yeah. A problem preventing a LED from blinking.
That's a real regression Come on. Stop that bullshit.
> One problem related to udev rules, that may or may not be fixed in the
> latest udev. I have udev version 113, which is the latest shipped in
> Ubuntu's nightly development snapshots (hardy heron). I see that
> version 117 of udev is available on kernel.org, but mine is from the
> end of June. One would think that wouldn't be so old as to be a
> complete deal breaker. Especially as bcm43xx works fine with my udev.
How can I fix that?
> With udev rules hand-edited to include the ATTRS{type}==1 Larry
> pointed out (thanks Larry), b43 also seems to create an odd extra
> device, wmaster0.
That's not b43 specific. And it is not a bug. Ignore wmaster.
It is not useful for anything from userspace.
> Same MAC as eth1, my wireless. It's just an odd
> thing that wasn't there before with bcm43xx. May be good, may be bad,
> dunno.
Blame your distribution, please.
> And yeah, in my opinion, making the kernel play well with up-to-date
> userspace actually *is* part of your job, but then again, what do I
> know.
How the hell do I workaround broken udev scripts from within the kernel?
> Michael, you're a good guy, I believe that. You're doing unglamorous
> and mostly thankless work, and I am thankful for it. I'm afraid the
> only way I could make it glamorous is to offer to send you a fancy
> feathered outfit to wear while coding :-). But try to meet us testers
> halfway, okay? Please keep in mind that I'm really only trying to
> help.
Yeah. So PLEASE point out real bugs in MY code and do not bother
me with other peoples bugs that I simply can not fix.
In the list above there was exactly one bug for which I am responsible.
And I already sent a fix for this one.
> Now I'm going to go off, sit in the sun, sip some coffee, and think
> happy thoughts of
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
* Ray Lee <[EMAIL PROTECTED]> wrote: > Now I'm going to go off, sit in the sun, sip some coffee, and think > happy thoughts of kittens playing with yarn for a while. ok, and given the time-shift and apparent season-shift i'll sit in the evening, watch the snowfall and think happy thoughts of kittens fetching nuclear-tipped uzis and hunting ueber-elite wireless developers to beat some humanity and compassion into them, ok? ;-) Ingo -- 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 8:49 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Friday 14 December 2007 17:06:39 Ray Lee wrote:
> > Hi all. Perhaps I can inject some facts into this?
> >
> > On Dec 14, 2007 5:08 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > > > > This user did get the following messages in dmesg:
> > > > >
> > > > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > > >"or load failed.\n", path);
> > > > > b43err(wl, "You must go to "
> > > > >"http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
> > > > >"and download the correct firmware (version 4).\n");
> > > > >
> > > > > I'm not sure how I can improve that even more. There is a full URL
> > > > > describing how to get the device workin in _full_ detail.
> >
> > Yes, but only if you load rfkill-input and rfkill by hand, prior.
>
> I'm not sure what you are doing there.
> Do you have module autoloading disabled?
No, I don't have module autoloading disabled. modprobe-ing b43
automatically loads ssb. Neither, however, will load rfkill or
rfkill-input. And if they aren't loaded, then b43/ssb are *completely*
silent during load. Nothing to dmesg at all.
> This all works perfectly well on all of my systems. And I never heared
> such a problem before.
WTF? Please read *YOUR OWN MESSAGE* to the bcm43xx-dev list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006456.html
I'm going to blame this on you being tired or something, okay? But in
the meantime, could you *PLEASE* start giving me the benefit of the
doubt?
> If you have a PCI device probing works as follows:
> The PCI table is in ssb. So as soon as your kernel detects the PCI device
> it will load ssb. ssb will register the PCI device. That will trigger
> an udev event for the contained 802.11 core to get probed. This will load
> b43.
>
> So, I'm not sure where's the issue with my code here.
There's a patch from Larry Finger to address this and other issues. It
hasn't made it's way fully upstream yet. Please read your message
here, in particular item number seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
> > That I'm one of the first people to hit that makes me think that your
> > testing base so far has been miniscule.
>
> The driver is shipped by Fedora since quite some time.
Well, then they've made changes to udev or something else to
make this work okay for mere mortals such as myself, and haven't
pushed those changes upstream so that others can benefit from it.
> > > > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in
> > > > || dmesg other than lines related to the bcm43xx driver.
> > > > || iwconfig/ifconfig do not see the interface either.
> >
> > See above. Without a modprobe of rfkill, rfkill-input that is the case.
>
> You can't do
> modprobe ssb b43
> This will be interpreted as modprobe of "ssb" with the module
> parameter "b43". At least by my modutils.
Yes, I know. I'm sorry I was unclear.
> If you do
> modprobe b43
> it will automatically load _all_ required modules.
> It works perfectly well on my systems.
> Try it. Simply type "modprobe b43". It will also work for you.
As I've said multiple times earlier in this thread, I did try that and
it didn't work. Do you believe me now?
> > Hello? I tried that. It failed. What *I'm* talking about here
> > is that this everyone needs to be aware that this is *not* a drop in
> > replacement for bcm43xx, and if I'm having problems (not a kernel
> > hacker, but I make my living writing code), then sheesh, you're gonna
> > have a flood of people needing hand-holding on this.
>
> All problems so far were not related to the b43 sourcecode at all.
> And I think I can not be held responsible for unrelated code or bugs
> in the operating system scripts.
So, do you want a scorecard on this?
One problem related to b43 source code, patch exists, has yet to be
merged upstream.
One problem related to udev rules, that may or may not be fixed in the
latest udev. I have udev version 113, which is the latest shipped in
Ubuntu's nightly development snapshots (hardy heron). I see that
version 117 of udev is available on kernel.org, but mine is from the
end of June. One would think that wouldn't be so old as to be a
complete deal breaker. Especially as bcm43xx works fine with my udev.
The b43 code requires the latest firmware, something that isn't quite
obvious from skimming the changelogs. But is in dmesg, so thanks for
that.
With udev rules hand-edited to include the ATTRS{type}==1 Larry
pointed out (thanks Larry), b43 also seems to create an odd extra
device, wmaster0. Same MAC as eth1, my wireless. It's just an odd
thing that wasn't there before with bcm43xx. May be good, may be bad,
dunno.
And yeah, in my opinion, making the kernel play well with up-to-date
userspace actually *is* part of your job, but then again, what do I
know.
Michael, you're a good guy, I believe that. You're doing
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
* Michael Buesch <[EMAIL PROTECTED]> wrote: > In my opinion this all is the work of the distributions and not the > work of the kernel developers. Distributions have to make sure that > everything works after a kernel update. [...] actually, not. The the task of kernel developers is to KEEP OLD DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around until eternity, because the new one is just BROKEN. Take a look at CONFIG_COMPAT_VDSO for example - one single version of glibc was released in a distro that depended on a kernel vDSO bug. So we'll keep that aspect of the vDSO perhaps forever. Simple as that. Stuff must just work. Whatever it takes. Best is if you add in new stuff without the user noticing _ANYTHING_ but that the kernel version bumped. If the maintainers of the other 7 million lines of kernel code can get this right then the wireless code should be able to do it too. Ok? all this "distributors will have to sort out the mess" talk is nonsense, and i really hope you do not truly believe in that crap. If your attitude is prevalent in the wireless development community then it's in worse shape than i thought :-( Ingo -- 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 8:59 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > What if you want to compile your own kernel? Well, then you are on > your own anyway. You have to track kernel changes anyway. I'm trying to help you test your code before it goes out to the unsuspecting masses. Do you think I do this for *fun*? Sheesh. No, fun is leaving my system exactly as it is not putting my brain into ADD (Attention Deficit Disorder) mode to track the latest rc and look for bugs. I'm trying to point out issues that are going to to come up once the full release hits. Testing, you know? Because I guarantee you that I'm a nicer and more competent tester than a lot of the people you'll have to deal with if there's a bug. (I, at least, have been writing software for 20+ years, and have been on all sides of the process.) If you *don't* want testing of b43, then I'm happy to leave it alone and go back to bcm43xx, and point out that it shouldn't be removed from the tree. None of us want that, as bcm43xx is a pile of junk. (I just tried rmmod'ing it twice. First time, it oopsed my system. I was in X, so no backtrace, just a blinking caps lock LED. Second time was a hard lock, no oops. Have I mentioned that I'm not doing this for fun?) > There are news sites (even not specific ones for the kernel) > that reported the bcm43xx->b43 change weeks ago. Perhaps so. It didn't hit kerneltrap or lwn, both of which I follow via RSS, so not sure what I should have been looking at instead. Regardless, I'm asking for three sentences to be added to the kernel release announcement. Hell, maybe Linus would even *like* to have you guys supply part of the release announcement. He's a nice guy, how about we ask? Look, this really isn't all that much about bcm43xx/b43 here. I'm trying to say that there are things that can help get more testers. If you don't care about that, then fine, ignore this message. Ray -- 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 Friday 14 December 2007 17:45:52 Ray Lee wrote: > On Dec 14, 2007 8:27 AM, Ray Lee <[EMAIL PROTECTED]> wrote: > > On Dec 14, 2007 6:40 AM, <[EMAIL PROTECTED]> wrote: > > > Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo > > > suggests other ways to smooth out the transition. I haven't read > > > proposals yet. > > > > This isn't rocket science guys. Put a file in somewhere in your tree > > called ReleaseAnnouncement or something, and ask Linus to adjust his > > kernel release process to include the contents of `cat $( find . -name > > ReleaseAnnouncement )` in the release message he sends out. Clear out > > the file after the release. > > > > Include things such as "bcm43xx is scheduled for removal. build both > > b43 and b43legacy as a replacement. Be sure to download the latest > > firmware from $URL and follow the instructions there to extract the > > correct latest firmware necessary for your chip. There are known > > incompatibilities with old udev versions, please ensure blah blah > > blah." > > Or even better, keep the history, and show the diff of the old versus > new in the release announcement, with an appropriate sed 's/+/ /' or > somesuch. > > I'm sure you all will figure something out. Regardless, my > point is a higher level changelog that is human readable would be > helpful. (There are thousands of per-commit changelog entries to read, > it's beyond what I have the time to do when testing a new kernel). > Also, it seems distributing the release announcement work would be as > helpful as distributing the code development work. In my opinion this all is the work of the distributions and not the work of the kernel developers. Distributions have to make sure that everything works after a kernel update. Yes I know that this is difficult with b43, as the firmware is closed source. But this can be worked around by explicitely prompting the user when the kernel is updated. This is all distribution stuff. What if you want to compile your own kernel? Well, then you are on your own anyway. You have to track kernel changes anyway. And I am pretty sure that it really is simple to track kernel changes. Get your favourite kernel news site. It will tell you the changes without this magic ReleaseAnnouncement file stuff. I mean. There are news sites (even not specific ones for the kernel) that reported the bcm43xx->b43 change weeks ago. There must be some place where they get this information from without magic files. ;) -- Greetings Michael. -- 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 Friday 14 December 2007 17:06:39 Ray Lee wrote: > Hi all. Perhaps I can inject some facts into this? > > On Dec 14, 2007 5:08 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > This user did get the following messages in dmesg: > > > > > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > > > >"or load failed.\n", path); > > > > b43err(wl, "You must go to " > > > >"http://linuxwireless.org/en/users/Drivers/b43#devicefirmware " > > > >"and download the correct firmware (version 4).\n"); > > > > > > > > I'm not sure how I can improve that even more. There is a full URL > > > > describing how to get the device workin in _full_ detail. > > Yes, but only if you load rfkill-input and rfkill by hand, prior. I'm not sure what you are doing there. Do you have module autoloading disabled? This all works perfectly well on all of my systems. And I never heared such a problem before. If you have a PCI device probing works as follows: The PCI table is in ssb. So as soon as your kernel detects the PCI device it will load ssb. ssb will register the PCI device. That will trigger an udev event for the contained 802.11 core to get probed. This will load b43. So, I'm not sure where's the issue with my code here. > That I'm one of the first people to hit that makes me think that your > testing base so far has been miniscule. The driver is shipped by Fedora since quite some time. > > > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in > > > || dmesg other than lines related to the bcm43xx driver. > > > || iwconfig/ifconfig do not see the interface either. > > See above. Without a modprobe of rfkill, rfkill-input that is the case. You can't do modprobe ssb b43 This will be interpreted as modprobe of "ssb" with the module parameter "b43". At least by my modutils. If you do modprobe b43 it will automatically load _all_ required modules. It works perfectly well on my systems. Try it. Simply type "modprobe b43". It will also work for you. > Hello? I tried that. It failed. What *I'm* talking about here > is that this everyone needs to be aware that this is *not* a drop in > replacement for bcm43xx, and if I'm having problems (not a kernel > hacker, but I make my living writing code), then sheesh, you're gonna > have a flood of people needing hand-holding on this. All problems so far were not related to the b43 sourcecode at all. And I think I can not be held responsible for unrelated code or bugs in the operating system scripts. -- Greetings Michael. -- 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 8:27 AM, Ray Lee <[EMAIL PROTECTED]> wrote: > On Dec 14, 2007 6:40 AM, <[EMAIL PROTECTED]> wrote: > > Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo > > suggests other ways to smooth out the transition. I haven't read > > proposals yet. > > This isn't rocket science guys. Put a file in somewhere in your tree > called ReleaseAnnouncement or something, and ask Linus to adjust his > kernel release process to include the contents of `cat $( find . -name > ReleaseAnnouncement )` in the release message he sends out. Clear out > the file after the release. > > Include things such as "bcm43xx is scheduled for removal. build both > b43 and b43legacy as a replacement. Be sure to download the latest > firmware from $URL and follow the instructions there to extract the > correct latest firmware necessary for your chip. There are known > incompatibilities with old udev versions, please ensure blah blah > blah." Or even better, keep the history, and show the diff of the old versus new in the release announcement, with an appropriate sed 's/+/ /' or somesuch. I'm sure you all will figure something out. Regardless, my point is a higher level changelog that is human readable would be helpful. (There are thousands of per-commit changelog entries to read, it's beyond what I have the time to do when testing a new kernel). Also, it seems distributing the release announcement work would be as helpful as distributing the code development work. Ray -- 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 6:40 AM, <[EMAIL PROTECTED]> wrote: > Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo > suggests other ways to smooth out the transition. I haven't read > proposals yet. This isn't rocket science guys. Put a file in somewhere in your tree called ReleaseAnnouncement or something, and ask Linus to adjust his kernel release process to include the contents of `cat $( find . -name ReleaseAnnouncement )` in the release message he sends out. Clear out the file after the release. Include things such as "bcm43xx is scheduled for removal. build both b43 and b43legacy as a replacement. Be sure to download the latest firmware from $URL and follow the instructions there to extract the correct latest firmware necessary for your chip. There are known incompatibilities with old udev versions, please ensure blah blah blah." Ray -- 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
Hi all. Perhaps I can inject some facts into this? On Dec 14, 2007 5:08 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > This user did get the following messages in dmesg: > > > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > > >"or load failed.\n", path); > > > b43err(wl, "You must go to " > > >"http://linuxwireless.org/en/users/Drivers/b43#devicefirmware " > > >"and download the correct firmware (version 4).\n"); > > > > > > I'm not sure how I can improve that even more. There is a full URL > > > describing how to get the device workin in _full_ detail. Yes, but only if you load rfkill-input and rfkill by hand, prior. Without those, dmesg is entirely silent, and nothing works even to the stage that I got it to last night. I had to search the bcm43xx-dev archives to find that out, and it was a message from Larry saying that he'd finally tracked down why it was working for some people and not others -- some of us build fully modular kernels. That I'm one of the first people to hit that makes me think that your testing base so far has been miniscule. Once I did that, the dmesg after loading did indeed contain the URL, and thank you for that. > > well i dont have this hardware, but the following description in this > > thread seems to contradict that: > > > > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in > > || dmesg other than lines related to the bcm43xx driver. > > || iwconfig/ifconfig do not see the interface either. See above. Without a modprobe of rfkill, rfkill-input that is the case. > Let's quote another of Ray's statements: > "And ifconfig -a does indeed show it, sorry about that." > > So if he did then try to initialize that device, that clearly > _did_ show up in a standard place where network devices are > expected to show up, he did see the message I quoted. > Well, what if he did not try to initialize the device by doing > an "ifconfig wlanX up"? That can hardly be my fault, right? Hello? I tried that. It failed. What *I'm* talking about here is that this everyone needs to be aware that this is *not* a drop in replacement for bcm43xx, and if I'm having problems (not a kernel hacker, but I make my living writing code), then sheesh, you're gonna have a flood of people needing hand-holding on this. I still don't understand why bcm43xx is sane enough to create an eth1 entry, and b43 needs more handholding, but I'm going to hold off on commenting farther on that until I download the newer firmware. As it stands, I haven't given b43 an honest test yet. Please keep in mind that I'm really just trying to report my issues with the code before others hit the same thing, and trying to do this in a way that's productive for you all. I actually do understand what an amazing amount of effort you've poured into bcm43xx and the b43's, and again, I am thankful. I understand that bcm43xx is effectively dead, and it has architectural problems (locking, at minimum), that have been a problem for at least the past two years that *I've* been using it, probably more. The goal here is to make sure that your shiny new code will *work* for everyone, okay? Not to attack you, as I don't think you in any way deserve an attack. If I come off that way, I'm sorry. But likewise, if you could give me the benefit of the doubt, this conversation would go a lot smoother. Thanks. Ray -- 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
"John W. Linville" <[EMAIL PROTECTED]> wrote: On Fri, Dec 14, 2007 at 11:56:24AM +0100, Ingo Molnar wrote: * Michael Buesch <[EMAIL PROTECTED]> wrote: > Oh come on. b43 is more than a year old now. How long should we wait? > Two or three? Forever? possibly forever, if you dont get obvious regressions like "my wlan does not work" (reported in this very thread), resolved. Pushing the blame to udev (in a rather unfriendly way) wont give users a working system and wont get you many new testers for the new driver either. It is true that Michael can be a little unpleasant at times. The colloquialism that comes to mind is that he "does not suffer fools lightly". Hopefully he will take your counseling to heart and learn to be a bit more moderate in his tone. FWIW, he is still young. :-) No way. He's just inhuman. :P That said, it is also true that the b43[legacy] driver[s] do a more than adequate job of replacing the old bcm43xx driver provided that one (re-)installs the proper firmware. And I know of no other driver that goes to more trouble to tell you how to get the proper firmware installed than this one. The bcm43xx driver will be added to the feature removal schedule in 2.6.25. Proper judgment will be used in deciding the actual date of its removal. In the meantime hopefully every distribution will have or obtain a working udev configuration. If things don't work out as planned then we will re-evaluate. Let's stop this now please. Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo suggests other ways to smooth out the transition. I haven't read proposals yet. -- Ciao Stefano -- 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 Fri, Dec 14, 2007 at 11:56:24AM +0100, Ingo Molnar wrote: > > * Michael Buesch <[EMAIL PROTECTED]> wrote: > > Oh come on. b43 is more than a year old now. How long should we wait? > > Two or three? Forever? > > possibly forever, if you dont get obvious regressions like "my wlan does > not work" (reported in this very thread), resolved. Pushing the blame to > udev (in a rather unfriendly way) wont give users a working system and > wont get you many new testers for the new driver either. It is true that Michael can be a little unpleasant at times. The colloquialism that comes to mind is that he "does not suffer fools lightly". Hopefully he will take your counseling to heart and learn to be a bit more moderate in his tone. FWIW, he is still young. :-) That said, it is also true that the b43[legacy] driver[s] do a more than adequate job of replacing the old bcm43xx driver provided that one (re-)installs the proper firmware. And I know of no other driver that goes to more trouble to tell you how to get the proper firmware installed than this one. The bcm43xx driver will be added to the feature removal schedule in 2.6.25. Proper judgment will be used in deciding the actual date of its removal. In the meantime hopefully every distribution will have or obtain a working udev configuration. If things don't work out as planned then we will re-evaluate. Let's stop this now please. John -- John W. Linville [EMAIL PROTECTED] -- 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 Friday 14 December 2007 13:53:27 Ingo Molnar wrote: > > * Michael Buesch <[EMAIL PROTECTED]> wrote: > > > This user did get the following messages in dmesg: > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > >"or load failed.\n", path); > > b43err(wl, "You must go to " > >"http://linuxwireless.org/en/users/Drivers/b43#devicefirmware " > >"and download the correct firmware (version 4).\n"); > > > > I'm not sure how I can improve that even more. There is a full URL > > describing how to get the device workin in _full_ detail. > > well i dont have this hardware, but the following description in this > thread seems to contradict that: > > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in > || dmesg other than lines related to the bcm43xx driver. > || iwconfig/ifconfig do not see the interface either. Let's quote another of Ray's statements: "And ifconfig -a does indeed show it, sorry about that." So if he did then try to initialize that device, that clearly _did_ show up in a standard place where network devices are expected to show up, he did see the message I quoted. Well, what if he did not try to initialize the device by doing an "ifconfig wlanX up"? That can hardly be my fault, right? -- Greetings Michael. -- 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 Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: > > This user did get the following messages in dmesg: > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > >"or load failed.\n", path); > > So the question seems to be why b43 needs version 4, when b43legacy and > bcm43x uses version 3? That's really a question, right? Well. linux-2.4 doesn't work with the linux-2.6 modutils. Windows Vista doesn't work with Windows 98 device drivers. That leads to this assumption: b43 doesn't work with version 3 firmware but needs version 4. Newer drivers supporting newer hardware need newer firmware. -- Greetings Michael. -- 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
fre, 14 12 2007 kl. 13:31 +0100, skrev Michael Buesch: > On Friday 14 December 2007 13:16:17 Ingo Molnar wrote: > > > > * Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > > > The testers who did nothing but reported that the new driver did not > > > > work on their hardware. > > > > > > Which testers? > > > > right in this thread Ray Lee is reporting: > > > > | | Digging a little farther into it, it looks like b43 is barfing > > | | partway through init as the firmware file it's looking for has > > | | changed names. Perhaps that's the issue. I'll take a longer look at ^^ Ray probably has version 3 of the firmware. > > | | this all tomorrow. > > > > you are really in denial of reality. Just re-read this thread. Upon > > re-reading this thread, try to imagine that you are in place of Ray Lee > > (might be hard), that you had a working bcm43xx driver and that now you > > try to get b43 to work. You are not a kernel hacker who knows this > > driver, just an advanced user who'd like to give you some more feedback > > about your shiny new code. > > This user did get the following messages in dmesg: > > b43err(dev->wl, "Firmware file \"%s\" not found " >"or load failed.\n", path); So the question seems to be why b43 needs version 4, when b43legacy and bcm43x uses version 3? Simon Holm Thøgersen -- 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
* Michael Buesch <[EMAIL PROTECTED]> wrote: > This user did get the following messages in dmesg: > > b43err(dev->wl, "Firmware file \"%s\" not found " >"or load failed.\n", path); > b43err(wl, "You must go to " >"http://linuxwireless.org/en/users/Drivers/b43#devicefirmware " >"and download the correct firmware (version 4).\n"); > > I'm not sure how I can improve that even more. There is a full URL > describing how to get the device workin in _full_ detail. well i dont have this hardware, but the following description in this thread seems to contradict that: || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in || dmesg other than lines related to the bcm43xx driver. || iwconfig/ifconfig do not see the interface either. Ingo -- 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 Friday 14 December 2007 13:16:17 Ingo Molnar wrote: > > * Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > The testers who did nothing but reported that the new driver did not > > > work on their hardware. > > > > Which testers? > > right in this thread Ray Lee is reporting: > > | | Digging a little farther into it, it looks like b43 is barfing > | | partway through init as the firmware file it's looking for has > | | changed names. Perhaps that's the issue. I'll take a longer look at > | | this all tomorrow. > > you are really in denial of reality. Just re-read this thread. Upon > re-reading this thread, try to imagine that you are in place of Ray Lee > (might be hard), that you had a working bcm43xx driver and that now you > try to get b43 to work. You are not a kernel hacker who knows this > driver, just an advanced user who'd like to give you some more feedback > about your shiny new code. This user did get the following messages in dmesg: b43err(dev->wl, "Firmware file \"%s\" not found " "or load failed.\n", path); b43err(wl, "You must go to " "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware " "and download the correct firmware (version 4).\n"); I'm not sure how I can improve that even more. There is a full URL describing how to get the device workin in _full_ detail. Yes. I know people don't read messages and immediately report a "regression". But that is not my fault. Not in this case. It's not rocket science to get b43 working. The way firmware is installed did not change at all. (b43-fwcutter is still used). So it's the very same procedure that user X already successfully did when installing bcm43xx. What should I do to improve the situation? Writing the message all in uppercase? Maybe. I can do a patch, if people finally start reading it then. > > Ray Lee didn't even install the firmware. So it can't work by > > definition. That is not my fault. > > which questions your basic skills of reading or of empathy. Why is a > reasonable firmware blob not included in the kernel? Because it's closed source. > If not, why doesnt > the b43 driver warn in the dmesg (where Ray Lee did look) that no > firmware was loaded? These are basic driver usability issues, and of > course they are your fault too. This is a proven false statement. > > So new code is included in the Linux kernel based only on political > > considerations instead on technical? > > huh? This is nothing "political". It's the basic rule of maintenance: > try to be a good maintainer, involve people, forgive their newbie > mistakes. It's like the driving principle of Intenret protocols: be > conservative at what you xmit and be liberal at what you rx. That's not what my problem is here. The problem is that every now and then people come up and say that b43 is crap and doesn't work for them while bcm43xx does. In _every_ single case it was the user's fault. Mostly not reading the kernel message I quoted above. So I'm not sure what I have to do now? Defer removal of an obsolete and unstable piece of junk because some people don't read kernel logs in case something doesn't work? -- Greetings Michael. -- 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
* Michael Buesch <[EMAIL PROTECTED]> wrote: > > The testers who did nothing but reported that the new driver did not > > work on their hardware. > > Which testers? right in this thread Ray Lee is reporting: | | Digging a little farther into it, it looks like b43 is barfing | | partway through init as the firmware file it's looking for has | | changed names. Perhaps that's the issue. I'll take a longer look at | | this all tomorrow. you are really in denial of reality. Just re-read this thread. Upon re-reading this thread, try to imagine that you are in place of Ray Lee (might be hard), that you had a working bcm43xx driver and that now you try to get b43 to work. You are not a kernel hacker who knows this driver, just an advanced user who'd like to give you some more feedback about your shiny new code. From that perspective, do you think your replies were fine, constructive and involved the tester? I sure read them as dismissive, they had an annoyed tone (i'm not sure why - he was trying to get _YOUR_ code to work) and were borderline arrogant. Looking at the replies from Ray Lee it sure seemed to me he had a similar impression. In place of Ray Lee, would you report new bugs to the maintainer of b43? I sure as hell would avoid it if i could. Do you think such incidents help Linux in the long run? and you even claim: > Ray Lee didn't even install the firmware. So it can't work by > definition. That is not my fault. which questions your basic skills of reading or of empathy. Why is a reasonable firmware blob not included in the kernel? If not, why doesnt the b43 driver warn in the dmesg (where Ray Lee did look) that no firmware was loaded? These are basic driver usability issues, and of course they are your fault too. > > Yes, you can then "unsupport it" in spite and be a prick about it in > > general but that will only talk of your own personal qualities and > > will sharply reduce your credibility as a maintainer (and eventually > > hinder your ability to introduce new code) - users will still have > > the code available and will have a chance to fix the driver that > > happens to work. (and perhaps another, capable, but friendler > > maintainer arises.) And that old code will be a clot to drag around, > > hindering your 'new' wireless code all along. > > So new code is included in the Linux kernel based only on political > considerations instead on technical? huh? This is nothing "political". It's the basic rule of maintenance: try to be a good maintainer, involve people, forgive their newbie mistakes. It's like the driving principle of Intenret protocols: be conservative at what you xmit and be liberal at what you rx. Ingo -- 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 Friday 14 December 2007 12:15:34 Ingo Molnar wrote: > > So you volunteer to maintain bcm43xx? Fine. Thanks a lot. > > it's sad that you are trying to force testers to upgrade to your new > driver by threatening to unsupport the old driver. I dropped maintainance for bcm43xx over a year ago. So I am not going to catch it up again. b43 works fine. I don't see a reason to support bcm43xx anymore. Currently bcm43xx is orphaned, as Larry couldn't support it anymore due to other issues. > The testers who did > nothing but reported that the new driver did not work on their hardware. Which testers? Ray Lee didn't even install the firmware. So it can't work by definition. That is not my fault. > You can write new drivers but you must not break existing users. That's > true for every single piece of the kernel. It is _your_ responsibility > to get that rule right - and if it does not work out of box (no matter > whom to blame, udev or the driver) you dont get to remove the driver > from the upstream kernel. Ok. So we have to live with an orphaned driver. I am fine with that, too. > Yes, you can then "unsupport it" in spite and be a prick about it in > general but that will only talk of your own personal qualities and will > sharply reduce your credibility as a maintainer (and eventually hinder > your ability to introduce new code) - users will still have the code > available and will have a chance to fix the driver that happens to work. > (and perhaps another, capable, but friendler maintainer arises.) And > that old code will be a clot to drag around, hindering your 'new' > wireless code all along. So new code is included in the Linux kernel based only on political considerations instead on technical? I'm not sure what's the matter. Show me _one_ person for whom bcm43xx works and b43/legacy does not. And I will immediately stop removal of that driver and fix b43. > I really dont know why it's so hard to understand: new is totally > useless if it does not work for old setups 100% of the time. And people > _WANT_ to use your new code, so it's not like you have to pull their > hairs to get your stuff tested. And YOU wrote the old code in large > part: > > $ git-authors drivers/net/wireless/bcm43xx/ | tail -10 > 2 Sam Ravnborg > 3 David Howells > 3 David Woodhouse > 3 Joe Perches > 4 Jeff Garzik > 5 Daniel Drake > 6 Stefano Brivio > 9 John W. Linville > 48 Larry Finger > 80 Michael Buesch > > so it's not like "someone else messed it up" and that you would be > incapable of getting it all work nicely and make the migration of users > smoother. And if udev is a hindrance to you, reduce your driver's > dependence on udev breakages. I'm not sure what you are talking about. If udev renames the device to something stupid (like wlan0_rename) that is not my fault. That is the fault of a big Linux Distribution messing udev config up. Let's summarise it: I don't know a single user for whom bcm43xx works but b43 does not. In most cases b43 does work a _lot_ better than bcm43xx. If you show me one person for whom bcm43xx works but b43 does not I will stop removal of the driver. -- Greetings Michael. -- 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
* Michael Buesch <[EMAIL PROTECTED]> wrote: > On Friday 14 December 2007 02:12:25 Ray Lee wrote: > > Digging a little farther into it, it looks like b43 is barfing partway > > through init as the firmware file it's looking for has changed names. > > Perhaps that's the issue. I'll take a longer look at this all > > tomorrow. > > http://www.linuxwireless.org/en/users/Drivers/b43#firmwareinstallation > > > Well, it only hit the main kernel October 10th. That means no final > > point release of the kernel.org kernel has even had it included! So > > testing-wise, you still haven't hit the hordes yet. Scheduling a > > removal of bcm43xx (as painful as that code is [*]), seems either > > premature or very optimistic. So, how about scheduling the removal > > once you get a feel for the bug reports that'll come in once 2.6.24 is > > released. > > So you volunteer to maintain bcm43xx? Fine. Thanks a lot. it's sad that you are trying to force testers to upgrade to your new driver by threatening to unsupport the old driver. The testers who did nothing but reported that the new driver did not work on their hardware. You can write new drivers but you must not break existing users. That's true for every single piece of the kernel. It is _your_ responsibility to get that rule right - and if it does not work out of box (no matter whom to blame, udev or the driver) you dont get to remove the driver from the upstream kernel. Yes, you can then "unsupport it" in spite and be a prick about it in general but that will only talk of your own personal qualities and will sharply reduce your credibility as a maintainer (and eventually hinder your ability to introduce new code) - users will still have the code available and will have a chance to fix the driver that happens to work. (and perhaps another, capable, but friendler maintainer arises.) And that old code will be a clot to drag around, hindering your 'new' wireless code all along. I really dont know why it's so hard to understand: new is totally useless if it does not work for old setups 100% of the time. And people _WANT_ to use your new code, so it's not like you have to pull their hairs to get your stuff tested. And YOU wrote the old code in large part: $ git-authors drivers/net/wireless/bcm43xx/ | tail -10 2 Sam Ravnborg 3 David Howells 3 David Woodhouse 3 Joe Perches 4 Jeff Garzik 5 Daniel Drake 6 Stefano Brivio 9 John W. Linville 48 Larry Finger 80 Michael Buesch so it's not like "someone else messed it up" and that you would be incapable of getting it all work nicely and make the migration of users smoother. And if udev is a hindrance to you, reduce your driver's dependence on udev breakages. Ingo -- 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
* Michael Buesch <[EMAIL PROTECTED]> wrote: > > (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.) > > > > `ifconfig` doesn't see eth1 or wlan0_rename. > > > > What else might I be doing wrong? > > I don't know. Try ifconfig -a Or tell udev to not crap up your device > names. > > > Regardless, perhaps scheduling bcm43xx for removal in 2.6.26 is a > > bit premature. > > Oh come on. b43 is more than a year old now. How long should we wait? > Two or three? Forever? possibly forever, if you dont get obvious regressions like "my wlan does not work" (reported in this very thread), resolved. Pushing the blame to udev (in a rather unfriendly way) wont give users a working system and wont get you many new testers for the new driver either. Ingo -- 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 Friday 14 December 2007 02:12:25 Ray Lee wrote: > Digging a little farther into it, it looks like b43 is barfing partway > through init as the firmware file it's looking for has changed names. > Perhaps that's the issue. I'll take a longer look at this all > tomorrow. http://www.linuxwireless.org/en/users/Drivers/b43#firmwareinstallation > Well, it only hit the main kernel October 10th. That means no final > point release of the kernel.org kernel has even had it included! So > testing-wise, you still haven't hit the hordes yet. Scheduling a > removal of bcm43xx (as painful as that code is [*]), seems either > premature or very optimistic. So, how about scheduling the removal > once you get a feel for the bug reports that'll come in once 2.6.24 is > released. So you volunteer to maintain bcm43xx? Fine. Thanks a lot. >[*] Yeah, even as a user the code is painful. It *still* locks my > keyboard if I happen to disable the wireless while it's scanning. The > sooner bcm43xx is dead, the better. But b43 is quite obviously not a > full replacement for everyone. I'm pretty sure it is. Please carefully read the instructions on http://www.linuxwireless.org/en/users/Drivers/b43 especially for firmware installation. It will work very well. -- Greetings Michael. -- 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 Friday 14 December 2007 01:55:50 Harvey Harrison wrote: > On Fri, 2007-12-14 at 01:43 +0100, Michael Buesch wrote: > > Oh come on. b43 is more than a year old now. How long should we wait? > > Two or three? Forever? > > > > Any pointers to the advantages of b43? http://www.linuxwireless.org/en/users/Drivers/b43 -- Greetings Michael. -- 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
* Michael Buesch [EMAIL PROTECTED] wrote: (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.) `ifconfig` doesn't see eth1 or wlan0_rename. What else might I be doing wrong? I don't know. Try ifconfig -a Or tell udev to not crap up your device names. Regardless, perhaps scheduling bcm43xx for removal in 2.6.26 is a bit premature. Oh come on. b43 is more than a year old now. How long should we wait? Two or three? Forever? possibly forever, if you dont get obvious regressions like my wlan does not work (reported in this very thread), resolved. Pushing the blame to udev (in a rather unfriendly way) wont give users a working system and wont get you many new testers for the new driver either. Ingo -- 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/
