Re: [EXTERNAL] Re: Mention pkg-readmes in FAQ
Point taken, but what about a readme associated with a dependency install? I've seen them buried, even scroll off screen, in pkg install with a lot of dependencies. Then again, most people don't RTFM. -Original Message- From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of Stuart Henderson Sent: Saturday, April 25, 2015 10:07 AM To: trondd Cc: tech@openbsd.org Subject: [EXTERNAL] Re: Mention pkg-readmes in FAQ On 2015/04/25 11:21, trondd wrote: Seems like I see a lot of people who don't know about pkg-readmes and it was a long time before I knew about them, too. Note their existence in the package/ports FAQ. I don't object to it, but when you install a package with such information, it says: # pkg_add xl2tpd quirks-2.66 signed on 2015-04-23T10:51:49Z xl2tpd-1.3.1p5: ok The following new rcscripts were installed: /etc/rc.d/xl2tpd See rcctl(8) for details. Look in /usr/local/share/doc/pkg-readmes for extra documentation. If people don't manage to find it when it's right in front of them, what hope is there of them noticing it in the FAQ? --- faq15.html 27 Feb 2015 09:16:26 - 1.105 +++ faq15.html 25 Apr 2015 15:18:01 - @@ -370,6 +370,9 @@ scaled. Below is the relevant section fr /pre/blockquote p +Additionally, some packages provide configuration and other +information in a file located in i/usr/local/share/docs/pkg-readmes/i. +p Let us now continue with an example of a package which has dependencies: blockquotepre
Re: Return free'ed memory to OS
http://www.openbsd.org/papers/eurobsdcon2009/otto-malloc.pdf On the page 17 it says that Regions free'ed are kept for later reuse. I have a long living program which do alot of malloc and free. I want free'ed memory to be returned back to the OS. How can i do that? is there any equivalent function like malloc_trim in openBSD? No, and there never will be such a non-standard function. But don't worry. Only small amounts of free memory are kept around as a cache, for performance reasons. The other randomization safety ideas mentioned in the paper are also applied when reusing out of this cache.
Return free'ed memory to OS
Hi Everyone I read the following document about OpenBSD new malloc. http://www.openbsd.org/papers/eurobsdcon2009/otto-malloc.pdf On the page 17 it says that Regions free'ed are kept for later reuse. I have a long living program which do alot of malloc and free. I want free'ed memory to be returned back to the OS. How can i do that? is there any equivalent function like malloc_trim in openBSD? Thanks
Re: [patch] rtl8188eu support for urtwn(4)
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've committed the part below already. I put the ID 0x0179 before 0x018a though, not after. Index: sys/dev/usb/usbdevs === RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.646 diff -u -p -u -r1.646 usbdevs --- sys/dev/usb/usbdevs 2 Apr 2015 14:24:02 - 1.646 +++ sys/dev/usb/usbdevs 19 Apr 2015 20:27:41 - @@ -3486,6 +3486,7 @@ product RATOC REXUSB60F 0xb020 REX-USB6 /* Realtek products */ product REALTEK RTL8188CTV 0x018a RTL8188CTV +product REALTEK RTL8188ETV 0x0179 RTL8188ETV product REALTEK RTL8188RU_2 0x317f RTL8188RU product REALTEK RTL8150 0x8150 RTL8150 product REALTEK RTL8151 0x8151 RTL8151 PNA @@ -3499,6 +3500,7 @@ product REALTEK RTL8174 0x8174 RTL8174 product REALTEK RTL8188CU_0 0x8176 RTL8188CU product REALTEK RTL8191CU0x8177 RTL8191CU product REALTEK RTL8192CU0x8178 RTL8192CU +product REALTEK RTL8188EU0x8179 RTL8188EU product REALTEK RTL8188CU_1 0x817a RTL8188CU product REALTEK RTL8188CU_2 0x817b RTL8188CU product REALTEK RTL8192CE0x817c RTL8192CE
Re: bioctl -d: accept DUIDs
On Sun, Apr 26, 2015 at 11:17:36PM +1000, bytevolc...@safe-mail.net wrote: Whilst I mostly like this patch, and it appears to be much cleaner than the bodgy solution I came up with a few years back, perhaps there is something here worth mentioning: ... I'm glad you like it, but the devs found a better solution; see https://marc.info/?l=openbsd-cvsm=142877223817406w=2
Re: [patch] rtl8188eu support for urtwn(4)
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?
Re: bioctl -d: accept DUIDs
Whilst I mostly like this patch, and it appears to be much cleaner than
the bodgy solution I came up with a few years back, perhaps there is
something here worth mentioning:
+ snprintf(devname, sizeof(devname), %s%d, blkname,
+ DISKUNIT(bd-bd_dev));
TAILQ_FOREACH(sd, sc-sc_dis_list, sd_link) {
- if (!strncmp(sd-sd_meta-ssd_devname, bd-bd_dev,
+ if (!strncmp(sd-sd_meta-ssd_devname, devname,
sizeof(sd-sd_meta-ssd_devname)))
break;
}
The output of snprintf() isn't checked for overflowing. Though I think
the possibility of anything greater than sd9 is low,
probably even zero, I'm still of the view that it is not a bad idea to
code defensively.
If the above case was indeed satisfied, you would get the wrong
device. sd1, missing a zero, for example.
Might be worth something like this:
if(snprintf(devname, sizeof(devname), %s%d, blkname,
DISKUNIT(bd-bd_dev)) = sizeof(devname))
/* error */
Something like that perhaps.
(disclaimer: I'm not a dev; I'm not sure if they would consider it
overkill or precaution).
document how to get line numbers in ddb traces
This feature is very useful but I didn't realise it existed since it's not in GENERIC. Can we document it? Index: crash.8 === RCS file: /cvs/src/share/man/man8/crash.8,v retrieving revision 1.33 diff -u -p -r1.33 crash.8 --- crash.8 8 Nov 2010 15:52:05 - 1.33 +++ crash.8 26 Apr 2015 10:29:47 - @@ -186,7 +186,7 @@ For custom-built kernels, it is helpful configured your kernel to include debugging symbols with .Sq makeoptions DEBUG=-g .Pq see Xr options 4 -(though you will not be able to boot an unstripped kernel since it uses too +(though you might not be able to boot an unstripped kernel since it uses much memory). In this case, you should use .Pa bsd.gdb @@ -293,8 +293,26 @@ After this, the command will show a trace of procedure calls, right back to where the selected process entered the kernel. .Sh CRASH LOCATION DETERMINATION +Custom-built kernels configured to include debugging symbols with +.Sq makeoptions DEBUG=-g +.Pq see Xr options 4 +show symbolic names for addresses and line numbers from source files +in +.Xr ddb 4 +traces. +To make use of this, boot +.Pa bsd.gdb +instead of +.Pa bsd +and try reproducing the crash to drop the system into +.Xr ddb 4 . +Note that +.Pa bsd.gdb +may fail to boot on memory-constrained systems. +.Pp +It is also possible to compile individual files with debug symbols. The following example should make it easier for a novice kernel -developer to find out where the kernel crashed. +developer to find out where a kernel compiled without debug symbols crashed. .Pp First, in .Xr ddb 4
route show -priority n
Hi,
this adds a -priority argument to route show to filter on routes of a
certain priority.
With this you can see all ospf routes
route -n show -priority 32
or any other priority. You can also name some common priorities:
route -n show -priority bgp
This is useful on a router with a full view routing table where
route show | grep foo
takes a little bit long.
any oks or other feedback?
diff --git sbin/route/keywords.h sbin/route/keywords.h
index 6174989..2d322ac 100644
--- sbin/route/keywords.h
+++ sbin/route/keywords.h
@@ -1,4 +1,4 @@
-/* $OpenBSD: keywords.h,v 1.29 2015/02/06 03:22:00 reyk Exp $ */
+/* $OpenBSD$ */
/* WARNING! This file was generated by keywords.sh */
@@ -10,6 +10,7 @@ struct keytab {
enum {
K_NULL,
K_ADD,
+ K_BGP,
K_BLACKHOLE,
K_CHANGE,
K_CLONING,
@@ -33,6 +34,7 @@ enum {
K_LABEL,
K_LINK,
K_LLINFO,
+ K_LOCAL,
K_LOCK,
K_LOCKREST,
K_MONITOR,
@@ -44,6 +46,7 @@ enum {
K_NETMASK,
K_NOJUMBO,
K_NOSTATIC,
+ K_OSPF,
K_OUT,
K_POP,
K_PREFIXLEN,
@@ -53,6 +56,7 @@ enum {
K_PUSH,
K_RECVPIPE,
K_REJECT,
+ K_RIP,
K_RTT,
K_RTTVAR,
K_SA,
@@ -66,6 +70,7 @@ enum {
struct keytab keywords[] = {
{ add,K_ADD },
+ { bgp,K_BGP },
{ blackhole, K_BLACKHOLE },
{ change, K_CHANGE },
{ cloning,K_CLONING },
@@ -89,6 +94,7 @@ struct keytab keywords[] = {
{ label, K_LABEL },
{ link, K_LINK },
{ llinfo, K_LLINFO },
+ { local, K_LOCAL },
{ lock, K_LOCK },
{ lockrest, K_LOCKREST },
{ monitor,K_MONITOR },
@@ -100,6 +106,7 @@ struct keytab keywords[] = {
{ netmask,K_NETMASK },
{ nojumbo,K_NOJUMBO },
{ nostatic, K_NOSTATIC },
+ { ospf, K_OSPF },
{ out,K_OUT },
{ pop,K_POP },
{ prefixlen, K_PREFIXLEN },
@@ -109,6 +116,7 @@ struct keytab keywords[] = {
{ push, K_PUSH },
{ recvpipe, K_RECVPIPE },
{ reject, K_REJECT },
+ { rip,K_RIP },
{ rtt,K_RTT },
{ rttvar, K_RTTVAR },
{ sa, K_SA },
diff --git sbin/route/keywords.sh sbin/route/keywords.sh
index db99593..d4844e2 100644
--- sbin/route/keywords.sh
+++ sbin/route/keywords.sh
@@ -12,6 +12,7 @@ awk=${AWK:-awk}
cat _EOF_ | sort _keywords.t1
add
blackhole
+bgp
change
cloning
delete
@@ -34,6 +35,7 @@ jumbo
label
link
llinfo
+local
lock
lockrest
monitor
@@ -45,6 +47,7 @@ net
netmask
nojumbo
nostatic
+ospf
out
pop
prefixlen
@@ -54,6 +57,7 @@ proto2
push
recvpipe
reject
+rip
rtt
rttvar
sa
diff --git sbin/route/route.8 sbin/route/route.8
index d867e87..efe1c77 100644
--- sbin/route/route.8
+++ sbin/route/route.8
@@ -165,6 +165,7 @@ are shown.
.Op Ar family
.Op Fl gateway
.Op Fl label Ar label
+.Op Fl priority Ar priority
.Xc
Print out the route table similar to netstat -r (see
.Xr netstat 1 ) .
@@ -177,6 +178,11 @@ same address family as the destination are shown.
If
.Fl label
is specified, only routes with the specified label are shown.
+.Pp
+If
+.Fl priority
+is specified, only routes with the specified (numeric) priority are shown.
+Some well known priorities can be given by name.
.El
.Pp
The other commands relating to adding, changing, or deleting routes
diff --git sbin/route/route.c sbin/route/route.c
index c1445db..de37b6f 100644
--- sbin/route/route.c
+++ sbin/route/route.c
@@ -662,7 +662,10 @@ newroute(int argc, char **argv)
void
show(int argc, char *argv[])
{
- int af = 0;
+ int af = 0;
+ u_char prio = 0;
+ char*priostr;
+ const char *errstr;
while (--argc 0) {
if (**(++argv)== '-')
@@ -687,6 +690,34 @@ show(int argc, char *argv[])
usage(1+*argv);
getlabel(*++argv);
break;
+ case K_PRIORITY:
+ if (!--argc)
+ usage(1+*argv);
+ priostr = *++argv;
+ switch (keyword(priostr)) {
+ case K_LOCAL:
+ prio = RTP_LOCAL;
+ break;
+ case K_STATIC:
+ prio = RTP_STATIC;
+ break;
+ case K_OSPF:
+ prio = RTP_OSPF;
+ break;
+ case K_RIP:
+
Re: [patch] rtl8188eu support for urtwn(4)
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.c14 Mar 2015 03:38:49 - 1.43
+++ sys/dev/usb/if_urtwn.c19 Apr 2015 20:27:41 -
@@ -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.
Re: [patch] rtl8188eu support for urtwn(4)
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 - 1.43
+++ sys/dev/usb/if_urtwn.c 19 Apr 2015 20:27:41 -
@@ -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
Re: [patch] rtl8188eu support for urtwn(4)
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 - 1.43
+++ sys/dev/usb/if_urtwn.c 19 Apr 2015 20:27:41 -
@@ -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.
Re: [EXTERNAL] Re: Mention pkg-readmes in FAQ
On 04/26/15 10:14, Eichert, Diana wrote: Point taken, but what about a readme associated with a dependency install? I've seen them buried, even scroll off screen, in pkg install with a lot of dependencies. that's why I added it. Then again, most people don't RTFM. that's why I don't expect to change the world. :) Nick. -Original Message- From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of Stuart Henderson Sent: Saturday, April 25, 2015 10:07 AM To: trondd Cc: tech@openbsd.org Subject: [EXTERNAL] Re: Mention pkg-readmes in FAQ On 2015/04/25 11:21, trondd wrote: Seems like I see a lot of people who don't know about pkg-readmes and it was a long time before I knew about them, too. Note their existence in the package/ports FAQ. I don't object to it, but when you install a package with such information, it says: # pkg_add xl2tpd quirks-2.66 signed on 2015-04-23T10:51:49Z xl2tpd-1.3.1p5: ok The following new rcscripts were installed: /etc/rc.d/xl2tpd See rcctl(8) for details. Look in /usr/local/share/doc/pkg-readmes for extra documentation. If people don't manage to find it when it's right in front of them, what hope is there of them noticing it in the FAQ? --- faq15.html 27 Feb 2015 09:16:26 - 1.105 +++ faq15.html 25 Apr 2015 15:18:01 - @@ -370,6 +370,9 @@ scaled. Below is the relevant section fr /pre/blockquote p +Additionally, some packages provide configuration and other +information in a file located in i/usr/local/share/docs/pkg-readmes/i. +p Let us now continue with an example of a package which has dependencies: blockquotepre
Re: [patch] rtl8188eu support for urtwn(4)
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 - 1.43
+++ sys/dev/usb/if_urtwn.c 19 Apr 2015 20:27:41 -
@@ -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 :
+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
Re: [patch] rtl8188eu support for urtwn(4)
On Sun, Apr 26, 2015 at 6:31 AM, Stefan Sperling s...@stsp.name 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? Hi I tested this diff with my previously unsupported urtwn device: TP-link TL-WN725N dmesg and usbdevs attached. I can confirm speed issue (30Kbits/s via tcpbench) Thanks for the work! dmesg Description: Binary data usbdevs Description: Binary data
