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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
