linux-kernel - Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c0942db0712141155n40ba60agde79e436aa5cb8f2@mail.gmail.com>
Date:	Fri, 14 Dec 2007 11:55:43 -0800
From:	"Ray Lee" <ray-lk@...rabbit.org>
To:	"Michael Buesch" <mb@...sch.de>
Cc:	"Ingo Molnar" <mingo@...e.hu>, bcm43xx-dev@...ts.berlios.de,
	"Daniel Walker" <dwalker@...sta.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux@...mer.net,
	jonathan@...masters.org, matthias.kaehlcke@...il.com,
	kjwinchester@...il.com, "John Linville" <linville@...driver.com>,
	"Larry Finger" <Larry.Finger@...inger.net>
Subject: Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex

On Dec 14, 2007 11:38 AM, Michael Buesch <mb@...sch.de> wrote:
> On Friday 14 December 2007 20:25:39 Ray Lee wrote:
> > > 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!
>
> Guy... .
> I KNOW what the patch above does.
> What do you think does the following line?
>         err = request_module("rfkill-input");
> Does it load the "rfkill-input" or the "rfkill" module.
> That's the million dollar question. You only have one try.

Oh. My. God.

Michael. I have a degree in Physics. I placed sixth in the world
finals of the ACM Collegiate programming contest in 1999, Cal Poly
Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html
, I'm the guy all the way to the right. ) I ported the 2.4 kernel to a
custom ppc platform, including writing drivers for various hardware on
it ( http://patinc.com ). I'm the guy who did all the software for a
linux-based Voice over IP call center (
http://broncocommunications.com/ ).

So, *now* do you believe I'm not an idiot?

To answer your question, it requests the rfkill-input module. But
under the version I'm trying, rfkill-input is not automatically
loaded. I've pointed to the mailing list URL that proves that. So, I
loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't
necessary, I don't know, and I don't care. But once I did that, *then
and only then* did your damn b43 driver start printing out any
messages to dmesg at all, which then let me download the latest
firmware, and continue moving forward.

> You are telling me that I don't understand patches that I sign off
> and I should not take this personally?
> That is challenging.

I'm saying the patch you signed off on has a side-effect that will fix
my issue. And even if I *were* saying that, the most you should take
from it is that you are human and sometimes may make mistakes, just
like the rest of us. There's nothing challenging in that statement.

I've provided the bug report as many ways as I can think to. If you
don't agree, then I guess you'll just have to get the bug report from
someone else who can figure out exactly how to sugar coat the message
so that you'll listen to it.

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