From owner-freebsd-mobile@FreeBSD.ORG Sat Jul 29 05:44:46 2006 Return-Path: X-Original-To: freebsd-mobile@freebsd.org Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D469816A4DA for ; Sat, 29 Jul 2006 05:44:45 +0000 (UTC) (envelope-from rsf@ns.live555.com) Received: from ns.live555.com (ns.live555.com [66.80.62.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88A2743D49 for ; Sat, 29 Jul 2006 05:44:45 +0000 (GMT) (envelope-from rsf@ns.live555.com) Received: from ns.live555.com (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.13.6/8.13.6) with ESMTP id k6T5ijJ5025596 for ; Fri, 28 Jul 2006 22:44:45 -0700 (PDT) (envelope-from rsf@ns.live555.com) Received: (from rsf@localhost) by ns.live555.com (8.13.6/8.13.6/Submit) id k6T5ijsb025595; Fri, 28 Jul 2006 22:44:45 -0700 (PDT) (envelope-from rsf) Mime-Version: 1.0 Message-Id: Date: Fri, 28 Jul 2006 22:44:36 -0700 To: freebsd-mobile@freebsd.org From: Ross Finlayson Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Ongoing problems with the "ath" interface - is any relief in sight?? 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: Sat, 29 Jul 2006 05:44:46 -0000 For several months now, the "ath" interface has been spazzing out at random times (in systems that are acting as wireless base stations). For example: Jul 28 21:44:47 ns kernel: ath0: stuck beacon; resetting (bmiss count 4) Jul 28 21:44:47 ns kernel: ath0: ath_reset: unable to reset hardware; hal status 3 Jul 28 21:45:08 ns kernel: ath0: device timeout Jul 28 21:45:08 ns kernel: ath0: stuck beacon; resetting (bmiss count 4) Jul 28 21:45:08 ns kernel: ath0: ath_reset: unable to reset hardware; hal status 3 [and then the interface stops working] %cat /etc/motd FreeBSD 6.1-STABLE (GENERIC) #6: Thu Jul 27 20:55:43 PDT 2006 The error isn't always the same, however. Often it is ath0: device timeout or ath0: discard frame w/o packet header or even arp: unknown hardware address format (0x4500) In each case, however, the "ath" interface stops working Immediately after the error report, so I don't believe that the latter two error reports are legitimate. I'm wondering it perhaps there's a memory smash somewhere that's corrupting some driver data structures (thereby causing bogus error reports in addition to stopping the interface from working)? The last time I asked about this, someone speculated that 'power save mode' was the culprit. Unfortunately, the system is running in a coffee shop that provides public WiFi, so it's not possible to stop clients from using power save mode. On my system, these errors are often happening several times a day. Has anyone else run into frequent problems like this, and is anyone looking into a solution? Ross.