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: 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
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
* 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
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 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: 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
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
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
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
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. shrug 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 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 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. shrug 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 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 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 kittens playing with yarn for a while.
Have fun.
--
Greetings Michael.
--
To unsubscribe from this list: send
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 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
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
* 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: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.
shrug 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 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
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
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 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 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: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: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 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 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
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 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
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
[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 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: 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
Michael Buesch wrote:
On Friday 14 December 2007 01:05:00 Ray Lee wrote:
Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
realize that. Hopefully that'll be automatic soon. Regardless, upon
doing so, and loading ssb and b43, it sees my card, but is still not
fully functional. iwconfig sees:
lono wireless extensions.
eth0 no wireless extensions.
tun0 no wireless extensions.
eth1 no wireless extensions.
wlan0_rename IEEE 802.11g ESSID:""
Mode:Managed Channel:0 Access Point: Not-Associated
Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
(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?
Your udev rules are screwed up. In /etc/udev/rules.d/70-persistent-net.rules, you should have a line
that looks like
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1a:73:6b:28:5a", ATTR{type}=="1",
NAME="eth1"
with the MAC address for your device. You probably have the ATTR{type}=="1"
clause missing.
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 13, 2007 4:43 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Friday 14 December 2007 01:05:00 Ray Lee wrote: > > Okay, I had to modprobe rfkill-input and rfkill by hand, didn't > > realize that. Hopefully that'll be automatic soon. Regardless, upon > > doing so, and loading ssb and b43, it sees my card, but is still not > > fully functional. iwconfig sees: > > > > lono wireless extensions. > > eth0 no wireless extensions. > > tun0 no wireless extensions. > > eth1 no wireless extensions. > > wlan0_rename IEEE 802.11g ESSID:"" > > Mode:Managed Channel:0 Access Point: Not-Associated > > Tx-Power=0 dBm > > Retry min limit:7 RTS thr:off Fragment thr=2346 B > > Link Quality:0 Signal level:0 Noise level:0 > > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > > > (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. Uhm, I haven't had to tell udev to not crap up any of my *other* devices, why is b43 special? I'm using an up-to-date userspace, so I'm not going to be the only one hitting this problem. And ifconfig -a does indeed show it, sorry about that. But my understanding is that udev renames interfaces based on MAC address, so I wouldn't suspect udev to be at fault here. 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. > > 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? 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. [*] 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 don't mean to come off harsh, I know you put an amazing amount of work into both b43 and bcm43xx, and I'm thankful for that. But requiring the end-user to go scan bcm43xx-dev archives to find out that the b43 module isn't correctly autoloading all of its dependencies is a sign that the code still hasn't had a lot of testing, no? In the meantime I'll keep plugging away at trying to figure out what's wrong. 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 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? Harvey -- 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:05:00 Ray Lee wrote: > Okay, I had to modprobe rfkill-input and rfkill by hand, didn't > realize that. Hopefully that'll be automatic soon. Regardless, upon > doing so, and loading ssb and b43, it sees my card, but is still not > fully functional. iwconfig sees: > > lono wireless extensions. > eth0 no wireless extensions. > tun0 no wireless extensions. > eth1 no wireless extensions. > wlan0_rename IEEE 802.11g ESSID:"" > Mode:Managed Channel:0 Access Point: Not-Associated > Tx-Power=0 dBm > Retry min limit:7 RTS thr:off Fragment thr=2346 B > Link Quality:0 Signal level:0 Noise level:0 > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > (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? -- 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 13, 2007 5:45 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Thursday 13 December 2007 02:17:16 Ray Lee wrote:
> > Uhm, hijacking the thread a bit here, but which driver is supposed to
> > be supporting my 4309? Neither b43 nor b43legacy found my wireless,
> > and I'm not seeing its PCI ID anywhere either of those...
> >
> > 02:02.0 0280: 14e4:4324 (rev 03)
>
> The device is supported by b43.
> The PCI ID is in the SSB PCI bridge code
>
> static const struct pci_device_id b43_pci_bridge_tbl[] = {
...
> { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
Ah, thanks, so it is. 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.
Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
realize that. Hopefully that'll be automatic soon. Regardless, upon
doing so, and loading ssb and b43, it sees my card, but is still not
fully functional. iwconfig sees:
lono wireless extensions.
eth0 no wireless extensions.
tun0 no wireless extensions.
eth1 no wireless extensions.
wlan0_rename IEEE 802.11g ESSID:""
Mode:Managed Channel:0 Access Point: Not-Associated
Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
(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? Regardless, perhaps scheduling
bcm43xx for removal in 2.6.26 is a bit premature.
--
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 Thu, Dec 13, 2007 at 12:11:32PM +0100, Michael Buesch wrote: > On Thursday 13 December 2007 11:13:27 Ingo Molnar wrote: > > > > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > > > > This driver is scheduled for removal, so I'd not touch it anymore to > > > > avoid the possibility to introduce a lastminute regression. The new > > > > drivers (b43 and b43legacy) have this fixed (in a different way by > > > > completely removing it). > > > > > > When is the removal scheduled? > > > > $ grep -i bcm Documentation/feature-removal-schedule.txt > > $ > > > > might make sense to update this file. > > Patches are on their way. > I think it's scheduled to be removed after 2.6.25 was released. A patch w/ subject "bcm43xx: mark as obsolete and schedule for removal" is queued in net-2.6.25 and waiting for the 2.6.25 merge window. It includes this hunk: --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -333,3 +333,12 @@ Why: This driver has been marked obsolete for many years. Who: Stephen Hemminger <[EMAIL PROTECTED]> --- + +What: bcm43xx wireless network driver +When: 2.6.26 +Files: drivers/net/wireless/bcm43xx +Why: This driver's functionality has been replaced by the + mac80211-based b43 and b43legacy drivers. +Who: John W. Linville <[EMAIL PROTECTED]> + +--- Hth! 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 Thursday 13 December 2007 02:17:16 Ray Lee wrote:
> On Dec 12, 2007 4:48 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > This driver is scheduled for removal, so I'd not touch it anymore
> > to avoid the possibility to introduce a lastminute regression.
> > The new drivers (b43 and b43legacy) have this fixed (in a different
> > way by completely removing it).
>
> Uhm, hijacking the thread a bit here, but which driver is supposed to
> be supporting my 4309? Neither b43 nor b43legacy found my wireless,
> and I'm not seeing its PCI ID anywhere either of those...
>
> $ lspci -s 02:02 -v; lspci -n -s 02:02 -v -x
> 02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03)
> Subsystem: Hewlett-Packard Company Unknown device 12f9
> Flags: bus master, fast devsel, latency 64, IRQ 22
> Memory at d001 (32-bit, non-prefetchable) [size=8K]
>
> 02:02.0 0280: 14e4:4324 (rev 03)
The device is supported by b43.
The PCI ID is in the SSB PCI bridge code
static const struct pci_device_id b43_pci_bridge_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4301) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4307) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4311) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4312) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4318) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4319) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4320) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4321) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4325) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4328) },
{ 0, },
};
MODULE_DEVICE_TABLE(pci, b43_pci_bridge_tbl);
--
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 Thursday 13 December 2007 11:13:27 Ingo Molnar wrote: > > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > > This driver is scheduled for removal, so I'd not touch it anymore to > > > avoid the possibility to introduce a lastminute regression. The new > > > drivers (b43 and b43legacy) have this fixed (in a different way by > > > completely removing it). > > > > When is the removal scheduled? > > $ grep -i bcm Documentation/feature-removal-schedule.txt > $ > > might make sense to update this file. Patches are on their way. I think it's scheduled to be removed after 2.6.25 was released. -- 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
* Daniel Walker <[EMAIL PROTECTED]> wrote: > > This driver is scheduled for removal, so I'd not touch it anymore to > > avoid the possibility to introduce a lastminute regression. The new > > drivers (b43 and b43legacy) have this fixed (in a different way by > > completely removing it). > > When is the removal scheduled? $ grep -i bcm Documentation/feature-removal-schedule.txt $ might make sense to update this file. 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
* Daniel Walker [EMAIL PROTECTED] wrote: This driver is scheduled for removal, so I'd not touch it anymore to avoid the possibility to introduce a lastminute regression. The new drivers (b43 and b43legacy) have this fixed (in a different way by completely removing it). When is the removal scheduled? $ grep -i bcm Documentation/feature-removal-schedule.txt $ might make sense to update this file. 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 Thursday 13 December 2007 11:13:27 Ingo Molnar wrote: * Daniel Walker [EMAIL PROTECTED] wrote: This driver is scheduled for removal, so I'd not touch it anymore to avoid the possibility to introduce a lastminute regression. The new drivers (b43 and b43legacy) have this fixed (in a different way by completely removing it). When is the removal scheduled? $ grep -i bcm Documentation/feature-removal-schedule.txt $ might make sense to update this file. Patches are on their way. I think it's scheduled to be removed after 2.6.25 was released. -- 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 Thursday 13 December 2007 02:17:16 Ray Lee wrote:
On Dec 12, 2007 4:48 PM, Michael Buesch [EMAIL PROTECTED] wrote:
This driver is scheduled for removal, so I'd not touch it anymore
to avoid the possibility to introduce a lastminute regression.
The new drivers (b43 and b43legacy) have this fixed (in a different
way by completely removing it).
Uhm, hijacking the thread a bit here, but which driver is supposed to
be supporting my 4309? Neither b43 nor b43legacy found my wireless,
and I'm not seeing its PCI ID anywhere either of those...
$ lspci -s 02:02 -v; lspci -n -s 02:02 -v -x
02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03)
Subsystem: Hewlett-Packard Company Unknown device 12f9
Flags: bus master, fast devsel, latency 64, IRQ 22
Memory at d001 (32-bit, non-prefetchable) [size=8K]
02:02.0 0280: 14e4:4324 (rev 03)
The device is supported by b43.
The PCI ID is in the SSB PCI bridge code
static const struct pci_device_id b43_pci_bridge_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4301) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4307) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4311) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4312) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4318) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4319) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4320) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4321) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4325) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4328) },
{ 0, },
};
MODULE_DEVICE_TABLE(pci, b43_pci_bridge_tbl);
--
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 Thu, Dec 13, 2007 at 12:11:32PM +0100, Michael Buesch wrote: On Thursday 13 December 2007 11:13:27 Ingo Molnar wrote: * Daniel Walker [EMAIL PROTECTED] wrote: This driver is scheduled for removal, so I'd not touch it anymore to avoid the possibility to introduce a lastminute regression. The new drivers (b43 and b43legacy) have this fixed (in a different way by completely removing it). When is the removal scheduled? $ grep -i bcm Documentation/feature-removal-schedule.txt $ might make sense to update this file. Patches are on their way. I think it's scheduled to be removed after 2.6.25 was released. A patch w/ subject bcm43xx: mark as obsolete and schedule for removal is queued in net-2.6.25 and waiting for the 2.6.25 merge window. It includes this hunk: --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -333,3 +333,12 @@ Why: This driver has been marked obsolete for many years. Who: Stephen Hemminger [EMAIL PROTECTED] --- + +What: bcm43xx wireless network driver +When: 2.6.26 +Files: drivers/net/wireless/bcm43xx +Why: This driver's functionality has been replaced by the + mac80211-based b43 and b43legacy drivers. +Who: John W. Linville [EMAIL PROTECTED] + +--- Hth! 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 13, 2007 5:45 AM, Michael Buesch [EMAIL PROTECTED] wrote:
On Thursday 13 December 2007 02:17:16 Ray Lee wrote:
Uhm, hijacking the thread a bit here, but which driver is supposed to
be supporting my 4309? Neither b43 nor b43legacy found my wireless,
and I'm not seeing its PCI ID anywhere either of those...
02:02.0 0280: 14e4:4324 (rev 03)
The device is supported by b43.
The PCI ID is in the SSB PCI bridge code
static const struct pci_device_id b43_pci_bridge_tbl[] = {
...
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
Ah, thanks, so it is. 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.
goes and reads bcm43xx-dev archives
Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
realize that. Hopefully that'll be automatic soon. Regardless, upon
doing so, and loading ssb and b43, it sees my card, but is still not
fully functional. iwconfig sees:
lono wireless extensions.
eth0 no wireless extensions.
tun0 no wireless extensions.
eth1 no wireless extensions.
wlan0_rename IEEE 802.11g ESSID:
Mode:Managed Channel:0 Access Point: Not-Associated
Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
(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? Regardless, perhaps scheduling
bcm43xx for removal in 2.6.26 is a bit premature.
--
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, 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? Harvey -- 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:05:00 Ray Lee wrote: Okay, I had to modprobe rfkill-input and rfkill by hand, didn't realize that. Hopefully that'll be automatic soon. Regardless, upon doing so, and loading ssb and b43, it sees my card, but is still not fully functional. iwconfig sees: lono wireless extensions. eth0 no wireless extensions. tun0 no wireless extensions. eth1 no wireless extensions. wlan0_rename IEEE 802.11g ESSID: Mode:Managed Channel:0 Access Point: Not-Associated Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2346 B Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 (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? -- 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 13, 2007 4:43 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Friday 14 December 2007 01:05:00 Ray Lee wrote: Okay, I had to modprobe rfkill-input and rfkill by hand, didn't realize that. Hopefully that'll be automatic soon. Regardless, upon doing so, and loading ssb and b43, it sees my card, but is still not fully functional. iwconfig sees: lono wireless extensions. eth0 no wireless extensions. tun0 no wireless extensions. eth1 no wireless extensions. wlan0_rename IEEE 802.11g ESSID: Mode:Managed Channel:0 Access Point: Not-Associated Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2346 B Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 (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. Uhm, I haven't had to tell udev to not crap up any of my *other* devices, why is b43 special? I'm using an up-to-date userspace, so I'm not going to be the only one hitting this problem. And ifconfig -a does indeed show it, sorry about that. But my understanding is that udev renames interfaces based on MAC address, so I wouldn't suspect udev to be at fault here. 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. 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? 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. [*] 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 don't mean to come off harsh, I know you put an amazing amount of work into both b43 and bcm43xx, and I'm thankful for that. But requiring the end-user to go scan bcm43xx-dev archives to find out that the b43 module isn't correctly autoloading all of its dependencies is a sign that the code still hasn't had a lot of testing, no? In the meantime I'll keep plugging away at trying to figure out what's wrong. 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
Michael Buesch wrote:
On Friday 14 December 2007 01:05:00 Ray Lee wrote:
Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
realize that. Hopefully that'll be automatic soon. Regardless, upon
doing so, and loading ssb and b43, it sees my card, but is still not
fully functional. iwconfig sees:
lono wireless extensions.
eth0 no wireless extensions.
tun0 no wireless extensions.
eth1 no wireless extensions.
wlan0_rename IEEE 802.11g ESSID:
Mode:Managed Channel:0 Access Point: Not-Associated
Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
(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?
Your udev rules are screwed up. In /etc/udev/rules.d/70-persistent-net.rules, you should have a line
that looks like
SUBSYSTEM==net, DRIVERS==?*, ATTR{address}==00:1a:73:6b:28:5a, ATTR{type}==1,
NAME=eth1
with the MAC address for your device. You probably have the ATTR{type}==1
clause missing.
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 Thu, 2007-12-13 at 01:48 +0100, Michael Buesch wrote: > On Wednesday 12 December 2007 09:00:03 Daniel Walker wrote: > > > > Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]> > > > > --- > > drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 30 > > - > > 1 file changed, 15 insertions(+), 15 deletions(-) > > > > Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c > > === > > --- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c > > +++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c > > @@ -43,7 +43,7 @@ > > > > static struct bcm43xx_debugfs fs; > > static char really_big_buffer[REALLY_BIG_BUFFER_SIZE]; > > -static DECLARE_MUTEX(big_buffer_sem); > > +static DEFINE_MUTEX(big_buffer_mutex); > > This driver is scheduled for removal, so I'd not touch it anymore > to avoid the possibility to introduce a lastminute regression. > The new drivers (b43 and b43legacy) have this fixed (in a different > way by completely removing it). When is the removal scheduled? Daniel -- 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 12, 2007 4:48 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > This driver is scheduled for removal, so I'd not touch it anymore > to avoid the possibility to introduce a lastminute regression. > The new drivers (b43 and b43legacy) have this fixed (in a different > way by completely removing it). Uhm, hijacking the thread a bit here, but which driver is supposed to be supporting my 4309? Neither b43 nor b43legacy found my wireless, and I'm not seeing its PCI ID anywhere either of those... $ lspci -s 02:02 -v; lspci -n -s 02:02 -v -x 02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03) Subsystem: Hewlett-Packard Company Unknown device 12f9 Flags: bus master, fast devsel, latency 64, IRQ 22 Memory at d001 (32-bit, non-prefetchable) [size=8K] 02:02.0 0280: 14e4:4324 (rev 03) Subsystem: 103c:12f9 Flags: bus master, fast devsel, latency 64, IRQ 22 Memory at d001 (32-bit, non-prefetchable) [size=8K] 00: e4 14 24 43 06 00 00 00 03 00 80 02 00 40 00 00 10: 00 00 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 f9 12 30: 00 00 00 00 00 00 00 00 00 00 00 00 05 01 00 00 -- 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 Wednesday 12 December 2007 09:00:03 Daniel Walker wrote: > > Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]> > > --- > drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 30 > - > 1 file changed, 15 insertions(+), 15 deletions(-) > > Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c > === > --- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c > +++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c > @@ -43,7 +43,7 @@ > > static struct bcm43xx_debugfs fs; > static char really_big_buffer[REALLY_BIG_BUFFER_SIZE]; > -static DECLARE_MUTEX(big_buffer_sem); > +static DEFINE_MUTEX(big_buffer_mutex); This driver is scheduled for removal, so I'd not touch it anymore to avoid the possibility to introduce a lastminute regression. The new drivers (b43 and b43legacy) have this fixed (in a different way by completely removing it). -- 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/
[PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>
---
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 30 -
1 file changed, 15 insertions(+), 15 deletions(-)
Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
===
--- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
+++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
@@ -43,7 +43,7 @@
static struct bcm43xx_debugfs fs;
static char really_big_buffer[REALLY_BIG_BUFFER_SIZE];
-static DECLARE_MUTEX(big_buffer_sem);
+static DEFINE_MUTEX(big_buffer_mutex);
static ssize_t write_file_dummy(struct file *file, const char __user *buf,
@@ -75,7 +75,7 @@ static ssize_t devinfo_read_file(struct
u16 tmp16;
int i;
- down(_buffer_sem);
+ mutex_lock(_buffer_mutex);
mutex_lock(>mutex);
spin_lock_irqsave(>irq_lock, flags);
@@ -125,7 +125,7 @@ out:
spin_unlock_irqrestore(>irq_lock, flags);
mutex_unlock(>mutex);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(_buffer_sem);
+ mutex_unlock(_buffer_mutex);
return res;
}
@@ -138,14 +138,14 @@ static ssize_t drvinfo_read_file(struct
size_t pos = 0;
ssize_t res;
- down(_buffer_sem);
+ mutex_lock(_buffer_mutex);
/* This is where the information is written to the "driver" file */
fappend(KBUILD_MODNAME " driver\n");
fappend("Compiled at: %s %s\n", __DATE__, __TIME__);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(_buffer_sem);
+ mutex_unlock(_buffer_mutex);
return res;
}
@@ -160,7 +160,7 @@ static ssize_t spromdump_read_file(struc
ssize_t res;
unsigned long flags;
- down(_buffer_sem);
+ mutex_lock(_buffer_mutex);
mutex_lock(>mutex);
spin_lock_irqsave(>irq_lock, flags);
if (bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED) {
@@ -175,7 +175,7 @@ out:
spin_unlock_irqrestore(>irq_lock, flags);
mutex_unlock(>mutex);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(_buffer_sem);
+ mutex_unlock(_buffer_mutex);
return res;
}
@@ -191,7 +191,7 @@ static ssize_t tsf_read_file(struct file
unsigned long flags;
u64 tsf;
- down(_buffer_sem);
+ mutex_lock(_buffer_mutex);
mutex_lock(>mutex);
spin_lock_irqsave(>irq_lock, flags);
if (bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED) {
@@ -207,7 +207,7 @@ out:
spin_unlock_irqrestore(>irq_lock, flags);
mutex_unlock(>mutex);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(_buffer_sem);
+ mutex_unlock(_buffer_mutex);
return res;
}
@@ -222,7 +222,7 @@ static ssize_t tsf_write_file(struct fil
unsigned long long tsf;
buf_size = min(count, sizeof (really_big_buffer) - 1);
- down(_buffer_sem);
+ mutex_lock(_buffer_mutex);
if (copy_from_user(buf, user_buf, buf_size)) {
res = -EFAULT;
goto out_up;
@@ -247,7 +247,7 @@ out_unlock:
spin_unlock_irqrestore(>irq_lock, flags);
mutex_unlock(>mutex);
out_up:
- up(_buffer_sem);
+ mutex_unlock(_buffer_mutex);
return res;
}
@@ -265,7 +265,7 @@ static ssize_t txstat_read_file(struct f
struct bcm43xx_xmitstatus *status;
int i, cnt, j = 0;
- down(_buffer_sem);
+ mutex_lock(_buffer_mutex);
mutex_lock(>mutex);
spin_lock_irqsave(>irq_lock, flags);
@@ -312,7 +312,7 @@ static ssize_t txstat_read_file(struct f
}
spin_unlock_irqrestore(>irq_lock, flags);
mutex_unlock(>mutex);
- up(_buffer_sem);
+ mutex_unlock(_buffer_mutex);
return res;
}
@@ -326,7 +326,7 @@ static ssize_t restart_write_file(struct
unsigned long flags;
buf_size = min(count, sizeof (really_big_buffer) - 1);
- down(_buffer_sem);
+ mutex_lock(_buffer_mutex);
if (copy_from_user(buf, user_buf, buf_size)) {
res = -EFAULT;
goto out_up;
@@ -348,7 +348,7 @@ out_unlock:
spin_unlock_irqrestore(&(bcm)->irq_lock, flags);
mutex_unlock(&(bcm)->mutex);
out_up:
- up(_buffer_sem);
+ mutex_unlock(_buffer_mutex);
return res;
}
--
--
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/
[PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
Signed-Off-By: Daniel Walker [EMAIL PROTECTED]
---
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 30 -
1 file changed, 15 insertions(+), 15 deletions(-)
Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
===
--- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
+++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
@@ -43,7 +43,7 @@
static struct bcm43xx_debugfs fs;
static char really_big_buffer[REALLY_BIG_BUFFER_SIZE];
-static DECLARE_MUTEX(big_buffer_sem);
+static DEFINE_MUTEX(big_buffer_mutex);
static ssize_t write_file_dummy(struct file *file, const char __user *buf,
@@ -75,7 +75,7 @@ static ssize_t devinfo_read_file(struct
u16 tmp16;
int i;
- down(big_buffer_sem);
+ mutex_lock(big_buffer_mutex);
mutex_lock(bcm-mutex);
spin_lock_irqsave(bcm-irq_lock, flags);
@@ -125,7 +125,7 @@ out:
spin_unlock_irqrestore(bcm-irq_lock, flags);
mutex_unlock(bcm-mutex);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(big_buffer_sem);
+ mutex_unlock(big_buffer_mutex);
return res;
}
@@ -138,14 +138,14 @@ static ssize_t drvinfo_read_file(struct
size_t pos = 0;
ssize_t res;
- down(big_buffer_sem);
+ mutex_lock(big_buffer_mutex);
/* This is where the information is written to the driver file */
fappend(KBUILD_MODNAME driver\n);
fappend(Compiled at: %s %s\n, __DATE__, __TIME__);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(big_buffer_sem);
+ mutex_unlock(big_buffer_mutex);
return res;
}
@@ -160,7 +160,7 @@ static ssize_t spromdump_read_file(struc
ssize_t res;
unsigned long flags;
- down(big_buffer_sem);
+ mutex_lock(big_buffer_mutex);
mutex_lock(bcm-mutex);
spin_lock_irqsave(bcm-irq_lock, flags);
if (bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED) {
@@ -175,7 +175,7 @@ out:
spin_unlock_irqrestore(bcm-irq_lock, flags);
mutex_unlock(bcm-mutex);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(big_buffer_sem);
+ mutex_unlock(big_buffer_mutex);
return res;
}
@@ -191,7 +191,7 @@ static ssize_t tsf_read_file(struct file
unsigned long flags;
u64 tsf;
- down(big_buffer_sem);
+ mutex_lock(big_buffer_mutex);
mutex_lock(bcm-mutex);
spin_lock_irqsave(bcm-irq_lock, flags);
if (bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED) {
@@ -207,7 +207,7 @@ out:
spin_unlock_irqrestore(bcm-irq_lock, flags);
mutex_unlock(bcm-mutex);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(big_buffer_sem);
+ mutex_unlock(big_buffer_mutex);
return res;
}
@@ -222,7 +222,7 @@ static ssize_t tsf_write_file(struct fil
unsigned long long tsf;
buf_size = min(count, sizeof (really_big_buffer) - 1);
- down(big_buffer_sem);
+ mutex_lock(big_buffer_mutex);
if (copy_from_user(buf, user_buf, buf_size)) {
res = -EFAULT;
goto out_up;
@@ -247,7 +247,7 @@ out_unlock:
spin_unlock_irqrestore(bcm-irq_lock, flags);
mutex_unlock(bcm-mutex);
out_up:
- up(big_buffer_sem);
+ mutex_unlock(big_buffer_mutex);
return res;
}
@@ -265,7 +265,7 @@ static ssize_t txstat_read_file(struct f
struct bcm43xx_xmitstatus *status;
int i, cnt, j = 0;
- down(big_buffer_sem);
+ mutex_lock(big_buffer_mutex);
mutex_lock(bcm-mutex);
spin_lock_irqsave(bcm-irq_lock, flags);
@@ -312,7 +312,7 @@ static ssize_t txstat_read_file(struct f
}
spin_unlock_irqrestore(bcm-irq_lock, flags);
mutex_unlock(bcm-mutex);
- up(big_buffer_sem);
+ mutex_unlock(big_buffer_mutex);
return res;
}
@@ -326,7 +326,7 @@ static ssize_t restart_write_file(struct
unsigned long flags;
buf_size = min(count, sizeof (really_big_buffer) - 1);
- down(big_buffer_sem);
+ mutex_lock(big_buffer_mutex);
if (copy_from_user(buf, user_buf, buf_size)) {
res = -EFAULT;
goto out_up;
@@ -348,7 +348,7 @@ out_unlock:
spin_unlock_irqrestore((bcm)-irq_lock, flags);
mutex_unlock((bcm)-mutex);
out_up:
- up(big_buffer_sem);
+ mutex_unlock(big_buffer_mutex);
return res;
}
--
--
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 Wednesday 12 December 2007 09:00:03 Daniel Walker wrote: Signed-Off-By: Daniel Walker [EMAIL PROTECTED] --- drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 30 - 1 file changed, 15 insertions(+), 15 deletions(-) Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c === --- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c +++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c @@ -43,7 +43,7 @@ static struct bcm43xx_debugfs fs; static char really_big_buffer[REALLY_BIG_BUFFER_SIZE]; -static DECLARE_MUTEX(big_buffer_sem); +static DEFINE_MUTEX(big_buffer_mutex); This driver is scheduled for removal, so I'd not touch it anymore to avoid the possibility to introduce a lastminute regression. The new drivers (b43 and b43legacy) have this fixed (in a different way by completely removing it). -- 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 Thu, 2007-12-13 at 01:48 +0100, Michael Buesch wrote: On Wednesday 12 December 2007 09:00:03 Daniel Walker wrote: Signed-Off-By: Daniel Walker [EMAIL PROTECTED] --- drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 30 - 1 file changed, 15 insertions(+), 15 deletions(-) Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c === --- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c +++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c @@ -43,7 +43,7 @@ static struct bcm43xx_debugfs fs; static char really_big_buffer[REALLY_BIG_BUFFER_SIZE]; -static DECLARE_MUTEX(big_buffer_sem); +static DEFINE_MUTEX(big_buffer_mutex); This driver is scheduled for removal, so I'd not touch it anymore to avoid the possibility to introduce a lastminute regression. The new drivers (b43 and b43legacy) have this fixed (in a different way by completely removing it). When is the removal scheduled? Daniel -- 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 12, 2007 4:48 PM, Michael Buesch [EMAIL PROTECTED] wrote: This driver is scheduled for removal, so I'd not touch it anymore to avoid the possibility to introduce a lastminute regression. The new drivers (b43 and b43legacy) have this fixed (in a different way by completely removing it). Uhm, hijacking the thread a bit here, but which driver is supposed to be supporting my 4309? Neither b43 nor b43legacy found my wireless, and I'm not seeing its PCI ID anywhere either of those... $ lspci -s 02:02 -v; lspci -n -s 02:02 -v -x 02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03) Subsystem: Hewlett-Packard Company Unknown device 12f9 Flags: bus master, fast devsel, latency 64, IRQ 22 Memory at d001 (32-bit, non-prefetchable) [size=8K] 02:02.0 0280: 14e4:4324 (rev 03) Subsystem: 103c:12f9 Flags: bus master, fast devsel, latency 64, IRQ 22 Memory at d001 (32-bit, non-prefetchable) [size=8K] 00: e4 14 24 43 06 00 00 00 03 00 80 02 00 40 00 00 10: 00 00 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 f9 12 30: 00 00 00 00 00 00 00 00 00 00 00 00 05 01 00 00 -- 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/
