Date: Mon, 23 Jan 2006 16:30:38 -0200 From: AT Matik <asstec@matik.com.br> To: freebsd-mobile@freebsd.org Subject: Re: Debugging ath device timeouts Message-ID: <200601231630.39009.asstec@matik.com.br> In-Reply-To: <43D518D9.6030208@errno.com> References: <20060123041139.GB69091@geoff.deadheaven.com> <20060123145219.GF17465@laverenz.de> <43D518D9.6030208@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 sensitive to this in FreeBSD, and the risk grows while traffic grows, often it happens after the card was idle also, seems pci-cards are less and PCMCIA cards more risky the exactly same hardware with linux or staros often do not show this problem, 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 be 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 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 disable sio/lpt or others often helps checking with pciconf -lv or vmstat -i to find a slot order where the WLcard is not sharing any other resource certain MBs work better with and other without acpi enabled Joćo A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601231630.39009.asstec>