From owner-freebsd-mobile@FreeBSD.ORG Mon Feb 9 10:45:19 2009 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2581B106564A for ; Mon, 9 Feb 2009 10:45:19 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id BD8418FC19 for ; Mon, 9 Feb 2009 10:45:18 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.3/8.14.3) with ESMTP id n19ADjPa009710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Feb 2009 11:13:45 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.3/8.14.3) with ESMTP id n19AGUbg001405; Mon, 9 Feb 2009 11:16:30 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.3/8.14.3/Submit) id n19AGUX3001404; Mon, 9 Feb 2009 11:16:30 +0100 (CET) (envelope-from bengta@P142.sics.se) To: freebsd-mobile@freebsd.org From: Bengt Ahlgren User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (berkeley-unix) Date: Mon, 09 Feb 2009 11:16:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Problems with ath at kern.hz=100 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 10:45:19 -0000 Hello! I was changing kern.hz to 100 on my IBM X40 (Pentium-M) laptop to see whether that saves some battery, but ran into problems with ath not working properly. At first I thought that my hardware was failing, but changing hz back to 1000 solved the problem. I am running 7.1-RELEASE-p1 and have the following Atheros chip: Feb 9 11:13:10 P142 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Feb 9 11:13:10 P142 kernel: ath0: mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2 Feb 9 11:13:10 P142 kernel: ath0: [ITHREAD] Feb 9 11:13:10 P142 kernel: ath0: WARNING: using obsoleted if_watchdog interface Feb 9 11:13:10 P142 kernel: ath0: Ethernet address: 00:05:4e:4e:1f:c7 Feb 9 11:13:10 P142 kernel: ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 The symptom is that ath stops sending packets out. They seem to be buffered somewhere. After a while it gets going again, albeit some packets are lost. "A while" can be from 5 secs to a minute or so when continously running a ping. In the below logs, a ping is started when ath has stopped sending. "netstat -I ath0 1" reports that no packets are sent, but the byte count is still incremented. When it gets going again, 18 packets are sent, but the byte count does not reflect that (which perpaps is logical): 1 0 56 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 98 0 1 0 56 0 0 98 0 1 0 56 0 0 98 0 input (ath0) output packets errs bytes packets errs bytes colls 0 0 0 0 0 98 0 1 0 56 0 0 98 0 1 0 56 0 0 98 0 1 0 56 0 0 98 0 0 0 0 0 0 98 0 0 0 0 0 0 98 0 0 0 0 0 0 98 0 0 0 0 0 0 98 0 0 0 0 0 0 98 0 1 0 56 0 0 98 0 1 0 56 0 0 98 0 2 0 112 0 0 98 0 0 0 0 0 0 98 0 4 0 350 18 0 140 0 2 0 112 0 0 0 0 1 1 56 0 0 0 0 1 0 56 0 0 0 0 0 0 0 0 0 0 0 ^C Here is a tcpdump of the same event: 18:40:59.025364 arp who-has 10.1.1.72 tell 10.1.7.250 18:41:00.049385 arp who-has 10.1.1.72 tell 10.1.7.250 18:41:00.868608 arp who-has 10.1.6.253 tell 10.1.7.250 18:41:01.073387 arp who-has 10.1.1.72 tell 10.1.7.250 18:41:02.761445 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 0, length 64 18:41:02.761456 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 1, length 64 18:41:02.761461 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 2, length 64 18:41:02.761466 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 3, length 64 18:41:02.761470 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 4, length 64 18:41:02.761474 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 5, length 64 18:41:02.761479 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 6, length 64 18:41:02.761483 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 7, length 64 18:41:02.761487 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 8, length 64 18:41:02.761492 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 9, length 64 18:41:02.761497 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 10, length 64 18:41:02.761502 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 11, length 64 18:41:02.761506 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 12, length 64 18:41:02.761510 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 13, length 64 18:41:02.761515 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 14, length 64 18:41:02.761519 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 15, length 64 18:41:02.761523 IP 10.1.1.107 > 193.10.65.193: ICMP echo request, id 63239, seq 16, length 64 18:41:02.916556 arp who-has 10.1.1.107 tell 10.1.7.250 18:41:02.916579 arp reply 10.1.1.107 is-at 00:05:4e:4e:1f:c7 18:41:02.917707 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 14, length 64 18:41:02.917906 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 15, length 64 18:41:02.918187 IP 193.10.65.193 > 10.1.1.107: ICMP echo reply, id 63239, seq 16, length 64 18:41:03.531108 arp who-has 10.1.1.72 tell 10.1.7.250 18:41:04.350185 arp who-has 10.1.6.166 tell 10.1.7.250 18:41:04.554984 arp who-has 10.1.1.72 tell 10.1.7.250 18:41:05.578972 arp who-has 10.1.1.72 tell 10.1.7.250 ^C 289 packets captured 289 packets received by filter 0 packets dropped by kernel Any idea on what the problem can be, or how do debug this further? Regards, Bengt