login
Search
Signed-Off-By: Daniel Walker <dwalker@mvista.com>
---
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:
...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. --
When is the removal scheduled? Daniel --
Patches are on their way. I think it's scheduled to be removed after 2.6.25 was released. -- Greetings Michael. --
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 <shemminger@linux-foundation.org> --------------------------- + +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 <linville@tuxdriver.com> + +--------------------------- Hth! John -- John W. Linville linville@tuxdriver.com --
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 d0010000 (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 d0010000 (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
--
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.
--
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:
lo no 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.
--
I don't know. Try ifconfig -a Oh come on. b43 is more than a year old now. How long should we wait? Two or three? Forever? -- Greetings Michael. --
Any pointers to the advantages of b43? Harvey --
http://www.linuxwireless.org/en/users/Drivers/b43 -- Greetings Michael. --
possibly forever, if you dont get obvious regressions like "my wlan does not work" (reported in this very thread), resolved. Pushing the blame to udev (in a rather unfriendly way) wont give users a working system and wont get you many new testers for the new driver either. Ingo --
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 linville@tuxdriver.com --
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 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 --
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. --
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
--
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 Which testers? Ray Lee didn't even install the firmware. So it can't work by definition. 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 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. --
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? 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 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 --
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
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.
--
^^^^^^^^^^^^^^ So the question seems to be why b43 needs version 4, when b43legacy and bcm43x uses version 3? Simon Holm Thøgersen --
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. --
Actually, can you explain why, from the technical point of view, the version 4 firware is better than version 3, please? Rafael --
version 4 is the new firmware released by broadcom. They obviously won't support and write any version 3 firmware anymore. So we are forced to switch to version 4 firmware to support the newest hardware (like N-PHY in the future). It's really as simple as that. The difference between v3 and v4 is basically the driver API. It changed a lot and it is nontrivial to support both v3 and v4 in one driver. So we decided to stay with v3 for legacy devices and take v4 for any newer devices. We have to live with that crap until someone comes up with an opensource firmware. :) -- Greetings Michael. --
Well, the only problem with that is I suspect there are some "newer" cards that work better with v3 firmware, although they are supposed to support both. Greetings, Rafael --
And I suspect that you are wrong until you show me one. :) -- Greetings Michael. --
h. Impossible. The firmware is only the MAC. johannes
I should probably mention though that of course it is (in theory!) possible that the card works better with bcm43xx, it just never has happened for all I know. johannes
The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power control problem was "solved" in b43, there is very little difference. When I built my special system to use the BCM4311 with b43legacy, there was no difference. I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing SoftMAC with mac80211. There is, of course, no comparison. Larry --
This was about version 3 firmware vs version 4 firmware. I doubt the firmware makes any difference at all. -- Greetings Michael. --
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 --
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. --
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, 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 --
Hi all. Perhaps I can inject some facts into this? 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, Heeeeellooooo? 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 ...
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. 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. 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. --
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* 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 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: <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 As I've said multiple times earlier in this thread, I did try that and 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 ...
That is a bug in your distribution. I cannot fix this. 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. 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 Yeah. A problem preventing a LED from blinking. That's not b43 specific. And it is not a bug. Ignore wmaster. 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. Have fun. -- Greetings Michael. --
I've run out of time to donate to the kernel today, so I'll keep this short. 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 --
*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 I'm not asking you to do that, this particular bug will be fixed by 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, 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 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? --
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 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. --
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. 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. 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 Ok. So please revert that patch and try to reproduce the breakage. 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. --
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 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 Thanks for treating me like an adult. --
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
--
