On 4/26/15, Mikhail <mp39...@gmail.com> wrote: > On 21:22 26-Apr 2015 Mikhail wrote: >> On 20:20 26-Apr 2015 Stefan Sperling wrote: >> > On Sun, Apr 26, 2015 at 01:31:17PM +0200, Stefan Sperling wrote: >> > > On Sun, Apr 19, 2015 at 11:48:32PM +0300, Mikhail wrote: >> > > > Bellow new version of the patch with above things fixed, also I've >> > > > fixed >> > > > detection of ETV chip in urtwn_attach(), nothing else is changed. >> > > >> > > I'm seeing very low data transmission rates with your patch and a >> > > TP-Link TL-WN725N device. In both 11b and 11g mode, the data rate >> > > remains very low (less than 100Kbit/s). A different urtwn(4) device >> > > (with 8188CUS chip) has much better throughput. >> > > >> > > Are you seeing this, too? >> > >> > The chunk below is wrong for OpenBSD since it sets the intitial >> > transmit >> > rate to an 11n rate. 0x13 corresponds to the "MCS7" 11n rate, >> > see linux/drivers/net/wireless/rtlwifi/rtl8188ee/def.h enum >> > rtl_desc92c_rate. >> > The value 11 corresponds to OFDM 54Mbit which is fine for OpenBSD. >> > We only support 11a/b/g at present. >> > >> > --- sys/dev/usb/if_urtwn.c 14 Mar 2015 03:38:49 -0000 1.43 >> > +++ sys/dev/usb/if_urtwn.c 19 Apr 2015 20:27:41 -0000 >> > @@ -1813,7 +2011,10 @@ urtwn_tx(struct urtwn_softc *sc, struct >> > txd->txdw4 |= htole32(SM(R92C_TXDW4_RTSRATE, 8)); >> > txd->txdw5 |= htole32(0x0001ff00); >> > /* Send data at OFDM54. */ >> > - txd->txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11)); >> > + if (sc->chip & URTWN_CHIP_88E) >> > + txd->txdw5 |= htole32(0x13 & 0x3f); >> > + else >> > + txd->txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11)); >> > >> > } else { >> > txd->txdw1 |= htole32( >> > >> > Reverting this change doesn't fix the transmit speed problem, >> > unfortunately. >> > >> > I wonder if we're making some mistake while setting up the TX >> > descriptor? >> > There are several differences in the TX descriptors of 88E vs 92C. >> > For example, 88E has third antenna C available. >> >> Hello, in urtwn_init(), in part: >> >> if (sc->chip & URTWN_CHIP_88E) >> urtwn_write_1(sc, R92C_RXDMA_AGG_PG_TH + 1, 4); >> else >> urtwn_write_1(sc, R92C_USB_DMA_AGG_TO, 4); >> >> comment first 3 lines. It fixes speed problem for me, but I need to >> understand the issue further, before proposing any solution. > > The issue isn't in those lines, but a little bit higher - the driver > enables usb and dma aggregations, but native linux implementation > enables only dma and disables usb one. > > I've submitted bug report to FreeBSD[1] with a patch, which I see as a > proper solution: > > urtwn_write_1(sc, R92C_USB_SPECIAL_OPTION, > urtwn_read_1(sc, R92C_USB_SPECIAL_OPTION) | > - R92C_USB_SPECIAL_OPTION_AGG_EN); > + (sc->chip & URTWN_CHIP_88E ? > + ~R92C_USB_SPECIAL_OPTION_AGG_EN :
umm... maybe 0, as it is being ORed with what read returns. But maybe the check should be against URTWN_CHIP_92C since the option is specific to it (or at least implied to be so). --patrick > + R92C_USB_SPECIAL_OPTION_AGG_EN)); > > I'd suggest to wait some time for feedback. Testing is welcome, of > course. Thank you for pointing this out and review in general. > > [1] - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199718 > >