Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

[Ray Lee]

On Dec 13, 2007 4:43 PM, Michael Buesch <mb@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/