From owner-freebsd-mobile@FreeBSD.ORG Mon Jan 23 18:31:07 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 C883A16A423 for ; Mon, 23 Jan 2006 18:31:07 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BA9C442DB for ; Mon, 23 Jan 2006 18:31:06 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k0NIUpxW013694; Mon, 23 Jan 2006 16:30:51 -0200 (BRST) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-mobile@freebsd.org Date: Mon, 23 Jan 2006 16:30:38 -0200 User-Agent: KMail/1.9.1 References: <20060123041139.GB69091@geoff.deadheaven.com> <20060123145219.GF17465@laverenz.de> <43D518D9.6030208@errno.com> In-Reply-To: <43D518D9.6030208@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200601231630.39009.asstec@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: Debugging ath device timeouts 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, 23 Jan 2006 18:31:08 -0000 On Monday 23 January 2006 15:56, Sam Leffler wrote: > > A device timeout in ath means a frame was submitted to the hardware for > transmit but no interrupt was received for 5 seconds. I cannot comment > on the other drivers but I find it unlikely that the issue is common. not exactly, this is very common on almost all WL cards and they are very=20 sensitive to this in FreeBSD, and the risk grows while traffic grows, often= =20 it happens after the card was idle also, seems pci-cards are less and PCMCI= A=20 cards more risky the exactly same hardware with linux or staros often do not show this probl= em,=20 booting back to freebsd it appears imediatly wi cards often do not come back but ath card driver seems to be better device_polling helped a lot because seems that other NICs on the PC could b= e=20 taken out so that only the WLcards are interrupt driven it helps also a lot using better MBs with nothing onboard or at least with= =20 good acpi qualities and anything you do not need disabled in the Bios often this points are useless for client stations which often do not can=20 disable sio/lpt or others often helps checking with pciconf -lv or vmstat -i to find a slot order whe= re=20 the WLcard is not sharing any other resource certain MBs work better with and other without acpi enabled Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br