From owner-freebsd-wireless@FreeBSD.ORG Sat Mar 17 11:32:29 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E792D106566B for ; Sat, 17 Mar 2012 11:32:29 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 725CF8FC0C for ; Sat, 17 Mar 2012 11:32:28 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so1539439wib.13 for ; Sat, 17 Mar 2012 04:32:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=BTrA7j9wQZI3oofL8H4dGHBcIDQK8iSSOCcIrbAzFYY=; b=LI3srP39at3/3snAk/aemVYlA4HDd8Rr4hA58B8md1sPCTPnBKeSWKvly7JwvxpHOJ EBn4sRhAQRV2vJ6TTa3cxuc7AlUF10xds/IARQKbZ7IO0F7hm0oTtyX1Vtf4jbdo3Z34 lENfZLoaxjkJMXFkoXVpPsoUFNgm5utr+YXZD+O8ijy1dMDAmv/Vc7UI4oH6PY5cKjDx K3xLJtzFBzOceOfUQ58/XZzvilPlWLy8TXiEHem8157EKZP8yNywxA8iH6pnrkKJRVbV OEIcvGFS1aYte8PeqU2ii/sj7qyB4so9BIh8d03gyOn7Y38rjDrkis2MWVVP8tKog8ks SueA== Received: by 10.180.101.230 with SMTP id fj6mr5785481wib.13.1331983948225; Sat, 17 Mar 2012 04:32:28 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-065-048-156.pools.arcor-ip.net. [88.65.48.156]) by mx.google.com with ESMTPS id gg2sm11255868wib.7.2012.03.17.04.32.26 (version=SSLv3 cipher=OTHER); Sat, 17 Mar 2012 04:32:27 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Mitsuru IWASAKI Date: Sat, 17 Mar 2012 12:32:42 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201203142031.41181.jhugo@meraka.csir.co.za> <20120316.230547.41627417.iwasaki@jp.FreeBSD.org> In-Reply-To: <20120316.230547.41627417.iwasaki@jp.FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203171232.42515.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQntz/NCPTH3goyFK2GqbjCS48IKZ1ZGHz5kHP3rLSUYOrA1Xk0bLF6bj9Gy6V7+gXO9PLfF Cc: freebsd-wireless@freebsd.org Subject: Re: [patch] iwi(4) suspend/resume broken X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 11:32:30 -0000 On Friday, March 16, 2012 03:05:47 PM Mitsuru IWASAKI wrote: > Hi, thanks for comments. > > > Hmm, I'm not sure I like this direct, unconditional fiddling with a > > VAP's state in the stop function, have you made sure that there are no > > side effects? eg. in case no VAP exists? I remember running into issue > > while doing that on iwn(4) and it helped to not have any knowledge > > about ic or vap in either init() or stop(). Well, I've settled for > > I don't warry about sc_ifp->if_l2com, because it is allocated at > attach(), but there is not guarantee that sc_ifp->if_l2com->ic_vaps is > allocated, as you pointed out. > > Updated patches at: > http://people.freebsd.org/~iwasaki/wlan/ipw-20120316.diff > http://people.freebsd.org/~iwasaki/wlan/iww-20120316.diff > http://people.freebsd.org/~iwasaki/wlan/wpi-20120316.diff > > > about ic or vap in either init() or stop(). Well, I've settled for > > ieee80211_stop() and ieee80211_start() in suspend/resume, which seems > > to work. > > I was thinking so too, but ieee80211_stop()/ieee80211_init() are never > called from suspend/resume. > Also wpa_supplicant(8) seems to set roaming mode to manual, so > ieee80211 state doesn't change in this case. > That's why iwi(4) suspend/resume is broken, I think. > > ieee80211_proto.c:ieee80211_start_locked() > ---- > /* > * If the parent is up and running, then kick the > * 802.11 state machine as appropriate. > */ > if ((parent->if_drv_flags & IFF_DRV_RUNNING) && > vap->iv_roaming != IEEE80211_ROAMING_MANUAL) { > if (vap->iv_opmode == IEEE80211_M_STA) { > #if 0 > /* XXX bypasses scan too easily; disable for now */ > /* > * Try to be intelligent about clocking the state > * machine. If we're currently in RUN state then > * we should be able to apply any new state/parameters > * simply by re-associating. Otherwise we need to > * re-scan to select an appropriate ap. > */ > if (vap->iv_state >= IEEE80211_S_RUN) > ieee80211_new_state_locked(vap, > IEEE80211_S_ASSOC, 1); > else > #endif > ieee80211_new_state_locked(vap, > IEEE80211_S_SCAN, 0); > } else { > /* > * For monitor+wds mode there's nothing to do but > * start running. Otherwise if this is the first > * vap to be brought up, start a scan which may be > * preempted if the station is locked to a particular > * channel. > */ > vap->iv_flags_ext |= IEEE80211_FEXT_REINIT; > if (vap->iv_opmode == IEEE80211_M_MONITOR || > vap->iv_opmode == IEEE80211_M_WDS) > ieee80211_new_state_locked(vap, > IEEE80211_S_RUN, -1); > else > ieee80211_new_state_locked(vap, > IEEE80211_S_SCAN, 0); > } > } > } > ---- > > Should we call ieee80211_stop()/ieee80211_init() from suspend/resume > and fix above code? > I prefer calling ieee80211_new_state(IEEE80211_S_INIT) in > iwi_stop_locked() because it's equivalent to RELENG_7's > behavior and fix iwi_restart() too. Sorry, for the delay. I'd really prefer calling ieee80211_stop/init() in the suspend/resume functions, while the driver is not holding the lock (net80211 might call into the driver again). I roughly checked a few things and I even think that calling ieee80211_stop_all() might be enough. Still playing around though. -- Bernhard