* Re: [ath9k-devel] [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Ben Greear @ 2011-01-07 22:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Luis R. Rodriguez, Johannes Berg, ath9k-devel@venema.h4ckr.net,
linux-wireless@vger.kernel.org
In-Reply-To: <1294432018.2709.2.camel@edumazet-laptop>
On 01/07/2011 12:26 PM, Eric Dumazet wrote:
> Le vendredi 07 janvier 2011 à 12:09 -0800, Luis R. Rodriguez a écrit :
>> On Fri, Jan 07, 2011 at 10:34:52AM -0800, Ben Greear wrote:
>>> On 01/07/2011 02:58 AM, Johannes Berg wrote:
>>>> On Thu, 2011-01-06 at 16:46 -0800, greearb@candelatech.com wrote:
>>>>> From: Ben Greear<greearb@candelatech.com>
>>>>>
>>>>> Patch is from Eric Dumazet, as described here:
>>>>> https://patchwork.kernel.org/patch/104271/
>>>>>
>>>>> Reported-by: Michael Guntsche<mike@it-loops.com>
>>>>> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>>>>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>>>>> ---
>>>>>
>>>>> NOTE: This needs review by ath9k and/or other informed
>>>>> people.
>>>>
>>>> This doesn't make sense. It might help, but it'll probably lead to not
>>>> being able to receive all frames off the air.
>>>>
>>>> If this is an issue, ath9k should do paged RX like iwlwifi.
>>>
>>> Ok, I backed this out..but now I'm back to getting buffer allocation
>>> failures (and this is on a system with 2GB RAM).
>>>
>>> Seems it's coming from mac80211 instead of ath9k, at least most of
>>> the time (I'm using 60 stations, so it probably needs to make lots of
>>> copies in the rx path). The traffic I'm generating/receiving is 1024 byte UDP
>>> payloads.
>>>
>>> Does this mean I really received a packet that was 3872 bytes long,
>>> or is the skb_copy allocating/copying empty data?
>>
>> Good question. The buffer we setup for DMA should be large since we
>> need to support AMSDU RX up to a certain bytes of RX data for the frame.
>> Harwdware should tell us the right size for the RX'd data and the skb
>> should be set with that size, respectively. Following this logic,
>> skb_copy() should only allocate on the order of the required skb->len.
>>
>> Remember that trick we did to force the older memory leak issues by
>> forcing an skb_copy() on every RX'd frame and then just discarding that
>> buffer immediately? You can try to do the same and print the skb->len
>> there, just to check what's going on.
>
>
> Using skb_copy() is wrong then, since it makes a copy (order-1
> allocations)
>
> It should use :
> skb_alloc( actual_size_of_frame not the 3840 thing ...)
> copy(data)
We need the extra stuff copied too I think (like skb->cb).
If you could provide a bit more complete example code, I'll be happy
to test it...
Thanks,
Ben
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Luis R. Rodriguez @ 2011-01-07 22:18 UTC (permalink / raw)
To: Luis R. Rodriguez, Aleksandar Milivojevic,
linux-wireless@vger.kernel.org, users@rt2x00.serialmonkey.com,
Luis Rodriguez
In-Reply-To: <20110107221305.6484.qmail@stuge.se>
On Fri, Jan 7, 2011 at 2:13 PM, Peter Stuge <peter@stuge.se> wrote:
> Luis R. Rodriguez wrote:
>> bgscan="simple:30:-45:300"
> ..
>> No Linux distributions today uses this other than ChromeOS, but
>> they should all change to use it.
>
> Maybe wpa_supplicant should be changed to use it by default?
The supplicant is configured by dbus, so its not up to the supplicant
by design. What has to change is Network Manager and connman needs to
change to use bgscan by default. ChromeOS uses a fork of connman
called flimflam and it uses it by default now.
Luis
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Peter Stuge @ 2011-01-07 22:13 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Aleksandar Milivojevic, linux-wireless@vger.kernel.org,
users@rt2x00.serialmonkey.com, Luis Rodriguez
In-Reply-To: <20110107202224.GI21588@tux>
Luis R. Rodriguez wrote:
> bgscan="simple:30:-45:300"
..
> No Linux distributions today uses this other than ChromeOS, but
> they should all change to use it.
Maybe wpa_supplicant should be changed to use it by default?
//Peter
^ permalink raw reply
* Re: [ath9k-devel] ath9k tx lockup, ath: received PCI FATAL interrupt
From: Brian Prodoehl @ 2011-01-07 22:09 UTC (permalink / raw)
To: ath9k-devel, linux-wireless
In-Reply-To: <20110107215549.4053.qmail@stuge.se>
On Fri, Jan 7, 2011 at 4:55 PM, Peter Stuge <peter@stuge.se> wrote:
> First of all, sorry for dropping linux-wireless from my previous
> message, it was mostly about my understanding of ath9k processes.
>
> Crossposting is a bit unnatural for me, I usually strictly use
> list-reply. Let's try with this one! :)
>
>
> Peter Stuge wrote:
>> So there was a problem while writing this message. Will follow up
>> in separate message. I can only describe the symptom, but as I wrote
>> after subscribing this list over a year ago I'm comfortable and more
>> than happy to help with debugging on register level, and below, but I
>> still know neither driver nor hardware and if possible I would like
>> to not have to learn all of the driver, so I would need to be told
>> fairly specifically what to instrument.
>>
>> I think someone with good knowledge of driver and hardware could give
>> guidance very quickly.
>
> I booted wireless-testing master-2011-01-05 with an AR9280 Mini PCI
> card in my ThinkPad X40 today.
>
> I normally never use wpa_supplicant. I don't accept that it would be
> required for a working connection and so far noone has really
> explained why that would be the case. Only ath9k (ie. neither ipw2200
> nor ath5k) has ever made a difference between wpa_supplicant running
> or not.
>
> I configure manually. Module is loaded by kernel on boot. After
> logging in, I run:
>
> ip l s dev eth1 up
> iw dev eth1 connect Stuge
> ip a a 192.168.5.4/24 dev eth1
> ip r a default via 192.168.5.1
>
> ..and that is my internet connection.
>
>
> I used the connection without issues for about an hour, working
> remotely and listening to a music stream, then I was disassociated,
> with the PCI FATAL interrupt in the kernel log.
>
> dmesg output is log1_ath_pci_fatal_interrupt.txt
>
>
> Trying to revive the connection it seemed like no packets were being
> transmitted because I could scan, but not associate again.
>
> I then tried to start wpa_supplicant, which made four attempts at
> authenticating with the (unencrypted) AP, without success.
>
> dmesg output is log2_after_wpa_supplicant_4x_trying_to_auth.txt
>
>
> I tried to rmmod and modprobe the driver, followed by
>
> iw dev eth1 connect Stuge
>
> but that also did not work.
>
> dmesg output is log3_after_rmmod_modprobe.txt
>
>
> I power cycled and did the above ip l s + iw connect, which made the
> card sort-of associate, but not function correctly.
>
> dmesg output is log4_after_power_cycle_and_iw_connect.txt
>
> Running iw dev eth1 link at this time showed me *not* being
> successfully connected.
>
> I started wpa_supplicant 0.7.2 without debug messages.
> Output is in log5_wpa_supplicant.txt
>
> I ran iw dev eth1 connect Stuge
>
> wpa_supplicant output is log6_wpa_supplicant_after_iw_connect.txt
>
> dmesg output is log7_after_wpa_supplicant_and_iw_connect.txt
>
>
> This is the connection I am currently using.
>
>
> The above identifies at least two issues:
>
> 1. ath: received PCI FATAL interrupt
>
> How can I find out more about the reason for this?
>
>
> 2. Unworking association without wpa_supplicant after power cycle
>
> How can I find out more about the reason for this?
>
>
> The log files are attached and available at http://stuge.se/ath9k/wl0105/
> All dmesg output is incremental. boot1.txt and boot2.txt are initial
> messages for each boot, but not included as attachments.
>
> boot2.txt (after power cycle) had different timing, keyboard detected
> earlier, no tty60 hash and different btrfs transaction id. I added
> the Time: stamp in log4_after_power_cycle_and_iw_connect.txt.
>
> Please help me provide further neccessary information to debug this.
> Thank you!
>
>
> //Peter
Out of curiosity, what's your AP? I've never seen those "detected
beacon loss from AP" messages. If you bring up a monitor-mode
interface, do you see beacons at a sane, regular interval?
-Brian
^ permalink raw reply
* ath9k tx lockup, ath: received PCI FATAL interrupt
From: Peter Stuge @ 2011-01-07 21:55 UTC (permalink / raw)
To: ath9k-devel, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 3457 bytes --]
First of all, sorry for dropping linux-wireless from my previous
message, it was mostly about my understanding of ath9k processes.
Crossposting is a bit unnatural for me, I usually strictly use
list-reply. Let's try with this one! :)
Peter Stuge wrote:
> So there was a problem while writing this message. Will follow up
> in separate message. I can only describe the symptom, but as I wrote
> after subscribing this list over a year ago I'm comfortable and more
> than happy to help with debugging on register level, and below, but I
> still know neither driver nor hardware and if possible I would like
> to not have to learn all of the driver, so I would need to be told
> fairly specifically what to instrument.
>
> I think someone with good knowledge of driver and hardware could give
> guidance very quickly.
I booted wireless-testing master-2011-01-05 with an AR9280 Mini PCI
card in my ThinkPad X40 today.
I normally never use wpa_supplicant. I don't accept that it would be
required for a working connection and so far noone has really
explained why that would be the case. Only ath9k (ie. neither ipw2200
nor ath5k) has ever made a difference between wpa_supplicant running
or not.
I configure manually. Module is loaded by kernel on boot. After
logging in, I run:
ip l s dev eth1 up
iw dev eth1 connect Stuge
ip a a 192.168.5.4/24 dev eth1
ip r a default via 192.168.5.1
..and that is my internet connection.
I used the connection without issues for about an hour, working
remotely and listening to a music stream, then I was disassociated,
with the PCI FATAL interrupt in the kernel log.
dmesg output is log1_ath_pci_fatal_interrupt.txt
Trying to revive the connection it seemed like no packets were being
transmitted because I could scan, but not associate again.
I then tried to start wpa_supplicant, which made four attempts at
authenticating with the (unencrypted) AP, without success.
dmesg output is log2_after_wpa_supplicant_4x_trying_to_auth.txt
I tried to rmmod and modprobe the driver, followed by
iw dev eth1 connect Stuge
but that also did not work.
dmesg output is log3_after_rmmod_modprobe.txt
I power cycled and did the above ip l s + iw connect, which made the
card sort-of associate, but not function correctly.
dmesg output is log4_after_power_cycle_and_iw_connect.txt
Running iw dev eth1 link at this time showed me *not* being
successfully connected.
I started wpa_supplicant 0.7.2 without debug messages.
Output is in log5_wpa_supplicant.txt
I ran iw dev eth1 connect Stuge
wpa_supplicant output is log6_wpa_supplicant_after_iw_connect.txt
dmesg output is log7_after_wpa_supplicant_and_iw_connect.txt
This is the connection I am currently using.
The above identifies at least two issues:
1. ath: received PCI FATAL interrupt
How can I find out more about the reason for this?
2. Unworking association without wpa_supplicant after power cycle
How can I find out more about the reason for this?
The log files are attached and available at http://stuge.se/ath9k/wl0105/
All dmesg output is incremental. boot1.txt and boot2.txt are initial
messages for each boot, but not included as attachments.
boot2.txt (after power cycle) had different timing, keyboard detected
earlier, no tty60 hash and different btrfs transaction id. I added
the Time: stamp in log4_after_power_cycle_and_iw_connect.txt.
Please help me provide further neccessary information to debug this.
Thank you!
//Peter
[-- Attachment #2: log1_ath_pci_fatal_interrupt.txt --]
[-- Type: text/plain, Size: 9883 bytes --]
[ 116.379476] ieee80211 phy0: device now idle
[ 128.258056] ieee80211 phy0: device no longer idle - scanning
[ 131.749216] eth1: authenticate with 00:02:6f:21:ea:94 (try 1)
[ 131.949037] eth1: authenticate with 00:02:6f:21:ea:94 (try 2)
[ 131.950969] eth1: authenticated
[ 131.950993] ieee80211 phy0: device now idle
[ 131.978744] ieee80211 phy0: device no longer idle - working
[ 131.996384] eth1: associate with 00:02:6f:21:ea:94 (try 1)
[ 131.999167] eth1: RX AssocResp from 00:02:6f:21:ea:94 (capab=0x421 status=0 aid=1)
[ 131.999172] eth1: associated
[ 131.999181] ieee80211 phy0: Allocated STA 00:02:6f:21:ea:94
[ 131.999199] ieee80211 phy0: Inserted STA 00:02:6f:21:ea:94
[ 131.999205] ieee80211 phy0: WMM queue=2 aci=0 acm=0 aifs=2 cWmin=7 cWmax=1023 txop=64 uapsd=0
[ 131.999214] ieee80211 phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0 uapsd=0
[ 131.999220] ieee80211 phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94 uapsd=0
[ 131.999226] ieee80211 phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47 uapsd=0
[ 1005.004039] eth1: detected beacon loss from AP - sending probe request
[ 1008.004661] eth1: detected beacon loss from AP - sending probe request
[ 1010.004664] eth1: detected beacon loss from AP - sending probe request
[ 1012.004661] eth1: detected beacon loss from AP - sending probe request
[ 1016.004663] eth1: detected beacon loss from AP - sending probe request
[ 1016.394039] eth1: cancelling probereq poll due to a received beacon
[ 1019.004016] eth1: detected beacon loss from AP - sending probe request
[ 1021.004031] eth1: detected beacon loss from AP - sending probe request
[ 1021.102510] eth1: cancelling probereq poll due to a received beacon
[ 1022.002033] eth1: detected beacon loss from AP - sending probe request
[ 1024.002038] eth1: detected beacon loss from AP - sending probe request
[ 1027.004034] eth1: detected beacon loss from AP - sending probe request
[ 1027.243583] eth1: cancelling probereq poll due to a received beacon
[ 1029.002037] eth1: detected beacon loss from AP - sending probe request
[ 1029.290442] eth1: cancelling probereq poll due to a received beacon
[ 1037.004033] eth1: detected beacon loss from AP - sending probe request
[ 1037.376311] eth1: cancelling probereq poll due to a received beacon
[ 1045.004035] eth1: detected beacon loss from AP - sending probe request
[ 1053.004038] eth1: detected beacon loss from AP - sending probe request
[ 1053.138950] eth1: cancelling probereq poll due to a received beacon
[ 1070.002042] eth1: detected beacon loss from AP - sending probe request
[ 1070.026256] eth1: cancelling probereq poll due to a received beacon
[ 1071.002034] eth1: detected beacon loss from AP - sending probe request
[ 1073.004035] eth1: detected beacon loss from AP - sending probe request
[ 1076.004665] eth1: detected beacon loss from AP - sending probe request
[ 1078.004663] eth1: detected beacon loss from AP - sending probe request
[ 1080.004661] eth1: detected beacon loss from AP - sending probe request
[ 1082.004662] eth1: detected beacon loss from AP - sending probe request
[ 1084.004662] eth1: detected beacon loss from AP - sending probe request
[ 1086.004654] eth1: detected beacon loss from AP - sending probe request
[ 1088.004674] eth1: detected beacon loss from AP - sending probe request
[ 1090.004664] eth1: detected beacon loss from AP - sending probe request
[ 1092.004659] eth1: detected beacon loss from AP - sending probe request
[ 1094.004662] eth1: detected beacon loss from AP - sending probe request
[ 1096.004662] eth1: detected beacon loss from AP - sending probe request
[ 1096.229341] eth1: cancelling probereq poll due to a received beacon
[ 1097.002034] eth1: detected beacon loss from AP - sending probe request
[ 1099.004036] eth1: detected beacon loss from AP - sending probe request
[ 1101.004034] eth1: detected beacon loss from AP - sending probe request
[ 1101.243160] eth1: cancelling probereq poll due to a received beacon
[ 1102.002041] eth1: detected beacon loss from AP - sending probe request
[ 1110.004664] eth1: detected beacon loss from AP - sending probe request
[ 1112.004661] eth1: detected beacon loss from AP - sending probe request
[ 1114.004652] eth1: detected beacon loss from AP - sending probe request
[ 1116.004654] eth1: detected beacon loss from AP - sending probe request
[ 1118.004654] eth1: detected beacon loss from AP - sending probe request
[ 1118.233488] eth1: cancelling probereq poll due to a received beacon
[ 1119.002034] eth1: detected beacon loss from AP - sending probe request
[ 1119.053983] eth1: cancelling probereq poll due to a received beacon
[ 1120.002037] eth1: detected beacon loss from AP - sending probe request
[ 1120.486930] eth1: cancelling probereq poll due to a received beacon
[ 1122.004652] eth1: detected beacon loss from AP - sending probe request
[ 1125.004027] eth1: detected beacon loss from AP - sending probe request
[ 1125.297132] eth1: cancelling probereq poll due to a received beacon
[ 1128.002028] eth1: detected beacon loss from AP - sending probe request
[ 1128.061036] eth1: cancelling probereq poll due to a received beacon
[ 1130.004652] eth1: detected beacon loss from AP - sending probe request
[ 1130.312726] eth1: cancelling probereq poll due to a received beacon
[ 1132.004658] eth1: detected beacon loss from AP - sending probe request
[ 1135.004038] eth1: detected beacon loss from AP - sending probe request
[ 1139.004040] eth1: detected beacon loss from AP - sending probe request
[ 1141.004036] eth1: detected beacon loss from AP - sending probe request
[ 1144.004661] eth1: detected beacon loss from AP - sending probe request
[ 1146.004653] eth1: detected beacon loss from AP - sending probe request
[ 1148.004664] eth1: detected beacon loss from AP - sending probe request
[ 1152.002038] eth1: detected beacon loss from AP - sending probe request
[ 1159.004048] eth1: detected beacon loss from AP - sending probe request
[ 1161.004036] eth1: detected beacon loss from AP - sending probe request
[ 1163.004039] eth1: detected beacon loss from AP - sending probe request
[ 1163.269913] eth1: cancelling probereq poll due to a received beacon
[ 1165.004053] eth1: detected beacon loss from AP - sending probe request
[ 1165.010338] eth1: cancelling probereq poll due to a received beacon
[ 1169.002037] eth1: detected beacon loss from AP - sending probe request
[ 1169.204488] eth1: cancelling probereq poll due to a received beacon
[ 1170.002032] eth1: detected beacon loss from AP - sending probe request
[ 1176.004656] eth1: detected beacon loss from AP - sending probe request
[ 1180.004669] eth1: detected beacon loss from AP - sending probe request
[ 1180.056148] eth1: cancelling probereq poll due to a received beacon
[ 1184.004662] eth1: detected beacon loss from AP - sending probe request
[ 1184.047795] eth1: cancelling probereq poll due to a received beacon
[ 1185.002035] eth1: detected beacon loss from AP - sending probe request
[ 1187.004033] eth1: detected beacon loss from AP - sending probe request
[ 1189.004036] eth1: detected beacon loss from AP - sending probe request
[ 1195.004029] eth1: detected beacon loss from AP - sending probe request
[ 1195.408589] eth1: cancelling probereq poll due to a received beacon
[ 1197.004036] eth1: detected beacon loss from AP - sending probe request
[ 1199.004036] eth1: detected beacon loss from AP - sending probe request
[ 1202.004662] eth1: detected beacon loss from AP - sending probe request
[ 1202.061495] eth1: cancelling probereq poll due to a received beacon
[ 1203.002029] eth1: detected beacon loss from AP - sending probe request
[ 1205.004037] eth1: detected beacon loss from AP - sending probe request
[ 1207.004036] eth1: detected beacon loss from AP - sending probe request
[ 1209.004037] eth1: detected beacon loss from AP - sending probe request
[ 1211.004024] eth1: detected beacon loss from AP - sending probe request
[ 1215.002037] eth1: detected beacon loss from AP - sending probe request
[ 1222.004663] eth1: detected beacon loss from AP - sending probe request
[ 1233.004037] eth1: detected beacon loss from AP - sending probe request
[ 3703.522722] ath: received PCI FATAL interrupt
[ 3705.004034] eth1: detected beacon loss from AP - sending probe request
[ 3705.505041] ieee80211 phy0: eth1: Failed to send nullfunc to AP 00:02:6f:21:ea:94 after 500ms, disconnecting.
[ 3705.506029] ieee80211 phy0: Removed STA 00:02:6f:21:ea:94
[ 3705.506041] ieee80211 phy0: Destroyed STA 00:02:6f:21:ea:94
[ 3705.506053] ieee80211 phy0: device now idle
[ 3705.518226] cfg80211: Calling CRDA for country: US
[ 3705.531607] cfg80211: Regulatory domain changed to country: US
[ 3705.531617] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 3705.531629] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 3705.531639] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[ 3705.531650] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3705.531660] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3705.531670] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 3705.531680] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[ 3705.531709] cfg80211: Calling CRDA for country: NA
[ 3729.069673] ieee80211 phy0: device no longer idle - scanning
[ 3732.667595] ieee80211 phy0: device now idle
[ 3732.675072] ieee80211 phy0: device no longer idle - working
[ 3732.685319] eth1: direct probe to 00:02:6f:21:ea:94 (try 1/3)
[ 3732.885476] eth1: direct probe to 00:02:6f:21:ea:94 (try 2/3)
[ 3733.085043] eth1: direct probe to 00:02:6f:21:ea:94 (try 3/3)
[ 3733.285038] eth1: direct probe to 00:02:6f:21:ea:94 timed out
[ 3733.286035] ieee80211 phy0: device now idle
[-- Attachment #3: log2_after_wpa_supplicant_4x_trying_to_auth.txt --]
[-- Type: text/plain, Size: 1850 bytes --]
[ 3866.251301] ieee80211 phy0: device no longer idle - scanning
[ 3869.412919] eth1: direct probe to 00:02:6f:21:ea:94 (try 1/3)
[ 3869.612048] eth1: direct probe to 00:02:6f:21:ea:94 (try 2/3)
[ 3869.812043] eth1: direct probe to 00:02:6f:21:ea:94 (try 3/3)
[ 3870.012035] eth1: direct probe to 00:02:6f:21:ea:94 timed out
[ 3870.013037] ieee80211 phy0: device now idle
[ 3875.029880] ieee80211 phy0: device no longer idle - scanning
[ 3875.245414] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 3875.245468] ath: Failed to stop TX DMA!
[ 3878.196841] eth1: direct probe to 00:02:6f:21:ea:94 (try 1/3)
[ 3878.396046] eth1: direct probe to 00:02:6f:21:ea:94 (try 2/3)
[ 3878.596024] eth1: direct probe to 00:02:6f:21:ea:94 (try 3/3)
[ 3878.796062] eth1: direct probe to 00:02:6f:21:ea:94 timed out
[ 3878.797038] ieee80211 phy0: device now idle
[ 3883.814050] ieee80211 phy0: device no longer idle - scanning
[ 3884.314318] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 3884.314371] ath: Failed to stop TX DMA!
[ 3886.980998] eth1: direct probe to 00:02:6f:21:ea:94 (try 1/3)
[ 3887.181043] eth1: direct probe to 00:02:6f:21:ea:94 (try 2/3)
[ 3887.381042] eth1: direct probe to 00:02:6f:21:ea:94 (try 3/3)
[ 3887.581029] eth1: direct probe to 00:02:6f:21:ea:94 timed out
[ 3887.582032] ieee80211 phy0: device now idle
[ 3887.590413] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 3887.590465] ath: Failed to stop TX DMA!
[ 3892.602928] ieee80211 phy0: device no longer idle - scanning
[ 3895.767977] eth1: direct probe to 00:02:6f:21:ea:94 (try 1/3)
[ 3895.967048] eth1: direct probe to 00:02:6f:21:ea:94 (try 2/3)
[ 3896.167040] eth1: direct probe to 00:02:6f:21:ea:94 (try 3/3)
[ 3896.367039] eth1: direct probe to 00:02:6f:21:ea:94 timed out
[ 3896.368038] ieee80211 phy0: device now idle
[-- Attachment #4: log3_after_rmmod_modprobe.txt --]
[-- Type: text/plain, Size: 1148 bytes --]
[ 3928.010276] ieee80211 phy0: device no longer idle - scanning
[ 3931.185157] ieee80211 phy0: device now idle
[ 3946.277200] ieee80211 phy0: device no longer idle - scanning
[ 3949.442729] ieee80211 phy0: device now idle
[ 3963.534723] ath9k 0000:02:02.0: PCI INT A disabled
[ 3963.534769] ath9k: Driver unloaded
[ 3970.103921] ath9k 0000:02:02.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
[ 3971.667953] ath: EEPROM regdomain: 0x0
[ 3971.667959] ath: EEPROM indicates default country code should be used
[ 3971.667961] ath: doing EEPROM country->regdmn map search
[ 3971.667966] ath: country maps to regdmn code: 0x3a
[ 3971.667969] ath: Country alpha2 being used: US
[ 3971.668009] ath: Regpair used: 0x3a
[ 3971.677862] ieee80211 phy1: Selected rate control algorithm 'ath9k_rate_control'
[ 3971.678916] Registered led device: ath9k-phy1::radio
[ 3971.679244] Registered led device: ath9k-phy1::assoc
[ 3971.679557] Registered led device: ath9k-phy1::tx
[ 3971.679866] Registered led device: ath9k-phy1::rx
[ 3971.679876] ieee80211 phy1: Atheros AR9280 Rev:2 mem=0xf8800000, irq=21
[ 3971.708098] udev: renamed network interface wlan0 to eth1
[-- Attachment #5: log4_after_power_cycle_and_iw_connect.txt --]
[-- Type: text/plain, Size: 8796 bytes --]
[ 0.040025] Time: 20:28:45 Date: 01/07/11
[ 21.240806] ieee80211 phy0: device now idle
[ 24.848752] ieee80211 phy0: device no longer idle - scanning
[ 28.344240] eth1: authenticate with 00:02:6f:21:ea:94 (try 1)
[ 28.346255] eth1: authenticated
[ 28.346300] eth1: associate with 00:02:6f:21:ea:94 (try 1)
[ 28.348861] eth1: RX AssocResp from 00:02:6f:21:ea:94 (capab=0x421 status=0 aid=1)
[ 28.348872] eth1: associated
[ 28.348889] ieee80211 phy0: Allocated STA 00:02:6f:21:ea:94
[ 28.348925] ieee80211 phy0: Inserted STA 00:02:6f:21:ea:94
[ 28.348939] ieee80211 phy0: WMM queue=2 aci=0 acm=0 aifs=2 cWmin=7 cWmax=1023 txop=64 uapsd=0
[ 28.348956] ieee80211 phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0 uapsd=0
[ 28.348970] ieee80211 phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94 uapsd=0
[ 28.348984] ieee80211 phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47 uapsd=0
[ 29.708663] eth1: detected beacon loss from AP - sending probe request
[ 29.802310] eth1: cancelling probereq poll due to a received beacon
[ 30.706036] eth1: detected beacon loss from AP - sending probe request
[ 30.723929] eth1: cancelling probereq poll due to a received beacon
[ 31.706033] eth1: detected beacon loss from AP - sending probe request
[ 31.747957] eth1: cancelling probereq poll due to a received beacon
[ 32.706035] eth1: detected beacon loss from AP - sending probe request
[ 32.771984] eth1: cancelling probereq poll due to a received beacon
[ 33.706035] eth1: detected beacon loss from AP - sending probe request
[ 33.796014] eth1: cancelling probereq poll due to a received beacon
[ 34.717640] net_ratelimit: 1 callbacks suppressed
[ 34.717650] eth1: cancelling probereq poll due to a received beacon
[ 35.706037] eth1: detected beacon loss from AP - sending probe request
[ 35.741658] eth1: cancelling probereq poll due to a received beacon
[ 36.706037] eth1: detected beacon loss from AP - sending probe request
[ 36.765683] eth1: cancelling probereq poll due to a received beacon
[ 37.706040] eth1: detected beacon loss from AP - sending probe request
[ 37.789713] eth1: cancelling probereq poll due to a received beacon
[ 38.706038] eth1: detected beacon loss from AP - sending probe request
[ 38.711337] eth1: cancelling probereq poll due to a received beacon
[ 39.706039] eth1: detected beacon loss from AP - sending probe request
[ 40.759391] net_ratelimit: 2 callbacks suppressed
[ 40.759401] eth1: cancelling probereq poll due to a received beacon
[ 41.706040] eth1: detected beacon loss from AP - sending probe request
[ 41.783412] eth1: cancelling probereq poll due to a received beacon
[ 42.706038] eth1: detected beacon loss from AP - sending probe request
[ 42.807437] eth1: cancelling probereq poll due to a received beacon
[ 43.706034] eth1: detected beacon loss from AP - sending probe request
[ 43.729068] eth1: cancelling probereq poll due to a received beacon
[ 44.706037] eth1: detected beacon loss from AP - sending probe request
[ 44.753088] eth1: cancelling probereq poll due to a received beacon
[ 45.706036] eth1: detected beacon loss from AP - sending probe request
[ 46.801148] net_ratelimit: 2 callbacks suppressed
[ 46.801158] eth1: cancelling probereq poll due to a received beacon
[ 47.706036] eth1: detected beacon loss from AP - sending probe request
[ 47.722770] eth1: cancelling probereq poll due to a received beacon
[ 48.706036] eth1: detected beacon loss from AP - sending probe request
[ 48.746791] eth1: cancelling probereq poll due to a received beacon
[ 49.706043] eth1: detected beacon loss from AP - sending probe request
[ 49.770819] eth1: cancelling probereq poll due to a received beacon
[ 50.706037] eth1: detected beacon loss from AP - sending probe request
[ 50.794847] eth1: cancelling probereq poll due to a received beacon
[ 51.706022] eth1: detected beacon loss from AP - sending probe request
[ 52.740505] net_ratelimit: 2 callbacks suppressed
[ 52.740515] eth1: cancelling probereq poll due to a received beacon
[ 53.706055] eth1: detected beacon loss from AP - sending probe request
[ 53.764527] eth1: cancelling probereq poll due to a received beacon
[ 54.706018] eth1: detected beacon loss from AP - sending probe request
[ 54.788634] eth1: cancelling probereq poll due to a received beacon
[ 55.706038] eth1: detected beacon loss from AP - sending probe request
[ 55.710175] eth1: cancelling probereq poll due to a received beacon
[ 56.706039] eth1: detected beacon loss from AP - sending probe request
[ 56.734200] eth1: cancelling probereq poll due to a received beacon
[ 57.706042] eth1: detected beacon loss from AP - sending probe request
[ 58.782259] net_ratelimit: 2 callbacks suppressed
[ 58.782270] eth1: cancelling probereq poll due to a received beacon
[ 59.706042] eth1: detected beacon loss from AP - sending probe request
[ 59.806284] eth1: cancelling probereq poll due to a received beacon
[ 60.706038] eth1: detected beacon loss from AP - sending probe request
[ 60.727901] eth1: cancelling probereq poll due to a received beacon
[ 61.706038] eth1: detected beacon loss from AP - sending probe request
[ 61.751924] eth1: cancelling probereq poll due to a received beacon
[ 62.706038] eth1: detected beacon loss from AP - sending probe request
[ 62.775949] eth1: cancelling probereq poll due to a received beacon
[ 63.706039] eth1: detected beacon loss from AP - sending probe request
[ 64.721607] net_ratelimit: 2 callbacks suppressed
[ 64.721616] eth1: cancelling probereq poll due to a received beacon
[ 65.706044] eth1: detected beacon loss from AP - sending probe request
[ 65.745633] eth1: cancelling probereq poll due to a received beacon
[ 66.706056] eth1: detected beacon loss from AP - sending probe request
[ 66.769958] eth1: cancelling probereq poll due to a received beacon
[ 67.706038] eth1: detected beacon loss from AP - sending probe request
[ 67.793680] eth1: cancelling probereq poll due to a received beacon
[ 68.706032] eth1: detected beacon loss from AP - sending probe request
[ 68.715308] eth1: cancelling probereq poll due to a received beacon
[ 69.706039] eth1: detected beacon loss from AP - sending probe request
[ 70.763925] net_ratelimit: 2 callbacks suppressed
[ 70.763935] eth1: cancelling probereq poll due to a received beacon
[ 71.706034] eth1: detected beacon loss from AP - sending probe request
[ 71.787392] eth1: cancelling probereq poll due to a received beacon
[ 72.706037] eth1: detected beacon loss from AP - sending probe request
[ 72.709000] eth1: cancelling probereq poll due to a received beacon
[ 73.706039] eth1: detected beacon loss from AP - sending probe request
[ 73.733036] eth1: cancelling probereq poll due to a received beacon
[ 74.706033] eth1: detected beacon loss from AP - sending probe request
[ 74.757112] eth1: cancelling probereq poll due to a received beacon
[ 75.706037] eth1: detected beacon loss from AP - sending probe request
[ 76.805117] net_ratelimit: 2 callbacks suppressed
[ 76.805127] eth1: cancelling probereq poll due to a received beacon
[ 77.706040] eth1: detected beacon loss from AP - sending probe request
[ 77.726736] eth1: cancelling probereq poll due to a received beacon
[ 78.706036] eth1: detected beacon loss from AP - sending probe request
[ 78.750761] eth1: cancelling probereq poll due to a received beacon
[ 79.706040] eth1: detected beacon loss from AP - sending probe request
[ 79.774794] eth1: cancelling probereq poll due to a received beacon
[ 80.706036] eth1: detected beacon loss from AP - sending probe request
[ 80.798817] eth1: cancelling probereq poll due to a received beacon
[ 81.706037] eth1: detected beacon loss from AP - sending probe request
[ 82.744471] net_ratelimit: 2 callbacks suppressed
[ 82.744481] eth1: cancelling probereq poll due to a received beacon
[ 83.706039] eth1: detected beacon loss from AP - sending probe request
[ 83.768494] eth1: cancelling probereq poll due to a received beacon
[ 84.706038] eth1: detected beacon loss from AP - sending probe request
[ 84.792514] eth1: cancelling probereq poll due to a received beacon
[ 85.706038] eth1: detected beacon loss from AP - sending probe request
[ 85.714138] eth1: cancelling probereq poll due to a received beacon
[ 86.706037] eth1: detected beacon loss from AP - sending probe request
[ 86.738161] eth1: cancelling probereq poll due to a received beacon
[ 87.706033] eth1: detected beacon loss from AP - sending probe request
[ 88.786228] net_ratelimit: 2 callbacks suppressed
[ 88.786239] eth1: cancelling probereq poll due to a received beacon
[-- Attachment #6: log5_wpa_supplicant.txt --]
[-- Type: text/plain, Size: 254 bytes --]
# wpa_supplicant -Dnl80211 -ieth1 -c /etc/wpa_supplicant/wpa_supplicant.conf
Trying to authenticate with 00:02:6f:21:ea:94 (SSID='Stuge' freq=2417 MHz)
Authentication request to the driver failed
CTRL-EVENT-DISCONNECTED bssid=00:02:6f:21:ea:94 reason=2
[-- Attachment #7: log6_wpa_supplicant_after_iw_connect.txt --]
[-- Type: text/plain, Size: 268 bytes --]
Trying to authenticate with 00:02:6f:21:ea:94 (SSID='Stuge' freq=2417 MHz)
Trying to associate with 00:02:6f:21:ea:94 (SSID='Stuge' freq=2417 MHz)
Associated with 00:02:6f:21:ea:94
CTRL-EVENT-CONNECTED - Connection to 00:02:6f:21:ea:94 completed (auth) [id=1 id_str=]
[-- Attachment #8: log7_after_wpa_supplicant_and_iw_connect.txt --]
[-- Type: text/plain, Size: 2698 bytes --]
[ 89.706035] eth1: detected beacon loss from AP - sending probe request
[ 89.810249] eth1: cancelling probereq poll due to a received beacon
[ 90.706036] eth1: detected beacon loss from AP - sending probe request
[ 90.731865] eth1: cancelling probereq poll due to a received beacon
[ 91.706036] eth1: detected beacon loss from AP - sending probe request
[ 91.755888] eth1: cancelling probereq poll due to a received beacon
[ 92.706035] eth1: detected beacon loss from AP - sending probe request
[ 92.779920] eth1: cancelling probereq poll due to a received beacon
[ 93.706014] eth1: detected beacon loss from AP - sending probe request
[ 94.725552] net_ratelimit: 2 callbacks suppressed
[ 94.725558] eth1: cancelling probereq poll due to a received beacon
[ 95.150498] eth1: deauthenticating from 00:02:6f:21:ea:94 by local choice (reason=2)
[ 95.151032] ieee80211 phy0: Removed STA 00:02:6f:21:ea:94
[ 95.151044] ieee80211 phy0: Destroyed STA 00:02:6f:21:ea:94
[ 95.151055] ieee80211 phy0: device now idle
[ 95.158416] cfg80211: Calling CRDA for country: US
[ 95.175126] cfg80211: Regulatory domain changed to country: US
[ 95.175137] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 95.175149] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 95.175160] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[ 95.175170] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 95.175180] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 95.175190] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 95.175200] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[ 95.175228] cfg80211: Calling CRDA for country: NA
[ 144.165559] ieee80211 phy0: device no longer idle - scanning
[ 147.671758] eth1: authenticate with 00:02:6f:21:ea:94 (try 1)
[ 147.673640] eth1: authenticated
[ 147.673815] eth1: associate with 00:02:6f:21:ea:94 (try 1)
[ 147.676657] eth1: RX AssocResp from 00:02:6f:21:ea:94 (capab=0x421 status=0 aid=1)
[ 147.676668] eth1: associated
[ 147.676685] ieee80211 phy0: Allocated STA 00:02:6f:21:ea:94
[ 147.676771] ieee80211 phy0: Inserted STA 00:02:6f:21:ea:94
[ 147.676785] ieee80211 phy0: WMM queue=2 aci=0 acm=0 aifs=2 cWmin=7 cWmax=1023 txop=64 uapsd=0
[ 147.676804] ieee80211 phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0 uapsd=0
[ 147.676818] ieee80211 phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94 uapsd=0
[ 147.676832] ieee80211 phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47 uapsd=0
^ permalink raw reply
* Re: [PATCH] compat: fix a typo in pm_qos_update_request for 2.6.35
From: Luis R. Rodriguez @ 2011-01-07 21:34 UTC (permalink / raw)
To: Jason Andryuk; +Cc: Luis Rodriguez, Felix Fietkau, linux-wireless, Tim Gardner
In-Reply-To: <AANLkTiksqbUnvNV=yQJxC=kGJzBpRk2FrwftKWv5A18G@mail.gmail.com>
On Fri, Jan 07, 2011 at 12:42:05PM -0800, Jason Andryuk wrote:
> On Fri, Nov 12, 2010 at 2:16 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > On Fri, Nov 12, 2010 at 10:47 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> >> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> >
> > Applied and pushed, thanks!
> >
> > Luis
>
> This patch is to compile compat-wireless-2.6.37-2-sn.tar.bz2 on Ubuntu
> 10.10 2.6.35-24-generic.
I just sucked these two:
commit 7010ed051959df86a772dd730b8ea5921cc350d8
Author: Felix Fietkau <nbd@openwrt.org>
Date: Fri Nov 12 11:15:28 2010 -0800
compat: fix a typo in pm_qos_update_request for 2.6.35
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
commit e8f244e7399eb4eb0ef6930bbcefe6fea74b4a73
Author: Felix Fietkau <nbd@openwrt.org>
Date: Fri Nov 12 11:14:44 2010 -0800
compat: fix pm_qos_params compile error on 2.6.35
Linux 2.6.35 pm_qos_params.h is missing a #ifndef/define/endif around
its header file contents, causing a compile error when its functions
are overwritten by macros in the compat header files.
Fix this by adding these to the compat version of this header file.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
into these releases:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.37/compat-wireless-2.6.37-3.tar.bz2
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.37/compat-wireless-2.6.37-3-sn.tar.bz2
Please test and let me know if that fixes your woes.
Luis
^ permalink raw reply
* Re: [PATCH] compat: fix a typo in pm_qos_update_request for 2.6.35
From: Jason Andryuk @ 2011-01-07 20:42 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <AANLkTimsTn7SFPXvUM7Puc7N+30O=c5LC+AiN4b=8wmy@mail.gmail.com>
On Fri, Nov 12, 2010 at 2:16 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Fri, Nov 12, 2010 at 10:47 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>
> Applied and pushed, thanks!
>
> Luis
This patch is to compile compat-wireless-2.6.37-2-sn.tar.bz2 on Ubuntu
10.10 2.6.35-24-generic.
Jason
^ permalink raw reply
* Re: [PATCH v2] compat: fix pm_qos_params compile error on 2.6.35
From: Jason Andryuk @ 2011-01-07 20:41 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <AANLkTinqd0soSAeTe0CtsXdnRvFHfBXa-YipNV2LWVbm@mail.gmail.com>
On Fri, Nov 12, 2010 at 2:16 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Fri, Nov 12, 2010 at 11:12 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> Linux 2.6.35 pm_qos_params.h is missing a #ifndef/define/endif around
>> its header file contents, causing a compile error when its functions
>> are overwritten by macros in the compat header files.
>> Fix this by adding these to the compat version of this header file.
>>
>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>
> Applied and pushed, thanks!
>
> Luis
This patch is to compile compat-wireless-2.6.37-2-sn.tar.bz2 on Ubuntu
10.10 2.6.35-24-generic.
Jason
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: Luis R. Rodriguez @ 2011-01-07 20:30 UTC (permalink / raw)
To: Luis Rodriguez
Cc: Peter Stuge, Ben Greear, linux-wireless@vger.kernel.org,
ath9k-devel@venema.h4ckr.net
In-Reply-To: <20110107202531.GK21588@tux>
On Fri, Jan 07, 2011 at 12:25:31PM -0800, Luis Rodriguez wrote:
> On Fri, Jan 07, 2011 at 12:01:01PM -0800, Luis Rodriguez wrote:
> > On Fri, Jan 07, 2011 at 07:36:07AM -0800, Peter Stuge wrote:
> > > Ben Greear wrote:
> > > > > but at least other clueless users would not go over stable limit
> > > > > you have found.
> > > >
> > > > I think it's very likely that the problems I find are general
> > > > issues that are just much easier to hit with lots of stations.
> > >
> > > I strongly support this. I recognize several of your problems from my
> > > attempts at using ath9k with only a single STA which was all but stable.
> >
> > Sure, see my other e-mail.
> >
> > > > There is probably no 'safe' number of stations...just takes longer
> > > > to see bugs with fewer stations.
> > > >
> > > > For instance, you still see the failure-to-stop-DMA errors with a
> > > > single station, right? And the tx locking stuff was just easier to
> > > > exercise with lots of stations, but it would have been possible to
> > > > hit it with 2 stations.
> > > >
> > > > The current tx-hang stuff I'm chasing seems like logic bugs in the
> > > > queueing, probably nothing in particular about the chipset.
> > >
> > > This is also my impression. Since it is important for Atheros to have
> > > bugzilla reports rather than discussion on list
> >
> > I'm trying to tell you how you can more efficiently work with developers
> > on reporting issues, I'm not singling you out but I am telling you that
> > the energy you spend on complaining on things not being addressed can be
> > better put on reporting issues more efficiently.
> >
> > Reporting issues on the list helps but what helps is a describin the
> > issue for a specific release but the most difficult thing to do sometimes
> > is to come up with a recipe for a way to reproduce a specific issue. Without
> > this it is harder to debug issues. If you can come up with ways to reproduce
> > issues then it becomes easier for engineers to start digging. Additionally
> > if an issue is seen that was not observed before the reporter may also
> > do a git bisect to try to identify the culprit commit. Be aware though that
> > bisecting on wireless-testing can only be done against the master-* tags,
> > and not on the entire tree due to the way John updates his tree. If you
> > see the issue on a stable kernel though you can just use Linus' tree or
> > the linux-2.6-allstable git tree which will have the stable extra versioned
> > kernels as well.
> >
> > Reporting issues for stable kernels should go through the kernel bugzilla,
> > but can start off on the mailing list. ath9k-devel though is not ideal for
> > reporting major issues and I recommend linux-wireless to be used instead
> > for that. If an issue is reporting for wireless-testing with a good series
> > of reproducible steps chances are very high it will be addressed. Motivated
> > highly technical users willing to help further get bonus points if they go
> > the extra mile and bisect.
> >
> > Furthermore, issues can be kept track on here:
> >
> > http://wireless.kernel.org/en/users/Drivers/ath9k/bugs
> >
> > This keeps track of major issues reported, and what people are working on.
>
> I'll also note:
>
> http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
>
> If this needs update feel free to edit. The hope is to make it easier for
> users to identify issues and report them properly.
Oh and before I forget, last tip, using a new wpa_supplicant always helps me :)
Luis
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Eric Dumazet @ 2011-01-07 20:26 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ben Greear, Johannes Berg, ath9k-devel@venema.h4ckr.net,
linux-wireless@vger.kernel.org
In-Reply-To: <20110107200913.GF21588@tux>
Le vendredi 07 janvier 2011 à 12:09 -0800, Luis R. Rodriguez a écrit :
> On Fri, Jan 07, 2011 at 10:34:52AM -0800, Ben Greear wrote:
> > On 01/07/2011 02:58 AM, Johannes Berg wrote:
> > > On Thu, 2011-01-06 at 16:46 -0800, greearb@candelatech.com wrote:
> > >> From: Ben Greear<greearb@candelatech.com>
> > >>
> > >> Patch is from Eric Dumazet, as described here:
> > >> https://patchwork.kernel.org/patch/104271/
> > >>
> > >> Reported-by: Michael Guntsche<mike@it-loops.com>
> > >> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> > >> Signed-off-by: Ben Greear<greearb@candelatech.com>
> > >> ---
> > >>
> > >> NOTE: This needs review by ath9k and/or other informed
> > >> people.
> > >
> > > This doesn't make sense. It might help, but it'll probably lead to not
> > > being able to receive all frames off the air.
> > >
> > > If this is an issue, ath9k should do paged RX like iwlwifi.
> >
> > Ok, I backed this out..but now I'm back to getting buffer allocation
> > failures (and this is on a system with 2GB RAM).
> >
> > Seems it's coming from mac80211 instead of ath9k, at least most of
> > the time (I'm using 60 stations, so it probably needs to make lots of
> > copies in the rx path). The traffic I'm generating/receiving is 1024 byte UDP
> > payloads.
> >
> > Does this mean I really received a packet that was 3872 bytes long,
> > or is the skb_copy allocating/copying empty data?
>
> Good question. The buffer we setup for DMA should be large since we
> need to support AMSDU RX up to a certain bytes of RX data for the frame.
> Harwdware should tell us the right size for the RX'd data and the skb
> should be set with that size, respectively. Following this logic,
> skb_copy() should only allocate on the order of the required skb->len.
>
> Remember that trick we did to force the older memory leak issues by
> forcing an skb_copy() on every RX'd frame and then just discarding that
> buffer immediately? You can try to do the same and print the skb->len
> there, just to check what's going on.
Using skb_copy() is wrong then, since it makes a copy (order-1
allocations)
It should use :
skb_alloc( actual_size_of_frame not the 3840 thing ...)
copy(data)
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: Luis R. Rodriguez @ 2011-01-07 20:25 UTC (permalink / raw)
To: Luis Rodriguez
Cc: Peter Stuge, Ben Greear, linux-wireless@vger.kernel.org,
ath9k-devel@venema.h4ckr.net
In-Reply-To: <20110107200101.GE21588@tux>
On Fri, Jan 07, 2011 at 12:01:01PM -0800, Luis Rodriguez wrote:
> On Fri, Jan 07, 2011 at 07:36:07AM -0800, Peter Stuge wrote:
> > Ben Greear wrote:
> > > > but at least other clueless users would not go over stable limit
> > > > you have found.
> > >
> > > I think it's very likely that the problems I find are general
> > > issues that are just much easier to hit with lots of stations.
> >
> > I strongly support this. I recognize several of your problems from my
> > attempts at using ath9k with only a single STA which was all but stable.
>
> Sure, see my other e-mail.
>
> > > There is probably no 'safe' number of stations...just takes longer
> > > to see bugs with fewer stations.
> > >
> > > For instance, you still see the failure-to-stop-DMA errors with a
> > > single station, right? And the tx locking stuff was just easier to
> > > exercise with lots of stations, but it would have been possible to
> > > hit it with 2 stations.
> > >
> > > The current tx-hang stuff I'm chasing seems like logic bugs in the
> > > queueing, probably nothing in particular about the chipset.
> >
> > This is also my impression. Since it is important for Atheros to have
> > bugzilla reports rather than discussion on list
>
> I'm trying to tell you how you can more efficiently work with developers
> on reporting issues, I'm not singling you out but I am telling you that
> the energy you spend on complaining on things not being addressed can be
> better put on reporting issues more efficiently.
>
> Reporting issues on the list helps but what helps is a describin the
> issue for a specific release but the most difficult thing to do sometimes
> is to come up with a recipe for a way to reproduce a specific issue. Without
> this it is harder to debug issues. If you can come up with ways to reproduce
> issues then it becomes easier for engineers to start digging. Additionally
> if an issue is seen that was not observed before the reporter may also
> do a git bisect to try to identify the culprit commit. Be aware though that
> bisecting on wireless-testing can only be done against the master-* tags,
> and not on the entire tree due to the way John updates his tree. If you
> see the issue on a stable kernel though you can just use Linus' tree or
> the linux-2.6-allstable git tree which will have the stable extra versioned
> kernels as well.
>
> Reporting issues for stable kernels should go through the kernel bugzilla,
> but can start off on the mailing list. ath9k-devel though is not ideal for
> reporting major issues and I recommend linux-wireless to be used instead
> for that. If an issue is reporting for wireless-testing with a good series
> of reproducible steps chances are very high it will be addressed. Motivated
> highly technical users willing to help further get bonus points if they go
> the extra mile and bisect.
>
> Furthermore, issues can be kept track on here:
>
> http://wireless.kernel.org/en/users/Drivers/ath9k/bugs
>
> This keeps track of major issues reported, and what people are working on.
I'll also note:
http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
If this needs update feel free to edit. The hope is to make it easier for
users to identify issues and report them properly.
Luis
^ permalink raw reply
* Re: [ath9k-devel] [PATCH v2 3/3] ath9k: Keep track of stations for debugfs.
From: Ben Greear @ 2011-01-07 20:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
In-Reply-To: <20110107201204.GG21588@tux>
On 01/07/2011 12:12 PM, Luis R. Rodriguez wrote:
> On Thu, Jan 06, 2011 at 08:49:12PM -0800, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> The stations hold the ath_node, which holds the tid
>> and other xmit logic structures. In order to debug
>> stuck xmit logic, we need a way to print out the tid
>> state for the stations.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>> ---
>>
>> v1 -> v2: Use linked list instead of array. Protect with spinlock.
>
> Again, see my comments about the # STAs limit. I think this can go in
> as a cfg80211 driver limitation which can be exposed. If you want to go
> over the supported number (known to work, safe, call it what you want)
> then a kconfig option can be used.
Either way, it's a separate patch.
The last thing I want to do is to make it harder to reproduce bugs,
so if 60 causes issues, and we made the default limit to 32,
then it just makes it that much harder for someone to reproduce
bugs and fix them (twiddle kconfig, re-compile kernel, etc).
I surely can't stop you from putting in a similar patch, but
I'm going to focus my own efforts on fixing problems I've already
found.
Thanks,
Ben
>
> Luis
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Luis R. Rodriguez @ 2011-01-07 20:22 UTC (permalink / raw)
To: Aleksandar Milivojevic
Cc: Helmut Schaa, Luis Rodriguez, linux-wireless@vger.kernel.org,
Wolfgang Kufner, Luis Correia, users@rt2x00.serialmonkey.com
In-Reply-To: <AANLkTi=cxggOG6xkVQqJ9S+ieg8LD43TSVEYAJW7YFrk@mail.gmail.com>
On Fri, Jan 07, 2011 at 11:46:48AM -0800, Aleksandar Milivojevic wrote:
> On Fri, Jan 7, 2011 at 2:11 AM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
> > Am Freitag, 7. Januar 2011 schrieb Luis R. Rodriguez:
> >> On Thu, Jan 06, 2011 at 08:31:22AM -0800, Aleksandar Milivojevic wrote:
> >> > Playing with it a bit more this morning. Looks like the connection
> >> > from wireless adapter to my AP drops periodically. Sometimes it
> >> > recovers (sometimes after several attempts), sometimes it does not.
> >> > Seems to be very random:
> >> >
> >> > # egrep 'authent|associat' /var/log/debug
> >> > Jan 6 08:00:54 toporko kernel: [ 47.570810] wlan0: authenticate
> >> > with 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:00:54 toporko kernel: [ 47.571321] wlan0: authenticated
> >> > Jan 6 08:00:56 toporko kernel: [ 49.174175] wlan0: associate with
> >> > 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:00:56 toporko kernel: [ 49.175536] wlan0: associated
> >> > Jan 6 08:06:01 toporko kernel: [ 354.230874] wlan0: authenticate
> >> > with 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:06:01 toporko kernel: [ 354.231364] wlan0: authenticated
> >> > Jan 6 08:06:01 toporko kernel: [ 354.236066] wlan0: associate with
> >> > 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:06:01 toporko kernel: [ 354.236865] wlan0: associated
> >> > Jan 6 08:09:36 toporko kernel: [ 569.868923] wlan0: authenticate
> >> > with 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:09:36 toporko kernel: [ 569.869416] wlan0: authenticated
> >> > Jan 6 08:09:36 toporko kernel: [ 569.873736] wlan0: associate with
> >> > 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:09:36 toporko kernel: [ 569.874507] wlan0: associated
> >> > Jan 6 08:09:46 toporko kernel: [ 579.233563] wlan0: authenticate
> >> > with 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:09:46 toporko kernel: [ 579.235574] wlan0: authenticated
> >> > Jan 6 08:09:46 toporko kernel: [ 579.240737] wlan0: associate with
> >> > 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:09:46 toporko kernel: [ 579.241518] wlan0: associated
> >> > Jan 6 08:09:57 toporko kernel: [ 590.830933] wlan0: authenticate
> >> > with 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:09:57 toporko kernel: [ 590.831435] wlan0: authenticated
> >> > Jan 6 08:09:57 toporko kernel: [ 590.839102] wlan0: associate with
> >> > 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:09:57 toporko kernel: [ 590.839881] wlan0: associated
> >> > Jan 6 08:21:29 toporko kernel: [ 1282.823289] wlan0: authenticate
> >> > with 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:21:29 toporko kernel: [ 1282.823783] wlan0: authenticated
> >> > Jan 6 08:21:29 toporko kernel: [ 1282.828990] wlan0: associate with
> >> > 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:21:29 toporko kernel: [ 1282.830132] wlan0: associated
> >> > Jan 6 08:25:30 toporko kernel: [ 1523.433931] wlan0: authenticate
> >> > with 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:25:30 toporko kernel: [ 1523.434930] wlan0: authenticated
> >> > Jan 6 08:25:30 toporko kernel: [ 1523.439868] wlan0: associate with
> >> > 00:1e:52:79:e9:ff (try 1)
> >> > Jan 6 08:25:30 toporko kernel: [ 1523.440652] wlan0: associated
> >> >
> >> > So far, it managed to re-connect every time. Though, I'm rather sure
> >> > if I leave it long enough, the last night's case of connection dropped
> >> > completely would repeat sooner or later (even last night, there were
> >> > some connect/disconnect events before connection was dropped
> >> > permanently).
> >> >
> >> > The AP reports signal from wireless card between -70 and -75dB, noise
> >> > at -96dB, and speed at 120mbps (with occasional drop to 45mbps).
> >> > These numbers sound about OK for the location (on the other side of my
> >> > apartment, few walls in between). For comparison, if I position my
> >> > MacBook at same location (right next to my Linux box), AP reports
> >> > signal from its AirPort card at about -60dB and speed in about 100mbps
> >> > range and no drops.
> >>
> >> The Linux regulatory code only relies on the Country IE from the AP you
> >> decide to associate to, that's it. Then, as for all the regulatory stuff
> >> popping out once you are associated, its happening because as I see it
> >> you are being disconnected from the AP. The Linux regulatory code will
> >> reset the regulatory settings after you disconnect from an AP.
> >>
> >> The disconnect issues should not be regularory related from what I see.
> >> Seems like a general disconnect issue with your driver.
> >
> > Sounds reasonable. Thanks for the update Luis. So, it's more likely a
> > rt2x00 or mac80211 issue.
>
> I'd put my vote there too, probably hitting some corner case or
> something specific to either WUSB600N or Airport Extreme or
> combination of the two. I'd be glad to help debug the issue, and if
> you need any info just give me a shout what to do, what to try out,
> and/or what to look for.
>
> There was huge improvement in rt2x00 regarding support for Linksys
> WUSB600N over the last half a year or so. Until several months ago,
> using rt2x00 driver, I wasn't able to connect to my AP at all (I would
> see the list of networks, but would not be able to connect to any of
> them). The version from 2.6.35 kernel would connect for short period
> of time, but speed was abysmal (in order of few kB/sec), and
> connection would be completely dropped within minutes. With the
> latest version of driver (compiled from comapt-wireless tarball), I'm
> getting good transfer speeds, and connection to my AP is mostly up
> (there's some flapping every few minutes, as you can see from logs).
> In the last two days, there was only one occurrence where connection
> to my AP was dropped and driver failed to re-connect.
You may want to try checing the 'iw event -t' output while the issue happens.
Maybe it is due to a roaming issue, if you are using a large BSS and roam
in between you may want to try using wpa_supplicant with nl80211 and use
the new bgscan module from wpa_supplicant to trigger you to only switch
based on triggered events from nl80211 like signal rssi changes.
Here is an example supplicant conf that uses the bgscan module:
# WPA-PSK/TKIP
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="my-corp-cool-bss"
bgscan="simple:30:-45:300"
key_mgmt=WPA-PSK
proto=RSN
pairwise=CCMP
group=CCMP
psk="foobar_is_great"
}
No Linux distributions today uses this other than ChromeOS, but they should
all change to use it.
Luis
^ permalink raw reply
* Re: [ath9k-devel] [PATCH v2 3/3] ath9k: Keep track of stations for debugfs.
From: Luis R. Rodriguez @ 2011-01-07 20:12 UTC (permalink / raw)
To: greearb@candelatech.com
Cc: linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
In-Reply-To: <1294375752-3946-1-git-send-email-greearb@candelatech.com>
On Thu, Jan 06, 2011 at 08:49:12PM -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> The stations hold the ath_node, which holds the tid
> and other xmit logic structures. In order to debug
> stuck xmit logic, we need a way to print out the tid
> state for the stations.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
>
> v1 -> v2: Use linked list instead of array. Protect with spinlock.
Again, see my comments about the # STAs limit. I think this can go in
as a cfg80211 driver limitation which can be exposed. If you want to go
over the supported number (known to work, safe, call it what you want)
then a kconfig option can be used.
Luis
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Luis R. Rodriguez @ 2011-01-07 20:09 UTC (permalink / raw)
To: Ben Greear
Cc: Johannes Berg, ath9k-devel@venema.h4ckr.net,
linux-wireless@vger.kernel.org, Eric Dumazet
In-Reply-To: <4D275CCC.90905@candelatech.com>
On Fri, Jan 07, 2011 at 10:34:52AM -0800, Ben Greear wrote:
> On 01/07/2011 02:58 AM, Johannes Berg wrote:
> > On Thu, 2011-01-06 at 16:46 -0800, greearb@candelatech.com wrote:
> >> From: Ben Greear<greearb@candelatech.com>
> >>
> >> Patch is from Eric Dumazet, as described here:
> >> https://patchwork.kernel.org/patch/104271/
> >>
> >> Reported-by: Michael Guntsche<mike@it-loops.com>
> >> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> >> Signed-off-by: Ben Greear<greearb@candelatech.com>
> >> ---
> >>
> >> NOTE: This needs review by ath9k and/or other informed
> >> people.
> >
> > This doesn't make sense. It might help, but it'll probably lead to not
> > being able to receive all frames off the air.
> >
> > If this is an issue, ath9k should do paged RX like iwlwifi.
>
> Ok, I backed this out..but now I'm back to getting buffer allocation
> failures (and this is on a system with 2GB RAM).
>
> Seems it's coming from mac80211 instead of ath9k, at least most of
> the time (I'm using 60 stations, so it probably needs to make lots of
> copies in the rx path). The traffic I'm generating/receiving is 1024 byte UDP
> payloads.
>
> Does this mean I really received a packet that was 3872 bytes long,
> or is the skb_copy allocating/copying empty data?
Good question. The buffer we setup for DMA should be large since we
need to support AMSDU RX up to a certain bytes of RX data for the frame.
Harwdware should tell us the right size for the RX'd data and the skb
should be set with that size, respectively. Following this logic,
skb_copy() should only allocate on the order of the required skb->len.
Remember that trick we did to force the older memory leak issues by
forcing an skb_copy() on every RX'd frame and then just discarding that
buffer immediately? You can try to do the same and print the skb->len
there, just to check what's going on.
Luis
^ permalink raw reply
* Compat-wireless release for 2011-01-07 is baked
From: Compat-wireless cronjob account @ 2011-01-07 20:04 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
07667d5..919757f linux-2.6.37.y -> origin/linux-2.6.37.y
c46a7ef..69ec1f8 master -> origin/master
* [new tag] compat-wireless-2011-01-06 -> compat-wireless-2011-01-06
* [new tag] compat-wireless-v2.6.37-2 -> compat-wireless-v2.6.37-2
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat
dcd6955..4bf0115 master -> origin/master
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
91493a5..d184f08 history -> origin/history
+ 47ec851...f69eb67 master -> origin/master (forced update)
3c0eee3..cb600d2 stable -> origin/stable
* [new tag] next-20110107 -> next-20110107
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
782479 - Total upstream lines of code being pulled
2103 - backport code changes
1843 - backport code additions
260 - backport code deletions
7279 - backport from compat module
9382 - total backport code
1.1990 - % of code consists of backport work
1531 - Crap changes not yet posted
1488 - Crap additions not yet posted
43 - Crap deletions not yet posted
0.1957 - % of crap code
Base tree: linux-next.git
Base tree version: next-20110107
compat-wireless release: compat-wireless-2011-01-06-pc
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: Luis R. Rodriguez @ 2011-01-07 20:01 UTC (permalink / raw)
To: Peter Stuge
Cc: Ben Greear, Luis Rodriguez, linux-wireless@vger.kernel.org,
ath9k-devel@venema.h4ckr.net
In-Reply-To: <20110107153607.11061.qmail@stuge.se>
On Fri, Jan 07, 2011 at 07:36:07AM -0800, Peter Stuge wrote:
> Ben Greear wrote:
> > > but at least other clueless users would not go over stable limit
> > > you have found.
> >
> > I think it's very likely that the problems I find are general
> > issues that are just much easier to hit with lots of stations.
>
> I strongly support this. I recognize several of your problems from my
> attempts at using ath9k with only a single STA which was all but stable.
Sure, see my other e-mail.
> > There is probably no 'safe' number of stations...just takes longer
> > to see bugs with fewer stations.
> >
> > For instance, you still see the failure-to-stop-DMA errors with a
> > single station, right? And the tx locking stuff was just easier to
> > exercise with lots of stations, but it would have been possible to
> > hit it with 2 stations.
> >
> > The current tx-hang stuff I'm chasing seems like logic bugs in the
> > queueing, probably nothing in particular about the chipset.
>
> This is also my impression. Since it is important for Atheros to have
> bugzilla reports rather than discussion on list
I'm trying to tell you how you can more efficiently work with developers
on reporting issues, I'm not singling you out but I am telling you that
the energy you spend on complaining on things not being addressed can be
better put on reporting issues more efficiently.
Reporting issues on the list helps but what helps is a describin the
issue for a specific release but the most difficult thing to do sometimes
is to come up with a recipe for a way to reproduce a specific issue. Without
this it is harder to debug issues. If you can come up with ways to reproduce
issues then it becomes easier for engineers to start digging. Additionally
if an issue is seen that was not observed before the reporter may also
do a git bisect to try to identify the culprit commit. Be aware though that
bisecting on wireless-testing can only be done against the master-* tags,
and not on the entire tree due to the way John updates his tree. If you
see the issue on a stable kernel though you can just use Linus' tree or
the linux-2.6-allstable git tree which will have the stable extra versioned
kernels as well.
Reporting issues for stable kernels should go through the kernel bugzilla,
but can start off on the mailing list. ath9k-devel though is not ideal for
reporting major issues and I recommend linux-wireless to be used instead
for that. If an issue is reporting for wireless-testing with a good series
of reproducible steps chances are very high it will be addressed. Motivated
highly technical users willing to help further get bonus points if they go
the extra mile and bisect.
Furthermore, issues can be kept track on here:
http://wireless.kernel.org/en/users/Drivers/ath9k/bugs
This keeps track of major issues reported, and what people are working on.
> I will try to find
> time for creating more and/or new bug reports about my problems.
Good, the bug reports will not be necessary if the issue is not on a
stable kernel as it will just be a regression against the last stable
kernel. If the issue is seen on a
> (But the ones I have created so far did not really receive very good
> response.)
Try to increase the quality of your reports and I assure you that your
issues will be addressed.
> Note that my AR9280 is not even detected correctly on PCI now so I
> may switch back to AR5008 for that.
>
> I really should try out FreeBSD too.
Good luck with that ;)
Luis
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Aleksandar Milivojevic @ 2011-01-07 19:46 UTC (permalink / raw)
To: Helmut Schaa
Cc: Luis R. Rodriguez, linux-wireless@vger.kernel.org,
Wolfgang Kufner, Luis Correia, users@rt2x00.serialmonkey.com
In-Reply-To: <201101071111.17423.helmut.schaa@googlemail.com>
On Fri, Jan 7, 2011 at 2:11 AM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Am Freitag, 7. Januar 2011 schrieb Luis R. Rodriguez:
>> On Thu, Jan 06, 2011 at 08:31:22AM -0800, Aleksandar Milivojevic wrote:
>> > Playing with it a bit more this morning. Looks like the connection
>> > from wireless adapter to my AP drops periodically. Sometimes it
>> > recovers (sometimes after several attempts), sometimes it does not.
>> > Seems to be very random:
>> >
>> > # egrep 'authent|associat' /var/log/debug
>> > Jan 6 08:00:54 toporko kernel: [ 47.570810] wlan0: authenticate
>> > with 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:00:54 toporko kernel: [ 47.571321] wlan0: authenticated
>> > Jan 6 08:00:56 toporko kernel: [ 49.174175] wlan0: associate with
>> > 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:00:56 toporko kernel: [ 49.175536] wlan0: associated
>> > Jan 6 08:06:01 toporko kernel: [ 354.230874] wlan0: authenticate
>> > with 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:06:01 toporko kernel: [ 354.231364] wlan0: authenticated
>> > Jan 6 08:06:01 toporko kernel: [ 354.236066] wlan0: associate with
>> > 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:06:01 toporko kernel: [ 354.236865] wlan0: associated
>> > Jan 6 08:09:36 toporko kernel: [ 569.868923] wlan0: authenticate
>> > with 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:09:36 toporko kernel: [ 569.869416] wlan0: authenticated
>> > Jan 6 08:09:36 toporko kernel: [ 569.873736] wlan0: associate with
>> > 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:09:36 toporko kernel: [ 569.874507] wlan0: associated
>> > Jan 6 08:09:46 toporko kernel: [ 579.233563] wlan0: authenticate
>> > with 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:09:46 toporko kernel: [ 579.235574] wlan0: authenticated
>> > Jan 6 08:09:46 toporko kernel: [ 579.240737] wlan0: associate with
>> > 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:09:46 toporko kernel: [ 579.241518] wlan0: associated
>> > Jan 6 08:09:57 toporko kernel: [ 590.830933] wlan0: authenticate
>> > with 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:09:57 toporko kernel: [ 590.831435] wlan0: authenticated
>> > Jan 6 08:09:57 toporko kernel: [ 590.839102] wlan0: associate with
>> > 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:09:57 toporko kernel: [ 590.839881] wlan0: associated
>> > Jan 6 08:21:29 toporko kernel: [ 1282.823289] wlan0: authenticate
>> > with 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:21:29 toporko kernel: [ 1282.823783] wlan0: authenticated
>> > Jan 6 08:21:29 toporko kernel: [ 1282.828990] wlan0: associate with
>> > 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:21:29 toporko kernel: [ 1282.830132] wlan0: associated
>> > Jan 6 08:25:30 toporko kernel: [ 1523.433931] wlan0: authenticate
>> > with 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:25:30 toporko kernel: [ 1523.434930] wlan0: authenticated
>> > Jan 6 08:25:30 toporko kernel: [ 1523.439868] wlan0: associate with
>> > 00:1e:52:79:e9:ff (try 1)
>> > Jan 6 08:25:30 toporko kernel: [ 1523.440652] wlan0: associated
>> >
>> > So far, it managed to re-connect every time. Though, I'm rather sure
>> > if I leave it long enough, the last night's case of connection dropped
>> > completely would repeat sooner or later (even last night, there were
>> > some connect/disconnect events before connection was dropped
>> > permanently).
>> >
>> > The AP reports signal from wireless card between -70 and -75dB, noise
>> > at -96dB, and speed at 120mbps (with occasional drop to 45mbps).
>> > These numbers sound about OK for the location (on the other side of my
>> > apartment, few walls in between). For comparison, if I position my
>> > MacBook at same location (right next to my Linux box), AP reports
>> > signal from its AirPort card at about -60dB and speed in about 100mbps
>> > range and no drops.
>>
>> The Linux regulatory code only relies on the Country IE from the AP you
>> decide to associate to, that's it. Then, as for all the regulatory stuff
>> popping out once you are associated, its happening because as I see it
>> you are being disconnected from the AP. The Linux regulatory code will
>> reset the regulatory settings after you disconnect from an AP.
>>
>> The disconnect issues should not be regularory related from what I see.
>> Seems like a general disconnect issue with your driver.
>
> Sounds reasonable. Thanks for the update Luis. So, it's more likely a
> rt2x00 or mac80211 issue.
I'd put my vote there too, probably hitting some corner case or
something specific to either WUSB600N or Airport Extreme or
combination of the two. I'd be glad to help debug the issue, and if
you need any info just give me a shout what to do, what to try out,
and/or what to look for.
There was huge improvement in rt2x00 regarding support for Linksys
WUSB600N over the last half a year or so. Until several months ago,
using rt2x00 driver, I wasn't able to connect to my AP at all (I would
see the list of networks, but would not be able to connect to any of
them). The version from 2.6.35 kernel would connect for short period
of time, but speed was abysmal (in order of few kB/sec), and
connection would be completely dropped within minutes. With the
latest version of driver (compiled from comapt-wireless tarball), I'm
getting good transfer speeds, and connection to my AP is mostly up
(there's some flapping every few minutes, as you can see from logs).
In the last two days, there was only one occurrence where connection
to my AP was dropped and driver failed to re-connect.
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: Luis R. Rodriguez @ 2011-01-07 19:46 UTC (permalink / raw)
To: Ben Greear
Cc: Luis Rodriguez, Luis R. Rodriguez, ath9k-devel@venema.h4ckr.net,
linux-wireless@vger.kernel.org
In-Reply-To: <4D2685CC.7020502@candelatech.com>
On Thu, Jan 06, 2011 at 07:17:32PM -0800, Ben Greear wrote:
> On 01/06/2011 06:49 PM, Luis R. Rodriguez wrote:
> > On Thu, Jan 06, 2011 at 06:45:33PM -0800, Ben Greear wrote:
> >> On 01/06/2011 06:30 PM, Luis R. Rodriguez wrote:
> >>> On Thu, Jan 6, 2011 at 4:46 PM,<greearb@candelatech.com> wrote:
> >>>> +#define ATH9K_MAX_STATIONS 1024
> >>>
> >>> How about making this a Kconfig with a default to a value of the known
> >>> (by you) max workable number of STAs that one can use on ath9k, which
> >>> is modifiable to other values by power of two up to 1024. Advise in
> >>> the kconfig that if more STAs are used then some issue may arise but
> >>> should be reported (so the issue can be fixed). This way by default
> >>> normal users (you're not normal) won't enable> max known workable
> >>> stable number of STAs on ath9k.
> >>
> >> This is just for debugging at this point. It wastes a bit of memory
> >> when debugfs is enabled, but otherwise doesn't affect anything. It's
> >> not even really a problem if there are more stations than fit in
> >> the array.
> >
> > I meant to use the value as a limit on the # of STAs you can create
> > with one ath9k device. The debugfs can still be used as you did,
> > only that the limit would come from the kconfig value.
> >
> >> I can reproduce all my problems with< 128, so if you'd prefer
> >> the number be smaller, that's fine with me. I don't think it's
> >> worth a configurable value, however.
> >
> > I thikn we should limit the # STAs to whatever it is that you can
> > use in a realiable way, this should be a driver limitation, but
> > I figured you'd want to configure this to a higher value yourself
> > for whatever tests you are doing. We should fix it though but at
> > least other clueless users would not go over stable limit you have
> > found.
>
> I think it's very likely that the problems I find are general issues that
> are just much easier to hit with lots of stations.
I agree 100% :)
> There is probably no
> 'safe' number of stations...just takes longer to see bugs with
> fewer stations.
The point is to prevent users from going above the known safe limit.
No point in allowing more STAs in the driver if they won't work.
As a matter of fact, this may be a welcomed cfg80211 driver limitation
which can be exposed via nl80211.
> For instance, you still see the failure-to-stop-DMA errors with a single station, right?
On some hard corner cases but yes, and this is exactly why I agree that
the issues you are seeing *must* be debugged and fixed. The issues you have
found with over 60 STAs on ath9k with one device have helped us reproduce
some hard corner case bugs that were triggerable before only in rare situations.
> And the tx locking stuff was just easier to exercise with lots of stations,
> but it would have been possible to hit it with 2 stations.
Right.
> The current tx-hang stuff I'm chasing seems like logic bugs in the queueing,
> probably nothing in particular about the chipset.
Sure.
Luis
^ permalink raw reply
* RE: brcm80211 can not set wireless interface mode master?
From: Brett Rudley @ 2011-01-07 19:06 UTC (permalink / raw)
To: stutiredboy, linux-wireless@vger.kernel.org
In-Reply-To: <4D26E00B.2090202@gmail.com>
> the brcm80211 still do not support master mode or anything i missed ?
>
Nope, not yet. Its among several features in the TODO list still to be implemented.
Thanks
Brett
^ permalink raw reply
* [PATCH] ssb: Ignore dangling ethernet cores on wireless devices
From: Michael Büsch @ 2011-01-07 18:48 UTC (permalink / raw)
To: John Linville; +Cc: Larry Finger, linux-wireless, b43-dev
Some Broadcom based wireless devices contain dangling ethernet cores.
This triggers the ssb probing mechanism and tries to load the b44 driver
on this core.
Ignore the dangling core in the ssb core scanning code to avoid
access to the core and failure of b44 probing.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Does not need to go into stable, because probing of that core
doesn't hurt except for failure messages in the logs.
Index: linux-2.6.37/drivers/ssb/scan.c
===================================================================
--- linux-2.6.37.orig/drivers/ssb/scan.c 2011-01-07 15:35:10.518000002 +0100
+++ linux-2.6.37/drivers/ssb/scan.c 2011-01-07 15:45:54.231998930 +0100
@@ -420,6 +420,16 @@
bus->pcicore.dev = dev;
#endif /* CONFIG_SSB_DRIVER_PCICORE */
break;
+ case SSB_DEV_ETHERNET:
+ if (bus->bustype == SSB_BUSTYPE_PCI) {
+ if (bus->host_pci->vendor == PCI_VENDOR_ID_BROADCOM &&
+ (bus->host_pci->device & 0xFF00) == 0x4300) {
+ /* This is a dangling ethernet core on a
+ * wireless device. Ignore it. */
+ continue;
+ }
+ }
+ break;
default:
break;
}
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Ben Greear @ 2011-01-07 18:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ath9k-devel, Eric Dumazet
In-Reply-To: <1294397880.3467.1.camel@jlt3.sipsolutions.net>
On 01/07/2011 02:58 AM, Johannes Berg wrote:
> On Thu, 2011-01-06 at 16:46 -0800, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> Patch is from Eric Dumazet, as described here:
>> https://patchwork.kernel.org/patch/104271/
>>
>> Reported-by: Michael Guntsche<mike@it-loops.com>
>> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>> ---
>>
>> NOTE: This needs review by ath9k and/or other informed
>> people.
>
> This doesn't make sense. It might help, but it'll probably lead to not
> being able to receive all frames off the air.
>
> If this is an issue, ath9k should do paged RX like iwlwifi.
Ok, I backed this out..but now I'm back to getting buffer allocation
failures (and this is on a system with 2GB RAM).
Seems it's coming from mac80211 instead of ath9k, at least most of
the time (I'm using 60 stations, so it probably needs to make lots of
copies in the rx path). The traffic I'm generating/receiving is 1024 byte UDP
payloads.
Does this mean I really received a packet that was 3872 bytes long,
or is the skb_copy allocating/copying empty data?
Jan 7 10:00:45 localhost kernel: skbuff alloc of size 3872 failed
Jan 7 10:00:45 localhost kernel: skbuff alloc of size 3872 failed
Jan 7 10:00:45 localhost kernel: __alloc_pages_slowpath: 2886 callbacks suppressed
Jan 7 10:00:45 localhost kernel: kswapd0: page allocation failure. order:2, mode:0x4020
Jan 7 10:00:45 localhost kernel: Pid: 29, comm: kswapd0 Not tainted 2.6.37-wl+ #62
Jan 7 10:00:45 localhost kernel: Call Trace:
Jan 7 10:00:45 localhost kernel: [<7878c822>] ? printk+0x18/0x1e
Jan 7 10:00:45 localhost kernel: [<784938ef>] __alloc_pages_nodemask+0x625/0x668
Jan 7 10:00:45 localhost kernel: [<784b66a5>] alloc_slab_page+0x1d/0x21
Jan 7 10:00:45 localhost kernel: [<784b66fc>] new_slab+0x53/0x144
Jan 7 10:00:45 localhost kernel: [<784b6c05>] __slab_alloc.clone.4+0x133/0x1f9
Jan 7 10:00:45 localhost kernel: [<784b6f3c>] ? kmem_cache_alloc+0x7c/0xa1
Jan 7 10:00:45 localhost kernel: [<786edc0d>] ? skb_copy+0x33/0x87
Jan 7 10:00:45 localhost kernel: [<784b7374>] __kmalloc_track_caller+0xc6/0x115
Jan 7 10:00:45 localhost kernel: [<786edc0d>] ? skb_copy+0x33/0x87
Jan 7 10:00:45 localhost kernel: [<786ed642>] __alloc_skb+0x58/0xf4
Jan 7 10:00:45 localhost kernel: [<786edc0d>] skb_copy+0x33/0x87
Jan 7 10:00:45 localhost kernel: [<fa4c73e2>] ieee80211_prepare_and_rx_handle+0x3be/0x86f [mac80211]
Jan 7 10:00:45 localhost kernel: [<fa4c80ba>] ieee80211_rx+0x795/0x853 [mac80211]
Jan 7 10:00:45 localhost kernel: [<fa4c7a1c>] ? ieee80211_rx+0xf7/0x853 [mac80211]
Jan 7 10:00:45 localhost kernel: [<7845007b>] ? pm_qos_update_request+0x4b/0x57
Jan 7 10:00:45 localhost kernel: [<fa591366>] ath_rx_send_to_mac80211+0x5a/0x60 [ath9k]
Jan 7 10:00:45 localhost kernel: [<fa592ce7>] ath_rx_tasklet+0x1318/0x13af [ath9k]
Jan 7 10:00:45 localhost kernel: [<7845a405>] ? mark_lock+0x1e/0x1eb
Jan 7 10:00:45 localhost kernel: [<7845a619>] ? mark_held_locks+0x47/0x5f
Jan 7 10:00:45 localhost kernel: [<7878ebcb>] ? _raw_spin_unlock_irqrestore+0x3c/0x48
Jan 7 10:00:45 localhost kernel: [<7845a85c>] ? trace_hardirqs_on_caller+0xeb/0x125
Jan 7 10:00:45 localhost kernel: [<7845a8a1>] ? trace_hardirqs_on+0xb/0xd
Jan 7 10:00:45 localhost kernel: [<fa590ce1>] ath9k_tasklet+0x98/0x12d [ath9k]
Jan 7 10:00:45 localhost kernel: [<7845a85c>] ? trace_hardirqs_on_caller+0xeb/0x125
Jan 7 10:00:45 localhost kernel: [<7843be09>] tasklet_action+0x88/0xe3
Jan 7 10:00:45 localhost kernel: [<7843c385>] __do_softirq+0x85/0x142
Jan 7 10:00:45 localhost kernel: [<7843c300>] ? __do_softirq+0x0/0x142
Jan 7 10:00:45 localhost kernel: [<7843c300>] ? __do_softirq+0x0/0x142
Jan 7 10:00:45 localhost kernel: <IRQ> [<7843c1a7>] ? irq_exit+0x35/0x69
Jan 7 10:00:45 localhost kernel: [<7841a399>] ? smp_apic_timer_interrupt+0x74/0x81
Jan 7 10:00:45 localhost kernel: [<785976e0>] ? trace_hardirqs_off_thunk+0xc/0x10
Jan 7 10:00:45 localhost kernel: [<7878f39f>] ? apic_timer_interrupt+0x2f/0x40
Jan 7 10:00:45 localhost kernel: [<7845007b>] ? pm_qos_update_request+0x4b/0x57
Jan 7 10:00:45 localhost kernel: [<784b700a>] ? kmem_cache_free+0xa9/0xb5
Jan 7 10:00:45 localhost kernel: [<7852cafa>] ? ext4_destroy_inode+0x91/0x98
Jan 7 10:00:45 localhost kernel: [<7852cafa>] ? ext4_destroy_inode+0x91/0x98
Jan 7 10:00:45 localhost kernel: [<7852cafa>] ? ext4_destroy_inode+0x91/0x98
Jan 7 10:00:45 localhost kernel: [<784d0c1d>] ? percpu_counter_dec+0x19/0x1b
Jan 7 10:00:45 localhost kernel: [<784d12f1>] ? destroy_inode+0x2d/0x3e
Jan 7 10:00:45 localhost kernel: [<784d17f8>] ? dispose_list+0x8d/0x9c
Jan 7 10:00:45 localhost kernel: [<784d1d8d>] ? shrink_icache_memory+0x1d7/0x218
Jan 7 10:00:45 localhost kernel: [<78497560>] ? shrink_slab+0xdc/0x144
Jan 7 10:00:45 localhost kernel: [<78498891>] ? kswapd+0x468/0x66f
Jan 7 10:00:45 localhost kernel: [<7844b776>] ? autoremove_wake_function+0x0/0x34
Jan 7 10:00:45 localhost kernel: [<78498429>] ? kswapd+0x0/0x66f
Jan 7 10:00:45 localhost kernel: [<7844b465>] ? kthread+0x62/0x67
Jan 7 10:00:45 localhost kernel: [<7844b403>] ? kthread+0x0/0x67
Jan 7 10:00:45 localhost kernel: [<784036c6>] ? kernel_thread_helper+0x6/0x1a
Jan 7 10:00:45 localhost kernel: Mem-Info:
Jan 7 10:00:45 localhost kernel: DMA per-cpu:
Jan 7 10:00:45 localhost kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 7 10:00:45 localhost kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 7 10:00:45 localhost kernel: Normal per-cpu:
Jan 7 10:00:45 localhost kernel: CPU 0: hi: 186, btch: 31 usd: 165
Jan 7 10:00:45 localhost kernel: CPU 1: hi: 186, btch: 31 usd: 61
Jan 7 10:00:45 localhost kernel: active_anon:48191 inactive_anon:1802 isolated_anon:0
Jan 7 10:00:45 localhost kernel: active_file:16287 inactive_file:29786 isolated_file:0
Jan 7 10:00:45 localhost kernel: unevictable:0 dirty:12 writeback:0 unstable:0
Jan 7 10:00:45 localhost kernel: free:7257 slab_reclaimable:12121 slab_unreclaimable:386040
Jan 7 10:00:45 localhost kernel: mapped:9692 shmem:1985 pagetables:1131 bounce:0
Jan 7 10:00:45 localhost kernel: DMA free:4288kB min:40kB low:48kB high:60kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15804kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB
slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Jan 7 10:00:45 localhost kernel: lowmem_reserve[]: 0 2007 2007 2007
Jan 7 10:00:45 localhost kernel: Normal free:24740kB min:5712kB low:7140kB high:8568kB active_anon:192764kB inactive_anon:7208kB active_file:65148kB
inactive_file:119144kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2056128kB mlocked:0kB dirty:48kB writeback:0kB mapped:38768kB shmem:7940kB
slab_reclaimable:48484kB slab_unreclaimable:1544160kB kernel_stack:6736kB pagetables:4524kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 7 10:00:45 localhost kernel: lowmem_reserve[]: 0 0 0 0
Jan 7 10:00:45 localhost kernel: DMA: 0*4kB 2*8kB 1*16kB 1*32kB 2*64kB 2*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 4288kB
Jan 7 10:00:45 localhost kernel: Normal: 3067*4kB 1491*8kB 26*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 24740kB
Jan 7 10:00:45 localhost kernel: 48061 total pagecache pages
Jan 7 10:00:45 localhost kernel: 0 pages in swap cache
Jan 7 10:00:45 localhost kernel: Swap cache stats: add 0, delete 0, find 0/0
Jan 7 10:00:45 localhost kernel: Free swap = 0kB
Jan 7 10:00:45 localhost kernel: Total swap = 0kB
Jan 7 10:00:45 localhost kernel: 522160 pages RAM
Jan 7 10:00:45 localhost kernel: 0 pages HighMem
Jan 7 10:00:45 localhost kernel: 12174 pages reserved
Jan 7 10:00:45 localhost kernel: 78943 pages shared
Jan 7 10:00:45 localhost kernel: 469325 pages non-shared
Thanks,
Ben
>
> johannes
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: hostapd hangs on quit, multi-BSSID scenario
From: Ben Greear @ 2011-01-07 18:07 UTC (permalink / raw)
To: Chaoxing Lin; +Cc: 'linux-wireless@vger.kernel.org'
In-Reply-To: <BD54DDEB2546894FAB0731EA7B0EDF8D05715D9E@RockMX01.rock.corp>
On 01/07/2011 09:58 AM, Chaoxing Lin wrote:
> 1. I don't know how to use GDB. Consider me entry level developer.
You need to learn how to use gdb..it will be well worth your time
if you plan to ever move beyond entry-level-developer.
Something as simple as:
gdb [hostapd-binary] [pid-of-hostapd-process]
Then inside of gdb:
bt
You might also try 'strace'.
> 2. It should not be related the change I made on ath9k. The reasons are
> a. My change is simple, linux/drivers/net/wireless/ath/ath9k/ath9k.h: change ATH_BCBUF from 4 to 12
> b. Without my change, driver accepts up to 3 extra BSSID. But hostapd still hangs on quit. Hostapd quits well if there only one extra BSSID.
>
> This problem is 100% reproducible. I guess it would be quite easy for the original hostapd developer to fix it.
Heh, maybe so..but if you want it fixed fast, you might need to put in some
extra debugging effort.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Odd behavior of ssb, b43, b43legacy, and b44
From: Larry Finger @ 2011-01-07 18:03 UTC (permalink / raw)
To: Michael Büsch; +Cc: b43-dev, wireless
In-Reply-To: <1294411555.18385.1.camel@maggie>
On 01/07/2011 08:45 AM, Michael Büsch wrote:
> On Thu, 2011-01-06 at 22:31 -0600, Larry Finger wrote:
>> On 01/06/2011 09:34 PM, Michael Büsch wrote:
>>>
>>> Does one of these wireless cards have a dangling ethernet core? I would
>>> not be surprised...
>>
>> Yes. The core scan for the BCM4303 is as follows:
>>
>> ssb: Core 0 found: IEEE 802.11 (cc 0x812, rev 0x02, vendor 0x4243)
>> ssb: Core 1 found: PCMCIA (cc 0x80D, rev 0x00, vendor 0x4243)
>> ssb: Core 2 found: Fast Ethernet (cc 0x806, rev 0x02, vendor 0x4243)
>> ssb: Core 3 found: V90 (cc 0x807, rev 0x01, vendor 0x4243)
>> ssb: Core 4 found: PCI (cc 0x804, rev 0x03, vendor 0x4243)
>> ssb: Sonics Silicon Backplane found on PCI device 0000:01:09.0
>>
>> Larry
>>
>
> Can you please try this patch?
>
>
> Index: linux-2.6.37/drivers/ssb/scan.c
> ===================================================================
> --- linux-2.6.37.orig/drivers/ssb/scan.c 2011-01-07 15:35:10.518000002 +0100
> +++ linux-2.6.37/drivers/ssb/scan.c 2011-01-07 15:45:54.231998930 +0100
> @@ -420,6 +420,16 @@
> bus->pcicore.dev = dev;
> #endif /* CONFIG_SSB_DRIVER_PCICORE */
> break;
> + case SSB_DEV_ETHERNET:
> + if (bus->bustype == SSB_BUSTYPE_PCI) {
> + if (bus->host_pci->vendor == PCI_VENDOR_ID_BROADCOM &&
> + (bus->host_pci->device & 0xFF00) == 0x4300) {
> + /* This is a dangling ethernet core on a
> + * wireless device. Ignore it. */
> + continue;
> + }
> + }
> + break;
> default:
> break;
> }
>
>
That patch fixes the problem. Thanks.
Larry
^ permalink raw reply
* [PATCH 2/2] ath9k: Fix incorrect tx-hang detection logic.
From: greearb @ 2011-01-07 18:00 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, Ben Greear
In-Reply-To: <1294423259-8163-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
It is not guaranteed that the ath_tx_complete_poll_work runs
after some fixed duration because the channel-reset logic
removes the work and then re-adds it to run immediately.
Two channel-changes 1ms apart, with a transmit was being
attempted, could thus incorrectly trigger a reset by
the ath_tx_complete_poll_work method.
Add a jiffies timestamp to ensure that at least 1 second
has elapsed before triggering the reset.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 3f5c513... 93209d6... M drivers/net/wireless/ath/ath9k/ath9k.h
:100644 100644 3aae523... e63de71... M drivers/net/wireless/ath/ath9k/xmit.c
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/xmit.c | 15 ++++++++++-----
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 3f5c513..93209d6 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -190,6 +190,7 @@ struct ath_txq {
spinlock_t axq_lock;
u32 axq_depth;
u32 axq_ampdu_depth;
+ unsigned long start_tx_timer; /* jiffies */
bool stopped;
bool axq_tx_inprogress;
struct list_head axq_acq;
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 3aae523..e63de71 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2097,6 +2097,7 @@ static void ath_tx_complete_poll_work(struct work_struct *work)
struct ath_txq *txq;
int i;
bool needreset = false;
+ unsigned long timeout = msecs_to_jiffies(ATH_TX_COMPLETE_POLL_INT);
for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++)
if (ATH_TXQ_SETUP(sc, i)) {
@@ -2104,11 +2105,16 @@ static void ath_tx_complete_poll_work(struct work_struct *work)
spin_lock_bh(&txq->axq_lock);
if (txq->axq_depth) {
if (txq->axq_tx_inprogress) {
- needreset = true;
- spin_unlock_bh(&txq->axq_lock);
- break;
+ if (time_after_eq(jiffies,
+ txq->start_tx_timer +
+ timeout)) {
+ needreset = true;
+ spin_unlock_bh(&txq->axq_lock);
+ break;
+ }
} else {
txq->axq_tx_inprogress = true;
+ txq->start_tx_timer = jiffies;
}
}
spin_unlock_bh(&txq->axq_lock);
@@ -2122,8 +2128,7 @@ static void ath_tx_complete_poll_work(struct work_struct *work)
ath9k_ps_restore(sc);
}
- ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work,
- msecs_to_jiffies(ATH_TX_COMPLETE_POLL_INT));
+ ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work, timeout);
}
--
1.7.2.3
^ permalink raw reply related
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