Re: [patch] rtl8188eu support for urtwn(4)
On Sun, Apr 26, 2015 at 6:31 AM, 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? > 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
vmx ring sizes
ola, i just moved the bittorrent seeder we use to reimage our lab machines off a physical box onto a vm, and found it hit the current ring limits. bumping this up gave us some more headroom. the CWM on vmx0 now sits up around 150 on our vm, but the extra tx descriptors has helped a lot since we're mostly pushing packets. ok? Index: if_vmx.c === RCS file: /cvs/src/sys/dev/pci/if_vmx.c,v retrieving revision 1.24 diff -u -p -r1.24 if_vmx.c --- if_vmx.c10 Feb 2015 02:57:32 - 1.24 +++ if_vmx.c27 Apr 2015 04:43:02 - @@ -50,9 +50,9 @@ #define NRXQUEUE 1 #define NTXQUEUE 1 -#define NTXDESC 128 /* tx ring size */ +#define NTXDESC 512 /* tx ring size */ #define NTXSEGS 8 /* tx descriptors per packet */ -#define NRXDESC 128 +#define NRXDESC 512 #define NTXCOMPDESC NTXDESC #define NRXCOMPDESC (NRXDESC * 2) /* ring1 + ring2 */
Re: [patch] rtl8188eu support for urtwn(4)
On 4/26/15, Mikhail 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 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: [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 >> >> +Additionally, some packages provide configuration and other >> +information in a file located in >> /usr/local/share/docs/pkg-readmes. + Let us now continue >> with an example of a package which has dependencies: >> >> >> >
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 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: Return free'ed memory to OS
On Sun, Apr 26, 2015 at 08:53:10PM +0430, sadegh solati wrote: > 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 Don't worry, only a handfull of pages max are cached. But if youy are really worried, you can set the malloc cache size to 0. See malloc(3). -Otto
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: [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 > > > > +Additionally, some packages provide configuration and other > +information in a file located in /usr/local/share/docs/pkg-readmes. > + > Let us now continue with an example of a package which has dependencies: > > >
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-cvs&m=142877223817406&w=2
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).
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;
+
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: [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?
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
