* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Johannes Berg @ 2009-08-23 9:11 UTC (permalink / raw)
To: Rafael Laufer; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <4A906B4C.6010208@cs.ucla.edu>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Sat, 2009-08-22 at 15:03 -0700, Rafael Laufer wrote:
> >> + * @IEEE80211_TX_CTL_RATE_RADIOTAP: completely internal to mac80211,
> >> + * used to indicate that the rate was defined in the received radiotap
> >> + * header and therefore the rate control algorithm should not change it.
> >>
> >
> > This should be an internal flag, the driver doesn't care.
> >
>
> right, and where are those set?
It's just a naming thing really. Look at the other flags.
> >> + /* Get the rate parameter from the radiotap header,
> >> + * allowing rate selection on a per-packet basis
> >> + */
> >>
> >
> > coding style
> >
>
> I am a newbie, I am gonna look into the coding style, but I assume you
> are talking about the missing blank line in the beginning
What Kalle said. Sorry to be a bit terse at times.
> This is a good point and now I see that Gábor pointed this out as well.
> There are other fields in the radiotap header that define the RTS and
> DATA retries. However, if those fields are not set, there must be a
> default value in this case. Are there any?
Well there's the short and long retry counts, that could be used I
guess. It would make some sense to do that. And the RTS/CTS-to-self
determination should probably be made by the network in absence of
explicit configuration, but the tx_h_rate_ctrl function should do that
already I think, even if you skip the rate control algorithm. Same with
short preamble or not. If you want to support only the rate, I suspect
that leaving the flags and setting just the rate index/count will be
sufficient. Unfortunately, you'll have to take a closer look at the code
to determine it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Kalle Valo @ 2009-08-23 8:06 UTC (permalink / raw)
To: Rafael Laufer; +Cc: Johannes Berg, Gábor Stefanik, linux-wireless
In-Reply-To: <4A906B4C.6010208@cs.ucla.edu>
Rafael Laufer <rlaufer@CS.UCLA.EDU> writes:
>>> + /* Get the rate parameter from the radiotap header, +
>>> * allowing rate selection on a per-packet basis + */
>>>
>>
>> coding style
>>
>
> I am a newbie, I am gonna look into the coding style,
In case you didn't know, Documentation/CodingStyle is the file you want
to need.
> but I assume you are talking about the missing blank line in the
> beginning
I think Johannes' means the comment style:
/*
* The prefer multiline comments to look like this. blah blah blah blah
* blah blah blah blah blah blah blah blah blah blah blah blah
*/
--
Kalle Valo
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Larry Finger @ 2009-08-23 2:59 UTC (permalink / raw)
To: feng tian; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <f42a38140908221927qabc3f25t60f348f7c4a446c9@mail.gmail.com>
feng tian wrote:
> Thank you for the information.
> I get your point. As for the radio and phy driver, I think it's some
> command based configurations for the chip via SDIO. And that I can
> refer to the BCM 43xx PCI driver codes.
> Wonder if it's feasible. Needs your comments.
> Thanks
The first step is to be able to read/write the various registers via
SDIO. That will be similar to the PCI operations. The next step is
knowing what to read/write and when. We are still working that out for
PCI. It is not trivial. See the recent postings of patches for the LP
pHY in the linux-wireless mailing list. These are _NOT_ complete.
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-23 2:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, linux-wireless
In-Reply-To: <1250964823.23605.22.camel@johannes.local>
Thank you for the information.
I get your point. As for the radio and phy driver, I think it's some
command based configurations for the chip via SDIO. And that I can
refer to the BCM 43xx PCI driver codes.
Wonder if it's feasible. Needs your comments.
Thanks
BR
Feng
2009/8/23 Johannes Berg <johannes@sipsolutions.net>:
> On Sat, 2009-08-22 at 09:27 -0500, Larry Finger wrote:
>> feng tian wrote:
>> > Instead of waiting for the codes, we decide to do someting on
>> > supporting the BCM 4325 running in linux via SDIO.
>> > The linux wireless dirver supports another chip (marvel 8686) with
>> > SDIO interface, the sources codes locate in
>> > drivers/net/wireless/libertas.
>> > We are wondering to develop the BCM4325 driver in the reference to the
>> > marvel 8686 SDIO driver.
>> > Please give comments on this, thanks.
>>
>> The SDIO routines might be transferable; however, the radio and PHY
>> code will be completely different.
>
> Very few of them will be, afaict the SDIO bus access is vastly
> different. Learning how to write an SDIO driver might be possible, but I
> suspect transferring code won't make much sense.
>
> Either way, isobel has some b43 sdio code already.
>
> johannes
>
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Bob Copeland @ 2009-08-23 0:12 UTC (permalink / raw)
To: Fabio Comolli; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <b637ec0b0908221229k5a738f8dgc0aa9e58337c743e@mail.gmail.com>
On Sat, Aug 22, 2009 at 09:29:39PM +0200, Fabio Comolli wrote:
> Hi Bob.
> Unfortunately the patch doesn't apply at all with compat-wireless,
> there's no "flush_workqueue" before "local->suspended" there....
Ah yes, it got moved into ieee80211_stop_device(). Can you put
local->suspended and the barrier() ahead of that?
Thanks!
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Rafael Laufer @ 2009-08-22 22:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <1250927425.23605.8.camel@johannes.local>
Johannes Berg wrote:
> On Fri, 2009-08-21 at 13:21 -0700, Rafael Laufer wrote:
>
>
>> It is strange that a function called "get_rate" would also change other
>> fields which are at first sight do not look related to rate. Why not
>> call other functions for that? What is the reasoning behind this?
>> Different rates have different retry counts or RTS/CTS usage?
>>
> I can't tell if you're kidding or not. This also doesn't get a single
> rate, but the entire rate control setup.
>
>> As far as I could tell from a quick look in the code,
>> rate_control_get_rate only sets the fields of info->control.rates,
>> except for this driver-specific function.
>>
> Right. And now look again what's in control.rates[].
>
ok, I get it now. The flags and count also need to be set. Anything else?
>
>> If this function really does other stuff, then a simple solution is to
>> check if the IEEE80211_TX_CTL_RATE_RADIOTAP flag is set and, in that
>> case, store the value of info->control.rates[0].idx before calling
>> rate_control_get_rate, and restoring it afterwards. Make sense?
>>
> Ick, no.
>
though so, it's so ugly
Rafael
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Rafael Laufer @ 2009-08-22 22:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <1250927308.23605.6.camel@johannes.local>
Johannes Berg wrote:
> On Fri, 2009-08-21 at 11:03 -0700, Rafael Laufer wrote:
>
>
>> + * @IEEE80211_TX_CTL_RATE_RADIOTAP: completely internal to mac80211,
>> + * used to indicate that the rate was defined in the received radiotap
>> + * header and therefore the rate control algorithm should not change it.
>>
>
> This should be an internal flag, the driver doesn't care.
>
right, and where are those set?
>
>> + /* In monitor mode, if the IEEE80211_RADIOTAP_RATE option is set in
>> + * the received radiotap header, do not call the rate control algorithm.
>> + */
>>
>
> coding style
>
>
>> + /* Get the rate parameter from the radiotap header,
>> + * allowing rate selection on a per-packet basis
>> + */
>>
>
> coding style
>
I am a newbie, I am gonna look into the coding style, but I assume you
are talking about the missing blank line in the beginning
>
>> + case IEEE80211_RADIOTAP_RATE:
>> + bitrate = (*iterator.this_arg) * 5;
>> + for (i = 0; i < sband->n_bitrates; i++) {
>> + if (sband->bitrates[i].bitrate == bitrate)
>> + break;
>> + }
>> + if (i != sband->n_bitrates) {
>> + info->control.rates[0].idx = i;
>> + info->flags |= IEEE80211_TX_CTL_RATE_RADIOTAP;
>> + }
>>
>
> You never set the counter, or any other fields.
>
This is a good point and now I see that Gábor pointed this out as well.
There are other fields in the radiotap header that define the RTS and
DATA retries. However, if those fields are not set, there must be a
default value in this case. Are there any?
>
>> /*
>> * Please update the file
>> * Documentation/networking/mac80211-injection.txt
>>
>
> And you even quote the instructions.
>
come on...
Rafael
^ permalink raw reply
* Re: [PATCH] rtl8187: always set MSR_LINK_ENEDCA flag with RTL8187B
From: Hin-Tak Leung @ 2009-08-22 22:06 UTC (permalink / raw)
To: Larry Finger
Cc: Herton Ronaldo Krzesinski, linux-wireless, John W. Linville,
Hin-Tak Leung, Rafael J. Wysocki
In-Reply-To: <4A8E9315.3000709@lwfinger.net>
On Fri, Aug 21, 2009 at 1:29 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> Hin-Tak Leung wrote:
>>
> This problem was quite strange. My system would fail when the RTL8187B
> was inserted when the system booted. Unloading the driver did not
> help, but removing/reinstalling the card fixed the problem. As all my
> testing had been to install the card after booting, I never saw the
> failure.
Removing/reinstalling the card also reset the usb hub driver, I think,
and does more than unloading the driver. I don't have that ability
(rtl8187 built-in), but suspend/resume on my system also works around
the 'can't load 2nd time' problem.
Anyway, the 'can't load compat-wireless 2nd time' problem seems to
have gone away - I just loaded it a 2nd time testing the rkfill patch.
Hin-Tak
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Hin-Tak Leung @ 2009-08-22 21:59 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: linux-wireless, Larry Finger, Hin-Tak Leung
In-Reply-To: <200908220038.35564.herton@mandriva.com.br>
On Sat, Aug 22, 2009 at 4:38 AM, Herton Ronaldo
Krzesinski<herton@mandriva.com.br> wrote:
> This change implements rfkill support for RTL8187B and RTL8187L devices,
> using new cfg80211 rfkill API.
>
> Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Tested-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Neat!
I ran a ping to the router while flicking the switch on and off, and
have 'ping: sendmsg: Network is unreachable' in the middle. dmesg also
shows
rtl8187: wireless radio switch turned off
wlan2: deauthenticating by local choice (reason=3)
rtl8187: wireless radio switch turned on
etc. Work as advertised.
Well done!
Hin-Tak
^ permalink raw reply
* Re: [RFT] ar9170: use eeprom's frequency calibration values
From: Christian Lamparter @ 2009-08-22 21:43 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless, John Linville, Johannes Berg
In-Reply-To: <4A905D2B.9090405@gmx.de>
On Saturday 22 August 2009 23:03:39 Joerg Albert wrote:
> On 08/22/2009 01:51 AM, Christian Lamparter wrote:
> > On Saturday 22 August 2009 01:36:17 Joerg Albert wrote:
> >> On 08/21/2009 10:52 PM, Christian Lamparter wrote:
> >>> This patch adds some more bits from the vendor driver, which
> >>> are supposed to help users with the one-stage/openfw firmwares.
> >> The otus driver sets phy registers 672-703 only for the one-stage firmware -
> >> hal/hpmain.c, line 3445:
> >>
> >> #ifndef ZM_OTUS_LINUX_PHASE_2
> >> reg_write(regAddr + i, val); /* CR672 */
> >> #endif
> >>
> >> Are you sure it doesn't hurt with the two-stage firmware?
> > no idea, that's why I ask requested input, instead of posting a patch +
> > sob right away.
> >
> > so far, I haven't heard of or experienced any regressions or anomalies.
> > Do you already have comments or complains? :)
>
> Your patch works fine here with a WNDA3100, using the two-stage firmware, against
> a 802.11g AP. After "iwconfig wlan1 rate 54M" I get approx. 22 MBit/s throughput
> with iperf, same as without the patch.
same here... and not really surprising.
According to my sources, the two-stage firmware is
capable of doing calibration without extra help from
the host.
> > Unfortunately, my device (WNDA3100) still doesn't work properly
> > with either version at phy-rates beyond the magic 18MBit barrier.
>
> Strange, same device here (or another hw version? FCC ID: PY307300073)
> and I see packets @ 54M from the dev in the sniffer. But it also has the
> invalid regdomain 0x8000 in the eeprom ...
that comment about "18mbit barrier" is only true for the one-stage fw.
I've no problem getting up and slightly above 80mbits with the original
two-stage fw.
Regards,
Chr
^ permalink raw reply
* Re: [RFT] ar9170: use eeprom's frequency calibration values
From: Joerg Albert @ 2009-08-22 21:03 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John Linville, Johannes Berg
In-Reply-To: <200908220151.19792.chunkeey@web.de>
On 08/22/2009 01:51 AM, Christian Lamparter wrote:
> On Saturday 22 August 2009 01:36:17 Joerg Albert wrote:
>> On 08/21/2009 10:52 PM, Christian Lamparter wrote:
>>> This patch adds some more bits from the vendor driver, which
>>> are supposed to help users with the one-stage/openfw firmwares.
>> The otus driver sets phy registers 672-703 only for the one-stage firmware -
>> hal/hpmain.c, line 3445:
>>
>> #ifndef ZM_OTUS_LINUX_PHASE_2
>> reg_write(regAddr + i, val); /* CR672 */
>> #endif
>>
>> Are you sure it doesn't hurt with the two-stage firmware?
> no idea, that's why I ask requested input, instead of posting a patch +
> sob right away.
>
> so far, I haven't heard of or experienced any regressions or anomalies.
> Do you already have comments or complains? :)
Your patch works fine here with a WNDA3100, using the two-stage firmware, against
a 802.11g AP. After "iwconfig wlan1 rate 54M" I get approx. 22 MBit/s throughput
with iperf, same as without the patch.
> Unfortunately, my device (WNDA3100) still doesn't work properly
> with either version at phy-rates beyond the magic 18MBit barrier.
Strange, same device here (or another hw version? FCC ID: PY307300073)
and I see packets @ 54M from the dev in the sniffer. But it also has the
invalid regdomain 0x8000 in the eeprom ...
With the one-stage firmware and without your patch my device doesn't associate with the AP,
seems like no packets are sent. So I can't test your patch with the one-stage fw.
Same result with a AVM Fritz stick.
I'll look into bisecting.
Regards,
Joerg.
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Fabio Comolli @ 2009-08-22 19:29 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <20090822134044.GC6762@hash.localnet>
Hi Bob.
Unfortunately the patch doesn't apply at all with compat-wireless,
there's no "flush_workqueue" before "local->suspended" there....
Please advice.
Regards,
Fabio
On Sat, Aug 22, 2009 at 3:40 PM, Bob Copeland<me@bobcopeland.com> wrote:
> On Sat, Aug 22, 2009 at 03:02:26PM +0200, Fabio Comolli wrote:
>> Hi Bob.
>>
>> I'm not a git user. How can I user wireless-testing without git? Is
>> there a patch or seomething?
>
> No, I'm unaware of a way to get it without git. Well, okay, try
> compat-wireless, but be sure to use the 'bleeding edge' compat-wireless,
> and post the contents of its 'git-describe' file with the warnings so
> I can be sure we're on the same page.
>
> http://wireless.kernel.org/en/users/Download
>
> --
> Bob Copeland %% www.bobcopeland.com
>
>
^ permalink raw reply
* [PATCH] nl80211: jump to out_err upon unsupported iftype
From: Roel Kluin @ 2009-08-22 19:15 UTC (permalink / raw)
To: John W. Linville, linux-wireless, Andrew Morton
Jump to out_err when the iftype is not supported.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 634496b..c6fc083 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1998,7 +1998,7 @@ static int nl80211_dump_mpath(struct sk_buff *skb,
if (netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_MESH_POINT) {
err = -EOPNOTSUPP;
- goto out;
+ goto out_err;
}
while (1) {
^ permalink raw reply related
* Re: Broadcom BCM43XG Master mode?
From: Gábor Stefanik @ 2009-08-22 18:59 UTC (permalink / raw)
To: Nathan Kennedy, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1250967366.23605.23.camel@johannes.local>
On Sat, Aug 22, 2009 at 8:56 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Sat, 2009-08-22 at 11:41 -0700, Nathan Kennedy wrote:
>> I recently purchased a Linksys WMP300N that has teh BCM43XG chipset.
>> The only driver that I've gotten to work well with it is the wl driver
>> from Broadcom, however when I try to set the wireless mode to master I
>> get an error that the operation is not permitted. Is there a different
>> way to get this card into master mode?
>
> If you're using wl, then we don't know, and you have to ask Broadcom.
>
> If you're using b43, you start hostapd.
>
> johannes
>
WMP300N is an N-PHY, not supported by b43 (LP-PHY is being done right
now, N-PHY is probably the next). AFAIK wl (the hybrid driver) only
supports STA mode, there is no AP-ready x86 driver (Broadcom only
makes AP drivers for the MIPS platform).
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: Broadcom BCM43XG Master mode?
From: Nathan Kennedy @ 2009-08-22 18:59 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1250967366.23605.23.camel@johannes.local>
Johannes Berg wrote:
> On Sat, 2009-08-22 at 11:41 -0700, Nathan Kennedy wrote:
>
>> I recently purchased a Linksys WMP300N that has teh BCM43XG chipset.
>> The only driver that I've gotten to work well with it is the wl driver
>> from Broadcom, however when I try to set the wireless mode to master I
>> get an error that the operation is not permitted. Is there a different
>> way to get this card into master mode?
>>
>
> If you're using wl, then we don't know, and you have to ask Broadcom.
>
> If you're using b43, you start hostapd.
>
> johannes
>
Unfortunately the b43 driver will not load at all because there hasn't
been an update to support this chipset. Any devs want a guinea pig to
test driver ideas?
^ permalink raw reply
* Re: Broadcom BCM43XG Master mode?
From: Johannes Berg @ 2009-08-22 18:56 UTC (permalink / raw)
To: Nathan Kennedy; +Cc: linux-wireless
In-Reply-To: <4A903BEB.4030606@flidais.net>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
On Sat, 2009-08-22 at 11:41 -0700, Nathan Kennedy wrote:
> I recently purchased a Linksys WMP300N that has teh BCM43XG chipset.
> The only driver that I've gotten to work well with it is the wl driver
> from Broadcom, however when I try to set the wireless mode to master I
> get an error that the operation is not permitted. Is there a different
> way to get this card into master mode?
If you're using wl, then we don't know, and you have to ask Broadcom.
If you're using b43, you start hostapd.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Broadcom BCM43XG Master mode?
From: Nathan Kennedy @ 2009-08-22 18:41 UTC (permalink / raw)
To: linux-wireless
I recently purchased a Linksys WMP300N that has teh BCM43XG chipset.
The only driver that I've gotten to work well with it is the wl driver
from Broadcom, however when I try to set the wireless mode to master I
get an error that the operation is not permitted. Is there a different
way to get this card into master mode?
Thanks in advance
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Johannes Berg @ 2009-08-22 18:13 UTC (permalink / raw)
To: Larry Finger; +Cc: feng tian, linux-wireless
In-Reply-To: <4A90005B.3030101@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
On Sat, 2009-08-22 at 09:27 -0500, Larry Finger wrote:
> feng tian wrote:
> > Instead of waiting for the codes, we decide to do someting on
> > supporting the BCM 4325 running in linux via SDIO.
> > The linux wireless dirver supports another chip (marvel 8686) with
> > SDIO interface, the sources codes locate in
> > drivers/net/wireless/libertas.
> > We are wondering to develop the BCM4325 driver in the reference to the
> > marvel 8686 SDIO driver.
> > Please give comments on this, thanks.
>
> The SDIO routines might be transferable; however, the radio and PHY
> code will be completely different.
Very few of them will be, afaict the SDIO bus access is vastly
different. Learning how to write an SDIO driver might be possible, but I
suspect transferring code won't make much sense.
Either way, isobel has some b43 sdio code already.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Larry Finger @ 2009-08-22 17:12 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: linux-wireless, Hin-Tak Leung
In-Reply-To: <200908220038.35564.herton@mandriva.com.br>
Herton Ronaldo Krzesinski wrote:
> This change implements rfkill support for RTL8187B and RTL8187L devices,
> using new cfg80211 rfkill API.
>
> Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
> ---
I don't have an RFKILL switch on my rtl8187 devices and cannot test
that part; however, everything looks OK and the devices still work.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry
^ permalink raw reply
* Re: ath5k: ath5k_pci_probe(): weirdo code
From: Andreas Mohr @ 2009-08-22 15:10 UTC (permalink / raw)
To: Bob Copeland
Cc: Andreas Mohr, ath5k-devel, linux-wireless, Johannes Stezenbach
In-Reply-To: <20090822133557.GB6762@hash.localnet>
Hi,
On Sat, Aug 22, 2009 at 09:35:57AM -0400, Bob Copeland wrote:
> On Fri, Aug 21, 2009 at 11:47:32AM +0200, Andreas Mohr wrote:
> > Hello all,
> >
> > that 2GHz/5GHz radio information code in ath5k_pci_probe() in 2.6.31-rc6
> > source seems VERY weird.
> ah_radio_{2,5}ghz_revision is what is in the appropriate registers in
> the card, but e.g. the revision in the 5ghz radio register may actually
> refer to the 2ghz radio on some 802.11B-only devices, depending on what
> is in the eeprom.
Ah, that explains why the logic was rather counter-intuitive.
Still, in OSS it is very common to have _other_ people modify code,
and with that kind of clarity things can thus go haywire easily
(unless a core maintainer happens to catch it after submission).
> Can you verify that the patch mentioned in the bug report works?
YES, I can verify that replacing those 2 §"§$%>: Hermei capacitors
with good Rubycon ones in one of my three WRT54G(S) worked. :-P
(global series failure, "Defective By Design _without_ even needing
to make use of DRM"). aka "Planned failure one year post warranty" ;)
It seems MUCH more reliable now, after some short testing...
> Can you supply /debug/ieee80211/phy0/stations/<...>/rc_stats?
[NOTE: not sure whether these ath5k module stats are (partially) still pre-repair]
root@andinet:/sys/kernel/debug/ieee80211/phy19/stations/00:0f:66:4c:c4:44# cat rc_stats
^^^^^ *wink* ;-)
rate throughput ewma prob this prob this succ/attempt success attempts
1 0.9 97.6 100.0 0( 0) 20 20
2 0.4 25.0 100.0 0( 0) 1 1
5.5 0.0 0.0 0.0 0( 0) 0 0
11 9.1 95.5 100.0 0( 0) 78 82
6 0.0 0.0 0.0 0( 0) 0 0
9 0.0 0.0 0.0 0( 0) 0 0
12 2.7 25.0 100.0 0( 0) 1 1
18 4.0 25.0 100.0 0( 0) 1 1
24 5.3 25.0 100.0 0( 0) 1 1
36 7.6 25.0 100.0 0( 0) 1 1
t 48 7.0 77.6 50.0 0( 0) 1543 1685
T P 54 20.0 99.9 100.0 1( 1) 357588 398612
Total packet count:: ideal 8186 lookaround 909
> We need to queue that for 2.6.31.
Cannot test the patch right now since I cannot do a kernel build at this place.
> As do I. I don't have a 2425 though, and there are quite some variations
> between each HW revision.
Which is quite the norm with todays hardware :-P
(I even once bought an ACX100 hardware with the wrong revision
- read: COMPLETELY different hardware - where I then found that the seller
had _both_ revision variants in the _SAME_ shelf box at the same time
and they were friggin' out themselves when I enlightened them about this fact...)
Not to mention the even much more HORRIBLE CRIME of assigning the SAME PCI ID even,
to DIFFERENT hardware, that some vendors dare to commit.
Andreas Mohr
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Larry Finger @ 2009-08-22 14:27 UTC (permalink / raw)
To: feng tian; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <f42a38140908212242h1ce0339fw1243dbacf54000ab@mail.gmail.com>
feng tian wrote:
> Instead of waiting for the codes, we decide to do someting on
> supporting the BCM 4325 running in linux via SDIO.
> The linux wireless dirver supports another chip (marvel 8686) with
> SDIO interface, the sources codes locate in
> drivers/net/wireless/libertas.
> We are wondering to develop the BCM4325 driver in the reference to the
> marvel 8686 SDIO driver.
> Please give comments on this, thanks.
The SDIO routines might be transferable; however, the radio and PHY
code will be completely different.
^ permalink raw reply
* 2.6.31 patch for regression #13948
From: Bob Copeland @ 2009-08-22 13:47 UTC (permalink / raw)
To: linville; +Cc: mickflemm, linux-wireless
Hi John,
Can you queue this patch for 2.6.31? It's on the regression list
but isn't upstream. I cherry-picked it here and it applied and
built cleanly.
http://bugzilla.kernel.org/show_bug.cgi?id=13948
commit 399b1ffc45081a0f087fe3824b263fd27909cb7a
Author: Nick Kossifidis <mick@madwifi-project.org>
Date: Mon Aug 10 03:29:02 2009 +0300
ath5k: Wakeup fixes
* Don't put chip to full sleep because there are problems during
wakeup. Instead hold MAC/Baseband on warm reset state via a new
function ath5k_hw_on_hold.
* Minor cleanups
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Tested-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Bob Copeland @ 2009-08-22 13:40 UTC (permalink / raw)
To: Fabio Comolli; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <b637ec0b0908220602v3b9c2a35ob1e44d70f131890c@mail.gmail.com>
On Sat, Aug 22, 2009 at 03:02:26PM +0200, Fabio Comolli wrote:
> Hi Bob.
>
> I'm not a git user. How can I user wireless-testing without git? Is
> there a patch or seomething?
No, I'm unaware of a way to get it without git. Well, okay, try
compat-wireless, but be sure to use the 'bleeding edge' compat-wireless,
and post the contents of its 'git-describe' file with the warnings so
I can be sure we're on the same page.
http://wireless.kernel.org/en/users/Download
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: ath5k: ath5k_pci_probe(): weirdo code
From: Bob Copeland @ 2009-08-22 13:35 UTC (permalink / raw)
To: Andreas Mohr; +Cc: ath5k-devel, linux-wireless, Johannes Stezenbach
In-Reply-To: <20090821094732.GA970@rhlx01.hs-esslingen.de>
On Fri, Aug 21, 2009 at 11:47:32AM +0200, Andreas Mohr wrote:
> Hello all,
>
> that 2GHz/5GHz radio information code in ath5k_pci_probe() in 2.6.31-rc6
> source seems VERY weird.
The code looks horribly confusing, it should be moved into attach.c
and reworked a lot probably. It looks correct though - it is fixing up
settings for (really old) multiple radio chip devices, where we can't
tell by the radio revision alone if it is multiband or not.
ah_radio_{2,5}ghz_revision is what is in the appropriate registers in
the card, but e.g. the revision in the 5ghz radio register may actually
refer to the 2ghz radio on some 802.11B-only devices, depending on what
is in the eeprom.
> Then also at this place, why is there no
> else
> {
> WARN_ONCE(...); // Huh. Unknown/unhandled/impossible revision combo
Should be caught already in attach.c, but yeah, another warning wouldn't
hurt.
> if (!sc->ah->ah_single_chip) {
> /* Single chip radio (!RF5111) */
>
> part seemed weird logic, too, but I then thought that this code section
> is perhaps _intended_ to be skipped in this case, to simply not log anything
> for single-chip radios
The comment belongs to the subsequent if() test, where it should probably
live to be clearer. All recent devices (including yours) are now single
chip so this code wouldn't run on your device.
> BTW, I'm currently on 2.6.31-rc6 on Aspire One, with even more ath5k problems
> than before, connection is dying every couple minutes, extended to every
> couple dozen minutes if I force rate 1M
Can you supply /debug/ieee80211/phy0/stations/<...>/rc_stats?
> (but it looks like "[Bug #13948] ath5k broken after suspend-to-ram"
> http://lkml.org/lkml/2009/8/19/468 is hopefully covering these issues already).
Can you verify that the patch mentioned in the bug report works?
We need to queue that for 2.6.31.
> And I do have CONFIG..._PS (powersave) enabled by default...
> And I do make liberal use of suspend-to-ram, as should everyone.
As do I. I don't have a 2425 though, and there are quite some variations
between each HW revision.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Fabio Comolli @ 2009-08-22 13:02 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <20090822124709.GA6762@hash.localnet>
Hi Bob.
On Sat, Aug 22, 2009 at 2:47 PM, Bob Copeland<me@bobcopeland.com> wrote:
> On Fri, Aug 21, 2009 at 10:19:33AM -0400, Bob Copeland wrote:
>> Okay, I think I see what is going on here.
>
> Well I can't quite convince myself of what exactly is requeing
> sta work; we do cancel everything already as far as I can tell, but
> something is rearming, I just can't tell which.
>
> Fabio, can you please apply this patch against wireless-testing (not
> compat-wireless) and report all the warnings produced when doing a
> suspend/resume? This should tell us the code paths that are queuing
> work too late.
I'm not a git user. How can I user wireless-testing without git? Is
there a patch or seomething?
>
> From 6eb7d5c3ae8f2f42b164491acd02631858515876 Mon Sep 17 00:00:00 2001
> From: Bob Copeland <me@bobcopeland.com>
> Date: Sat, 22 Aug 2009 08:40:53 -0400
> Subject: [PATCH] mac80211: set suspended before final flush_workqueue
>
> Just a temporary debugging aid.
> ---
> net/mac80211/pm.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
> index a5d2f1f..231c8be 100644
> --- a/net/mac80211/pm.c
> +++ b/net/mac80211/pm.c
> @@ -117,13 +117,13 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
> * shouldn't be doing (or cancel everything in the
> * stop callback) that but better safe than sorry.
> */
> - flush_workqueue(local->workqueue);
> -
> local->suspended = true;
> /* need suspended to be visible before quiescing is false */
> barrier();
> local->quiescing = false;
>
> + flush_workqueue(local->workqueue);
> +
> return 0;
> }
>
> --
> 1.6.2.5
>
>
> --
> Bob Copeland %% www.bobcopeland.com
>
>
Regards,
Fabio
^ 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