Hi all. Perhaps I can inject some facts into this?

On Dec 14, 2007 5:08 AM, Michael Buesch <mb@bu3sch.de> wrote:
quoted text
> > > 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, 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,
and thank you for that.

quoted text
> > well i dont have this hardware, but the following description in this
> > thread seems to contradict that:
> >
> > || 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.

See above. Without a modprobe of rfkill, rfkill-input that is the case.

quoted text
> Let's quote another of Ray's statements:
> "And ifconfig -a does indeed show it, sorry about that."
>
> So if he did then try to initialize that device, that clearly
> _did_ show up in a standard place where network devices are
> expected to show up, he did see the message I quoted.
> Well, what if he did not try to initialize the device by doing
> an "ifconfig wlanX up"? That can hardly be my fault, right?

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 go
a lot smoother.

Thanks.

Ray
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/