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. > > > 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. > > > > 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. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev