* Broadcom cards for free
From: Michael Buesch @ 2009-10-09 9:39 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: linux-wireless
Hi,
I've currently got two Broadcom cards to offer for free.
http://bu3sch.de/misc/bcmcards.JPG
The cardbus one is a WPC300N V1 802.11n card.
It can be used for development of the b43 N-PHY code.
The USB one is BCM4320 which works over RNDIS-WLAN.
This device is disassembled and the EEPROM, which contains
the on-board operating system, is unsoldered and connected through a pinheader.
That means it can be read and/or reprogrammed outside of the device.
The RF-shield on the RF-side of the board was removed.
The device should work properly. It properly registers to the kernel, but I did
not try if it works with the rndis-wlan driver.
--
Greetings, Michael.
^ permalink raw reply
* Re: Broadcom cards for free
From: Gábor Stefanik @ 2009-10-09 10:14 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, linux-wireless
In-Reply-To: <200910091139.36089.mb@bu3sch.de>
Sounds interesting... especially now that N-PHY is actually being
reverse-engineered (or is it?).
The modded 4320 is an attempt to replace the built-in OS and use it
with b43 as a softmac device... am I right?
On 10/9/09, Michael Buesch <mb@bu3sch.de> wrote:
> Hi,
>
> I've currently got two Broadcom cards to offer for free.
> http://bu3sch.de/misc/bcmcards.JPG
>
> The cardbus one is a WPC300N V1 802.11n card.
> It can be used for development of the b43 N-PHY code.
>
> The USB one is BCM4320 which works over RNDIS-WLAN.
> This device is disassembled and the EEPROM, which contains
> the on-board operating system, is unsoldered and connected through a
> pinheader.
> That means it can be read and/or reprogrammed outside of the device.
> The RF-shield on the RF-side of the board was removed.
> The device should work properly. It properly registers to the kernel, but I
> did
> not try if it works with the rndis-wlan driver.
>
> --
> Greetings, Michael.
> _______________________________________________
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: Broadcom cards for free
From: Michael Buesch @ 2009-10-09 10:34 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: bcm43xx-dev, linux-wireless
In-Reply-To: <69e28c910910090314j4e9885dfofbc58e901965b4ab@mail.gmail.com>
On Friday 09 October 2009 12:14:24 Gábor Stefanik wrote:
> Sounds interesting... especially now that N-PHY is actually being
> reverse-engineered (or is it?).
I don't know if somebody is working on it, but the card could be useful for
somebody working on it.
> The modded 4320 is an attempt to replace the built-in OS and use it
> with b43 as a softmac device... am I right?
No, it was used to read the EEPROM. There were no attempts to reverse-engineer
and rewrite the EEPROM, however one can do that with this device.
It contains about 300kb data, so it's probably hard to reverse engineer.
However, I think there's no need to start over from zero, because most parts
of the device should be known. They're most likely just running their portable
driver kit on it.
--
Greetings, Michael.
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-08
From: John W. Linville @ 2009-10-09 13:23 UTC (permalink / raw)
To: Michael Buesch; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <200910090108.08838.mb@bu3sch.de>
On Fri, Oct 09, 2009 at 01:08:06AM +0200, Michael Buesch wrote:
> On Friday 09 October 2009 00:34:54 John W. Linville wrote:
> > Albert Herranz (1):
> > b43: do not stack-allocate pio rx/tx header and tail buffers
>
> Come on, this is _not_ funny anymore. I did _not_ ack this patch, because I do _not_ like it.
> I was planning to do a better solution, but I didn't have the time, yet.
> Can you _please_ either:
> - Wait for my ack before you apply random b43 patches
> or
> - Remove me from MAINTAINERS
Michael,
After Albert posted his first version of the patch, you said:
"Just embed it into struct b43_wl (surround it by #ifdef CONFIG_B43_PIO). No need
to kzalloc then and it saves some memory.
You also need to alloc 4 bytes for the tail buffer (that currently is on the stack, too)."
AFAICT he complied with that request when he posted the second version.
Since the patch seemed fine otherwise, I applied it; and since it is
a fix I sent it on for 2.6.32.
As Dave suggested, there is plenty of time to fix it "properly"
for 2.6.33 and beyond. I'm happy to accomodate you.
John
P.S. Please understand that while some driver maintainers want to
ack every patch, others see that as a burden and get annoyed with me
if I don't apply reasonable patches without bothering them. It can
be a bit difficult these things...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-10-08
From: Michael Buesch @ 2009-10-09 13:49 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20091009132317.GA22719@tuxdriver.com>
On Friday 09 October 2009 15:23:17 John W. Linville wrote:
> On Fri, Oct 09, 2009 at 01:08:06AM +0200, Michael Buesch wrote:
> > On Friday 09 October 2009 00:34:54 John W. Linville wrote:
> > > Albert Herranz (1):
> > > b43: do not stack-allocate pio rx/tx header and tail buffers
> >
> > Come on, this is _not_ funny anymore. I did _not_ ack this patch, because I do _not_ like it.
> > I was planning to do a better solution, but I didn't have the time, yet.
> > Can you _please_ either:
> > - Wait for my ack before you apply random b43 patches
> > or
> > - Remove me from MAINTAINERS
>
> Michael,
>
> After Albert posted his first version of the patch, you said:
>
> "Just embed it into struct b43_wl (surround it by #ifdef CONFIG_B43_PIO). No need
> to kzalloc then and it saves some memory.
> You also need to alloc 4 bytes for the tail buffer (that currently is on the stack, too)."
>
> AFAICT he complied with that request when he posted the second version.
Yeah, but I don't like the result for reasons I already said.
I'll send another patch that moves the structure back and cleans up stuff later.
> Since the patch seemed fine otherwise, I applied it; and since it is
> a fix I sent it on for 2.6.32.
Well, we once had a rule that not everything that remotely looks like a fix should
go in, after the merge window closed. AFAIR this rule was made by Linus and I think
it does make sense, in some way.
This touched a lot of crap for fixing something that
a) is not a bug on any officially supported device
b) just triggers a harmless warning on devices that virtually nobody owns and/or
runs linux on (Nintendo Wii), if some specific debugging option is enabled.
So I don't buy the argument that suddenly millions over millions of bugreports will
flood the lists, if we didn't apply this.
I think we should be more careful about what patches are applied. Otherwise I'm sure
Linus will start to complain about crap pull requests with huge modifications again.
And he'd be right.
> P.S. Please understand that while some driver maintainers want to
> ack every patch, others see that as a burden and get annoyed with me
> if I don't apply reasonable patches without bothering them. It can
> be a bit difficult these things...
Yeah, however I think I _do_ respond very quickly to any patch that matters
with either an ack or comments.
I think it's always a good idea to wait for a final ack on a patch that
a maintainer complained about. If nobody complained, well that's a different thing.
I'd still prefer a review delay of at least 24hours for those, to ensure somebody
knowing the code has a chance to look at them.
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] b43: add 'struct b43_wl' missing declaration
From: Miguel Boton @ 2009-10-09 14:13 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-kernel, mb, linville, bcm43xx-dev
'struct b43_wl' declaration is missing at 'leds.h'.
It should be declared to avoid getting some GCC warnings at 'b43_leds_unregister'.
Signed-off-by: Miguel Botón <mboton@gmail.com>
---
drivers/net/wireless/b43/leds.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/b43/leds.h b/drivers/net/wireless/b43/leds.h
index 4c56187..32b66d5 100644
--- a/drivers/net/wireless/b43/leds.h
+++ b/drivers/net/wireless/b43/leds.h
@@ -1,6 +1,7 @@
#ifndef B43_LEDS_H_
#define B43_LEDS_H_
+struct b43_wl;
struct b43_wldev;
#ifdef CONFIG_B43_LEDS
^ permalink raw reply related
* Re: [PATCH] b43: add 'struct b43_wl' missing declaration
From: Michael Buesch @ 2009-10-09 14:29 UTC (permalink / raw)
To: Miguel Boton; +Cc: linux-wireless, linux-kernel, linville, bcm43xx-dev
In-Reply-To: <200910091613.53960.mboton@gmail.com>
On Friday 09 October 2009 16:13:53 Miguel Boton wrote:
> 'struct b43_wl' declaration is missing at 'leds.h'.
> It should be declared to avoid getting some GCC warnings at 'b43_leds_unregister'.
>
> Signed-off-by: Miguel Botón <mboton@gmail.com>
ack
(That was fast enough, eh? :D)
>
> ---
>
> drivers/net/wireless/b43/leds.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/b43/leds.h b/drivers/net/wireless/b43/leds.h
> index 4c56187..32b66d5 100644
> --- a/drivers/net/wireless/b43/leds.h
> +++ b/drivers/net/wireless/b43/leds.h
> @@ -1,6 +1,7 @@
> #ifndef B43_LEDS_H_
> #define B43_LEDS_H_
>
> +struct b43_wl;
> struct b43_wldev;
>
> #ifdef CONFIG_B43_LEDS
>
>
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] b43: add 'struct b43_wl' missing declaration
From: Larry Finger @ 2009-10-09 14:34 UTC (permalink / raw)
To: Miguel Boton; +Cc: linux-wireless, linux-kernel, mb, linville, bcm43xx-dev
In-Reply-To: <200910091613.53960.mboton@gmail.com>
On 10/09/2009 09:13 AM, Miguel Boton wrote:
> 'struct b43_wl' declaration is missing at 'leds.h'.
> It should be declared to avoid getting some GCC warnings at 'b43_leds_unregister'.
>
> Signed-off-by: Miguel Botón <mboton@gmail.com>
What architecture? There must be something strange with your
configuration as I see no such warnings. Please post your .CONFIG.
Larry
^ permalink raw reply
* Broken patch for b43
From: Larry Finger @ 2009-10-09 15:15 UTC (permalink / raw)
To: John Linville; +Cc: wireless, bcm43xx devel
Hi,
Unfortunately, my patch entitled "43: Fix PPC crash in rfkill polling
on unload" had more problems than a locking error. When you switch the
RF off, you cannot turn the radio back on without unloading/reloading
the module.
I have an alternative fix for the PPC that is now being tested;
however, it may just restrict the unload/load problem to older models.
To know whether that is a possibility, I need to know if anyone has a
G PHY device with PHY revision <= 2 that also has an RFKILL switch.
Note: LP PHYs (ID of 4315) will have such revisions, but they do not
count.
Thanks,
Larry
^ permalink raw reply
* Re: Broadcom cards for free
From: Larry Finger @ 2009-10-09 15:22 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: Michael Buesch, bcm43xx-dev, linux-wireless
In-Reply-To: <69e28c910910090314j4e9885dfofbc58e901965b4ab@mail.gmail.com>
On 10/09/2009 05:14 AM, Gábor Stefanik wrote:
> Sounds interesting... especially now that N-PHY is actually being
> reverse-engineered (or is it?).
I'm still working on it, although a lot of my time is taken in testing
openSUSE 11.2 pre-release code. As the release date is Nov. 12, that
will soon be over.
Larry
^ permalink raw reply
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Randy Dunlap @ 2009-10-09 16:06 UTC (permalink / raw)
To: Johannes Berg, gregkh, devel
Cc: John W. Linville, linux-wireless, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <1255026563.3713.28.camel@johannes.local>
On Thu, 08 Oct 2009 20:29:23 +0200 Johannes Berg wrote:
> On Thu, 2009-10-08 at 08:06 -0700, Randy Dunlap wrote:
>
> > > It's kinda strange though that you can select wireless drivers without
> > > selecting WIRELESS. Maybe the solution is as simple as making WLAN
> > > (drivers/net/wireless/Kconfig) depend on WIRELESS?
> >
> > Yes, I think that would be a very good start.
>
> On the other hand, of course, the whole WIRELESS thing is somewhat
> stupid. How about this?
>
> johannes
>
> From: Johannes Berg <johannes@sipsolutions.net>
> Subject: wireless: make wireless drivers select core
>
> It is somewhat non-sensical to allow selecting wireless
> drivers without showing wireless core code options, and
> since the wext refactoring this has made it possible to
> generate configurations that will not build. Avoid this
> and make wireless drivers select the wireless options.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> drivers/net/wireless/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- wireless-testing.orig/drivers/net/wireless/Kconfig 2009-10-08 20:25:04.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/Kconfig 2009-10-08 20:27:38.000000000 +0200
> @@ -5,6 +5,7 @@
> menuconfig WLAN
> bool "Wireless LAN"
> depends on !S390
> + select WIRELESS
> default y
> ---help---
> This section contains all the pre 802.11 and 802.11 wireless
I suppose that's OK, although I prefer "depends" rather than "select".
I tracked down one of the problems that I was seeing:
net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
with:
# CONFIG_WIRELESS is not set
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_PRIV=y
This is being caused by several drivers in drivers/staging/ doing
select WEXT_PRIV
without using either enough dependencies or even more (ugly) selects.
(or just because kconfig isn't sufficient)
---
~Randy
^ permalink raw reply
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Johannes Berg @ 2009-10-09 16:14 UTC (permalink / raw)
To: Randy Dunlap
Cc: gregkh, devel, John W. Linville, linux-wireless, Stephen Rothwell,
linux-next, linux-kernel
In-Reply-To: <20091009090601.73de5dc6.randy.dunlap@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
On Fri, 2009-10-09 at 09:06 -0700, Randy Dunlap wrote:
> > menuconfig WLAN
> > bool "Wireless LAN"
> > depends on !S390
> > + select WIRELESS
> > default y
> > ---help---
> > This section contains all the pre 802.11 and 802.11 wireless
>
>
> I suppose that's OK, although I prefer "depends" rather than "select".
I tend to as well, but in this case the WIRELESS itself is just an
option that makes other options invisible, it's not used elsewhere, and
as such I think this is ok -- why hide the wireless drivers unless the
user first selects the wireless core options?
OTOH, you already need to select cfg80211/mac80211 for most drivers, so
I suppose "depends on WIRELESS" would be ok too.
> I tracked down one of the problems that I was seeing:
>
> net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
>
> with:
> # CONFIG_WIRELESS is not set
> CONFIG_WIRELESS_EXT=y
> CONFIG_WEXT_PRIV=y
>
> This is being caused by several drivers in drivers/staging/ doing
> select WEXT_PRIV
> without using either enough dependencies or even more (ugly) selects.
> (or just because kconfig isn't sufficient)
Hah, staging/, well, that's kinda hard to solve I guess. Except by
fixing all the staging/ drivers to depend on WIRELESS too, like the
patch would do for the regular drivers.
I think you can get the same effect now with the non-staging drivers.
I'll submit this patch formally and ask John to include it, and staging/
can just depend on WIRELESS.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] wireless: make wireless drivers select core
From: Johannes Berg @ 2009-10-09 16:17 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Randy Dunlap
It is somewhat non-sensical to allow selecting wireless
drivers without showing wireless core code options, and
since the wext refactoring this has made it possible to
generate configurations that will not build. Avoid this
and make wireless drivers select the wireless options.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/net/wireless/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- wireless-testing.orig/drivers/net/wireless/Kconfig 2009-10-08 20:25:04.000000000 +0200
+++ wireless-testing/drivers/net/wireless/Kconfig 2009-10-08 20:27:38.000000000 +0200
@@ -5,6 +5,7 @@
menuconfig WLAN
bool "Wireless LAN"
depends on !S390
+ select WIRELESS
default y
---help---
This section contains all the pre 802.11 and 802.11 wireless
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Frans Pop @ 2009-10-09 16:27 UTC (permalink / raw)
To: Mike Galbraith
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <1255070103.7639.30.camel@marge.simson.net>
On Friday 09 October 2009, Mike Galbraith wrote:
> sched: update the clock of runqueue select_task_rq() selected.
>
> In try_to_wake_up(), we update the runqueue clock, but select_task_rq()
> may select a different runqueue than the one we updated, leaving the new
> runqueue's clock stale for a bit.
>
> This patch cures occasional huge latencies reported by latencytop when
> coming out of idle on a mostly idle NO_HZ box.
This patch (without Arjan's previous one applied) also fixes my latency
issues. Nice work!
Cheers,
FJP
^ permalink raw reply
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Greg KH @ 2009-10-09 16:32 UTC (permalink / raw)
To: Johannes Berg
Cc: Randy Dunlap, devel, John W. Linville, linux-wireless,
Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <1255104846.4095.2.camel@johannes.local>
On Fri, Oct 09, 2009 at 06:14:06PM +0200, Johannes Berg wrote:
> On Fri, 2009-10-09 at 09:06 -0700, Randy Dunlap wrote:
>
> > > menuconfig WLAN
> > > bool "Wireless LAN"
> > > depends on !S390
> > > + select WIRELESS
> > > default y
> > > ---help---
> > > This section contains all the pre 802.11 and 802.11 wireless
> >
> >
> > I suppose that's OK, although I prefer "depends" rather than "select".
>
> I tend to as well, but in this case the WIRELESS itself is just an
> option that makes other options invisible, it's not used elsewhere, and
> as such I think this is ok -- why hide the wireless drivers unless the
> user first selects the wireless core options?
>
> OTOH, you already need to select cfg80211/mac80211 for most drivers, so
> I suppose "depends on WIRELESS" would be ok too.
>
> > I tracked down one of the problems that I was seeing:
> >
> > net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
> >
> > with:
> > # CONFIG_WIRELESS is not set
> > CONFIG_WIRELESS_EXT=y
> > CONFIG_WEXT_PRIV=y
> >
> > This is being caused by several drivers in drivers/staging/ doing
> > select WEXT_PRIV
> > without using either enough dependencies or even more (ugly) selects.
> > (or just because kconfig isn't sufficient)
>
> Hah, staging/, well, that's kinda hard to solve I guess. Except by
> fixing all the staging/ drivers to depend on WIRELESS too, like the
> patch would do for the regular drivers.
That's fine, I'll gladly take patches to do that.
thanks,
greg k-h
^ permalink raw reply
* b43: do not stack-allocate pio rx/tx header and tail buffers (was: pull request: wireless-2.6 2009-10-08)
From: Albert Herranz @ 2009-10-09 17:46 UTC (permalink / raw)
To: mb; +Cc: bcm43xx-dev, linux-netdev, linux-wireless, linux-kernel
In-Reply-To: <4ACCD765.7080604@lwfinger.net>
Michael,
> Wait for my ack before you apply random b43 patches
^^^^^^
> The patch needlessly moves huge chunks of crap, adds stupid comments, wastes memory.
^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^
> This touched a lot of crap for fixing something that
^^^^^^^^^^^^^^^^^^^^^
If using that strong language helps you get your anger out of you I'm fine with that. But I think it is a bit unfair.
I'm not arguing if the patch should have been immediately merged upstream or not without your ack (I'm probably more on your side here, as the patch was still being discussed on the ML).
The patch [1] may not be up to your quality standards or may not take into account other requirements (that you have not expressed nor on the ML nor on IRC) but I'm sure it's far from being "random", "move crap" or "add stupid comments". That's the unfair part.
The reason I posted the initial patch for review was because you kind of told me [2].
[20:06] <mb_> Anyway, I'm not going to fix this. If you need it fixed, please send patches
Then I tried to address your concerns [3] and sent v2 (the patch merged).
In that patch I moved slightly struct b43_wl within b43.h to satisfy the dependencies generated by the addition of the new members to that struct (which was one of your concerns).
There was even a bit of public discussion about the relocation of the struct declaration [4].
After ~22 hours if I'm not mistaken (yes, less than 24...) John, who had previously expressed his intentions to merge the patch [5], picked it for wireless-2.6.
And a day later, more or less again, John did the GIT PULL request.
That's it. IMHO, even if the patch was (mistakenly) merged too early for your standards, it doesn't break anything (AFAIK) and delivers what promises.
And (yes!) it can still be modeled to perfection later.
My point here is that there's no reason for such strong words concerning the quality of the patch code. It's really not that bad for such wording.
I'm sure that if the patch was really crap it would have been immediately NAK'ed by you or by any sane maintainer.
Other than that, I'm happy to see that the side conflict generated seems to be in a good shape now.
It would have been a total waste otherwise.
Thanks,
Albert
PS: Sorry to generate a new post, but I wasn't directly CC'ed on this and I'm not subscribed to the MLs. And I did also want to express my opinion! :)
[1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff;h=7e937c633f718e0916a294db7282c922c1bf3ce3
[2] http://bcm-specs.sipsolutions.net/irc-logs/bcm-specs.2009-10-01
[3] http://marc.info/?l=linux-wireless&m=125486249831043
[4] http://marc.info/?l=linux-wireless&m=125493883613139
[5] http://marc.info/?l=linux-wireless&m=125486386100505
^ permalink raw reply
* Re: b43: do not stack-allocate pio rx/tx header and tail buffers (was: pull request: wireless-2.6 2009-10-08)
From: Michael Buesch @ 2009-10-09 18:05 UTC (permalink / raw)
To: Albert Herranz; +Cc: bcm43xx-dev, linux-netdev, linux-wireless, linux-kernel
In-Reply-To: <4ACF76F7.30406@yahoo.es>
On Friday 09 October 2009 19:46:31 Albert Herranz wrote:
> I'm not arguing if the patch should have been immediately merged upstream or not without your ack (I'm probably more on your side here, as the patch was still being discussed on the ML).
> The patch [1] may not be up to your quality standards or may not take into account other requirements (that you have not expressed nor on the ML nor on IRC) but I'm sure it's far from being "random", "move crap" or "add stupid comments". That's the unfair part.
>
> The reason I posted the initial patch for review was because you kind of told me [2].
>
> [20:06] <mb_> Anyway, I'm not going to fix this. If you need it fixed, please send patches
Yeah, but that doesn't mean that either hack is acceptable. It just means that my time is limited
and I added this non-issue (which I still think it is) to the very bottom of my priority list.
> After ~22 hours if I'm not mistaken (yes, less than 24...) John, who had previously expressed his intentions to merge the patch [5], picked it for wireless-2.6.
> And a day later, more or less again, John did the GIT PULL request.
My impression was, that if the maintainer rejects a patch and asks for a new version,
the upstream maintainer must not take the patch until the maintainer acked the new version.
It seems I was wrong, though.
> My point here is that there's no reason for such strong words concerning the quality of the patch code. It's really not that bad for such wording.
> I'm sure that if the patch was really crap it would have been immediately NAK'ed by you or by any sane maintainer.
It _was_ immediately NAK'ed by me. I did not know that I need to NAK
every single new version of a patch explicitely.
I thought NAK-ing a patch would put it into some special state that only an explicit ACK could
take it out of.
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] b43/legacy: Fix usage of host_pci pointer
From: Michael Buesch @ 2009-10-09 18:30 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless
We must check the bustype before using the host_pci pointer.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
This does not fix a bug, but is required for a future patch which puts
the pointer into a union.
Index: wireless-testing/drivers/net/wireless/b43/main.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-10-09 18:47:03.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c 2009-10-09 18:47:52.000000000 +0200
@@ -4671,7 +4671,7 @@ static int b43_wireless_core_attach(stru
{
struct b43_wl *wl = dev->wl;
struct ssb_bus *bus = dev->dev->bus;
- struct pci_dev *pdev = bus->host_pci;
+ struct pci_dev *pdev = (bus->bustype == SSB_BUSTYPE_PCI) ? bus->host_pci : NULL;
int err;
bool have_2ghz_phy = 0, have_5ghz_phy = 0;
u32 tmp;
@@ -4804,7 +4804,7 @@ static int b43_one_core_attach(struct ss
if (!list_empty(&wl->devlist)) {
/* We are not the first core on this chip. */
- pdev = dev->bus->host_pci;
+ pdev = (dev->bus->bustype == SSB_BUSTYPE_PCI) ? dev->bus->host_pci : NULL;
/* Only special chips support more than one wireless
* core, although some of the other chips have more than
* one wireless core as well. Check for this and
Index: wireless-testing/drivers/net/wireless/b43legacy/main.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c 2009-10-09 18:47:03.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43legacy/main.c 2009-10-09 18:47:52.000000000 +0200
@@ -3592,7 +3592,7 @@ static int b43legacy_wireless_core_attac
{
struct b43legacy_wl *wl = dev->wl;
struct ssb_bus *bus = dev->dev->bus;
- struct pci_dev *pdev = bus->host_pci;
+ struct pci_dev *pdev = (bus->bustype == SSB_BUSTYPE_PCI) ? bus->host_pci : NULL;
int err;
int have_bphy = 0;
int have_gphy = 0;
@@ -3706,7 +3706,7 @@ static int b43legacy_one_core_attach(str
if (!list_empty(&wl->devlist)) {
/* We are not the first core on this chip. */
- pdev = dev->bus->host_pci;
+ pdev = (dev->bus->bustype == SSB_BUSTYPE_PCI) ? dev->bus->host_pci : NULL;
/* Only special chips support more than one wireless
* core, although some of the other chips have more than
* one wireless core as well. Check for this and
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] ssb: Put host pointers into a union
From: Michael Buesch @ 2009-10-09 18:32 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless
This slightly shrinks the structure.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Index: wireless-testing/drivers/ssb/driver_pcicore.c
===================================================================
--- wireless-testing.orig/drivers/ssb/driver_pcicore.c 2008-07-20 12:09:34.000000000 +0200
+++ wireless-testing/drivers/ssb/driver_pcicore.c 2009-10-09 19:01:59.000000000 +0200
@@ -551,13 +551,13 @@ int ssb_pcicore_dev_irqvecs_enable(struc
might_sleep_if(pdev->id.coreid != SSB_DEV_PCI);
/* Enable interrupts for this device. */
- if (bus->host_pci &&
- ((pdev->id.revision >= 6) || (pdev->id.coreid == SSB_DEV_PCIE))) {
+ if ((pdev->id.revision >= 6) || (pdev->id.coreid == SSB_DEV_PCIE)) {
u32 coremask;
/* Calculate the "coremask" for the device. */
coremask = (1 << dev->core_index);
+ SSB_WARN_ON(bus->bustype != SSB_BUSTYPE_PCI);
err = pci_read_config_dword(bus->host_pci, SSB_PCI_IRQMASK, &tmp);
if (err)
goto out;
Index: wireless-testing/include/linux/ssb/ssb.h
===================================================================
--- wireless-testing.orig/include/linux/ssb/ssb.h 2009-09-11 21:27:27.000000000 +0200
+++ wireless-testing/include/linux/ssb/ssb.h 2009-10-09 19:10:42.000000000 +0200
@@ -269,7 +269,8 @@ struct ssb_bus {
const struct ssb_bus_ops *ops;
- /* The core in the basic address register window. (PCI bus only) */
+ /* The core currently mapped into the MMIO window.
+ * Not valid on all host-buses. So don't use outside of SSB. */
struct ssb_device *mapped_device;
union {
/* Currently mapped PCMCIA segment. (bustype == SSB_BUSTYPE_PCMCIA only) */
@@ -281,14 +282,17 @@ struct ssb_bus {
* On PCMCIA-host busses this is used to protect the whole MMIO access. */
spinlock_t bar_lock;
- /* The bus this backplane is running on. */
+ /* The host-bus this backplane is running on. */
enum ssb_bustype bustype;
- /* Pointer to the PCI bus (only valid if bustype == SSB_BUSTYPE_PCI). */
- struct pci_dev *host_pci;
- /* Pointer to the PCMCIA device (only if bustype == SSB_BUSTYPE_PCMCIA). */
- struct pcmcia_device *host_pcmcia;
- /* Pointer to the SDIO device (only if bustype == SSB_BUSTYPE_SDIO). */
- struct sdio_func *host_sdio;
+ /* Pointers to the host-bus. Check bustype before using any of these pointers. */
+ union {
+ /* Pointer to the PCI bus (only valid if bustype == SSB_BUSTYPE_PCI). */
+ struct pci_dev *host_pci;
+ /* Pointer to the PCMCIA device (only if bustype == SSB_BUSTYPE_PCMCIA). */
+ struct pcmcia_device *host_pcmcia;
+ /* Pointer to the SDIO device (only if bustype == SSB_BUSTYPE_SDIO). */
+ struct sdio_func *host_sdio;
+ };
/* See enum ssb_quirks */
unsigned int quirks;
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] b43: Optimize PIO scratchbuffer usage
From: Michael Buesch @ 2009-10-09 18:33 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless
This optimizes the PIO scratchbuffer usage.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h 2009-10-09 19:50:15.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/b43.h 2009-10-09 20:15:41.000000000 +0200
@@ -749,12 +749,6 @@ struct b43_wldev {
#endif
};
-/*
- * Include goes here to avoid a dependency problem.
- * A better fix would be to integrate xmit.h into b43.h.
- */
-#include "xmit.h"
-
/* Data structure for the WLAN parts (802.11 cores) of the b43 chip. */
struct b43_wl {
/* Pointer to the active wireless device on this chip */
@@ -830,13 +824,9 @@ struct b43_wl {
struct b43_leds leds;
#ifdef CONFIG_B43_PIO
- /*
- * RX/TX header/tail buffers used by the frame transmit functions.
- */
- struct b43_rxhdr_fw4 rxhdr;
- struct b43_txhdr txhdr;
- u8 rx_tail[4];
- u8 tx_tail[4];
+ /* Kmalloc'ed scratch space for PIO TX/RX. Protected by wl->mutex. */
+ u8 pio_scratchspace[110] __attribute__((__aligned__(8)));
+ u8 pio_tailspace[4] __attribute__((__aligned__(8)));
#endif /* CONFIG_B43_PIO */
};
Index: wireless-testing/drivers/net/wireless/b43/pio.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/pio.c 2009-10-09 19:50:15.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/pio.c 2009-10-09 20:15:41.000000000 +0200
@@ -341,12 +341,15 @@ static u16 tx_write_2byte_queue(struct b
q->mmio_base + B43_PIO_TXDATA,
sizeof(u16));
if (data_len & 1) {
+ u8 *tail = wl->pio_tailspace;
+ BUILD_BUG_ON(sizeof(wl->pio_tailspace) < 2);
+
/* Write the last byte. */
ctl &= ~B43_PIO_TXCTL_WRITEHI;
b43_piotx_write16(q, B43_PIO_TXCTL, ctl);
- wl->tx_tail[0] = data[data_len - 1];
- wl->tx_tail[1] = 0;
- ssb_block_write(dev->dev, wl->tx_tail, 2,
+ tail[0] = data[data_len - 1];
+ tail[1] = 0;
+ ssb_block_write(dev->dev, tail, 2,
q->mmio_base + B43_PIO_TXDATA,
sizeof(u16));
}
@@ -392,27 +395,27 @@ static u32 tx_write_4byte_queue(struct b
q->mmio_base + B43_PIO8_TXDATA,
sizeof(u32));
if (data_len & 3) {
- wl->tx_tail[3] = 0;
+ u8 *tail = wl->pio_tailspace;
+ BUILD_BUG_ON(sizeof(wl->pio_tailspace) < 4);
+
+ memset(tail, 0, 4);
/* Write the last few bytes. */
ctl &= ~(B43_PIO8_TXCTL_8_15 | B43_PIO8_TXCTL_16_23 |
B43_PIO8_TXCTL_24_31);
switch (data_len & 3) {
case 3:
ctl |= B43_PIO8_TXCTL_16_23 | B43_PIO8_TXCTL_8_15;
- wl->tx_tail[0] = data[data_len - 3];
- wl->tx_tail[1] = data[data_len - 2];
- wl->tx_tail[2] = data[data_len - 1];
+ tail[0] = data[data_len - 3];
+ tail[1] = data[data_len - 2];
+ tail[2] = data[data_len - 1];
break;
case 2:
ctl |= B43_PIO8_TXCTL_8_15;
- wl->tx_tail[0] = data[data_len - 2];
- wl->tx_tail[1] = data[data_len - 1];
- wl->tx_tail[2] = 0;
+ tail[0] = data[data_len - 2];
+ tail[1] = data[data_len - 1];
break;
case 1:
- wl->tx_tail[0] = data[data_len - 1];
- wl->tx_tail[1] = 0;
- wl->tx_tail[2] = 0;
+ tail[0] = data[data_len - 1];
break;
}
b43_piotx_write32(q, B43_PIO8_TXCTL, ctl);
@@ -455,6 +458,7 @@ static int pio_tx_frame(struct b43_pio_t
int err;
unsigned int hdrlen;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct b43_txhdr *txhdr = (struct b43_txhdr *)wl->pio_scratchspace;
B43_WARN_ON(list_empty(&q->packets_list));
pack = list_entry(q->packets_list.next,
@@ -462,7 +466,9 @@ static int pio_tx_frame(struct b43_pio_t
cookie = generate_cookie(q, pack);
hdrlen = b43_txhdr_size(dev);
- err = b43_generate_txhdr(dev, (u8 *)&wl->txhdr, skb,
+ BUILD_BUG_ON(sizeof(wl->pio_scratchspace) < sizeof(struct b43_txhdr));
+ B43_WARN_ON(sizeof(wl->pio_scratchspace) < hdrlen);
+ err = b43_generate_txhdr(dev, (u8 *)txhdr, skb,
info, cookie);
if (err)
return err;
@@ -476,9 +482,9 @@ static int pio_tx_frame(struct b43_pio_t
pack->skb = skb;
if (q->rev >= 8)
- pio_tx_frame_4byte_queue(pack, (const u8 *)&wl->txhdr, hdrlen);
+ pio_tx_frame_4byte_queue(pack, (const u8 *)txhdr, hdrlen);
else
- pio_tx_frame_2byte_queue(pack, (const u8 *)&wl->txhdr, hdrlen);
+ pio_tx_frame_2byte_queue(pack, (const u8 *)txhdr, hdrlen);
/* Remove it from the list of available packet slots.
* It will be put back when we receive the status report. */
@@ -624,8 +630,10 @@ static bool pio_rx_frame(struct b43_pio_
unsigned int i, padding;
struct sk_buff *skb;
const char *err_msg = NULL;
+ struct b43_rxhdr *rxhdr = (struct b43_rxhdr *)wl->pio_scratchspace;
- memset(&wl->rxhdr, 0, sizeof(wl->rxhdr));
+ BUILD_BUG_ON(sizeof(wl->pio_scratchspace) < sizeof(*rxhdr));
+ memset(rxhdr, 0, sizeof(*rxhdr));
/* Check if we have data and wait for it to get ready. */
if (q->rev >= 8) {
@@ -663,16 +671,16 @@ data_ready:
/* Get the preamble (RX header) */
if (q->rev >= 8) {
- ssb_block_read(dev->dev, &wl->rxhdr, sizeof(wl->rxhdr),
+ ssb_block_read(dev->dev, rxhdr, sizeof(*rxhdr),
q->mmio_base + B43_PIO8_RXDATA,
sizeof(u32));
} else {
- ssb_block_read(dev->dev, &wl->rxhdr, sizeof(wl->rxhdr),
+ ssb_block_read(dev->dev, rxhdr, sizeof(*rxhdr),
q->mmio_base + B43_PIO_RXDATA,
sizeof(u16));
}
/* Sanity checks. */
- len = le16_to_cpu(wl->rxhdr.frame_len);
+ len = le16_to_cpu(rxhdr->frame_len);
if (unlikely(len > 0x700)) {
err_msg = "len > 0x700";
goto rx_error;
@@ -682,7 +690,7 @@ data_ready:
goto rx_error;
}
- macstat = le32_to_cpu(wl->rxhdr.mac_status);
+ macstat = le32_to_cpu(rxhdr->mac_status);
if (macstat & B43_RX_MAC_FCSERR) {
if (!(q->dev->wl->filter_flags & FIF_FCSFAIL)) {
/* Drop frames with failed FCS. */
@@ -707,22 +715,25 @@ data_ready:
q->mmio_base + B43_PIO8_RXDATA,
sizeof(u32));
if (len & 3) {
+ u8 *tail = wl->pio_tailspace;
+ BUILD_BUG_ON(sizeof(wl->pio_tailspace) < 4);
+
/* Read the last few bytes. */
- ssb_block_read(dev->dev, wl->rx_tail, 4,
+ ssb_block_read(dev->dev, tail, 4,
q->mmio_base + B43_PIO8_RXDATA,
sizeof(u32));
switch (len & 3) {
case 3:
- skb->data[len + padding - 3] = wl->rx_tail[0];
- skb->data[len + padding - 2] = wl->rx_tail[1];
- skb->data[len + padding - 1] = wl->rx_tail[2];
+ skb->data[len + padding - 3] = tail[0];
+ skb->data[len + padding - 2] = tail[1];
+ skb->data[len + padding - 1] = tail[2];
break;
case 2:
- skb->data[len + padding - 2] = wl->rx_tail[0];
- skb->data[len + padding - 1] = wl->rx_tail[1];
+ skb->data[len + padding - 2] = tail[0];
+ skb->data[len + padding - 1] = tail[1];
break;
case 1:
- skb->data[len + padding - 1] = wl->rx_tail[0];
+ skb->data[len + padding - 1] = tail[0];
break;
}
}
@@ -731,15 +742,18 @@ data_ready:
q->mmio_base + B43_PIO_RXDATA,
sizeof(u16));
if (len & 1) {
+ u8 *tail = wl->pio_tailspace;
+ BUILD_BUG_ON(sizeof(wl->pio_tailspace) < 2);
+
/* Read the last byte. */
- ssb_block_read(dev->dev, wl->rx_tail, 2,
+ ssb_block_read(dev->dev, tail, 2,
q->mmio_base + B43_PIO_RXDATA,
sizeof(u16));
- skb->data[len + padding - 1] = wl->rx_tail[0];
+ skb->data[len + padding - 1] = tail[0];
}
}
- b43_rx(q->dev, skb, &wl->rxhdr);
+ b43_rx(q->dev, skb, rxhdr);
return 1;
Index: wireless-testing/drivers/net/wireless/b43/xmit.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/xmit.c 2009-10-09 19:50:15.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/xmit.c 2009-10-09 20:15:41.000000000 +0200
@@ -27,7 +27,7 @@
*/
-#include "b43.h"
+#include "xmit.h"
#include "phy_common.h"
#include "dma.h"
#include "pio.h"
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] b43: Remove me as maintainer
From: Michael Buesch @ 2009-10-09 18:48 UTC (permalink / raw)
To: linville; +Cc: bcm43xx-dev, linux-wireless
Remove me
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
A properly signed-off patch version...
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
--- wireless-testing.orig/MAINTAINERS
+++ wireless-testing/MAINTAINERS
@@ -1066,7 +1066,6 @@ F: include/net/ax25.h
F: net/ax25/
B43 WIRELESS DRIVER
-M: Michael Buesch <mb@bu3sch.de>
M: Stefano Brivio <stefano.brivio@polimi.it>
L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/en/users/Drivers/b43
--
Greetings, Michael.
^ permalink raw reply
* 2.6.31.[12] ath5k regression
From: Richard Zidlicky @ 2009-10-09 14:39 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <20090705123105.GE2132@hash.localnet>
Hi,
ath5k no longer works for me in 2.6.31.[1-2].
2.6.31 worked good enough even though in patched 2.6.30.3 the connection and association
is seemingly more stable.
All tests done in ad-hoc mode with 2 computers, the other end is a rt73usb which
is not quite trouble free either.
I have now confirmed that going back to 2.6.31 the wlan works at least most of the
time and completely stops working after applying this patch on top of 2.6.31
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 029c1bc..ba6d225 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2676,7 +2676,7 @@ ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
sc->curchan = chan;
sc->curband = &sc->sbands[chan->band];
}
- ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, true);
+ ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, chan != NULL);
if (ret) {
ATH5K_ERR(sc, "can't reset hardware (%d)\n", ret);
goto err;
One more odd observation - since 2.6.31 "iwlist wlan0 scan" will list my own ad-hoc
network twice although there are really only 2 machines.
messages:
Oct 8 10:44:09 richard kernel: [ 5818.459845] ath5k 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Oct 8 10:44:09 richard kernel: [ 5818.460301] ath5k 0000:02:00.0: registered as 'phy0'
Oct 8 10:44:09 richard kernel: [ 5818.564470] ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
lspci:
02:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
Some messages I caught on the other end of the connection:
- after cold booting the ath5k device:
[26996.271773] wlan0: RX ProbeReq SA=00:22:43:2c:76:0f DA=ff:ff:ff:ff:ff:ff BSSI
D=ff:ff:ff:ff:ff:ff (tx_last_beacon=1)
[27302.312129] wlan0: sta_find_ibss (active_ibss=0)
[27302.312134] sta_find_ibss: selected da:d2:d4:53:53:03 current da:d2:d4:53:
53:03
[27302.312136] did not try to join ibss
- after warm reboot from working 2.6.30.3
[26763.469116] wlan0: dropped frame to 00:22:43:2c:76:0f (unauthorized port)
[26763.931242] wlan0: RX ProbeReq SA=00:22:43:2c:76:0f DA=ff:ff:ff:ff:ff:ff BSSI
D=ff:ff:ff:ff:ff:ff (tx_last_beacon=1)
[26763.931248] wlan0: Sending ProbeResp to 00:22:43:2c:76:0f
[26764.469021] wlan0: dropped frame to 00:22:43:2c:76:0f (unauthorized port)
[26764.469115] wlan0: dropped frame to 00:22:43:2c:76:0f (unauthorized port)
[26766.151827] wlan0: RX ProbeReq SA=00:22:43:2c:76:0f DA=ff:ff:ff:ff:ff:ff BSSI
D=ff:ff:ff:ff:ff:ff (tx_last_beacon=1)
[26766.151833] wlan0: Sending ProbeResp to 00:22:43:2c:76:0f
Richard
^ permalink raw reply related
* Re: b43: do not stack-allocate pio rx/tx header and tail buffers
From: Albert Herranz @ 2009-10-09 18:52 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, linux-netdev, linux-wireless, linux-kernel
In-Reply-To: <200910092005.59916.mb@bu3sch.de>
Michael Buesch wrote:
>> The reason I posted the initial patch for review was because you kind of told me [2].
>>
>> [20:06] <mb_> Anyway, I'm not going to fix this. If you need it fixed, please send patches
>
> Yeah, but that doesn't mean that either hack is acceptable. It just means that my time is limited
> and I added this non-issue (which I still think it is) to the very bottom of my priority list.
The patch got elaborated and discussed publicly (successfully or not) by following your instructions.
>> My point here is that there's no reason for such strong words concerning the quality of the patch code. It's really not that bad for such wording.
>> I'm sure that if the patch was really crap it would have been immediately NAK'ed by you or by any sane maintainer.
>
> It _was_ immediately NAK'ed by me. I did not know that I need to NAK
> every single new version of a patch explicitely.
> I thought NAK-ing a patch would put it into some special state that only an explicit ACK could
> take it out of.
We all sure had a communication issue here.
What you thought it was an (implicit) NAK for the _initial_ version of the patch, others took that as "fix-those-concerns-and-its-fine".
And the expressed concerns where addressed later in the merged patch, sub-optimally (not crappily).
Looking at your new "[PATCH] b43: Optimize PIO scratchbuffer usage" to address the changes introduced by the merged patch, the merged solution is not that _blatantly_ far from your solution.
The patch would have probably got there in one iteration if you have had the chance again to express your new concerns about v2.
I'm sure we can avoid this in the future by being a bit more explicit.
Thanks,
Albert
^ permalink raw reply
* Ath5k data aborts
From: Krzysztof Halasa @ 2009-10-09 19:16 UTC (permalink / raw)
To: linux-wireless, ath5k-devel, netdev
Hi,
I have done a small investigation. IXP425 (ARM) in big-endian mode,
EABI, mini-PCI atk5k wifi card, hostapd.
Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
Subsystem: Wistron NeWeb Corp. CM9 Wireless a/b/g MiniPCI Adapter
168c:0013 subsystem 185f:1012
Results:
Bad mode in data abort handler detected
Internal error: Oops - bad mode: 0 [#1]
LR is at ath5k_beacon_config+0x150/0x1d4 [ath5k]
This means the PCI device didn't respond on the bus or something
like that. Obviously the card is then unusable and the system needs to
be restarted.
Bisecting (I had to modify the procedure a bit since it only started to
show up after other unrelated code was merged) shows the guilty commit:
e8f055f0c3ba226ca599c14c2e5fe829f6f57cbb (ath5k: Update reset code).
The problem exists with 2.6.30, 2.6.31 and current Linus' tree.
Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
----------------------------------------------
2.6.30 appears to be fixed by:
--- a/drivers/net/wireless/ath5k/reset.c
+++ b/drivers/net/wireless/ath5k/reset.c
@@ -476,7 +476,7 @@ static void ath5k_hw_set_sleep_clock(struct ath5k_hw *ah, bool enable)
(ah->ah_mac_version == (AR5K_SREV_AR2417 >> 4))) {
ath5k_hw_reg_write(ah, 0x26, AR5K_PHY_SLMT);
ath5k_hw_reg_write(ah, 0x0d, AR5K_PHY_SCAL);
- ath5k_hw_reg_write(ah, 0x07, AR5K_PHY_SCLOCK);
+ ath5k_hw_reg_write(ah, 0x0C, AR5K_PHY_SCLOCK);
ath5k_hw_reg_write(ah, 0x3f, AR5K_PHY_SDELAY);
AR5K_REG_WRITE_BITS(ah, AR5K_PCICFG,
AR5K_PCICFG_SLEEP_CLOCK_RATE, 0x02);
@@ -490,8 +490,10 @@ static void ath5k_hw_set_sleep_clock(struct ath5k_hw *ah, bool enable)
}
/* Enable sleep clock operation */
+#if 0
AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG,
AR5K_PCICFG_SLEEP_CLOCK_EN);
+#endif
} else {
The AR5K_PHY_SCLOCK brings the old value (before the commit in question)
back, I have no idea what is it. Leaving the new value causes the second
run of hostapd to make the driver fail, the chip seems to not respond.
It seems the value itself may be correct (as it works with 2.6.31+) but
there is some additional bug fixed after 2.6.30, gitk show several
candidate patches for this.
Only disabling AR5K_PCICFG write makes the data abort go away.
----------------------------------------------
2.6.31 and Linus-current only need the AR5K_PCICFG change:
--- a/drivers/net/wireless/ath/ath5k/reset.c
+++ b/drivers/net/wireless/ath/ath5k/reset.c
@@ -489,9 +489,10 @@ static void ath5k_hw_set_sleep_clock(struct ath5k_hw *ah, bool enable)
}
/* Enable sleep clock operation */
+#if 0
AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG,
AR5K_PCICFG_SLEEP_CLOCK_EN);
-
+#endif
} else {
/* Disable sleep clock operation and
The question is, obviously, how to fix that for good. I can test the
result.
Full error message, not sure why the backtrace isn't printed.
Bad mode in data abort handler detected
Internal error: Oops - bad mode: 0 [#1]
Modules linked in: ohci_hcd ehci_hcd usbcore nls_base ixp4xx_hss ath5k ath ixp4x
x_eth
CPU: 0 Not tainted (2.6.32-rc3 #123)
PC is at 0xffff01fc
LR is at ath5k_beacon_config+0x150/0x1d4 [ath5k]
pc : [<ffff01fc>] lr : [<bf028db0>] psr: a0000092
sp : c7dbfb90 ip : 00008050 fp : c78aa000
r10: c7dbfbd8 r9 : c78ac1c0 r8 : 00003304
r7 : c78aa000 r6 : c78aa000 r5 : 00000013 r4 : c78ac900
r3 : c88e0000 r2 : c88d0024 r1 : c88d0048 r0 : 800924b5
Flags: NzCv IRQs off FIQs on Mode IRQ_32 ISA ARM Segment user
Control: 000039ff Table: 067e0000 DAC: 00000015
Process hostapd (pid: 258, stack limit = 0xc7dbe278)
Stack: (0xc7dbfb90 to 0xc7dc0000)
fb80: 800924b5 c88d0048 c88d0024 c88e0000
fba0: c78ac900 00000013 c78aa000 c78aa000 00003304 c78ac1c0 c7dbfbd8 c78aa000
fbc0: 00008050 c7dbfb90 bf028db0 ffff01fc a0000092 ffffffff 00000003 00000000
fbe0: 00080000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fc00: c78ac924 c78ac900 c78ac924 c7d34628 00000300 c7d34620 00000013 bf028ec8
fc20: c78ac1c0 c7d52980 c0487e90 c7d342c0 c78ac1c0 c67e7140 c7caef20 0000001a
fc40: 00000004 00000000 00000024 c0391694 c67e7140 c7caef20 0000001a c7dbfc88
fc60: c7d342c0 c039e974 c7d52440 00000033 c7dbfcc0 c039e998 c7dbfc88 c0487d30
fc80: c7c6e810 c0384640 00000000 00000000 00000000 00000002 00000000 00000000
fca0: c7d34000 c78ac000 c0487bb0 c7c6e800 c7d52440 c02c5448 c0488184 00000102
fcc0: 00000080 00000102 c7c6e800 c7c6e810 c7c6e814 c788d000 c7c6e800 c7d52440
fce0: c02c5258 c7c54600 c04a0710 00000038 c7dbfd1c c02c42dc c047f6ac c7d52440
fd00: c7d52440 c02c5244 c788d200 00000000 c7d52440 c02c3f14 00000024 7fffffff
fd20: 00000000 c7dbff5c c7c54600 c7d52440 c7dbfe18 00000024 00000000 00000000
fd40: 00000000 c02c47cc c7dbfe38 c7c54600 00000102 00000000 00000000 00000000
fd60: 00000000 c7dbff5c c7dbfe18 00000000 00000000 00000024 c7dbfefc 00000000
fd80: 00000008 c0282298 00000000 c7dbff1c 00000000 00000001 ffffffff 00000000
fda0: 00000000 00000000 00000000 00000000 c7839080 00000001 00000000 00000000
fdc0: 00000000 c7839080 c0185ccc c7dbfdcc c7dbfdcc 0000092a c7dbfec8 c038eae4
fde0: c7dbfe18 00008b24 c7dbfec8 c037ab88 c7dbfdec c7dbfe0c c67d7360 c01aaf9c
fe00: c7dbfe38 c0161cfc 00000000 c67da1a4 00000040 00000000 00000000 c74231bc
fe20: 00000015 00000024 c7489380 0001d000 c7dbfd50 c7dbff5c c7dbfe7c c7dbfefc
fe40: c7dbfe7c c7dbfefc c015a048 c7dbfefc 00000008 00000000 c7dbff5c c7dbff5c
fe60: c7489380 00000000 c7dbfefc c02823ec c7dbff3c c7dbff3c 00000000 00100000
fe80: 00000000 00000000 00000020 00000000 00008933 c02941a4 c67e4380 c67e4000
fea0: 0000000a c67e4380 c7dbe000 c047bc28 c786d940 c024df48 776c616e 30000000
fec0: 00000000 00000000 00000006 00000000 00000000 0e000000 c67e40e0 c67e4084
fee0: 00000000 c028171c c786d340 00008933 00000000 60000013 00000007 0005c754
ff00: 00000000 00000000 00000000 00000000 c74890e8 c0472750 00200200 00100100
ff20: c7497338 c7401498 00200200 00100100 ffffffff ffffffff c780d5a0 c01ce3a0
ff40: c7497338 c0472750 00200200 c01cea04 c786d340 00000000 c7497338 c7dbfe7c
ff60: 0000000c c7dbfefc 00000001 00000000 00000000 00000000 00000000 ffffff97
ff80: c786d340 000598f8 400722b0 000598a0 00000128 c015a048 c7dbe000 00000000
ffa0: 00000001 c0159ea0 000598f8 400722b0 00000004 be9dfb24 00000000 00000000
ffc0: 000598f8 400722b0 000598a0 00000128 00000000 00000000 00000001 00000001
ffe0: be9dfb24 be9dfaf8 40039c84 402b022c 60000010 00000004 00000000 00000000
Code: 00000000 00000000 00000000 00000000 (00000000)
---[ end trace ff977de942e87c2d ]---
--
Krzysztof Halasa
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-09 20:06 UTC (permalink / raw)
To: Frans Pop
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <200910091827.01774.elendil@planet.nl>
On Fri, 2009-10-09 at 18:27 +0200, Frans Pop wrote:
> On Friday 09 October 2009, Mike Galbraith wrote:
> > sched: update the clock of runqueue select_task_rq() selected.
> >
> > In try_to_wake_up(), we update the runqueue clock, but select_task_rq()
> > may select a different runqueue than the one we updated, leaving the new
> > runqueue's clock stale for a bit.
> >
> > This patch cures occasional huge latencies reported by latencytop when
> > coming out of idle on a mostly idle NO_HZ box.
>
> This patch (without Arjan's previous one applied) also fixes my latency
> issues. Nice work!
Thanks for the confirmation (and kind words).
-Mike
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox