Date: Tue, 1 Jan 2008 14:27:47 +0800 From: "Sepherosa Ziehau" <sepherosa@gmail.com> To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" <des@des.no> Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression Message-ID: <ea7b9c170712312227m7a961c95kc2bed20f94d09593@mail.gmail.com> In-Reply-To: <86ir2hznnd.fsf@ds4.des.no> References: <86ir2hznnd.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 29, 2007 8:33 PM, Dag-Erling Sm=F8rgrav <des@des.no> wrote:
> I upgraded my router cum firewall cum access point (soekris net4801 with
> a cheap third-party ralink-based wlan adapter) from RELENG_6 to HEAD and
> noticed what seems to be a regression in if_ral. After a certain amount
> of use (i.e. actually having a client connected to it and transferring
> data), the connection falters, and eventually the client can no longer
> see even see the access point in a scan. Restarting the interface on
> the router (/etc/rc.d/netif restart ral0) fixes it. I now have a cron
> job that does this every five minutes. I still get occasional outages,
> but all I have to do is wait a few minutes for the cron job to kick in.
>
> Outages are clearly related to traffic; a sure-fire way to trigger one
> is to start a backup job on my laptop (rsync to my file server). I will
> lose the wlan connection repeatedly until I either stop trying or run
> the script with a bandwidth limit.
>
> des@soe ~% uname -a
> FreeBSD soe.des.no 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 15 20:46:2=
9 UTC 2007 des@pwd.des.no:/usr/obj/usr/src/sys/soe i386
> des@soe ~% kldstat -v
> Id Refs Address Size Name
> 1 18 0xc0400000 33fdfc kernel (/boot/soe/kernel)
> 2 1 0xc0740000 7690 if_sis.ko (/boot/soe/if_sis.ko)
> 3 2 0xc0748000 1dbe0 miibus.ko (/boot/soe/miibus.ko)
> 4 1 0xc0766000 18e28 if_ral.ko (/boot/soe/if_ral.ko)
> 5 4 0xc077f000 2a95c wlan.ko (/boot/soe/wlan.ko)
> 6 1 0xc07aa000 2cb0 wlan_acl.ko (/boot/soe/wlan_acl.ko)
> 7 1 0xc07ad000 1924 wlan_scan_ap.ko (/boot/soe/wlan_scan_ap.ko)
> 8 1 0xc107f000 6000 geom_md.ko (/boot/soe/geom_md.ko)
> 9 1 0xc10f9000 2000 pflog.ko (/boot/soe/pflog.ko)
> 10 1 0xc10fb000 2f000 pf.ko (/boot/soe/pf.ko)
> 11 4 0xc118d000 a000 netgraph.ko (/boot/soe/netgraph.ko)
> 12 1 0xc119c000 3000 ng_ether.ko (/boot/soe/ng_ether.ko)
> 13 1 0xc11a8000 5000 ng_pppoe.ko (/boot/soe/ng_pppoe.ko)
> 14 1 0xc11ad000 4000 ng_socket.ko (/boot/soe/ng_socket.ko)
> des@soe ~% grep ral0 /var/run/dmesg.boot
> ral0: <Ralink Technology RT2560> mem 0xa0004000-0xa0005fff irq 11 at devi=
ce 10.0 on pci0
I don't whether following thingies will fix your problem:
1)
rt2560.c: rt2560_setup_tx_desc()
Set RT2560_{TX,TX_CIPHER}_BUSY desc flag at the end of this function,
instead of at the beginning of this function. The original way _may_
confuse hardware encryption/tx engine.
2)
And the rt2560_bbp_read() is not correct, it should look like following:
static uint8_t
rt2560_bbp_read(struct rt2560_softc *sc, uint8_t reg)
{
=09uint32_t val;
=09int ntries;
=09for (ntries =3D 0; ntries < 100; ntries++) {
=09=09if (!(RAL_READ(sc, RT2560_BBPCSR) & RT2560_BBP_BUSY))
=09=09=09break;
=09=09DELAY(1);
=09}
=09if (ntries =3D=3D 100) {
=09=09device_printf(sc->sc_dev, "could not read from BBP\n");
=09=09return 0;
=09}
=09val =3D RT2560_BBP_BUSY | reg << 8;
=09RAL_WRITE(sc, RT2560_BBPCSR, val);
=09for (ntries =3D 0; ntries < 100; ntries++) {
=09=09val =3D RAL_READ(sc, RT2560_BBPCSR);
=09=09if (!(val & RT2560_BBP_BUSY))
=09=09=09return val & 0xff;
=09=09DELAY(1);
=09}
=09device_printf(sc->sc_dev, "could not read from BBP\n");
=09return 0;
}
3)
After above fix,
rt2560_set_txantenna() and rt2560_set_rxantenna() should be called
after rt2560_bbp_init(), since above two function touch BBP. NOTE:
without above fix, you may burn your card.
Even with these in place in dfly, I still have strange TX performance
regression in sta mode (drop from 20Mb/s to 3Mb/s under very well
condition) on certain hardwares after 20sec~30sec TCP_STREAM netperf
testing; didn't have enough time to dig, however, all of the tested
hardwares stayed connected during testing (I usually run netperf
stream test for 12 hours or more).
Best Regards,
sephe
--=20
Live Free or Die
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ea7b9c170712312227m7a961c95kc2bed20f94d09593>