Re: Support power saving with athn(4) in host AP mode
-Ursprüngliche Nachricht- An: tech@openbsd.org; Von:Uwe Werler uwe.wer...@retiolum.eu Gesendet: Mo 12.11.2012 15:32 Betreff:Re: Support power saving with athn(4) in host AP mode Further testing would be welcome. Even if you don't use clients with power saving enabled. So if you're running an athn(4) based AP, please give this a spin. Runs like a charme with snapshot from 2012-11-11. Tried Windows 7, Android ICS, IPhone 3S, OpenBSD 4.7 and 5.2, Ubuntu 10. Thank You Mark for the excellent work! I replaced my existing AP with OpenBSD + Alix now and I'm happy. add: I use a Wistron DNMA92 (miniPCI) / AR9280 athn0 at pci0 dev 12 function 0 Atheros AR9280 rev 0x01: irq 9 athn0: AR9280 rev 2 (2T2R), ROM rev 21, address a8:54:b2:3d:fd:a0
Re: 11n support for athn(4)
On 16. Jan 17:46:48, Uwe Werler wrote: > > Unfortunately the throughput is very low, only ~7 MBit. With mode 11g I get > ~16 MBit. > > > zarathustra:~# tcpbench apu01 > elapsed_ms bytes mbps bwidth > 1004 7482725.962 100.00% > Conn: 1 Mbps:5.962 Peak Mbps:5.962 Avg Mbps:5.962 > 2007 8396646.697 100.00% > Conn: 1 Mbps:6.697 Peak Mbps:6.697 Avg Mbps:6.697 > 3010 8182446.533 100.00% > Conn: 1 Mbps:6.533 Peak Mbps:6.697 Avg Mbps:6.533 > 4013 9096367.255 100.00% > Conn: 1 Mbps:7.255 Peak Mbps:7.255 Avg Mbps:7.255 > 5014 8568006.848 100.00% > Conn: 1 Mbps:6.848 Peak Mbps:7.255 Avg Mbps:6.848 > 6015 8682246.946 100.00% > Conn: 1 Mbps:6.946 Peak Mbps:7.255 Avg Mbps:6.946 > 7021 8725086.945 100.00% > Conn: 1 Mbps:6.945 Peak Mbps:7.255 Avg Mbps:6.945 > 8023 8353806.670 100.00% > Conn: 1 Mbps:6.670 Peak Mbps:7.255 Avg Mbps:6.670 > 9025 8482326.779 100.00% > Conn: 1 Mbps:6.779 Peak Mbps:7.255 Avg Mbps:6.779 >10028 8439486.731 100.00% > Conn: 1 Mbps:6.731 Peak Mbps:7.255 Avg Mbps:6.731 >11036 8310966.596 100.00% > Conn: 1 Mbps:6.596 Peak Mbps:7.255 Avg Mbps:6.596 > > I'm now ready to test furhter. > I tested yesterday with my Android phone (Galaxy S7) and got only ~4 MBit.
Re: 11n support for athn(4)
Hello Stefan, many many thanks for this work! I tested today with the latest snapshot from yesterday and a custom compiled kernel from today's sources. AP is my APU1D4 and Client is my ThinkPad T530 with iwn: AP: athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 19 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:17:40:ba athn0: flags=8947 mtu 1500 lladdr 04:f0:21:17:40:ba index 4 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect (autoselect hostap) status: active ieee80211: nwid TEST chan 1 bssid 04:f0:21:17:40:ba wpakey XXX wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp athn0: sending auth to 6c:88:14:36:27:b0 on channel 1 mode auto athn0: station 6c:88:14:36:27:b0 newly authenticated (open) athn0: sending assoc_resp to 6c:88:14:36:27:b0 on channel 1 mode auto athn0: sending msg 1/4 of the 4-way handshake to 6c:88:14:36:27:b0 athn0: received auth from 6c:88:14:36:27:b0 rssi 34 mode auto athn0: received assoc_req from 6c:88:14:36:27:b0 rssi 33 mode auto athn0: sending msg 1/4 of the 4-way handshake to 6c:88:14:36:27:b0 athn0: received msg 2/4 of the 4-way handshake from 6c:88:14:36:27:b0 athn0: sending msg 3/4 of the 4-way handshake to 6c:88:14:36:27:b0 athn0: received msg 4/4 of the 4-way handshake from 6c:88:14:36:27:b0 Client: iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, MIMO 2T2R, MoW, address 6c:88:14:36:27:b0 iwn0: end active scan iwn0: sending auth to 04:f0:21:17:40:ba on channel 1 mode 11g iwn0: sending assoc_req to 04:f0:21:17:40:ba on channel 1 mode 11g iwn0: received auth from 04:f0:21:17:40:ba rssi -20 mode 11g iwn0: associated with 04:f0:21:17:40:ba ssid "TEST" channel 1 start MCS 0 short preamble long slot time HT enabled iwn0: received assoc_resp from 04:f0:21:17:40:ba rssi -21 mode 11g iwn0: received msg 1/4 of the 4-way handshake from 04:f0:21:17:40:ba iwn0: sending msg 2/4 of the 4-way handshake to 04:f0:21:17:40:ba iwn0: received msg 3/4 of the 4-way handshake from 04:f0:21:17:40:ba iwn0: sending msg 4/4 of the 4-way handshake to 04:f0:21:17:40:ba iwn0: flags=208847 mtu 1500 lladdr 6c:88:14:36:27:b0 index 2 priority 4 llprio 3 groups: wlan egress media: IEEE802.11 autoselect mode 11n (HT-MCS2 mode 11n) status: active ieee80211: nwid TEST chan 1 bssid 04:f0:21:17:40:ba -20dBm wpakey XXX wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp Unfortunately the throughput is very low, only ~7 MBit. With mode 11g I get ~16 MBit. zarathustra:~# tcpbench apu01 elapsed_ms bytes mbps bwidth 1004 7482725.962 100.00% Conn: 1 Mbps:5.962 Peak Mbps:5.962 Avg Mbps:5.962 2007 8396646.697 100.00% Conn: 1 Mbps:6.697 Peak Mbps:6.697 Avg Mbps:6.697 3010 8182446.533 100.00% Conn: 1 Mbps:6.533 Peak Mbps:6.697 Avg Mbps:6.533 4013 9096367.255 100.00% Conn: 1 Mbps:7.255 Peak Mbps:7.255 Avg Mbps:7.255 5014 8568006.848 100.00% Conn: 1 Mbps:6.848 Peak Mbps:7.255 Avg Mbps:6.848 6015 8682246.946 100.00% Conn: 1 Mbps:6.946 Peak Mbps:7.255 Avg Mbps:6.946 7021 8725086.945 100.00% Conn: 1 Mbps:6.945 Peak Mbps:7.255 Avg Mbps:6.945 8023 8353806.670 100.00% Conn: 1 Mbps:6.670 Peak Mbps:7.255 Avg Mbps:6.670 9025 8482326.779 100.00% Conn: 1 Mbps:6.779 Peak Mbps:7.255 Avg Mbps:6.779 10028 8439486.731 100.00% Conn: 1 Mbps:6.731 Peak Mbps:7.255 Avg Mbps:6.731 11036 8310966.596 100.00% Conn: 1 Mbps:6.596 Peak Mbps:7.255 Avg Mbps:6.596 I'm now ready to test furhter. Many thanks again! Regards Uwe Am 09.01.2017 13:54:55, schrieb Stefan Sperling: > This diff adds 11n support to the athn(4) driver. > Requires -current net80211 code from today. > > Tested in hostap mode and client mode with: > athn0 at pci1 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16 > athn0: AR9280 rev 2 (2T2R), ROM rev 22, adddress xx:xx:xx:xx:xx:xx > > And in client mode with: > athn0 at uhub1 port 2 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev > 2.00/1.08 addr 2 > athn0: AR9271 rev 1 (1T1R), ROM rev 13, address xx:xx:xx:xx:xx:xx > > Hostap performance is not perfect yet but should be no worse than > 11a/b/g modes in the same environment. > > For Linux clients a fix for WME params is needed which I also posted to tech@. > > This diff does not modify the known-broken and disabled ar9003 code, > apart from making sure it still builds. > > I'm looking
Re: vmd: VMs with auto-configured L3 interfaces (call for testing)
Thanks Reyk for Your great work!
Tested and works like a charm. Made some tcpbench tests too and got ~180 MBit
between host and vm.
Regards Uwe
On 12 Apr 13:44, Reyk Floeter wrote:
> Hi,
>
> we want to make it easier to run NAT'ed and auto-configured VMs that
> don't need switches, L2, manual scripts, or any additional servers on
> the host. I wrote a new mode that just needs vmd, pf, and forwarding.
>
> I'm looking for feedback, testing, and responses on this list.
>
> vmd currently supports two modes to configure network interfaces:
> -i/interface: unconfigured tap(4) interfaces for static configuration.
> -n/switch: automatically adds tap(4) interfaces to bridge/switch interfaces.
>
> The attached diff adds a new mode for dynamic "NAT" interfaces:
> -L/local interface: auto-configure an L3 interface and run built-in DHCP.
>
> Setting it up is easy:
>
> 1. Enable forwarding:
>
> # sysctl net.inet.ip.forwarding=1
>
> 2. Add a NAT rule to pf.conf(5) and a redirection for DNS (or run unbound):
>
> pass out on egress received-on tap nat-to (egress:0)
> pass in on tap proto { tcp udp } to 100.64.0.0/10 port domain rdr-to
> 8.8.8.8
>
> 3. Now start a new VM with the -L option to add a "local" interface:
>
> # vmctl start foo -d foo.img -L -c
>
> vmd configures a /31 address on the tap(4) interface of the host and
> provides another IP in the same subnet via DHCP (BOOTP) to the VM.
> vmd runs an internal DHCP server that replies with IP, gateway, and
> DNS addresses to the VM - there is no need to run dhcpd! The built-in
> server only ever responds to the VM on the inside and cannot leak its
> DHCP responses to the outside.
>
> DHCPDISCOVER on vio0 - interval 1
> BOOTREPLY from 100.64.3.2 (fe:e1:bb:d1:b7:5e)
> bound to 100.64.3.3 -- renewal in 8000 seconds.
>
> Done.
>
> This also replaces the "dhcpd on vether0 on switch" approach for
> NAT'ed VMs on laptops that I recommended before. The switch concept
> itself will still be provided and improved for other use cases.
>
> The addresses are currently allocated from the RFC6598 100.64.0.0/10
> "IPv4 Prefix for Shared Address Space" to avoid collisions with
> RFC1918 addresses on the host. I will add a configuration option to
> change the default prefix later.
>
> The current algorithm to generate the IPs and /31 subnets from the
> prefix can be found in the vm_priv_addr() function below. The
> packet.c and dhcp.h code is copied from dhcrelay which got improved
> recently.
>
> Thoughts? OKs?
>
> Reyk
>
> Index: usr.sbin/vmd/Makefile
> ===
> RCS file: /cvs/src/usr.sbin/vmd/Makefile,v
> retrieving revision 1.13
> diff -u -p -u -p -r1.13 Makefile
> --- usr.sbin/vmd/Makefile 1 Mar 2017 18:00:50 - 1.13
> +++ usr.sbin/vmd/Makefile 12 Apr 2017 11:16:50 -
> @@ -5,7 +5,7 @@
> PROG=vmd
> SRCS=vmd.c control.c log.c priv.c proc.c config.c vmm.c
> SRCS+= vm.c loadfile_elf.c pci.c virtio.c i8259.c mc146818.c
> -SRCS+= ns8250.c i8253.c vmboot.c ufs.c disklabel.c
> +SRCS+= ns8250.c i8253.c vmboot.c ufs.c disklabel.c dhcp.c
> packet.c
> SRCS+= parse.y
>
> CFLAGS+= -Wall -I${.CURDIR}
> Index: usr.sbin/vmd/dhcp.c
> ===
> RCS file: usr.sbin/vmd/dhcp.c
> diff -N usr.sbin/vmd/dhcp.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ usr.sbin/vmd/dhcp.c 12 Apr 2017 11:16:50 -
> @@ -0,0 +1,163 @@
> +/* $OpenBSD$ */
> +
> +/*
> + * Copyright (c) 2017 Reyk Floeter
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include "proc.h"
> +#include "vmd.h"
> +#include "dhcp.h"
> +#include "virtio.h"
> +
> +static const uint8_t broadcast[6] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
> +
> +ssize_t
> +dhcp_request(struct vionet_dev *dev, char *buf, size_t buflen, char **obuf)
> +{
> + unsigned char *respbuf = NULL;
> + ssize_t offset, respbuflen = 0;
> + struct packet_ctxpc;
> + struct
Re: cwm: remove menu-ssh
rofi. It's in the ports.
Am 23. Januar 2020 15:01:54 GMT+00:00 schrieb Mikhail :
>Can you elaborate on tools for menu-ssh replacement?
>
>On Wed, Jan 22, 2020 at 11:16 PM Okan Demirmen
>wrote:
>>
>> Hi,
>>
>> I think we've (or at least I have) mused about this for a while; a
>> recent mail reminded me that this feature should go - a window
>manager
>> doesn't need to parse the ssh known_hosts file for a menu; there are
>> better tools for this.
>>
>> Remove menu-ssh.
>>
>> okay?
>>
>> Index: calmwm.h
>> ===
>> RCS file: /home/open/cvs/xenocara/app/cwm/calmwm.h,v
>> retrieving revision 1.372
>> diff -u -p -r1.372 calmwm.h
>> --- calmwm.h22 Jan 2020 19:58:35 - 1.372
>> +++ calmwm.h22 Jan 2020 20:09:13 -
>> @@ -304,7 +304,6 @@ struct conf {
>> int xrandr;
>> int xrandr_event_base;
>> char*conf_file;
>> - char*known_hosts;
>> char*wm_argv;
>> int debug;
>> };
>> @@ -517,7 +516,6 @@ void kbfunc_menu_cmd(void
>*, struct c
>> voidkbfunc_menu_group(void *, struct cargs *);
>> voidkbfunc_menu_wm(void *, struct cargs *);
>> voidkbfunc_menu_exec(void *, struct cargs *);
>> -voidkbfunc_menu_ssh(void *, struct cargs *);
>> voidkbfunc_client_menu_label(void *, struct
>cargs *);
>> voidkbfunc_exec_cmd(void *, struct cargs *);
>> voidkbfunc_exec_lock(void *, struct cargs *);
>> Index: conf.c
>> ===
>> RCS file: /home/open/cvs/xenocara/app/cwm/conf.c,v
>> retrieving revision 1.249
>> diff -u -p -r1.249 conf.c
>> --- conf.c 7 Mar 2019 12:54:21 - 1.249
>> +++ conf.c 22 Jan 2020 20:09:24 -
>> @@ -179,7 +179,6 @@ static const struct {
>>
>> { FUNC_SC(menu-cmd, menu_cmd, 0) },
>> { FUNC_SC(menu-group, menu_group, 0) },
>> - { FUNC_SC(menu-ssh, menu_ssh, 0) },
>> { FUNC_SC(menu-window, menu_client, CWM_MENU_WINDOW_ALL) },
>> { FUNC_SC(menu-window-hidden, menu_client,
>CWM_MENU_WINDOW_HIDDEN) },
>> { FUNC_SC(menu-exec, menu_exec, 0) },
>> @@ -210,7 +209,6 @@ static const struct {
>> { "CM-Delete", "lock" },
>> { "M-question", "menu-exec" },
>> { "CM-w", "menu-exec-wm" },
>> - { "M-period", "menu-ssh" },
>> { "M-Return", "window-hide" },
>> { "M-Down", "window-lower" },
>> { "M-Up", "window-raise" },
>> @@ -316,7 +314,6 @@ conf_init(struct conf *c)
>> home = "/";
>> }
>> xasprintf(>conf_file, "%s/%s", home, ".cwmrc");
>> - xasprintf(>known_hosts, "%s/%s", home,
>".ssh/known_hosts");
>> }
>>
>> void
>> @@ -363,7 +360,6 @@ conf_clear(struct conf *c)
>> free(c->color[i]);
>>
>> free(c->conf_file);
>> - free(c->known_hosts);
>> free(c->font);
>> free(c->wmname);
>> }
>> Index: cwm.1
>> ===
>> RCS file: /home/open/cvs/xenocara/app/cwm/cwm.1,v
>> retrieving revision 1.65
>> diff -u -p -r1.65 cwm.1
>> --- cwm.1 9 Jul 2019 21:38:44 - 1.65
>> +++ cwm.1 22 Jan 2020 20:08:19 -
>> @@ -140,15 +140,6 @@ Resize window by a large amount; see
>> Spawn
>> .Dq exec program
>> dialog.
>> -.It Ic M-period
>> -Spawn
>> -.Dq ssh to
>> -dialog.
>> -This parses
>> -.Pa $HOME/.ssh/known_hosts
>> -to provide host auto-completion.
>> -.Xr ssh 1
>> -will be executed via the configured terminal emulator.
>> .It Ic CM-w
>> Spawn
>> .Dq exec WindowManager
>> Index: cwmrc.5
>> ===
>> RCS file: /home/open/cvs/xenocara/app/cwm/cwmrc.5,v
>> retrieving revision 1.73
>> diff -u -p -r1.73 cwmrc.5
>> --- cwmrc.5 2 Jul 2019 23:37:47 - 1.73
>> +++ cwmrc.5 22 Jan 2020 20:07:57 -
>> @@ -280,10 +280,6 @@ menu.
>> Launch
>> .Dq exec WindowManager
>> menu.
>> -.It menu-ssh
>> -Launch
>> -.Dq ssh
>> -menu.
>> .It group-toggle-[n]
>> Toggle visibility of group n, where n is 1-9.
>> .It group-only-[n]
>> Index: kbfunc.c
>> ===
>> RCS file: /home/open/cvs/xenocara/app/cwm/kbfunc.c,v
>> retrieving revision 1.167
>> diff -u -p -r1.167 kbfunc.c
>> --- kbfunc.c21 Jan 2020 15:50:03 - 1.167
>> +++ kbfunc.c22 Jan 2020 20:09:03 -
>> @@ -647,72 +647,6 @@ out:
>> }
>>
>> void
>> -kbfunc_menu_ssh(void *ctx, struct cargs *cargs)
>> -{
>> - struct screen_ctx *sc = ctx;
>> - struct cmd_ctx *cmd;
>> - struct menu *mi;
>> - struct menu_qmenuq;
>>
PATCH: configurable tiling in cwm(1)
Hello @tech,
with this diff https://marc.info/?l=openbsd-tech=149192690925713=2 the
behaviour of cwm changed so vtile and htile always use 50% of the screen.
This is a reasonable default but sometimes I want to have the master windows
be bigger.
Inspired by this patch https://marc.info/?l=openbsd-tech=154887686615696=2
I suggest the following diff.
This adds two new config options "htile percent" and "vtile percent" which
define how much of the screen the current windows should occupy as the master
window. If set to "0" then the old behaviour is restored where the current
vertical or horizontal size of the window defines the size of the master
window. If unset the current behaviour is unchaged that means the master
windows uses half of the screen size.
For example in .cwmrc:
htile 66
vtile 0
For window-htile the master window will occupy 66% of the screen high or for
window-vtile the current window width defines the screen width of the master
window.
Any thoughts?
Regards Uwe
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.374
diff -u -p -r1.374 calmwm.h
--- calmwm.h24 Mar 2020 14:47:29 - 1.374
+++ calmwm.h27 Mar 2020 00:09:43 -
@@ -291,6 +291,8 @@ struct conf {
int bwidth;
int mamount;
int snapdist;
+ int htile;
+ int vtile;
struct gap gap;
char*color[CWM_COLOR_NITEMS];
char*font;
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.262
diff -u -p -r1.262 client.c
--- client.c24 Mar 2020 14:47:29 - 1.262
+++ client.c27 Mar 2020 00:09:43 -
@@ -940,7 +940,8 @@ client_htile(struct client_ctx *cc)
cc->geom.x = area.x;
cc->geom.y = area.y;
cc->geom.w = area.w - (cc->bwidth * 2);
- cc->geom.h = (area.h - (cc->bwidth * 2)) / 2;
+ if (Conf.htile > 0)
+ cc->geom.h = ((area.h - (cc->bwidth * 2)) * Conf.htile) / 100;
client_resize(cc, 1);
client_ptr_warp(cc);
@@ -1007,7 +1008,8 @@ client_vtile(struct client_ctx *cc)
cc->flags &= ~CLIENT_VMAXIMIZED;
cc->geom.x = area.x;
cc->geom.y = area.y;
- cc->geom.w = (area.w - (cc->bwidth * 2)) / 2;
+ if (Conf.vtile > 0)
+ cc->geom.w = ((area.w - (cc->bwidth * 2)) * Conf.vtile) / 100;
cc->geom.h = area.h - (cc->bwidth * 2);
client_resize(cc, 1);
client_ptr_warp(cc);
Index: conf.c
===
RCS file: /cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.251
diff -u -p -r1.251 conf.c
--- conf.c 27 Feb 2020 14:56:39 - 1.251
+++ conf.c 27 Mar 2020 00:09:43 -
@@ -281,6 +281,8 @@ conf_init(struct conf *c)
c->stickygroups = 0;
c->bwidth = 1;
c->mamount = 1;
+ c->htile = 50;
+ c->vtile = 50;
c->snapdist = 0;
c->ngroups = 0;
c->nameqlen = 5;
Index: cwmrc.5
===
RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.75
diff -u -p -r1.75 cwmrc.5
--- cwmrc.5 13 Mar 2020 20:50:07 - 1.75
+++ cwmrc.5 27 Mar 2020 00:09:43 -
@@ -183,6 +183,11 @@ This
can be used for applications such as
.Xr xclock 1 ,
where the user may wish to remain visible.
+.It Ic htile Ar percent
+The amount of the screen the master window should be resized to when
+.Ic window-htile
+is called. If set to 0 then the size is the vertical size of current current
+window.
.It Ic ignore Ar windowname
Ignore, and do not warp to, windows with the name
.Ar windowname
@@ -216,6 +221,11 @@ A special
keyword
.Dq all
can be used to unbind all buttons.
+.It Ic vtile Ar percent
+The amount of the screen the master window should be resized to when
+.Ic window-vtile
+is called. If set to 0 then the size is the horizontal size of the current
+window.
.It Ic wm Ar name path
Every
.Ar name
@@ -303,11 +313,15 @@ Vertically maximize current window (gap
Horizontally maximize current window (gap + border honored).
.It window-htile
Current window is placed at the top of the screen, maximized
-horizontally and resized to half of the vertical screen space.
+horizontally and resized to
+.Ar htile
+(default half) of the vertical screen space.
Other windows in its group share remaining screen space.
.It window-vtile
Current window is placed on the left of the screen, maximized vertically
-and resized to half of the horizontal screen space.
+and resized to
+.Ar vtile
+(default half) of the horizontal screen space.
Other windows in its group share remaining screen space.
.It window-move
Move current window.
Index: parse.y
Re: ksh "clear-screen" for vi mode
On 20 Sep 05:39, Theo Buehler wrote: > On Sat, Sep 19, 2020 at 03:50:52PM -0600, Todd C. Miller wrote: > > The vi and emacs edit code are completely separate. Try the following > > diff. I had to rename a few things to avoid clashing with ncurses.h. > > This works and appears to match bash's behavior in that it only works > in normal mode. I would slightly prefer to also add the command to the > nonstandard vi commands in the switch around line 650 to have it > available from insert mode as well. This would match zsh's behavior. That would be really great. > > Either way, ok tb >
Re: ksh "clear-screen" for vi mode
On 20 Sep 06:14, Todd C. Miller wrote:
> On Sun, 20 Sep 2020 05:39:02 +0200, Theo Buehler wrote:
>
> > This works and appears to match bash's behavior in that it only works
> > in normal mode. I would slightly prefer to also add the command to the
> > nonstandard vi commands in the switch around line 650 to have it
> > available from insert mode as well. This would match zsh's behavior.
>
> Sure, I was comparing it to bash so didn't support insert mode.
> I agree that it's more useful to have it available there too.
>
> - todd
>
> Index: bin/ksh/ksh.1
> ===
> RCS file: /cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.209
> diff -u -p -u -r1.209 ksh.1
> --- bin/ksh/ksh.1 7 Jul 2020 10:33:58 - 1.209
> +++ bin/ksh/ksh.1 20 Sep 2020 12:12:01 -
> @@ -5053,6 +5053,12 @@ Erases previous character.
> .It ^J | ^M
> End of line.
> The current line is read, parsed, and executed by the shell.
> +.It ^L
> +Clear screen.
> +The screen is cleared if the
> +.Ev TERM
> +parameter is set and the terminal supports clearing the screen.
> +The prompt string and the current line are redrawn.
> .It ^V
> Literal next.
> The next character typed is not treated specially (can be used
> Index: bin/ksh/vi.c
> ===
> RCS file: /cvs/src/bin/ksh/vi.c,v
> retrieving revision 1.56
> diff -u -p -u -r1.56 vi.c
> --- bin/ksh/vi.c 15 Mar 2018 16:51:29 - 1.56
> +++ bin/ksh/vi.c 20 Sep 2020 12:02:38 -
> @@ -14,12 +14,14 @@
> #include
> #include
> #include
> +#ifndef SMALL
> +# include
> +# include
> +#endif
>
> #include "sh.h"
> #include "edit.h"
>
> -#define CTRL(c) (c & 0x1f)
> -
> struct edstate {
> char*cbuf; /* main buffer to build the command line */
> int cbufsize; /* number of bytes allocated for cbuf */
> @@ -52,8 +54,9 @@ static int Backword(int);
> static int Endword(int);
> static int grabhist(int, int);
> static int grabsearch(int, int, int, char *);
> +static void do_clear_screen(void);
> static void redraw_line(int);
> -static void refresh(int);
> +static void refresh_line(int);
> static int outofwin(void);
> static void rewindow(void);
> static int newcol(int, int);
> @@ -271,9 +274,9 @@ vi_hook(int ch)
> case 0:
> if (state == VLIT) {
> es->cursor--;
> - refresh(0);
> + refresh_line(0);
> } else
> - refresh(insert != 0);
> + refresh_line(insert != 0);
> break;
> case 1:
> return 1;
> @@ -298,7 +301,7 @@ vi_hook(int ch)
> return -1;
> } else if (putbuf("?", 1, 0) != 0)
> return -1;
> - refresh(0);
> + refresh_line(0);
> }
> }
> }
> @@ -310,7 +313,7 @@ vi_hook(int ch)
> vi_error();
> } else
> es->cbuf[es->cursor++] = ch;
> - refresh(1);
> + refresh_line(1);
> state = VNORMAL;
> break;
>
> @@ -375,7 +378,7 @@ vi_hook(int ch)
> if (!srchpat[0]) {
> vi_error();
> state = VNORMAL;
> - refresh(0);
> + refresh_line(0);
> return 0;
> }
> } else {
> @@ -392,17 +395,17 @@ vi_hook(int ch)
> } while (srchlen > 0 &&
> isu8cont(locpat[srchlen]));
> es->cursor = es->linelen;
> - refresh(0);
> + refresh_line(0);
> return 0;
> }
> restore_cbuf();
> state = VNORMAL;
> - refresh(0);
> + refresh_line(0);
> } else if (ch == edchars.kill) {
> srchlen = 0;
> es->linelen = 1;
> es->cursor = 1;
> - refresh(0);
> + refresh_line(0);
> return 0;
> } else if (ch == edchars.werase) {
> struct edstate new_es, *save_es;
> @@ -421,7 +424,7 @@ vi_hook(int ch)
Re: 11n Tx aggregation for iwm(4)
Woahhh, was also trying 5GHz (and tcpbench against one of our bsd servers in DMZ): 469651560 bytes sent over 85.291 seconds bandwidth min/avg/max/std-dev = 3.475/43.927/87.071/29.809 Mbps 6 new output block ack agreements 0 output block ack agreements timed out (Tomorrow @work I will test against our new APs. My AP @home is a Technicolor MediaAccess TG789vac). mbk Uwe On 29 Jun 09:48, Uwe Werler wrote: > Hi Stefan, > > for me the patch works in mode 11n: > > before (OpenBSD 6.7-current (GENERIC.MP) #304: Fri Jun 26 02:08:50 MDT 2020) > bandwidth min/avg/max/std-dev = 2.354/12.319/15.391/3.850 Mbps > > with patch (OpenBSD 6.7-current (GENERIC.MP) #0: Mon Jun 29 09:35:24 GMT 2020) > bandwidth min/avg/max/std-dev = 12.174/31.411/57.746/15.154 Mbps > > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi > iwm0: hw rev 0x230, fw ver 34.0.1, address 60:f6:77:bc:3a:04 > > (mode 11g: bandwidth min/avg/max/std-dev = 0.620/0.844/1.101/0.153 Mbps) > > mbk Uwe > > > On 26 Jun 14:45, Stefan Sperling wrote: > > This patch adds support for 11n Tx aggregation to iwm(4). > > > > Please help with testing if you can by running the patch and using wifi > > as usual. Nothing should change, except that Tx speed may potentially > > improve. If you have time to run before/after performance measurements with > > tcpbench or such, that would be nice. But it's not required for testing. > > > > If Tx aggregation is active then netstat will show a non-zero output block > > ack > > agreement counter: > > > > $ netstat -W iwm0 | grep 'output block' > > 3 new output block ack agreements > > 0 output block ack agreements timed out > > > > It would be great to get at least one test for all the chipsets the driver > > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > > The behaviour of the access point also matters a great deal. It won't > > hurt to test the same chipset against several different access points. > > > > I have tested this version on 8265 only so far. I've run older revisions > > of this patch on 7265 so I'm confident that this chip will work, too. > > So far, the APs I have tested against are athn(4) in 11a mode and in 11n > > mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels. > > > > diff refs/heads/master refs/heads/txagg > > blob - 3a75d07a60a7eb4c66540474e47aeffd7a85250a > > blob + 853bdd1290ad509f5fce7b5bf20550f458a2b460 > > --- sys/dev/pci/if_iwm.c > > +++ sys/dev/pci/if_iwm.c > > @@ -144,6 +144,8 @@ > > #include > > #include > > #include > > +#include /* for SEQ_LT */ > > +#undef DPRINTF /* defined in ieee80211_priv.h */ > > > > #define DEVNAME(_s)((_s)->sc_dev.dv_xname) > > > > @@ -299,7 +301,8 @@ int iwm_nic_rx_mq_init(struct iwm_softc *); > > intiwm_nic_tx_init(struct iwm_softc *); > > intiwm_nic_init(struct iwm_softc *); > > intiwm_enable_ac_txq(struct iwm_softc *, int, int); > > -intiwm_enable_txq(struct iwm_softc *, int, int, int); > > +intiwm_enable_txq(struct iwm_softc *, int, int, int, int, uint8_t, > > + uint16_t); > > intiwm_post_alive(struct iwm_softc *); > > struct iwm_phy_db_entry *iwm_phy_db_get_section(struct iwm_softc *, > > uint16_t, > > uint16_t); > > @@ -334,12 +337,12 @@ void iwm_ampdu_rx_stop(struct ieee80211com *, struct > > i > > uint8_t); > > void iwm_sta_rx_agg(struct iwm_softc *, struct ieee80211_node *, > > uint8_t, > > uint16_t, uint16_t, int); > > -#ifdef notyet > > +void iwm_sta_tx_agg(struct iwm_softc *, struct ieee80211_node *, > > uint8_t, > > + uint16_t, uint16_t, int); > > intiwm_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node > > *, > > uint8_t); > > void iwm_ampdu_tx_stop(struct ieee80211com *, struct ieee80211_node > > *, > > uint8_t); > > -#endif > > void iwm_ba_task(void *); > > > > intiwm_parse_nvm_data(struct iwm_softc *, const uint16_t *, > > @@ -372,14 +375,25 @@ int iwm_rxmq_get_signal_strength(struct iwm_softc > > *, s > > void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *, > > struct iwm_rx_data *); > > intiwm_get_noise(const struct iwm_statistics_rx_non_phy *); > > +void iwm_txq_advance(struct iwm_softc *, struct iwm_tx_ring *, int); > > +void iwm_ampdu_tx_done(struct iwm_softc
Re: 11n Tx aggregation for iwm(4)
Hi Stefan, for me the patch works in mode 11n: before (OpenBSD 6.7-current (GENERIC.MP) #304: Fri Jun 26 02:08:50 MDT 2020) bandwidth min/avg/max/std-dev = 2.354/12.319/15.391/3.850 Mbps with patch (OpenBSD 6.7-current (GENERIC.MP) #0: Mon Jun 29 09:35:24 GMT 2020) bandwidth min/avg/max/std-dev = 12.174/31.411/57.746/15.154 Mbps iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi iwm0: hw rev 0x230, fw ver 34.0.1, address 60:f6:77:bc:3a:04 (mode 11g: bandwidth min/avg/max/std-dev = 0.620/0.844/1.101/0.153 Mbps) mbk Uwe On 26 Jun 14:45, Stefan Sperling wrote: > This patch adds support for 11n Tx aggregation to iwm(4). > > Please help with testing if you can by running the patch and using wifi > as usual. Nothing should change, except that Tx speed may potentially > improve. If you have time to run before/after performance measurements with > tcpbench or such, that would be nice. But it's not required for testing. > > If Tx aggregation is active then netstat will show a non-zero output block ack > agreement counter: > > $ netstat -W iwm0 | grep 'output block' > 3 new output block ack agreements > 0 output block ack agreements timed out > > It would be great to get at least one test for all the chipsets the driver > supports: 7260, 7265, 3160, 3165, 3168, 8260, 8265, 9260, 9560 > The behaviour of the access point also matters a great deal. It won't > hurt to test the same chipset against several different access points. > > I have tested this version on 8265 only so far. I've run older revisions > of this patch on 7265 so I'm confident that this chip will work, too. > So far, the APs I have tested against are athn(4) in 11a mode and in 11n > mode with the 'nomimo' nwflag, and a Sagemcom 11ac AP. All on 5Ghz channels. > > diff refs/heads/master refs/heads/txagg > blob - 3a75d07a60a7eb4c66540474e47aeffd7a85250a > blob + 853bdd1290ad509f5fce7b5bf20550f458a2b460 > --- sys/dev/pci/if_iwm.c > +++ sys/dev/pci/if_iwm.c > @@ -144,6 +144,8 @@ > #include > #include > #include > +#include /* for SEQ_LT */ > +#undef DPRINTF /* defined in ieee80211_priv.h */ > > #define DEVNAME(_s) ((_s)->sc_dev.dv_xname) > > @@ -299,7 +301,8 @@ int iwm_nic_rx_mq_init(struct iwm_softc *); > int iwm_nic_tx_init(struct iwm_softc *); > int iwm_nic_init(struct iwm_softc *); > int iwm_enable_ac_txq(struct iwm_softc *, int, int); > -int iwm_enable_txq(struct iwm_softc *, int, int, int); > +int iwm_enable_txq(struct iwm_softc *, int, int, int, int, uint8_t, > + uint16_t); > int iwm_post_alive(struct iwm_softc *); > struct iwm_phy_db_entry *iwm_phy_db_get_section(struct iwm_softc *, uint16_t, > uint16_t); > @@ -334,12 +337,12 @@ voidiwm_ampdu_rx_stop(struct ieee80211com *, struct > i > uint8_t); > void iwm_sta_rx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t, > uint16_t, uint16_t, int); > -#ifdef notyet > +void iwm_sta_tx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t, > + uint16_t, uint16_t, int); > int iwm_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node *, > uint8_t); > void iwm_ampdu_tx_stop(struct ieee80211com *, struct ieee80211_node *, > uint8_t); > -#endif > void iwm_ba_task(void *); > > int iwm_parse_nvm_data(struct iwm_softc *, const uint16_t *, > @@ -372,14 +375,25 @@ int iwm_rxmq_get_signal_strength(struct iwm_softc > *, s > void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *, > struct iwm_rx_data *); > int iwm_get_noise(const struct iwm_statistics_rx_non_phy *); > +void iwm_txq_advance(struct iwm_softc *, struct iwm_tx_ring *, int); > +void iwm_ampdu_tx_done(struct iwm_softc *, struct iwm_cmd_header *, > + struct iwm_node *, struct iwm_tx_ring *, uint32_t, uint8_t, > + uint8_t, uint16_t, int, struct iwm_agg_tx_status *); > int iwm_ccmp_decap(struct iwm_softc *, struct mbuf *, > struct ieee80211_node *); > void iwm_rx_frame(struct iwm_softc *, struct mbuf *, int, uint32_t, int, int, > uint32_t, struct ieee80211_rxinfo *, struct mbuf_list *); > -void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *, > - struct iwm_node *, int, int); > +void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_tx_resp *, > + struct iwm_node *, int, int, int); > +void iwm_txd_done(struct iwm_softc *, struct iwm_tx_data *); > void iwm_rx_tx_cmd(struct iwm_softc *, struct iwm_rx_packet *, > struct iwm_rx_data *); > +void iwm_clear_oactive(struct iwm_softc *, struct iwm_tx_ring *); > +void iwm_mira_choose(struct iwm_softc *, struct ieee80211_node *); > +void iwm_ampdu_rate_control(struct iwm_softc *, struct ieee80211_node *, > + struct iwm_tx_ring *, int, uint16_t, uint16_t); > +void iwm_rx_ba(struct iwm_softc *, struct iwm_rx_packet *, > + struct iwm_rx_data *); > void iwm_rx_bmiss(struct iwm_softc *, struct iwm_rx_packet *, >
Re: dhcpleased(8): implement classless static routes option
On 13 Jun 19:45, Florian Obser wrote: > > Implement "classless static routes" dhcp option. > > For this we need to be able to handle multiple routes being sent from > the engine to the main process as well as to the control tool. This also > lets us handle multiple default routes in the "routers" option for free. > > The configuration of the various cases (default route, directly > connected routes, non-default route via a gateway) was inspired by > dhclient's set_routes(). > > This also handles the case of the gateway of the default route being > outside of the configured address prefix for which I had sent a diff to > tech@ previously. > > Tests, OKs? > Hi Florian, till now it works for me. Will test tomorrow at work where I sometimes had problems because somehow the default route got lost at the ure(4) interface after some time. Regards Uwe -- wq: ~uw
Re: iwm(4) A-MSDU support
On 29 Mar 19:27, Stefan Sperling wrote: > This patch attempts to add support for receiving A-MSDUs to iwm(4). > If you are using iwm(4) then please run with this patch and let me > know if it causes regressions. Thanks! > > ACHTUNG: This patch breaks iwx(4)! Don't use it there! For this reason, > the patch can neither be committed nor be put into snapshots!!! > > Our net80211 stack de-aggregates A-MSDUs in software. This works fine with > iwm 7k and 8k devices. However, iwm 9k devices de-aggregate A-MSDUs in > hardware and net80211 is currently unable to handle this. > > Our current iwm 9k code only works because long ago I disabled reception > of A-MSDUs for all devices. Unfortunately, the only way to get A-MSDUs > working on 9k hardware is to add a bunch of driver-specific code which > handles de-aggregation. Otherwise, net80211 will drop frames which appear > to arrive out of order, or appear as duplicates even though they were > simply part of the same A-MSDU and thus share a sequence number. > The driver can re-order frames correctly based on information provided > by firmware. I'd rather implement this than letting these devices miss > out on A-MSDUs because the Rx speed advantage can be significant, around > 80/90 Mbps (but this will very much depend on the AP). > > If these A-* acronyms don't make sense and you'd like to know more, here > is a fairly good explanation: https://mrncciew.com/2013/04/11/a-mpdu-a-msdu/ > Note that we care about the nested case, which is also mentioned in this > article but not explained in detail. It's simply an A-MSDU stashed inside > an A-MPDU. If an AP can do 11AC, then it should support this. > > iwx(4) hardware has the same problem. > If this patch works fine on iwm(4) then I can port the changes to iwx(4), > do another round of testing, and eventually commit to both drivers at > the same time. > > Some of the changes below are based on code from the Linux iwlwifi driver. > I am not entirely happy with some of its style. But the code should be in > good enough shape to be tested. > Hi Stefan, I tested the patch with my: iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi iwm0: hw rev 0x230, fw ver 34.0.1, address xx:xx:xx:xx:xx:xx against my Technicolor MediaAccess TG789vac. 5GHz: Down: Conn: 1 Mbps: 105.479 Peak Mbps: 107.955 Avg Mbps: 105.479 25076 13282504 106.366 100.00% Up: Conn: 1 Mbps: 28.056 Peak Mbps: 28.096 Avg Mbps: 28.056 17004 3483888 27.899 100.00% 2GHz: Down: Conn: 1 Mbps: 87.640 Peak Mbps: 87.965 Avg Mbps: 87.640 14041 11096024 88.680 100.00% UP: Conn: 1 Mbps: 22.786 Peak Mbps: 22.844 Avg Mbps: 22.786 9003 3176912 25.441 100.00% Thanks for your hard work! -- wq: ~uw
Re: athn(4): switch Tx rate control to RA
On 23 Mar 18:01, Stefan Sperling wrote: > This switches athn(4) to the new RA Tx rate adaptation module. > Tests on athn(4) PCI devices are welcome. > USB devices don't need to be tested in this case Tx rate adaptation > is taken care of by firmware. > > I could only test on AR9285 so far, but the result looks promising. > Hi Stefan, I tested between my laptop with iwm: iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi iwm0: hw rev 0x230, fw ver 34.0.1, address xx:xx:xx:xx:xx:xx:xx and my APU1 with: athn0 at pci4 dev 0 function 0 "Atheros AR5418" rev 0x01: apic 2 int 19 athn0: MAC AR5418 rev 2, RF AR5133 (2T3R), ROM rev 8, address xx:xx:xx:xx:xx:xx:xx With patch laptop -> apu: Conn: 1 Mbps: 19.021 Peak Mbps: 19.021 Avg Mbps: 19.021 30042287840 18.284 100.00% With patch apu -> laptop: Conn: 1 Mbps: 27.987 Peak Mbps: 30.027 Avg Mbps: 27.987 50033528776 28.202 100.00% Without patch laptop -> apu: Conn: 1 Mbps:7.900 Peak Mbps: 13.750 Avg Mbps:7.900 7015 9281687.388 100.00% Without patch apu -> laptop: Conn: 1 Mbps:4.247 Peak Mbps:7.231 Avg Mbps:4.247 6055 4898043.868 100.00% So notable performance improvements! Thank you very much for your hard work! -- wq: ~uw
Re: net80211: new Tx rate adaptation module (iwn + iwm)
On 09 Mar 14:48, Stefan Sperling wrote: > This implements a new rate adaptation module for net80211, called "RA", > which resulted from a long discussion and exchanges of various diffs > between Christian Ehrhardt and myself, targeting problems with MiRA. > > Tests with any of the various iwn(4) and iwm(4) devices are very welcome. > > The iwn and iwm drivers get support in this patch. > No other drivers are affected. iwx(4) users in particular can ignore > this whole topic since Tx rate selection is handled in iwx firmware. > > If this works out well I will convert additional drivers later. > The next target would be athn(4). > Hi Stefan, this patch works quite well for me and increased also throughput notable. I get now upstream 24.674 Avg and downstream 85.854 Avg - absolutely great. Thanks for you work! -- OpenBSD 6.9-beta (GENERIC.MP) #2: Thu Mar 11 10:32:15 GMT 2021 uwerler@FT-51MV3Z2:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16965005312 (16179MB) avail mem = 16435466240 (15674MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xe (116 entries) bios0: vendor Dell Inc. version "1.5.4" date 10/03/2019 bios0: Dell Inc. Latitude 7400 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET SSDT SSDT UEFI LPIT WSMT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC DMAR SSDT NHLT BGRT TPM2 ASF! acpi0: wakeup devices RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz, 15866.35 MHz, 06-8e-0c cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz, 3791.17 MHz, 06-8e-0c cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz, 3791.17 MHz, 06-8e-0c cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz, 3791.17 MHz, 06-8e-0c cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz, 3791.17 MHz, 06-8e-0c cpu4:
Re: iwm(4) A-MSDU support
Hi Stefan,
just tested today with my other laptop (Dell Latitude 7400):
iwm0 at pci0 dev 20 function 3 "Intel Dual Band Wireless AC 9560" rev 0x30,
msix iwm0: hw rev 0x310, fw ver 34.3125811985.0, address 60:f2:62:06:61:f2
...against an Ubiquity UniFi AC AP Pro.
Before patch:
Up:
Conn: 1 Mbps: 24.859 Peak Mbps: 25.577 Avg Mbps: 24.859 8017
2932200 23.271 100.00%
Down:
Conn: 1 Mbps: 81.806 Peak Mbps: 87.146 Avg Mbps: 81.806
120168855968 70.848 100.00%
After patch:
Up:
Conn: 1 Mbps: 33.617 Peak Mbps: 33.617 Avg Mbps: 33.617
130763963176 31.674 100.00%
Down:
Conn: 1 Mbps: 87.707 Peak Mbps: 87.707 Avg Mbps: 87.707
8018 10584880 84.594 100.00%
Thanks for your work!
Uwe
> diff refs/heads/master refs/heads/amsdu
> blob - 00bf20b37ed33a652232885349c2f3dfa0d666d3
> blob + c353ee60473b7cfd237e1889e4a4b9235cb8bdc7
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -144,6 +144,8 @@
> #include
> #include
> #include
> +#include /* for SEQ_LT */
> +#undef DPRINTF /* defined in ieee80211_priv.h */
>
> #define DEVNAME(_s) ((_s)->sc_dev.dv_xname)
>
> @@ -328,12 +330,17 @@ int iwm_mimo_enabled(struct iwm_softc *);
> void iwm_setup_ht_rates(struct iwm_softc *);
> void iwm_htprot_task(void *);
> void iwm_update_htprot(struct ieee80211com *, struct ieee80211_node *);
> +void iwm_init_reorder_buffer(struct iwm_reorder_buffer *, uint16_t,
> + uint16_t);
> +void iwm_clear_reorder_buffer(struct iwm_softc *, struct iwm_rxba_data *);
> int iwm_ampdu_rx_start(struct ieee80211com *, struct ieee80211_node *,
> uint8_t);
> void iwm_ampdu_rx_stop(struct ieee80211com *, struct ieee80211_node *,
> uint8_t);
> +void iwm_rx_ba_session_expired(void *);
> +void iwm_reorder_timer_expired(void *);
> void iwm_sta_rx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t,
> - uint16_t, uint16_t, int);
> + uint16_t, uint16_t, int, int);
> #ifdef notyet
> int iwm_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node *,
> uint8_t);
> @@ -372,8 +379,10 @@ int iwm_rxmq_get_signal_strength(struct iwm_softc
> *, s
> void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *,
> struct iwm_rx_data *);
> int iwm_get_noise(const struct iwm_statistics_rx_non_phy *);
> +int iwm_rx_hwdecrypt(struct iwm_softc *, struct mbuf *, uint32_t,
> + struct ieee80211_rxinfo *);
> int iwm_ccmp_decap(struct iwm_softc *, struct mbuf *,
> - struct ieee80211_node *);
> + struct ieee80211_node *, struct ieee80211_rxinfo *);
> void iwm_rx_frame(struct iwm_softc *, struct mbuf *, int, uint32_t, int, int,
> uint32_t, struct ieee80211_rxinfo *, struct mbuf_list *);
> void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *,
> @@ -490,6 +499,20 @@ void iwm_nic_umac_error(struct iwm_softc *);
> #endif
> void iwm_rx_mpdu(struct iwm_softc *, struct mbuf *, void *, size_t,
> struct mbuf_list *);
> +void iwm_flip_address(uint8_t *);
> +int iwm_detect_duplicate(struct iwm_softc *, struct mbuf *,
> + struct iwm_rx_mpdu_desc *, struct ieee80211_rxinfo *);
> +int iwm_is_sn_less(uint16_t, uint16_t, uint16_t);
> +void iwm_release_frames(struct iwm_softc *, struct ieee80211_node *,
> + struct iwm_rxba_data *, struct iwm_reorder_buffer *, uint16_t,
> + struct mbuf_list *);
> +int iwm_oldsn_workaround(struct iwm_softc *, struct ieee80211_node *,
> + int, struct iwm_reorder_buffer *, uint32_t, uint32_t);
> +int iwm_rx_reorder(struct iwm_softc *, struct mbuf *, int,
> + struct iwm_rx_mpdu_desc *, int, int, uint32_t,
> + struct ieee80211_rxinfo *, struct mbuf_list *);
> +void iwm_rx_mpdu_mq(struct iwm_softc *, struct mbuf *, void *, size_t,
> + struct mbuf_list *);
> int iwm_rx_pkt_valid(struct iwm_rx_packet *);
> void iwm_rx_pkt(struct iwm_softc *, struct iwm_rx_data *,
> struct mbuf_list *);
> @@ -2902,11 +2925,139 @@ iwm_setup_ht_rates(struct iwm_softc *sc)
> ic->ic_sup_mcs[1] = 0xff; /* MCS 8-15 */
> }
>
> +void
> +iwm_init_reorder_buffer(struct iwm_reorder_buffer *reorder_buf,
> +uint16_t ssn, uint16_t buf_size)
> +{
> + reorder_buf->head_sn = ssn;
> + reorder_buf->num_stored = 0;
> + reorder_buf->buf_size = buf_size;
> + reorder_buf->last_amsdu = 0;
> + reorder_buf->last_sub_index = 0;
> + reorder_buf->removed = 0;
> + reorder_buf->valid = 0;
> + reorder_buf->consec_oldsn_drops = 0;
> + reorder_buf->consec_oldsn_ampdu_gp2 = 0;
> + reorder_buf->consec_oldsn_prev_drop = 0;
> +}
> +
> +void
> +iwm_clear_reorder_buffer(struct iwm_softc *sc, struct iwm_rxba_data *rxba)
> +{
> + int i;
> + struct iwm_reorder_buffer *reorder_buf = >reorder_buf;
> + struct iwm_reorder_buf_entry *entry;
> +
> + for (i = 0; i <
Re: iwm/iwx suspend/resume improvement
On 02 Sep 15:26, Stefan Sperling wrote: > This patch fixes suspend/resume with an AX201 device for gnezdo@. > Tests on any iwm/iwx device would be apreciated. > > Before testing this make sure to update your tree to -current which contains > a very recent fix for a double-free in the resume path of the iwx driver. > You won't have great results testing this patch without the double-free > fix in place. > Tested several times with: iwm0 at pci0 dev 20 function 3 "Intel AC 9560" rev 0x30, msix iwm0: hw rev 0x310, fw ver 46.6b541b68.0, address 60:f2:62:06:61:f2 and survives suspends and resumes without any problems.
Re: ksh in vi-mode and line editing
Hi Klemens,
On 19 Oct 08:49, Klemens Nanni wrote:
> On Wed, Aug 31, 2022 at 05:16:27PM +0200, Uwe Werler wrote:
> > Hi folks,
> >
> > I'm just wondering why there's a test for an empty line and args to start
> > the
> > editor for line editing. In bash one can start vi immediately with an empty
> > line by ^v. Might be there's another reason I don't understand for this
> > test?
>
> Logically, this should probably be allowed, but reading ksh(1)
>
> [n]vEdit line n using the vi(1) editor; if n is not specified,
> the current line is edited. The actual command executed is
> fc -e ${VISUAL:-${EDITOR:-vi}} n.
>
> this says that editing is implemented via history
...WHEN n is specified. Otherwise it uses the current line?
>
> fc [-e editor | -l [-n]] [-r] [first [last]]
> Fix command. first and last select commands from the
> history.
> Commands can be selected by history number or a string
> specifying
> the most recent command starting with that string. The -l
> option
> lists the command on standard output, and -n inhibits the
> default
> command numbers. The -r option reverses the order of the
> list.
> Without -l, the selected commands are edited by the editor
> specified with the -e option, or if no -e is specified, the
> editor specified by the FCEDIT parameter (if this parameter
> is
> not set, /bin/ed is used), and then executed by the shell.
>
> ^v does not specify a number, so ksh supposedly runs `fc -e vi'?
Yes. And that would edit the current line.
>
> The `fc' synopsis does not show how to use "a string specifying the most
> recent command starting with that string...
Because it only runs fc with either the line number to edit or simply the
current line?
When running manually 'fc expression' then it jumps to the first match
backwards or with 'fc -r expression' it reverses the list for matches.
>
> I guess ^v uses the current line for this string (no idea how), at which
> point it makes sense to not pass the empty string.
I think no, it doesn't search for the command via fc but simply passes the
current line by saving it to history and using that line number as argcnt.
And why it couldn't be even an empty line?
>
> In vi mode, if you enter only spaces, then ESC then `v' to edit:
> - our ksh will edit the previous line, not current whitespace one
> - ksh93 from ports will print a warning and not do anything
Mmh, the same happens when running the fc command...
I try to interprete the code here:
case 'v':
Ok, empty line and no linenum given - do nothing.
if (es->linelen == 0 && argcnt == 0)
return -1;
No linenum given:
if (!argcnt) {
Current line is modified (can even be empty by deleting everything) and saved
in history:
if (modified) {
es->cbuf[es->linelen] = '\0';
source->line++;
histsave(source->line, es->cbuf, 1);
Imho can't happen because then there must be an empty line before modify - but
we returned already with -1. That can only happen when applied my diff and will
be empty?
} else
argcnt = source->line + 1
- (hlast - hnum);
}
shf_snprintf(es->cbuf, es->cbufsize,
argcnt ? "%s %d" : "%s",
"fc -e ${VISUAL:-${EDITOR:-vi}} --",
argcnt);
es->linelen = strlen(es->cbuf);
return 2;
So finally with the diff we would run simply 'fc -e ${VISUAL:-${EDITOR:-vi}} --'
which opens vi with an empty file. When running 'fc -e vi -- ' (at least
one blank) it will use the last command from history somehow.
>
>
> So without looking at the code, I think this check is warranted.
>
Thanks for your time!
--
wq: ~uw
Re: ksh in vi-mode and line editing
On 19 Oct 08:49, Klemens Nanni wrote:
> On Wed, Aug 31, 2022 at 05:16:27PM +0200, Uwe Werler wrote:
> > Hi folks,
> >
> > I'm just wondering why there's a test for an empty line and args to start
> > the
> > editor for line editing. In bash one can start vi immediately with an empty
> > line by ^v. Might be there's another reason I don't understand for this
> > test?
>
> Logically, this should probably be allowed, but reading ksh(1)
>
> [n]vEdit line n using the vi(1) editor; if n is not specified,
> the current line is edited. The actual command executed is
> fc -e ${VISUAL:-${EDITOR:-vi}} n.
>
> this says that editing is implemented via history
>
> fc [-e editor | -l [-n]] [-r] [first [last]]
> Fix command. first and last select commands from the
> history.
> Commands can be selected by history number or a string
> specifying
> the most recent command starting with that string. The -l
> option
> lists the command on standard output, and -n inhibits the
> default
> command numbers. The -r option reverses the order of the
> list.
> Without -l, the selected commands are edited by the editor
> specified with the -e option, or if no -e is specified, the
> editor specified by the FCEDIT parameter (if this parameter
> is
> not set, /bin/ed is used), and then executed by the shell.
>
> ^v does not specify a number, so ksh supposedly runs `fc -e vi'?
>
> The `fc' synopsis does not show how to use "a string specifying the most
> recent command starting with that string...
>
> I guess ^v uses the current line for this string (no idea how), at which
> point it makes sense to not pass the empty string.
>
> In vi mode, if you enter only spaces, then ESC then `v' to edit:
> - our ksh will edit the previous line, not current whitespace one
> - ksh93 from ports will print a warning and not do anything
>
>
> So without looking at the code, I think this check is warranted.
Just for the record because first I thought the diff caused the empty lines in
my history file:
1. run some command
2. enter a blank and hit ^v so the last run command will be in the editor
3. delete the line and leave
4. check with fc -l
An empty line is then stored to the history.
--
wq: ~uw
don't save emtpy lines in ksh history
Hi all, when running ksh in vi-mode an empty line could be stored in history: Steps to reproduce in command mode: 1. go history back e.g.: k 2. start editor with: v 3. delete the whole line and :wq 4. check history with fc -l Without patch: zarathustra:/usr/src/bin/ksh$ fc -l 2 ls -la 3 fc -l 4 With patch: zarathustra:/usr/src/bin/ksh_new$ fc -l 7 fc -l 8 ls -la 9 fc -l 10 ls -la Index: history.c === RCS file: /cvs/src/bin/ksh/history.c,v retrieving revision 1.84 diff -u -p -u -r1.84 history.c --- history.c 27 Oct 2019 15:02:19 - 1.84 +++ history.c 26 Oct 2022 08:02:52 - @@ -659,6 +659,9 @@ histsave(int lno, const char *cmd, int d if (ignorespace && cmd[0] == ' ') return; + if (strlen(cmd) == 0) + return; + c = str_save(cmd, APERM); if ((cp = strrchr(c, '\n')) != NULL) *cp = '\0'; -- With kind regards / Með bestu kveðju / Mit freundlichen Grüßen Uwe Werler
Re: ksh in vi-mode and line editing
On 31 Aug 17:16, Uwe Werler wrote:
> Hi folks,
>
> I'm just wondering why there's a test for an empty line and args to start the
> editor for line editing. In bash one can start vi immediately with an empty
> line by ^v. Might be there's another reason I don't understand for this test?
>
>
> Index: bin/ksh/vi.c
> ===
> RCS file: /cvs/src/bin/ksh/vi.c,v
> retrieving revision 1.60
> diff -u -p -u -r1.60 vi.c
> --- bin/ksh/vi.c 12 Mar 2021 02:10:25 - 1.60
> +++ bin/ksh/vi.c 31 Aug 2022 14:48:37 -
> @@ -964,8 +964,6 @@ vi_cmd(int argcnt, const char *cmd)
> break;
>
> case 'v':
> - if (es->linelen == 0 && argcnt == 0)
> - return -1;
> if (!argcnt) {
> if (modified) {
> es->cbuf[es->linelen] = '\0';
>
> --
>
> Uwe
>
Ping
Index: vi.c
=== RCS file:
/cvs/src/bin/ksh/vi.c,v retrieving revision 1.60 diff -u -p -r1.60 vi.c ---
vi.c12 Mar 2021 02:10:25 - 1.60 +++ vi.c 19 Oct 2022 07:05:04
- @@ -964,8 +964,6 @@ vi_cmd(int argcnt, const char *cmd) break;
case 'v':
- if (es->linelen == 0 && argcnt == 0)
- return -1;
if (!argcnt) {
if (modified) {
es->cbuf[es->linelen] = '\0';
--
wq: ~uw
Re: move vmd vioblk handling to another thread
On 12 Nov 01:52, David Gwynne wrote:
> this updates a diff i had from a few years ago to move the vioblk
> handling in vmd into a separate thread.
>
> basically disk io in your virtual machine should not block the vcpu from
> running now.
>
> just throwing this out so people can give it a go and kick it around.
>
> Index: Makefile
> ===
> RCS file: /cvs/src/usr.sbin/vmd/Makefile,v
> retrieving revision 1.28
> diff -u -p -r1.28 Makefile
> --- Makefile 10 Nov 2022 11:46:39 - 1.28
> +++ Makefile 11 Nov 2022 15:51:50 -
> @@ -5,7 +5,7 @@
> PROG=vmd
> SRCS=vmd.c control.c log.c priv.c proc.c config.c vmm.c
> SRCS+= vm.c loadfile_elf.c pci.c virtio.c i8259.c mc146818.c
> -SRCS+= ns8250.c i8253.c dhcp.c packet.c mmio.c
> +SRCS+= ns8250.c i8253.c dhcp.c packet.c mmio.c task.c
> SRCS+= parse.y atomicio.c vioscsi.c vioraw.c vioqcow2.c
> fw_cfg.c
> SRCS+= vm_agentx.c
>
> Index: task.c
> ===
> RCS file: task.c
> diff -N task.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ task.c11 Nov 2022 15:51:50 -
> @@ -0,0 +1,158 @@
> +/* $OpenBSD: task.c,v 1.2 2018/06/19 17:12:34 reyk Exp $ */
> +
> +/*
> + * Copyright (c) 2017 David Gwynne
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "task.h"
> +
> +#define ISSET(_v, _m)((_v) & (_m))
> +#define SET(_v, _m) ((_v) |= (_m))
> +#define CLR(_v, _m) ((_v) &= ~(_m))
> +
> +struct taskq {
> + pthread_t thread;
> + struct task_list list;
> + pthread_mutex_t mtx;
> + pthread_cond_tcv;
> +};
> +
> +#define TASK_ONQUEUE (1 << 0)
> +
> +static void *taskq_run(void *);
> +
> +struct taskq *
> +taskq_create(const char *name)
> +{
> + struct taskq *tq;
> + int error;
> +
> + tq = malloc(sizeof(*tq));
> + if (tq == NULL)
> + return (NULL);
> +
> + TAILQ_INIT(>list);
> +
> + error = pthread_mutex_init(>mtx, NULL);
> + if (error != 0)
> + goto free;
> +
> + error = pthread_cond_init(>cv, NULL);
> + if (error != 0)
> + goto mtx;
> +
> + error = pthread_create(>thread, NULL, taskq_run, tq);
> + if (error != 0)
> + goto cv;
> +
> + pthread_set_name_np(tq->thread, name);
> +
> + return (tq);
> +
> +cv:
> + pthread_cond_destroy(>cv);
> +mtx:
> + pthread_mutex_destroy(>mtx); /* can this really fail? */
> +free:
> + free(tq);
> +
> + errno = error;
> + return (NULL);
> +}
> +
> +static void *
> +taskq_run(void *tqarg)
> +{
> + struct taskq *tq = tqarg;
> + struct task *t;
> +
> + void (*t_func)(void *);
> + void *t_arg;
> +
> + for (;;) {
> + pthread_mutex_lock(>mtx);
> + while ((t = TAILQ_FIRST(>list)) == NULL)
> + pthread_cond_wait(>cv, >mtx);
> +
> + TAILQ_REMOVE(>list, t, t_entry);
> + CLR(t->t_flags, TASK_ONQUEUE);
> +
> + t_func = t->t_func;
> + t_arg = t->t_arg;
> +
> + pthread_mutex_unlock(>mtx);
> +
> + (*t_func)(t_arg);
> + }
> +
> + return (NULL);
> +}
> +
> +void
> +task_set(struct task *t, void (*fn)(void *), void *arg)
> +{
> + t->t_func = fn;
> + t->t_arg = arg;
> + t->t_flags = 0;
> +}
> +
> +int
> +task_add(struct taskq *tq, struct task *t)
> +{
> + int rv = 1;
> +
> + if (ISSET(t->t_flags, TASK_ONQUEUE))
> + return (0);
> +
> + pthread_mutex_lock(>mtx);
> + if (ISSET(t->t_flags, TASK_ONQUEUE))
> + rv = 0;
> + else {
> + SET(t->t_flags, TASK_ONQUEUE);
> + TAILQ_INSERT_TAIL(>list, t, t_entry);
> + pthread_cond_signal(>cv);
> + }
> + pthread_mutex_unlock(>mtx);
> +
> + return (rv);
> +}
> +
> +int
> +task_del(struct taskq *tq, struct task *t)
> +{
> + int rv = 1;
> +
> + if (!ISSET(t->t_flags, TASK_ONQUEUE))
> + return (0);
> +
> +
