The following reply was made to PR kern/149185; it has been noted by GNATS.
From: Alex Kozlov <s...@rm-rf.kiev.ua>
To: Bernhard Schmidt <bschm...@techwires.net>, bug-follo...@freebsd.org,
n...@freebsd.org, rpa...@freebsd.org, s...@rm-rf.kiev.ua
Cc:
Subject: Re: kern/149185: [rum] [panic] panic in rum(4) driver on 8.1-R
Date: Thu, 5 Aug 2010 12:11:05 +0300
On Thu, Aug 05, 2010 at 10:05:39AM +0200, Bernhard Schmidt wrote:
> On Thu, Aug 5, 2010 at 08:52, Alex Kozlov <s...@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.
--
Adios
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
