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: > > > > 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? > > 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/