kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R

[Juergen Lock]

The following reply was made to PR kern/149185; it has been noted by GNATS.

From: Juergen Lock <nox at jelal.kn-bremen.de>
To: Bernhard Schmidt <bschmidt at techwires.net>
Cc: Alex Kozlov <spam at rm-rf.kiev.ua>, bug-followup at freebsd.org,
        Juergen Lock <nox at jelal.kn-bremen.de>, rpaulo at freebsd.org,
        Kevin Lo <kevlo at freebsd.org>
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 <spam at rm-rf.kiev.ua> wrote:
 > > On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote:
 > >> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov <spam at rm-rf.kiev.ua> 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