[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200712142113.09119.mb@bu3sch.de>
Date: Fri, 14 Dec 2007 21:13:08 +0100
From: Michael Buesch <mb@...sch.de>
To: "Ray Lee" <ray-lk@...rabbit.org>
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 Friday 14 December 2007 20:55:43 Ray Lee wrote:
> 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/ ).
Nice. I am one of the main b43 developers and I wrote most of the code.
I know most of the code from the top of my head.
Besides that my weiner is bigger than yours. :P
> To answer your question, it requests the rfkill-input module. But
> under the version I'm trying, rfkill-input is not automatically
> loaded.
It is not an issue. You can even rmmod rfkill-input in FULL operation.
It will not disturb the operation, except that an LED stops working.
Try it! (I _did_ try it).
> 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.
The b43 does print _nothing_ on modprobe. That is _correct_ behaviour.
b43 does print the firmware message after "ifconfig up".
Might it be possible that this was coincidence and you messed
with modprobe rfkill and ifconfig up and finally saw the message?
> > 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
Ok. So please revert that patch and try to reproduce the breakage.
Does that work?
> from it is that you are human and sometimes may make mistakes, just
I am inhuman. We all know that.
(That was a joke that you probably don't understand. But you can google
for "bcw vs. bcm43xx" :) )
Ray, I _do_ want to understand what is going on in your machine.
I _have_ to understand it. But I currently do not understand how the
quoted patch could fix modprobe of b43 or rfkill. I'd simply call that
impossible.
Impossible because the patch does change a few function called _inside_
of the b43 module. How could that fix load of the b43 module? (Note that
we are not changing some modprobe magic like the ID table).
So could you please try to reproduce the breakage by reverting that
patch again? Just to make really sure it is this patch fixing the issue
and not just some coincidence.
Thanks for your help.
--
Greetings Michael.
--
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/
Powered by blists - more mailing lists