From owner-freebsd-net@FreeBSD.ORG Thu Feb 15 23:29:42 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 356FF16A401 for ; Thu, 15 Feb 2007 23:29:42 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 28C0013C46B for ; Thu, 15 Feb 2007 23:29:42 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l1FMxnpX095593; Thu, 15 Feb 2007 14:59:49 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l1FMxn9U095592; Thu, 15 Feb 2007 14:59:49 -0800 (PST) (envelope-from rizzo) Date: Thu, 15 Feb 2007 14:59:49 -0800 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20070215145948.B94883@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: iwi freezing (RELENG_6) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 23:29:42 -0000 [This is a summary of something i have already discussed with other people with no solution so far. I have some more data points if that may help/ring any bell] Since an upgrade of if_iwi.c to 1.8.2.10 (before i have been running a prerelease of 1.8.2.7 which worked pretty reliably) I have been experiencing the problems described below with if_iwi on my Dell Latitude X1 laptop. I am trying to fix them, so i'd like to know if if others are seeing similar problems, and if so if they could contact me. The problems are mainly two: 1. Machine freezing. Very very frequently (7 out of 10 or more) the machine freezes solid (not even going to the debugger with ctrl-alt-esc) as soon as /etc/rc.d/netif starts and tries to setup the interface. For this i have a simple cure: adding this IWI_LOCK_DECL; + printf("%s: start\n", __func__); IWI_LOCK(sc); near the beginning of iwi_ioctl() (and maybe iwi_scanstart() ) has not caused a crash in the >20 reboots (warm&cold) done so far. Patching iwi_scanstart() alone is not enough. 2. Problem associating, reporting endlessly a BEACON MISS This happens with a particular AP which used to work fine until i did the upgrade. For this i don't have a cure yet, also because the AP is not in a convenient location. Anyone else experiencing similar problems ? More details below cheers luigi ---- DETAILED DESCRIPTION ---- 1. machine freezing. As said above, the machine freezes solid soon after netif starts. It really seems a race condition related to starting the card, as instrumenting the code with prinf, or setting debug.iwi to a high values changes things. Setting the radio off does not help. Some experiments show this to happen after iwi_scanstart() has been called 3 times. If i instrument more, the problem disappears so i cannot tell exactly where it happens, however it is before the 4th iwi_scanstart call, but no idea how it is positioned with respect to the iwi_ioctl(). One sequence i saw is this iwi_ioctl(SIOCSIFFLAGS) iwi_scanstart iwi_ioctl(SIOCS80211) iwi_scanstart iwi_ioctl(SIOCS80211) iwi_scanstart <--- freeze here iwi_ioctl(SIOCS80211) <--- freeze here <--- freeze here iwi_scanstart ... but the iwi_scanstart calls seem to be asynchronous and their position/number seem to be dependent on the presence of other access points in the area. When there are no printf and i am lucky (no hang) i see this iwi_cmd: cmd 6 not sent, busy device configuration failed and then dhcp manages to get an address. Note that the printf() in iwi_ioctl makes me never see the 'cmd 6 not sent' message. 2. Problem associating, reporting endlessly a BEACON MISS I have not investigated this in detail, but noticed that the card could not associate to a particular AP i was using just before rebooting after installing the new kernel, and constantly reporting beacin miss. Diffing the two version of the driver, my attention was caught by these threw chunks - could they have something to do with the problem ? @@ -433,6 +438,7 @@ } ieee80211_ifattach(ic); + ic->ic_bmissthreshold = 10; /* override default */ /* override default methods */ ic->ic_node_alloc = iwi_node_alloc; sc->sc_node_free = ic->ic_node_free; @@ -979,13 +972,19 @@ ieee80211_state_name[ic->ic_state], ieee80211_state_name[nstate], sc->flags)); + /* XXX state change race with taskqueue */ switch (nstate) { case IEEE80211_S_SCAN: if (ic->ic_state == IEEE80211_S_RUN) { /* * Beacon miss, send disassoc and wait for a reply - * from the card; we'll start a scan then. - */ + * from the card; we'll start a scan then. Note + * this only happens with auto roaming; otherwise + * just notify users and wait to be directed. + */ + /* notify directly as we bypass net80211 */ + ieee80211_sta_leave(ic, ic->ic_bss); + if (ic->ic_roaming == IEEE80211_ROAMING_AUTO) taskqueue_enqueue(sc->sc_tq, &sc->sc_downtask); break; } @@ -2455,6 +2585,7 @@ memset(&config, 0, sizeof config); config.bluetooth_coexistence = sc->bluetooth; + config.silence_threshold = 0x1e; config.antenna = sc->antenna; config.multicast_enabled = 1; config.answer_pbreq = (ic->ic_opmode == IEEE80211_M_IBSS) ? 1 : 0; ---------------------------------------------------------------------------