Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Apr 2010 13:06:43 +0100
From:      Rui Paulo <rpaulo@FreeBSD.org>
To:        PseudoCylon <moonlightakkiy@yahoo.ca>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r206358 (patch for if_run)
Message-ID:  <81BE57A1-3E1E-4BB9-9FCE-080B34B4452C@FreeBSD.org>
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 9 Apr 2010, at 03:15, PseudoCylon wrote:

>>> Author: rpaulo
>>> Date: Wed Apr  7 15:29:13 2010
>>> New Revision: 206358
>>> URL: http://svn.freebsd.org/changeset/base/206358
>>>=20
>>> Log:
>>> net80211 rate control framework (net80211 ratectl).
>>>=20
>>> 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).
>>>=20
>>=20
>> Hello,
>>=20
>> I've just tried the commit and run(4) works fine out of the box. It =
properly updates the rate.
>>=20
>> Thank you for updating the driver.
>>=20
>> AK
>>=20
>=20
> Sorry, correction.
>=20
> I've got complain from witness
>=20
> uma_zalloc_arg: zone "64" with the following non-sleepable locks held:
> exclusive sleep mutex run0 (network driver) r =3D 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 =3D 0, rsp =3D 0xffffff803e5d0d30, rbp =3D 0 ---
>=20
> 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.
>=20
> Here is patch
>=20
> *** orig_if_run.c    2010-04-08 03:29:31.000000000 -0600
> --- fix_if_run.c    2010-04-08 19:52:45.000000000 -0600
> ***************
> *** 1965,1969 ****
>      uint32_t sta[3];
> - #if 0
> -     uint8_t wcid;
> - #endif
>=20
> --- 1965,1966 ----
> ***************
> *** 1975,1981 ****
>=20
> ! #if 0
> !     wcid =3D RUN_AID2WCID(ni =3D=3D NULL ? 0 : ni->ni_associd);
> !     ieee80211_amrr_node_init(&rvp->amrr, &rvp->amn[wcid], ni);
> ! #endif
>      ieee80211_ratectl_node_init(ni);
>=20
> --- 1972,1976 ----
>=20
> !     RUN_UNLOCK(sc);
>      ieee80211_ratectl_node_init(ni);
> +     RUN_LOCK(sc);
>=20
> ***************
> *** 2096,2102 ****
>=20
> - #if 0
> -         wcid =3D RUN_AID2WCID(ni =3D=3D NULL ? 0 : ni->ni_associd);
> -         amn =3D &rvp->amn[wcid];
> - #endif
> -=20
>          /* count failed TX as errors */
> --- 2091,2092 ----
>=20
>=20
>=20
> P.S.
> #if 0s (amn[]) are no longer needed because now each amrr node is =
attached to individual ieee80211_node.

Can you try updating and see if everything works for you? Thanks.

Regards,
--
Rui Paulo




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?81BE57A1-3E1E-4BB9-9FCE-080B34B4452C>