Re: [ath9k-devel] ath9k_htc test release: please test
Hi Vikranth, i was not able to reproduce your issue. For some time you have sended some kernel debug messages. Plase send kernel patch you used to get this result. Describe host configuration and kind of monitored traffik needed to reproduce it. Am 17.10.2013 15:31, schrieb vikranth reddy: Hi Oleksij, Adrian Thanks for Reply. We are using Sony-UWA BR100 Adapter with AR7010+AR9280 chipset. We are using compat-wireless-3.6.8 in x86 machine with Intel Core i5. In monitor mode, we see for some packets the TSF difference is negative for consecutive captured packets, which confuses our analysis software in application. Last year Nov, Adrian had given a test-release with a fix for this issue, I was wondering whether this fix is updated in latest ath9k_htc firmware or not. Thanks Vikranth On Wed, Oct 16, 2013 at 8:41 PM, Oleksij Rempel li...@rempel-privat.de mailto:li...@rempel-privat.de wrote: Hi Vikranth, i can't find detailed description of this problem. Can you please attach patches you use for debugging and information about your testing setup, hw, usb controller, etc. Please describe symptom of this problem, for example connection lost etc. Am 16.10.2013 12:19, schrieb vikranth reddy: Hi Adrian, List, We are still finding the same negative timestamp difference (between consecutive packets) issue with some of packets, with latest ath9_htc open-source firmware version. Adrian, Did you add this fix into open-source version of ath9k_htc firmware already? or still its not updated in it. Thanks Vikranth On Tue, Dec 4, 2012 at 11:36 AM, vikranth reddy vikranth.reddydevelo...@gmail.com mailto:vikranth.reddydevelo...@gmail.com mailto:vikranth.reddydevelo...@gmail.com mailto:vikranth.reddydevelo...@gmail.com wrote: Hi Adrian, Sorry for delayed reply! Here the debug-logs are added only for the cases where there is negative time-difference, not for success case. Logs below, that you pointed out, are not from consecutive packets. Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 All the guys here, who reported as successfully working, have tested with AR9271 not with AR7010+AR9280. Not sure if there is any difference between two firmwares (htc_7010.fw and htc_9271.fw). ? Like you mentioned we are measuring time-difference between two consecutive packets, irrespective of packet-type. That might have an issue still. Hope to see a fix for this issue in next official release Thanks for your support on this issue. Thanks Vikranth On Fri, Nov 30, 2012 at 11:13 PM, Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org mailto:adr...@freebsd.org mailto:adr...@freebsd.org wrote: As I said, the cozybit guys reported that the TSF increment is behaving correctly. Maybe it's only behaving correctly for beacons here, hm. Also, look: Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 Your now/prev values are all messed up, the second prev should been 64609, right? In any case, unless it's really obvious to fix, I'm just going to leave this as-is as it's the same behaviour as previous firmware. (Which is my aim here..) Adrian -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Hi Oleksij, Adrian Thanks for Reply. We are using Sony-UWA BR100 Adapter with AR7010+AR9280 chipset. We are using compat-wireless-3.6.8 in x86 machine with Intel Core i5. In monitor mode, we see for some packets the TSF difference is negative for consecutive captured packets, which confuses our analysis software in application. Last year Nov, Adrian had given a test-release with a fix for this issue, I was wondering whether this fix is updated in latest ath9k_htc firmware or not. Thanks Vikranth On Wed, Oct 16, 2013 at 8:41 PM, Oleksij Rempel li...@rempel-privat.dewrote: Hi Vikranth, i can't find detailed description of this problem. Can you please attach patches you use for debugging and information about your testing setup, hw, usb controller, etc. Please describe symptom of this problem, for example connection lost etc. Am 16.10.2013 12:19, schrieb vikranth reddy: Hi Adrian, List, We are still finding the same negative timestamp difference (between consecutive packets) issue with some of packets, with latest ath9_htc open-source firmware version. Adrian, Did you add this fix into open-source version of ath9k_htc firmware already? or still its not updated in it. Thanks Vikranth On Tue, Dec 4, 2012 at 11:36 AM, vikranth reddy vikranth.reddydevelo...@gmail.com mailto:vikranth.reddydevelo...@gmail.com wrote: Hi Adrian, Sorry for delayed reply! Here the debug-logs are added only for the cases where there is negative time-difference, not for success case. Logs below, that you pointed out, are not from consecutive packets. Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 All the guys here, who reported as successfully working, have tested with AR9271 not with AR7010+AR9280. Not sure if there is any difference between two firmwares (htc_7010.fw and htc_9271.fw). ? Like you mentioned we are measuring time-difference between two consecutive packets, irrespective of packet-type. That might have an issue still. Hope to see a fix for this issue in next official release Thanks for your support on this issue. Thanks Vikranth On Fri, Nov 30, 2012 at 11:13 PM, Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org wrote: As I said, the cozybit guys reported that the TSF increment is behaving correctly. Maybe it's only behaving correctly for beacons here, hm. Also, look: Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 Your now/prev values are all messed up, the second prev should been 64609, right? In any case, unless it's really obvious to fix, I'm just going to leave this as-is as it's the same behaviour as previous firmware. (Which is my aim here..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Hi Adrian, List, We are still finding the same negative timestamp difference (between consecutive packets) issue with some of packets, with latest ath9_htc open-source firmware version. Adrian, Did you add this fix into open-source version of ath9k_htc firmware already? or still its not updated in it. Thanks Vikranth On Tue, Dec 4, 2012 at 11:36 AM, vikranth reddy vikranth.reddydevelo...@gmail.com wrote: Hi Adrian, Sorry for delayed reply! Here the debug-logs are added only for the cases where there is negative time-difference, not for success case. Logs below, that you pointed out, are not from consecutive packets. Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 All the guys here, who reported as successfully working, have tested with AR9271 not with AR7010+AR9280. Not sure if there is any difference between two firmwares (htc_7010.fw and htc_9271.fw). ? Like you mentioned we are measuring time-difference between two consecutive packets, irrespective of packet-type. That might have an issue still. Hope to see a fix for this issue in next official release Thanks for your support on this issue. Thanks Vikranth On Fri, Nov 30, 2012 at 11:13 PM, Adrian Chadd adr...@freebsd.org wrote: As I said, the cozybit guys reported that the TSF increment is behaving correctly. Maybe it's only behaving correctly for beacons here, hm. Also, look: Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 Your now/prev values are all messed up, the second prev should been 64609, right? In any case, unless it's really obvious to fix, I'm just going to leave this as-is as it's the same behaviour as previous firmware. (Which is my aim here..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Hi Vikranth, i cant find detailed description of this problem. Can you please attach patches you use for debugging and information about your testing setup, hw, usb controller, etc. Please describe symptom of this problem, for example connection lost etc. Am 16.10.2013 12:19, schrieb vikranth reddy: Hi Adrian, List, We are still finding the same negative timestamp difference (between consecutive packets) issue with some of packets, with latest ath9_htc open-source firmware version. Adrian, Did you add this fix into open-source version of ath9k_htc firmware already? or still its not updated in it. Thanks Vikranth On Tue, Dec 4, 2012 at 11:36 AM, vikranth reddy vikranth.reddydevelo...@gmail.com mailto:vikranth.reddydevelo...@gmail.com wrote: Hi Adrian, Sorry for delayed reply! Here the debug-logs are added only for the cases where there is negative time-difference, not for success case. Logs below, that you pointed out, are not from consecutive packets. Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 All the guys here, who reported as successfully working, have tested with AR9271 not with AR7010+AR9280. Not sure if there is any difference between two firmwares (htc_7010.fw and htc_9271.fw). ? Like you mentioned we are measuring time-difference between two consecutive packets, irrespective of packet-type. That might have an issue still. Hope to see a fix for this issue in next official release Thanks for your support on this issue. Thanks Vikranth On Fri, Nov 30, 2012 at 11:13 PM, Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org wrote: As I said, the cozybit guys reported that the TSF increment is behaving correctly. Maybe its only behaving correctly for beacons here, hm. Also, look: Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 Your now/prev values are all messed up, the second prev should been 64609, right? In any case, unless its really obvious to fix, Im just going to leave this as-is as its the same behaviour as previous firmware. (Which is my aim here..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Hi, Is this for aggregate frames? If it is, I _think_ aggregate frames only have a valid timestamp in the _last_ subframe. -adrian On 16 October 2013 08:11, Oleksij Rempel li...@rempel-privat.de wrote: Hi Vikranth, i can't find detailed description of this problem. Can you please attach patches you use for debugging and information about your testing setup, hw, usb controller, etc. Please describe symptom of this problem, for example connection lost etc. Am 16.10.2013 12:19, schrieb vikranth reddy: Hi Adrian, List, We are still finding the same negative timestamp difference (between consecutive packets) issue with some of packets, with latest ath9_htc open-source firmware version. Adrian, Did you add this fix into open-source version of ath9k_htc firmware already? or still its not updated in it. Thanks Vikranth On Tue, Dec 4, 2012 at 11:36 AM, vikranth reddy vikranth.reddydevelo...@gmail.com mailto:vikranth.reddydevelo...@gmail.com wrote: Hi Adrian, Sorry for delayed reply! Here the debug-logs are added only for the cases where there is negative time-difference, not for success case. Logs below, that you pointed out, are not from consecutive packets. Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 All the guys here, who reported as successfully working, have tested with AR9271 not with AR7010+AR9280. Not sure if there is any difference between two firmwares (htc_7010.fw and htc_9271.fw). ? Like you mentioned we are measuring time-difference between two consecutive packets, irrespective of packet-type. That might have an issue still. Hope to see a fix for this issue in next official release Thanks for your support on this issue. Thanks Vikranth On Fri, Nov 30, 2012 at 11:13 PM, Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org wrote: As I said, the cozybit guys reported that the TSF increment is behaving correctly. Maybe it's only behaving correctly for beacons here, hm. Also, look: Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 Your now/prev values are all messed up, the second prev should been 64609, right? In any case, unless it's really obvious to fix, I'm just going to leave this as-is as it's the same behaviour as previous firmware. (Which is my aim here..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
On 1 December 2012 06:31, Christian Lamparter chunk...@googlemail.com wrote: Please let me know if it works or doesn't work for you. Thanks! It seems to work/hold. Thanks! Can you please bump the version old: [ 26.106713] ath9k_htc 1-10:1.0: ath9k_htc: FW Version: 1.3 new: [16308.270828] ath9k_htc 1-10:1.0: ath9k_htc: FW Version: 1.3 I'll bump the firmware version when it's time to do a release. I'll see how difficult it'll be to have a development/snapshot and a release version number scheme too. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Hi Adrian, Sorry for delayed reply! Here the debug-logs are added only for the cases where there is negative time-difference, not for success case. Logs below, that you pointed out, are not from consecutive packets. Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 All the guys here, who reported as successfully working, have tested with AR9271 not with AR7010+AR9280. Not sure if there is any difference between two firmwares (htc_7010.fw and htc_9271.fw). ? Like you mentioned we are measuring time-difference between two consecutive packets, irrespective of packet-type. That might have an issue still. Hope to see a fix for this issue in next official release Thanks for your support on this issue. Thanks Vikranth On Fri, Nov 30, 2012 at 11:13 PM, Adrian Chadd adr...@freebsd.org wrote: As I said, the cozybit guys reported that the TSF increment is behaving correctly. Maybe it's only behaving correctly for beacons here, hm. Also, look: Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 Your now/prev values are all messed up, the second prev should been 64609, right? In any case, unless it's really obvious to fix, I'm just going to leave this as-is as it's the same behaviour as previous firmware. (Which is my aim here..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
On Thursday 29 November 2012 00:50:59 Adrian Chadd wrote: Hi all, I've done an updated build of the ath9k_htc firmware images. I don't currently have a HTC setup working so this is just a recompilation of the current firmware. http://dev.qca.qualcomm.com/~adrian/htc/20121128/ Please let me know if it works or doesn't work for you. Thanks! It seems to work/hold. Can you please bump the version old: [ 26.106713] ath9k_htc 1-10:1.0: ath9k_htc: FW Version: 1.3 new: [16308.270828] ath9k_htc 1-10:1.0: ath9k_htc: FW Version: 1.3 The specific two changes from Sujith's last release: * Update the embedded runtime OS code to the latest from Tensilica, in preparation for open sourcing it; Hey, I like to hear more about that. :) Regards, Chr ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
.. be64_to_cpu() ? That field is not already converted for you?
Adrian
On 29 November 2012 20:46, vikranth reddy
vikranth.reddydevelo...@gmail.com wrote:
Hi,
I have tested it using Sony BR-100 (AR7010 + AR9280). PFA the time diff logs
for the new firmware.(htc_7010.fw)
I added prints for time diff in
file:- ~/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
function:- ath9k_rx_tasklet
position:- just before ieee80211_rx function.
Code Snippet:
void ath9k_rx_tasklet(unsigned long data)
{
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *)data;
struct ath9k_htc_rxbuf *rxbuf = NULL, *tmp_buf = NULL;
struct ieee80211_rx_status rx_status;
struct sk_buff *skb;
unsigned long flags;
struct ieee80211_hdr *hdr;
/* Added to measure Time-Difference between successive WiFi Packets */
static u64 prev1,now1;
long long diff1 = 0;
static u32 counter1 = 0;
//
do {
spin_lock_irqsave(priv-rx.rxbuflock, flags);
list_for_each_entry(tmp_buf, priv-rx.rxbuf, list) {
if (tmp_buf-in_process) {
rxbuf = tmp_buf;
break;
}
}
if (rxbuf == NULL) {
spin_unlock_irqrestore(priv-rx.rxbuflock, flags);
break;
}
if (!rxbuf-skb)
goto requeue;
if (!ath9k_rx_prepare(priv, rxbuf, rx_status)) {
dev_kfree_skb_any(rxbuf-skb);
goto requeue;
}
memcpy(IEEE80211_SKB_RXCB(rxbuf-skb), rx_status,
sizeof(struct ieee80211_rx_status));
skb = rxbuf-skb;
hdr = (struct ieee80211_hdr *) skb-data;
if (ieee80211_is_beacon(hdr-frame_control) priv-ps_enabled)
ieee80211_queue_work(priv-hw, priv-ps_work);
spin_unlock_irqrestore(priv-rx.rxbuflock, flags);
/* Added to measure Time-Difference between successive WiFi Packets */
now1 = be64_to_cpu(rxbuf-rxstatus.rs_tstamp);
diff1 = now1 - prev1;
if(diff1 0) {
printk(###now = %llu prev = %llu diff = %lld counter =
%u\n,now1,prev1,diff1,counter1++);
}
prev1 = now1;
/**/
ieee80211_rx(priv-hw, skb);
spin_lock_irqsave(priv-rx.rxbuflock, flags);
...
...
}
Nov 29 10 36 29 [ 103.724123] ###now = 2683579500078 prev =
2684354679445 diff = -775179367
Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314
diff = -2683598376705
Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev =
2684354687871 diff = -755938925
Nov 29 10 36 50 [ 123.766144] ###now = 2683599568206 prev =
2684354697547 diff = -755129341
Nov 29 10 36 50 [ 124.072922] ###now = 2683599875386 prev =
2684354601000 diff = -754725614
Nov 29 10 36 50 [ 124.481997] ###now = 2683600284967 prev =
2684354598998 diff = -754314031
Nov 29 10 36 51 [ 124.890184] ###now = 2683600693668 prev =
2684354605871 diff = -753912203
Nov 29 10 36 51 [ 125.298751] ###now = 51576 prev = 2683601031091
diff = -2683600979515
Still I see the negative time-differences between successive WiFi-packets,
when it is stayed connected to single AP. In the log, now is the TSF of
current packet and prev is previous WiFi Packet's timestamp. All the
variables are 64-bit.
But the difference between new firmware and old-firmware is, I see less
number of negative differences comparatively.
Thanks
Vikranth
On Thu, Nov 29, 2012 at 5:20 AM, Adrian Chadd adr...@freebsd.org wrote:
Hi all,
I've done an updated build of the ath9k_htc firmware images. I don't
currently have a HTC setup working so this is just a recompilation of
the current firmware.
http://dev.qca.qualcomm.com/~adrian/htc/20121128/
Please let me know if it works or doesn't work for you.
The specific two changes from Sujith's last release:
* Fix the TSF extension logic to correctly extend TSF from 32 bit to 64
bit;
* Update the embedded runtime OS code to the latest from Tensilica, in
preparation for open sourcing it;
I don't plan on fixing any bugs that already exist in the latest
ath9k_htc drop in the firmware git repository; I just want to check
that the build hasn't broken any existing behaviour (ie, made things
worse.)
Thanks,
Adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Hi Adrian,
No its not already converted.
See the below code-snippet in ath9k_rx_prepare
rx_status-mactime = be64_to_cpu(rxbuf-rxstatus.rs_tstamp);
rx_status-band = hw-conf.channel-band;
rx_status-freq = hw-conf.channel-center_freq;
rx_status-signal = rxbuf-rxstatus.rs_rssi + ATH_DEFAULT_NOISE_FLOOR;
rx_status-antenna = rxbuf-rxstatus.rs_antenna;
rx_status-flag |= RX_FLAG_MACTIME_MPDU;
Which calculates the mactime, using be64_to_cpu.
Thanks
Vikranth
On Fri, Nov 30, 2012 at 2:29 PM, Adrian Chadd adr...@freebsd.org wrote:
.. be64_to_cpu() ? That field is not already converted for you?
Adrian
On 29 November 2012 20:46, vikranth reddy
vikranth.reddydevelo...@gmail.com wrote:
Hi,
I have tested it using Sony BR-100 (AR7010 + AR9280). PFA the time diff
logs
for the new firmware.(htc_7010.fw)
I added prints for time diff in
file:- ~/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
function:- ath9k_rx_tasklet
position:- just before ieee80211_rx function.
Code Snippet:
void ath9k_rx_tasklet(unsigned long data)
{
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *)data;
struct ath9k_htc_rxbuf *rxbuf = NULL, *tmp_buf = NULL;
struct ieee80211_rx_status rx_status;
struct sk_buff *skb;
unsigned long flags;
struct ieee80211_hdr *hdr;
/* Added to measure Time-Difference between successive WiFi Packets */
static u64 prev1,now1;
long long diff1 = 0;
static u32 counter1 = 0;
//
do {
spin_lock_irqsave(priv-rx.rxbuflock, flags);
list_for_each_entry(tmp_buf, priv-rx.rxbuf, list) {
if (tmp_buf-in_process) {
rxbuf = tmp_buf;
break;
}
}
if (rxbuf == NULL) {
spin_unlock_irqrestore(priv-rx.rxbuflock, flags);
break;
}
if (!rxbuf-skb)
goto requeue;
if (!ath9k_rx_prepare(priv, rxbuf, rx_status)) {
dev_kfree_skb_any(rxbuf-skb);
goto requeue;
}
memcpy(IEEE80211_SKB_RXCB(rxbuf-skb), rx_status,
sizeof(struct ieee80211_rx_status));
skb = rxbuf-skb;
hdr = (struct ieee80211_hdr *) skb-data;
if (ieee80211_is_beacon(hdr-frame_control) priv-ps_enabled)
ieee80211_queue_work(priv-hw, priv-ps_work);
spin_unlock_irqrestore(priv-rx.rxbuflock, flags);
/* Added to measure Time-Difference between successive WiFi Packets */
now1 = be64_to_cpu(rxbuf-rxstatus.rs_tstamp);
diff1 = now1 - prev1;
if(diff1 0) {
printk(###now = %llu prev = %llu diff = %lld counter =
%u\n,now1,prev1,diff1,counter1++);
}
prev1 = now1;
/**/
ieee80211_rx(priv-hw, skb);
spin_lock_irqsave(priv-rx.rxbuflock, flags);
...
...
}
Nov 29 10 36 29 [ 103.724123] ###now = 2683579500078 prev =
2684354679445 diff = -775179367
Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314
diff = -2683598376705
Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev =
2684354687871 diff = -755938925
Nov 29 10 36 50 [ 123.766144] ###now = 2683599568206 prev =
2684354697547 diff = -755129341
Nov 29 10 36 50 [ 124.072922] ###now = 2683599875386 prev =
2684354601000 diff = -754725614
Nov 29 10 36 50 [ 124.481997] ###now = 2683600284967 prev =
2684354598998 diff = -754314031
Nov 29 10 36 51 [ 124.890184] ###now = 2683600693668 prev =
2684354605871 diff = -753912203
Nov 29 10 36 51 [ 125.298751] ###now = 51576 prev = 2683601031091
diff = -2683600979515
Still I see the negative time-differences between successive
WiFi-packets,
when it is stayed connected to single AP. In the log, now is the TSF of
current packet and prev is previous WiFi Packet's timestamp. All the
variables are 64-bit.
But the difference between new firmware and old-firmware is, I see less
number of negative differences comparatively.
Thanks
Vikranth
On Thu, Nov 29, 2012 at 5:20 AM, Adrian Chadd adr...@freebsd.org
wrote:
Hi all,
I've done an updated build of the ath9k_htc firmware images. I don't
currently have a HTC setup working so this is just a recompilation of
the current firmware.
http://dev.qca.qualcomm.com/~adrian/htc/20121128/
Please let me know if it works or doesn't work for you.
The specific two changes from Sujith's last release:
* Fix the TSF extension logic to correctly extend TSF from 32 bit to 64
bit;
* Update the embedded runtime OS code to the latest from Tensilica, in
preparation for open sourcing it;
I don't plan on fixing any bugs that already exist in the latest
ath9k_htc drop in the firmware git repository; I just want to check
that the build hasn't broken any existing behaviour (ie, made things
worse.)
Thanks,
Adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
As I said, the cozybit guys reported that the TSF increment is behaving correctly. Maybe it's only behaving correctly for beacons here, hm. Also, look: Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 Your now/prev values are all messed up, the second prev should been 64609, right? In any case, unless it's really obvious to fix, I'm just going to leave this as-is as it's the same behaviour as previous firmware. (Which is my aim here..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Am 29.11.2012 00:50, schrieb Adrian Chadd: Hi all, I've done an updated build of the ath9k_htc firmware images. I don't currently have a HTC setup working so this is just a recompilation of the current firmware. http://dev.qca.qualcomm.com/~adrian/htc/20121128/ Please let me know if it works or doesn't work for you. The specific two changes from Sujith's last release: * Fix the TSF extension logic to correctly extend TSF from 32 bit to 64 bit; * Update the embedded runtime OS code to the latest from Tensilica, in preparation for open sourcing it; I don't plan on fixing any bugs that already exist in the latest ath9k_htc drop in the firmware git repository; I just want to check that the build hasn't broken any existing behaviour (ie, made things worse.) Thanks, Works without regressions on ALFA AWUS036NHA (Atheros AR9271 Rev:1) -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Hi On Thursday 29 November 2012, Adrian Chadd wrote: Hi all, I've done an updated build of the ath9k_htc firmware images. I don't currently have a HTC setup working so this is just a recompilation of the current firmware. http://dev.qca.qualcomm.com/~adrian/htc/20121128/ Please let me know if it works or doesn't work for you. […] Seems to work for me with ar9271/ TP-Link TL-WN721N, I don't notice anything strange so far. Feel free to ask me for any specific tests. Bus 001 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n 61a01f78317eff6675f59f6a111846dd */lib/firmware/htc_9271.fw [ 68.843124] usb 1-2: new high-speed USB device number 3 using ehci_hcd [ 68.977959] usb 1-2: New USB device found, idVendor=0cf3, idProduct=9271 [ 68.977977] usb 1-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48 [ 68.977989] usb 1-2: Product: USB2.0 WLAN [ 68.978000] usb 1-2: Manufacturer: ATHEROS [ 68.978070] usb 1-2: SerialNumber: 12345 [ 69.013788] usb 1-2: ath9k_htc: Firmware htc_9271.fw requested [ 69.013873] usbcore: registered new interface driver ath9k_htc [ 69.308128] usb 1-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 [ 69.543716] ath9k_htc 1-2:1.0: ath9k_htc: HTC initialized with 33 credits [ 69.753110] ath9k_htc 1-2:1.0: ath9k_htc: FW Version: 1.3 [ 69.753123] ath: EEPROM regdomain: 0x809c [ 69.753130] ath: EEPROM indicates we should expect a country code [ 69.753138] ath: doing EEPROM country-regdmn map search [ 69.753145] ath: country maps to regdmn code: 0x52 [ 69.753153] ath: Country alpha2 being used: CN [ 69.753160] ath: Regpair used: 0x52 [ 69.755825] ieee80211 phy1: Atheros AR9271 Rev:1 [ 69.756598] cfg80211: Calling CRDA for country: CN [ 69.762598] Registered led device: ath9k_htc-phy1 [ 69.784992] cfg80211: Current regulatory domain intersected: [ 69.785376] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 69.785387] cfg80211: (2402000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm) [ 72.936100] cfg80211: Calling CRDA to update world regulatory domain [ 72.956353] cfg80211: World regulatory domain updated: [ 72.956361] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 72.956368] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 72.956373] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [ 72.956378] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [ 72.956383] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 72.956389] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 73.708543] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready [ 74.906125] wlan1: authenticate with MAC redacted [ 75.000387] wlan1: send auth to MAC redacted (try 1/3) [ 75.002913] wlan1: authenticated [ 75.052045] wlan1: associate with MAC redacted (try 1/3) [ 75.055530] wlan1: RX AssocResp from MAC redacted (capab=0x411 status=0 aid=1) [ 75.059506] wlan1: associated [ 75.059586] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready [ 75.059739] cfg80211: Calling CRDA for country: DE [ 75.077662] ath: regdomain 0x8114 updated by CountryIE [ 75.077673] ath: EEPROM regdomain: 0x8114 [ 75.077678] ath: EEPROM indicates we should expect a country code [ 75.077683] ath: doing EEPROM country-regdmn map search [ 75.077688] ath: country maps to regdmn code: 0x37 [ 75.077693] ath: Country alpha2 being used: DE [ 75.077698] ath: Regpair used: 0x37 [ 75.077704] cfg80211: Regulatory domain changed to country: DE [ 75.077710] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 75.077718] cfg80211: (240 KHz - 2483500 KHz @ 4 KHz), (N/A, 2000 mBm) [ 75.077726] cfg80211: (515 KHz - 525 KHz @ 4 KHz), (N/A, 2000 mBm) [ 75.077732] cfg80211: (525 KHz - 535 KHz @ 4 KHz), (N/A, 2000 mBm) [ 75.077739] cfg80211: (547 KHz - 5725000 KHz @ 4 KHz), (N/A, 2698 mBm) The access point is a TP-Link TL-WDR4300 (AR9344+AR9340) running a recent OpenWrt build/ ath9k. By the way, do you happen to know an ar7010+ar9280 dualband/ 2-stream device that's a little easier to get hold of than the Netgear WNDA3200 (UK-only) or the Sony UWA-BR100? Regards Stefan Lippers-Hollmann ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Hi,
I have tested it using Sony BR-100 (AR7010 + AR9280). PFA the time diff
logs for the new firmware.(htc_7010.fw)
I added prints for time diff in
file:- ~/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
function:- ath9k_rx_tasklet
position:- just before ieee80211_rx function.
*Code Snippet:*
void ath9k_rx_tasklet(unsigned long data)
{
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *)data;
struct ath9k_htc_rxbuf *rxbuf = NULL, *tmp_buf = NULL;
struct ieee80211_rx_status rx_status;
struct sk_buff *skb;
unsigned long flags;
struct ieee80211_hdr *hdr;
/* Added to measure Time-Difference between successive WiFi Packets */
static u64 prev1,now1;
long long diff1 = 0;
static u32 counter1 = 0;
//
do {
spin_lock_irqsave(priv-rx.rxbuflock, flags);
list_for_each_entry(tmp_buf, priv-rx.rxbuf, list) {
if (tmp_buf-in_process) {
rxbuf = tmp_buf;
break;
}
}
if (rxbuf == NULL) {
spin_unlock_irqrestore(priv-rx.rxbuflock, flags);
break;
}
if (!rxbuf-skb)
goto requeue;
if (!ath9k_rx_prepare(priv, rxbuf, rx_status)) {
dev_kfree_skb_any(rxbuf-skb);
goto requeue;
}
memcpy(IEEE80211_SKB_RXCB(rxbuf-skb), rx_status,
sizeof(struct ieee80211_rx_status));
skb = rxbuf-skb;
hdr = (struct ieee80211_hdr *) skb-data;
if (ieee80211_is_beacon(hdr-frame_control) priv-ps_enabled)
ieee80211_queue_work(priv-hw, priv-ps_work);
spin_unlock_irqrestore(priv-rx.rxbuflock, flags);
/* Added to measure Time-Difference between successive WiFi Packets */
now1 = be64_to_cpu(rxbuf-rxstatus.rs_tstamp);
diff1 = now1 - prev1;
if(diff1 0) {
printk(###now = %llu prev = %llu diff = %lld counter =
%u\n,now1,prev1,diff1,counter1++);
}
prev1 = now1;
/**/
ieee80211_rx(priv-hw, skb);
spin_lock_irqsave(priv-rx.rxbuflock, flags);
...
...
}
Nov 29 10 36 29 [ 103.724123] ###now = 2683579500078 prev =
2684354679445 diff = -775179367
Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314
diff = -2683598376705
Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev =
2684354687871 diff = -755938925
Nov 29 10 36 50 [ 123.766144] ###now = 2683599568206 prev =
2684354697547 diff = -755129341
Nov 29 10 36 50 [ 124.072922] ###now = 2683599875386 prev =
2684354601000 diff = -754725614
Nov 29 10 36 50 [ 124.481997] ###now = 2683600284967 prev =
2684354598998 diff = -754314031
Nov 29 10 36 51 [ 124.890184] ###now = 2683600693668 prev =
2684354605871 diff = -753912203
Nov 29 10 36 51 [ 125.298751] ###now = 51576 prev = 2683601031091
diff = -2683600979515
Still I see the negative time-differences between successive WiFi-packets,
when it is stayed connected to single AP. In the log, *now *is the TSF of
current packet and *prev *is previous WiFi Packet's timestamp. All the
variables are 64-bit.
But the difference between new firmware and old-firmware is, I see less
number of negative differences comparatively.
Thanks
Vikranth
On Thu, Nov 29, 2012 at 5:20 AM, Adrian Chadd adr...@freebsd.org wrote:
Hi all,
I've done an updated build of the ath9k_htc firmware images. I don't
currently have a HTC setup working so this is just a recompilation of
the current firmware.
http://dev.qca.qualcomm.com/~adrian/htc/20121128/
Please let me know if it works or doesn't work for you.
The specific two changes from Sujith's last release:
* Fix the TSF extension logic to correctly extend TSF from 32 bit to 64
bit;
* Update the embedded runtime OS code to the latest from Tensilica, in
preparation for open sourcing it;
I don't plan on fixing any bugs that already exist in the latest
ath9k_htc drop in the firmware git repository; I just want to check
that the build hasn't broken any existing behaviour (ie, made things
worse.)
Thanks,
Adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Nov 29 10 36 29 [ 103.724123] ###now = 2683579500078 prev =
2684354679445 diff = -775179367
Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev =
2683598441314 diff = -2683598376705
Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev =
2684354687871 diff = -755938925
Nov 29 10 36 50 [ 123.766144] ###now = 2683599568206 prev =
2684354697547 diff = -755129341
Nov 29 10 36 50 [ 124.072922] ###now = 2683599875386 prev =
2684354601000 diff = -754725614
Nov 29 10 36 50 [ 124.481997] ###now = 2683600284967 prev =
2684354598998 diff = -754314031
Nov 29 10 36 51 [ 124.890184] ###now = 2683600693668 prev =
2684354605871 diff = -753912203
Nov 29 10 36 51 [ 125.298751] ###now = 51576 prev =
2683601031091 diff = -2683600979515
Nov 29 10 36 51 [ 125.402879] ###now =
[ath9k-devel] ath9k_htc test release: please test
Hi all, I've done an updated build of the ath9k_htc firmware images. I don't currently have a HTC setup working so this is just a recompilation of the current firmware. http://dev.qca.qualcomm.com/~adrian/htc/20121128/ Please let me know if it works or doesn't work for you. The specific two changes from Sujith's last release: * Fix the TSF extension logic to correctly extend TSF from 32 bit to 64 bit; * Update the embedded runtime OS code to the latest from Tensilica, in preparation for open sourcing it; I don't plan on fixing any bugs that already exist in the latest ath9k_htc drop in the firmware git repository; I just want to check that the build hasn't broken any existing behaviour (ie, made things worse.) Thanks, Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
