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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Dec 14, 2007 11:05 AM, Michael Buesch <[email protected]> wrote:
> On Friday 14 December 2007 19:45:02 Ray Lee wrote:
> > > > 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.
> >
> > I'm going to say this one last time. If rfkill and rfkill-input aren't
> > manually loaded before sb and b43, not one damn thing comes out in
> > dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to
> > find out that those modules had to be loaded by hand was to go read
> > the bcm43xx-dev archives. Once those were loaded, messages came out in
> > dmesg pointing me to the URL for updated firmware.
>
> I'm sorry. The patch that _you_ quoted fixes a blinking LED
> and nothing else.

Well, you're wrong. Sorry, but that's just the way it is. See below.

> It does _not_ fix loading of rfkill or b43 in any way.
> It does, however, fix loading of rfkill-input. But the b43 module
> operation does _not_ depend in any way on the rfkill-input module, except
> the tiny LED that doesn't blink if it's not loaded.
> I hope you understood now that the thread on bcm43xx-dev was NOT about
> your requirement to load rfkill before b43.

*AGAIN*, 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

For the last fscking time, if rfkill and rfkill-input are not loaded,
not one line comes out in dmesg when b43 and ssb are loaded. In
particular, your pretty little message about needing newer firmware
also does not print. So, yeah, not loading rfkill{,-input} *does*
cause issues with b43 working, as there's no damn way to find out
what's broken!

> > I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> > development archives.
>
> Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
> reproduce this.

I'm not asking you to do that, this particular bug will be fixed by
Larry's patch, whether you believe that or not.

> However the fact that this does not happen on older Ubuntu platforms
> and does not happen on Fedora leads to the conclusion that it
> is a bug in Hardy Heron that I am not responsible for.

The kernel does not exist in a vacuum. It's the kernel's job to make
sure it works with properly written userspace. Broken userspace, sure,
then we can talk about breaking it.

> And you also do realise that Hardy Heron is the current development
> version of Ubuntu? Development versions have bugs.

Oy vay. I'm not an idiot. Yes, it's the current develoment version.
But tracking the latest kernel.org kernel has in the past required the
latest develoment version of the distribution, so I upgrade it as
well.

> > One last thing. I've been nice to you. Please be nice to me.
>
> If you simply stop blaming bugs on me that I am not responsible for
> at all, that is a deal. What about filing a bug at the ubuntu bugzilla?

I'm not blaming it on you. I'm merely reporting a fucking
incompatibility. Read my messages again from the top, and stop taking
this all so damn personally, will you?
--
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]
  Powered by Linux