From owner-freebsd-net@FreeBSD.ORG Sun Aug 8 15:20:07 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FA521065680 for ; Sun, 8 Aug 2010 15:20:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8598FC21 for ; Sun, 8 Aug 2010 15:20:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o78FK7CP046153 for ; Sun, 8 Aug 2010 15:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o78FK7DQ046152; Sun, 8 Aug 2010 15:20:07 GMT (envelope-from gnats) Date: Sun, 8 Aug 2010 15:20:07 GMT Message-Id: <201008081520.o78FK7DQ046152@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Juergen Lock Cc: Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Juergen Lock List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 15:20:07 -0000 The following reply was made to PR kern/149185; it has been noted by GNATS. From: Juergen Lock To: Bernhard Schmidt Cc: Alex Kozlov , bug-followup@freebsd.org, Juergen Lock , rpaulo@freebsd.org, Kevin Lo Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R Date: Sun, 8 Aug 2010 17:14:46 +0200 On Thu, Aug 05, 2010 at 06:25:32PM +0200, Bernhard Schmidt wrote: > On Thu, Aug 5, 2010 at 11:11, Alex Kozlov wrote: > > On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote: > >> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov wrote: > >> > On Wed, Aug 04, 2010 at 10:02:35PM +0200, Juergen Lock wrote: > >> >>  Regarding the 8.1 if_rum(4) panics...  I got a similar one, extracted > >> >> a dump and tried to gather some info for someone who knows the code: > >> >> > >> >>  The zero divide fault was because (apparently) rate was unitialized, > >> >> as is > >> >> > >> >>       ((struct ieee80211_node *) m->M_dat.MH.MH_pkthdr.rcvif)->ni_vap->iv_txparms[0] > >> >> > >> >> i.e. struct ieee80211_txparam &vap->iv_txparms[0] in case it matters. > >> > Yes, its seems that ratectl framework sometimes set ni->ni_txrate to 0 > >> > This can be mitigated by patch [1] or by setting ucastrate option in > >> > ifconfig. Still real issue need to be solved. > >> > >> The real issue is that prior to an association (RUN state) > >> ieee80211_ratectl_node_init() is not called, therefore iv_bss is not > >> configured in any way. > > ieee80211_ratectl_node_init() called from iv_newstate when switching to > > IEEE80211_S_RUN state. Most drivers do the same. Is it wrong? > > Some call it from iv_newassoc, but this marked /* XXX move */ > > > >> I'll look into that if no one beats me. > > Thanks. > > > Please give attached patch a try, it should fix the issue for rum and > all other drivers relying on the new ratectl stuff. That seems to stop the panics, but the wifi still only works partially (at least with hostapd), like with my original hack of a patch. One reason might be that instead of beacon frames (Frame control 0x0080, wireshark calls this field wlan.fc), the device sends frames with Frame control 0x221e, which wireshark says is 802.11 Unrecognized, Type/Subtype Unknown 0x31... But that might not mean the patch is wrong, the driver might just have other problems too. :) Thanx, Juergen