From owner-freebsd-stable Mon Jun 10 16:12:32 2002 Delivered-To: freebsd-stable@freebsd.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by hub.freebsd.org (Postfix) with ESMTP id 9428A37B40A for ; Mon, 10 Jun 2002 16:12:16 -0700 (PDT) Received: from gauss ([24.91.142.45]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020610231215.ZPPA975.sccrmhc02.attbi.com@gauss> for ; Mon, 10 Jun 2002 23:12:15 +0000 Message-ID: <002401c210d4$3d0eda90$0200a8c0@gauss> From: "Yeasah Pell" To: Subject: if_an woes Date: Mon, 10 Jun 2002 19:12:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I recently switched from RELENG_4_5 to the "unofficial" RELENG_4_6, and since then I've started seeing rather serious stalls and lost connections on my wireless interface (if_an). This is an aironet wireless PC Card in a PCI adapter, and is labelled as a DELL PC4800B. The Intel dual-port wired NIC on the same machine is unaffected (fxp0, fxp1). It seems to take some amount of uptime before the wireless interface starts to misbehave noticably. So far, I've tried: 1) Turing off RFC1323 extensions. 2) Making if_an a kernel module, so I can reload it dynamically when it starts to really fail (see syslog messages below) -- [BTW, I noticed that if I make miibus and fxp into modules, I panic on boot, and if I make fxp a module and miibus built-in, fxp tries to load miibus as a module, fails, and I get no fxp.] 3) Tried if_an.ko from my kernel.GENERIC (from FreeBSD 4.2, crazy, amazed it worked...), and it still seemed to exhibit the same problem, or at least the 4.2 <-> 4.6 interface issues masqueraded as the same problem :-) 4) Tried disabling those services that require user kernel modules (e.g. drm-kmod, vmware) 5) Tried rebuilding a 4.5 release kernel with the same config as the 4.6, which works fine -- no delays, no dropped connections. Now that I have it built as a kernel module, I can bounce the driver with kldunload and kldload and the problem disappears for a while. Merely taking the interface down and up is not sufficient -- the driver must be reloaded. I've created an interface-bouncing script, but that's getting really old fast. :-) [BTW, I've noticed that the dhcpd I have running on both fxp1 and an0 goes berserk eating CPU once an0 goes away, and has to be restarted. I eventually get this in the log (after I restart dhcpd): "dhcpd: receive_packet failed on an0: Device not configured". Doesn't stop doing this, even when an0 comes back. Of course, this is with the isc-dhcp3-3.0.1.r9 from ports, so forget I said anything] Once, I actually got the wireless NIC to fail outright, and the following messages appeared in /var/log/messages: Jun 8 19:10:00 turing /kernel: an0: seek to record failed Jun 8 19:10:10 turing last message repeated 15 times Jun 8 19:10:10 turing /kernel: an0: xmit failed Jun 8 19:10:12 turing /kernel: an0: seek to record failed Jun 8 19:10:12 turing /kernel: an0: seek to record failed Jun 8 19:10:12 turing /kernel: an0: xmit failed Jun 8 19:10:12 turing /kernel: an0: seek to record failed Jun 8 19:10:12 turing /kernel: an0: seek to record failed Jun 8 19:10:14 turing /kernel: an0: xmit failed Jun 8 19:10:14 turing /kernel: an0: seek to record failed Jun 8 19:10:17 turing last message repeated 5 times Jun 8 19:10:18 turing /kernel: an0: xmit failed Jun 8 19:10:18 turing /kernel: an0: seek to record failed Jun 8 19:10:32 turing last message repeated 9 times Jun 8 19:10:32 turing /kernel: an0: device timeout Jun 8 19:10:32 turing /kernel: an0: reset failed Jun 8 19:10:32 turing /kernel: an0: failed to allocate 1586 bytes on NIC Jun 8 19:10:32 turing /kernel: an0: reset failed Jun 8 19:10:32 turing /kernel: an0: failed to allocate 1586 bytes on NIC Jun 8 19:10:32 turing /kernel: an0: tx buffer allocation failed Unfortuately, I've not seen these messages since, just random network failures. That was the first time I saw the problem, though, and I assume if I let the system continue to run uncorrected after I notice problems, I'll eventually get these messages again. I should mention that I have been compiling the 4.6 kernel with the ATAPICAM patches, although I can't imagine there being a connection to this problem. (Boy, I sure wish some form of ATAPI CAM linkage was in the official kernel source, even if it were disabled by default...) Any clues are greatly appreciated. If I can provide additional information, just let me know and I'll do my best to collect it. I plan to do some tcpdumping soon and I'll try to catch some stalls or dropped connections in the act and see what is going on at the packet level. Here's some additional information about my configuration ---------- My rc.local contains the following setup for the interface: ancontrol -c 3 ancontrol -n SCHWIDE ancontrol -o 0 Here are some dumps of anconfig info when the NIC is dropping/stalling packets: bash-2.05a$ ancontrol -S MAC address: [ 00:40:96:30:ad:47 ] Operating mode: [ configured MAC ON RX ON synced ] Error code: [ 00 ] Signal quality: [ 04 ] Signal strength: [ 82% ] Max Noise: [ 0% ] Current TX rate: [ 11 ] Current SSID: [ SCHWIDE ] Current AP name: [ ] Current BSSID: [ 02:90:aa:a4:44:3e ] Beacon period: [ 100 ] DTIM period: [ 1 ] ATIM duration: [ 0 ] HOP period: [ 200 ] Channel set: [ 0 ] Current channel: [ 3 ] Hops to backbone: [ 0 ] Total AP load: [ 0 ] Our generated load: [ 0 ] Accumulated ARL: [ 0 ] bash-2.05a$ ancontrol -I OUI: [ 00:40:96 ] Product number: [ 7 ] Manufacturer name: [ Aironet Wireless Communications ] Produce name: [ PC4800B ] Firmware version: [ 3 ] OEM MAC address: [ 00:40:96:30:ad:47 ] Aironet MAC address: [ 00:40:96:30:ad:47 ] Radio type: [ 802.11 DS ] Regulatory domain: [ 0 ] Assigned CallID: [ ff:ff:ff:ff:ff:ff ] Supported speeds: [ 1.0Mbps 2.0Mbps 5.5Mbps 11.0Mbps ] RX Diversity: [ antenna 1 and 2 ] TX Diversity: [ antenna 1 and 2 ] Supported power levels: [ 5 15 30 0 0 0 0 0 ] Hardware revision: [ 00:20 ] Software revision: [ 00:00 ] Software subrevision: [ 00:00 ] Interface revision: [ 00:00 ] Bootblock revision: [ 01:32 ] bash-2.05a$ ancontrol -T RX overruns: [ 0 ] RX PLCP CSUM errors: [ 2499 ] RX PLCP format errors: [ 93 ] RX PLCP length errors: [ 0 ] RX MAC CRC errors: [ 700 ] RX MAC CRC OK: [ 191715 ] RX WEP errors: [ 0 ] RX WEP OK: [ 0 ] Long retries: [ 727 ] Short retries: [ 421 ] Retries exhausted: [ 53 ] Bad ACK: [ 727 ] Bad CTS: [ 421 ] RX good ACKs: [ 21345 ] RX good CTSs: [ 103 ] TX good ACKs: [ 24806 ] TX good RTSs: [ 524 ] TX good CTSs: [ 2 ] LMAC multicasts transmitted: [ 1 ] LMAC broadcasts transmitted: [ 1025133 ] LMAC unicast frags transmitted: [ 21398 ] LMAC unicasts transmitted: [ 21398 ] Beacons transmitted: [ 1024656 ] Beacons received: [ 133287 ] Single transmit collisions: [ 0 ] Multiple transmit collisions: [ 0 ] Transmits without deferrals: [ 0 ] Transmits deferred due to protocol: [ 4 ] Transmits deferred due to energy detect: [ 1148663 ] RX duplicate frames/frags: [ 1 ] RX partial frames: [ 0 ] TX max lifetime exceeded: [ 0 ] RX max lifetime exceeded: [ 0 ] Sync lost due to too many missed beacons: [ 0 ] Sync lost due to ARL exceeded: [ 0 ] Sync lost due to deauthentication: [ 0 ] Sync lost due to disassociation: [ 0 ] Sync lost due to excess change in TSF timing: [ 18 ] Host transmitted multicasts: [ 3 ] Host transmitted broadcasts: [ 13 ] Host transmitted unicasts: [ 19507 ] Host transmission failures: [ 13 ] Host received multicasts: [ 24 ] Host received broadcasts: [ 4614 ] Host received unicasts: [ 12362 ] Host receive discards: [ 0 ] HMAC transmitted multicasts: [ 0 ] HMAC transmitted broadcasts: [ 467 ] HMAC transmitted unicasts: [ 1891 ] HMAC transmissions failed: [ 45 ] HMAC received multicasts: [ 0 ] HMAC received broadcasts: [ 138124 ] HMAC received unicasts: [ 21 ] HMAC receive discards: [ 2581 ] HMAC transmits accepted: [ 138145 ] SSID mismatches: [ 0 ] Access point mismatches: [ 0 ] Speed mismatches: [ 0 ] Authentication rejects: [ 0 ] Authentication timeouts: [ 0 ] Association rejects: [ 0 ] Association timeouts: [ 0 ] Management frames received: [ 0 ] Management frames transmitted: [ 0 ] Refresh frames received: [ 0 ] Refresh frames transmitted: [ 0 ] Poll frames received: [ 0 ] Poll frames transmitted: [ 0 ] Host requested sync losses: [ 0 ] Host transmitted bytes: [ 16577381 ] Host received bytes: [ 2358348 ] Uptime in microseconds: [ -684603459 ] Uptime in seconds: [ 111043 ] Sync lost due to better AP: [ 0 ] bash-2.05a$ ancontrol -C Operating mode: [ ad-hoc ] Receive mode: [ broadcast/multicast/unicast ] Fragment threshold: [ 2312 ] RTS threshold: [ 2312 ] MAC address: [ 00:40:96:30:ad:47 ] Supported rates: [ 65.0Mbps 2.0Mbps 5.5Mbps 11.0Mbps ] Short retry limit: [ 16 ] Long retry limit: [ 16 ] TX MSDU lifetime: [ 5000 ] RX MSDU lifetime: [ 10000 ] Stationary: [ Off ] Ordering: [ Off ] Device type: [ PC4800 ] Scanning mode: [ active ] Probe delay: [ 3 ] Probe energy timeout: [ 3 ] Probe response timeout: [ 20 ] Beacon listen timeout: [ 40 ] IBSS join network timeout: [ 10000 ] Authentication timeout: [ 2000 ] WEP enabled: [ no ] Authentication type: [ open ] Association timeout: [ 2000 ] Specified AP association timeout: [ 10000 ] Offline scan interval: [ 0 ] Offline scan duration: [ 0 ] Link loss delay: [ 0 ] Max beacon loss time: [ 500 ] Refresh interval: [ 10000 ] Power save mode: [ none ] Sleep through DTIMs: [ Off ] Power save listen interval: [ 200 ] Power save fast listen interval: [ 100 ] Power save listen decay: [ 2 ] Power save fast listen decay: [ 200 ] AP/ad-hoc Beacon period: [ 100 ] AP/ad-hoc ATIM duration: [ 0 ] AP/ad-hoc current channel: [ 3 ] AP/ad-hoc DTIM period: [ 1 ] Radio type: [ 802.11 DS ] RX Diversity: [ antenna 1 only ] TX Diversity: [ antenna 1 only ] Transmit power level: [ 30 ] RSS threshold: [ 0 ] Node name: [ FreeBSD ] ARL threshold: [ 65535 ] ARL decay: [ 65535 ] ARL delay: [ 65535 ] Configuration: [ Home Configuration ] WEP Key status: Key 0 is set 40 bits Key 1 is set 40 bits Key 4 is set 40 bits The active transmit key is 4 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message