From owner-freebsd-wireless@FreeBSD.ORG Sun Feb 15 19:02:43 2015 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B528A354 for ; Sun, 15 Feb 2015 19:02:43 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E5F4A97 for ; Sun, 15 Feb 2015 19:02:43 +0000 (UTC) Received: by iecrp18 with SMTP id rp18so14455499iec.9 for ; Sun, 15 Feb 2015 11:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oDQQTSdpVQaq8tI48aXI/PKPTbM1AMG6ns7KgLI5Sfk=; b=jgGX2QufPagAeXpttic5Dv2usPHv8H4INn8KtH9UBRy43BF1fmTr+WlWJvfMg7+we4 MoXE2s91qujGpym+1X1DGil+frvTspr5E0Mkuw7aR7bthsEEIv1ooYqUJvZhsqCDwQt4 8ts88MwyJHtvJgBZ0NzT1aNXp2UuZlZWH2m4YLVIRJhppg7LWSd7+Xxjx8M7B9YUt/Uy 7bdGP0G2fAExaKTvfu0jJFfg1NMuG6S2n7ze3w8mawq1COIXUicnIU8NX7qoqhqcPTPf s9qGP8/JDgDFuUSiCxWU5P7zS/zphcCikbJhhEQnEUQCqtZODstKsPIn2BXimrG6Q2yE UHGQ== MIME-Version: 1.0 X-Received: by 10.107.31.16 with SMTP id f16mr24935217iof.88.1424026956822; Sun, 15 Feb 2015 11:02:36 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.66 with HTTP; Sun, 15 Feb 2015 11:02:36 -0800 (PST) In-Reply-To: References: Date: Sun, 15 Feb 2015 11:02:36 -0800 X-Google-Sender-Auth: FqhHUhMBW9cRRRlnNZagGVfzzfo Message-ID: Subject: Re: ath0 performence issues "ar9300_Stub_GetCTSTimeout" "ar9300_Stub_GetCTSTimeout From: Adrian Chadd To: Miguel Clara Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 19:02:43 -0000 ifconfig -v wlan0 ; if you see powersave CAM rather than powersave NONE, then it's trying to do powersave. -a On 15 February 2015 at 11:00, Miguel Clara wrote: > > On Sun, Feb 15, 2015 at 6:49 PM, Adrian Chadd wrote: >> >> On 15 February 2015 at 10:47, Miguel Clara wrote: >> > >> > On Sat, Feb 14, 2015 at 2:40 AM, Miguel Clara >> > wrote: >> >> >> >> >> >> On Sat, Jan 31, 2015 at 7:00 PM, Adrian Chadd >> >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> please try updating to -HEAD. It's possible that'll fix things. >> >> >> >> >> >> Hi, >> >> >> >> I've update to head and still see the messages in dmesg. >> >> >> >> And the same slowness... rebooting seems to fix the issue, but it was >> >> the >> >> same in 10 and randomly (surely there's a reason only I'm not noticing >> >> what) >> >> it goes back to this state. >> >> >> >> Is there any debugging I can try to figure whats going on when this >> >> happens? >> > >> > >> > Also just now I lost network and saw this in dmesg: >> > ath0: ath_intr: TSFOOR >> > ath0: ath_intr: TSFOOR >> > ath0: ath_intr: TSFOOR >> > ath0: ath_intr: TSFOOR >> > ath0: ath_intr: TSFOOR >> > ath0: ath_intr: TSFOOR >> > ath0: ath_intr: TSFOOR >> > ath0: ath_intr: TSFOOR >> > ath0: ath_intr: TSFOOR >> > >> > >> > It was just during a few seconds. >> >> Ok, so that happens because you haven't heard a beacon for a while, >> and the "TSF out of range" interrupt has fired. >> >> Try creating the VAP again, but this time do it with -bgscan -powersave . >> >> > I just did that manually and added "-bgscan -powersave" to rc.conf. > > Is there a way I can verify those changes were applied? > > ifconfig wlan0 doesn't show anything related. > >> >> -adrian >> >> >> >> >>> >> >>> On 31 January 2015 at 09:19, Miguel Clara >> >>> wrote: >> >>> > I've just upgrade to the latest 10/stable. >> >>> > >> >>> > trying to git clone a repo was giving me horrible speed, and I >> >>> > honestly >> >>> > tough it was at their side, until I noticed issues while browsing >> >>> > and >> >>> > this >> >>> > in dmesg: >> >>> > >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetCTSTimeout: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > ar9300_Stub_GetAntennaSwitch: called >> >>> > >> >>> > Speedtest either gives me and ok result or very poor, and pings also >> >>> > prove >> >>> > that something is not quite right: >> >>> > 64 bytes from 216.58.210.110: icmp_seq=7 ttl=59 time=18.096 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=8 ttl=59 time=149.083 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=9 ttl=59 time=18.376 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=10 ttl=59 time=19.084 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=11 ttl=59 time=18.305 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=12 ttl=59 time=18.140 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=13 ttl=59 time=16.700 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=14 ttl=59 time=105.554 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=15 ttl=59 time=34.336 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=16 ttl=59 time=76.410 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=17 ttl=59 time=34.400 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=18 ttl=59 time=73.521 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=19 ttl=59 time=154.728 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=20 ttl=59 time=126.120 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=21 ttl=59 time=170.920 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=22 ttl=59 time=137.330 ms >> >>> > 64 bytes from 216.58.210.110: icmp_seq=23 ttl=59 time=17.424 ms >> >>> > >> >>> > (tried other host with similar results) >> >>> > >> >>> > It seems to settle for a while but randomly comes back.. >> >>> > >> >>> > uname -a >> >>> > FreeBSD r2d2 10.1-STABLE FreeBSD 10.1-STABLE #7 r277979M: Sat Jan 31 >> >>> > 16:05:30 WET 2015 root@r2d2:/usr/obj/usr/src/sys/GENERIC amd64 >> >>> > _______________________________________________ >> >>> > freebsd-wireless@freebsd.org mailing list >> >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> >>> > To unsubscribe, send any mail to >> >>> > "freebsd-wireless-unsubscribe@freebsd.org" >> >> >> >> >> > > >