svn commit: r206358 (patch for if_run)

[Bernhard Schmidt]

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