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: <2c0942db0712141045nf7bf730l677936614f7db736@mail.gmail.com>
Date:	Fri, 14 Dec 2007 10:45:02 -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

I've run out of time to donate to the kernel today, so I'll keep this short.

On Dec 14, 2007 10:22 AM, Michael Buesch <mb@...sch.de> wrote:
> > > If you have a PCI device probing works as follows:
> > > The PCI table is in ssb. So as soon as your kernel detects the PCI device
> > > it will load ssb. ssb will register the PCI device. That will trigger
> > > an udev event for the contained 802.11 core to get probed. This will load
> > > b43.
> > >
> > > So, I'm not sure where's the issue with my code here.
> >
> > There's a patch from Larry Finger to address this and other issues. It
> > hasn't made it's way fully upstream yet. 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
>
> 1) I sent this patch out today for inclusion in the kernel
> 2) This is a _completely_ unrelated issue.
>    It is about "rfkill-input" being not loaded. NOT about
>    "b43" or "rfkill" not being loaded.
[...]
> > So, do you want a scorecard on this?
> >
> > 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 have complete current userspace as of yesterday's Ubuntu Hardy Heron
development archives.

One last thing. I've been nice to you. Please be nice to me. If you
can't manage that, then let another wireless developer take over.

You apparently think I'm an idiot. I'm not, and if necessary I could
supply a long list of credentials to prove I'm not an idiot. I'd
rather you just accepted my emails at face value and spent more effort
on trying to see how the bugs could be occurring rather than spending
effort on trying to prove that I'm an idiot.

Thanks.

Ray
--
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/