Date: Fri, 9 Apr 2010 08:59:57 +0200 From: Bernhard Schmidt <bschmidt@techwires.net> To: PseudoCylon <moonlightakkiy@yahoo.ca> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Rui Paulo <rpaulo@FreeBSD.org> Subject: Re: svn commit: r206358 (patch for if_run) Message-ID: <20100409065957.GA6076@mx.techwires.net> In-Reply-To: <488108.55494.qm@web51803.mail.re2.yahoo.com> References: <20100407165048.8CF9E106566B@hub.freebsd.org> <488108.55494.qm@web51803.mail.re2.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 08, 2010 at 07:15:46PM -0700, PseudoCylon wrote: > >>Author: rpaulo > >>Date: Wed Apr 7 15:29:13 2010 > >>New Revision: 206358 > >>URL: http://svn.freebsd.org/changeset/base/206358 > >> > >>Log: > >> net80211 rate control framework (net80211 ratectl). > >> > >> This framework allows drivers to abstract the rate control algorithm and > >> just feed the framework with the usable parameters. The rate control > >> framework will now deal with passing the parameters to the selected > >> algorithm. Right now we have AMRR (the default) and RSSADAPT but there's > >> no way to select one with ifconfig, yet. > >> The objective is to have more rate control algorithms in the net80211 > >> stack so all drivers[0] can use it. Ideally, we'll have the well-known > >> sample rate control algorithm in the net80211 at some point so all > >> drivers can use it (not just ath). > >> > > > >Hello, > > > >I've just tried the commit and run(4) works fine out of the box. It properly updates the rate. > > > >Thank you for updating the driver. > > > >AK > > > > Sorry, correction. > > I've got complain from witness > > uma_zalloc_arg: zone "64" with the following non-sleepable locks held: > exclusive sleep mutex run0 (network driver) r = 0 (0xffffff80008de128) locked @ /usr/src/sys/dev/usb/usb_request.c:540 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_warn() at witness_warn+0x2c2 > uma_zalloc_arg() at uma_zalloc_arg+0x335 > malloc() at malloc+0x9a > amrr_node_init() at amrr_node_init+0x38 > run_newstate() at run_newstate+0x363 > ieee80211_newstate_cb() at ieee80211_newstate_cb+0xac > taskqueue_run() at taskqueue_run+0x91 > taskqueue_thread_loop() at taskqueue_thread_loop+0x3f > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff803e5d0d30, rbp = 0 --- > > Just unlocking the mutex before calling ieee80211_ratectl_node_init() fix this. As long as ieee80211_ratectl_node_init() won't be called with the same ni at the same time, unlocking should be safe. I'd prefer M_NOWAIT instead of M_WAITOK in amrr_node_init(). Fiddling with locking doesn't feel right. -- Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100409065957.GA6076>