Re: [OpenBSD -current] Change event timer in main loop with kqueue
On 21/03/21(Sun) 11:27, Visa Hankala wrote:
> On Sat, Feb 27, 2021 at 01:36:29PM +, Visa Hankala wrote:
> > The kernel does not reschedule the timer when the user changes the
> > timeout period. The new period will take effect only after the current
> > period has expired. This is not explained in the manual page, though.
> >
> > With the recent kqueue changes, it is straightforward to make the kernel
> > modify an existing timer. I think the clearest behaviour is to reset the
> > timer completely when it is modified. If there are pending events, they
> > should be cancelled because they do not necessarily correspond to the
> > new settings.
> >
> > When f_modify and f_process are present in kqread_filtops, filt_timer
> > is not used. filt_timerexpire() activates timer knotes directly using
> > knote_activate() instead of KNOTE().
> >
> > However, the current behaviour has been around so long that one can
> > argue that it is an actual feature. BSDs are not consistent with this,
> > though. FreeBSD resets the timer immediately, whereas NetBSD and
> > DragonFly BSD apply the new period after expiry.
> >
> > I guess the resetting is harmless in most cases but might wreak havoc
> > at least with software that keeps poking its timers before expiry.
>
> I have received too little feedback to commit this.
>
> The most important question is, should the timer behaviour be changed?
I don't know if it exist code depending on this specific behavior but I
believe that, when it comes to BSD APIs exported to userland, being
aligned with FreeBSD is helpful. That's what I learned when working on
kqueue(2) backends when porting OSS.
> > Index: lib/libc/sys/kqueue.2
> > ===
> > RCS file: src/lib/libc/sys/kqueue.2,v
> > retrieving revision 1.43
> > diff -u -p -r1.43 kqueue.2
> > --- lib/libc/sys/kqueue.2 14 Nov 2020 10:16:15 - 1.43
> > +++ lib/libc/sys/kqueue.2 27 Feb 2021 12:54:27 -
> > @@ -468,6 +468,11 @@ contains the number of times the timeout
> > This filter automatically sets the
> > .Dv EV_CLEAR
> > flag internally.
> > +.Pp
> > +If an existing timer is re-added, the existing timer and related pending
> > events
> > +will be cancelled.
> > +The timer will be re-started using the timeout period
> > +.Fa data .
> > .It Dv EVFILT_DEVICE
> > Takes a descriptor as the identifier and the events to watch for in
> > .Fa fflags ,
> > Index: sys/kern/kern_event.c
> > ===
> > RCS file: src/sys/kern/kern_event.c,v
> > retrieving revision 1.161
> > diff -u -p -r1.161 kern_event.c
> > --- sys/kern/kern_event.c 24 Feb 2021 14:59:52 - 1.161
> > +++ sys/kern/kern_event.c 27 Feb 2021 12:54:27 -
> > @@ -135,7 +135,8 @@ int filt_fileattach(struct knote *kn);
> > void filt_timerexpire(void *knx);
> > intfilt_timerattach(struct knote *kn);
> > void filt_timerdetach(struct knote *kn);
> > -intfilt_timer(struct knote *kn, long hint);
> > +intfilt_timermodify(struct kevent *kev, struct knote *kn);
> > +intfilt_timerprocess(struct knote *kn, struct kevent *kev);
> > void filt_seltruedetach(struct knote *kn);
> >
> > const struct filterops kqread_filtops = {
> > @@ -163,7 +164,9 @@ const struct filterops timer_filtops = {
> > .f_flags= 0,
> > .f_attach = filt_timerattach,
> > .f_detach = filt_timerdetach,
> > - .f_event= filt_timer,
> > + .f_event= NULL,
> > + .f_modify = filt_timermodify,
> > + .f_process = filt_timerprocess,
> > };
> >
> > struct pool knote_pool;
> > @@ -444,15 +447,48 @@ filt_timerdetach(struct knote *kn)
> > struct timeout *to;
> >
> > to = (struct timeout *)kn->kn_hook;
> > - timeout_del(to);
> > + timeout_del_barrier(to);
> > free(to, M_KEVENT, sizeof(*to));
> > kq_ntimeouts--;
> > }
> >
> > int
> > -filt_timer(struct knote *kn, long hint)
> > +filt_timermodify(struct kevent *kev, struct knote *kn)
> > +{
> > + struct timeout *to = kn->kn_hook;
> > + int s;
> > +
> > + /* Reset the timer. Any pending events are discarded. */
> > +
> > + timeout_del_barrier(to);
> > +
> > + s = splhigh();
> > + if (kn->kn_status & KN_QUEUED)
> > + knote_dequeue(kn);
> > + kn->kn_status &= ~KN_ACTIVE;
> > + splx(s);
> > +
> > + kn->kn_data = 0;
> > + knote_modify(kev, kn);
> > + /* Reinit timeout to invoke tick adjustment again. */
> > + timeout_set(to, filt_timerexpire, kn);
> > + filt_timer_timeout_add(kn);
> > +
> > + return (0);
> > +}
> > +
> > +int
> > +filt_timerprocess(struct knote *kn, struct kevent *kev)
> > {
> > - return (kn->kn_data != 0);
> > + int active, s;
> > +
> > + s = splsoftclock();
> > + active = (kn->kn_data != 0);
> > + if (active)
> > + knote_submit(kn, kev);
> > + splx(s);
> > +
> > + return (active);
> > }
> >
Re: disable PPP_BSDCOMP by default
On Tue, Mar 30, 2021 at 12:00:10AM +0200, Balder Oddson wrote: > On Thu, Mar 25, 2021 at 12:46:24PM -0600, Theo de Raadt wrote: > > No way for this diff. This is the wrong way. Surely there are ways > > to disable compression negotion on specific sessions, but removing > > the code from the kernel is the wrong knob. > > So whom do I explain for feedbeef OK? > You can run on Cray X1, where each terminal has a clock that is good? > Another way to do SMP is speed as security --- memory being dead. > That part doesnt get made with a shared vector machine in mind, and a > definiton of local and shared devices? Cray-1, otherwise this doesn't make sense, and reasoning why. How you come with sales arguments that involve being slower on integer operations, but since its scalar vector machine, as long as you have to do many, or many at the same time, I go faster anyways, so you can pay for what you use, if only integer operations. Anyways, these are also nice machines, even if small operations and integer operations take a hit, for the things done to make vectors to enable scalar operations for a net performance increase. Which should imply that virtual devices, and devices with a inherent clock are device drivers and daemons. Pretty nifty pipeline by antique standards. > > You don't need to check for many things at two thirds the speed of light > in copper, but if job done and time is deterministic. > Where everything is connected to a crossbarswitch, and buses are dead, > this analogue/non-interactive thing doesn't belong. > > The basic principle should be compatible with "everything is a filtered > file", "every file has an array of pointers with addresses" that is kept > around after berkley packet filter. And that this gives higher memory > bandwidth to feed beef. Huge performance increase with AVX2, but it can > also be used for this I believe, decreases memory operations and > therefore increases instructions per cycle, so can deal with more lesser > devices, dead or otherwise. > > Why is this ludicrous? And is this rationale good enough? > I believe something similar was done to increase the performance of some > physics simulation toolkit, but thats not kernel or OS design. > Path of a particle is not the same as the path of a particle. > > Vroom? > > > > > > Balder Oddson wrote: > > > > > Compression in PPP was great in the age of ISDN to increase speeds. > > > The more common use cases, and trends concerning TLS1.3 advancements. > > > > > > Having this enabled by default, and infrequently used could lead to > > > unintended consequences around how the data is passed around. > > > > > > > > > Index: GENERIC > > > === > > > RCS file: /cvs/src/sys/conf/GENERIC,v > > > retrieving revision 1.274 > > > diff -u -p -u -p -r1.274 GENERIC > > > --- GENERIC 25 Feb 2021 01:19:35 - 1.274 > > > +++ GENERIC 25 Mar 2021 18:07:58 - > > > @@ -50,8 +50,8 @@ option TCP_SIGNATURE # TCP MD5 Signatur > > > > > > option INET6 # IPv6 > > > option IPSEC # IPsec > > > -option PPP_BSDCOMP # PPP BSD compression > > > -option PPP_DEFLATE > > > +#option PPP_BSDCOMP # PPP BSD compression > > > +#option PPP_DEFLATE # Disabled by default, TLS1.3 trends > > > option PIPEX # Ppp IP EXtension, for npppd > > > option MROUTING# Multicast router > > > option MPLS# Multi-Protocol Label Switching > > > > -- Balder Oddson
rpki-client, don't double fail on getaddrinfo errors
Found the hard way. http_new() call http_free() if http_resolv() failes.
http_free() call http_fail() in that case since the state is not
STATE_DONE. In the main poll loop another http_fail() call is made. This
results in bad bad things.
--
:wq Claudio
Index: http.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
retrieving revision 1.11
diff -u -p -r1.11 http.c
--- http.c 29 Mar 2021 15:37:04 - 1.11
+++ http.c 30 Mar 2021 15:23:20 -
@@ -1198,8 +1198,8 @@ proc_http(char *bind_addr, int fd)
h = http_new(id, uri, mod, outfd);
if (h == NULL) {
+ /* response sent in http_new -> http_free */
close(outfd);
- http_fail(id);
} else
for (i = 0; i < MAX_CONNECTIONS; i++) {
if (http_conns[i] != NULL)
Re: rpki-client, don't double fail on getaddrinfo errors
On Tue, Mar 30, 2021 at 05:30:19PM +0200, Claudio Jeker wrote:
> Found the hard way. http_new() call http_free() if http_resolv() failes.
> http_free() call http_fail() in that case since the state is not
> STATE_DONE. In the main poll loop another http_fail() call is made. This
> results in bad bad things.
Ugh. This is ok if you want to land it separately.
There is also an issue with close(outfd): http_free() closes
conn->outfd, so you get an EBADF here on http_resolv() failure.
http_new() should probably take ownership of outfd and close it on
http_parse_uri() failure.
So I think the entire h == NULL case should go away.
>
> --
> :wq Claudio
>
> Index: http.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 http.c
> --- http.c29 Mar 2021 15:37:04 - 1.11
> +++ http.c30 Mar 2021 15:23:20 -
> @@ -1198,8 +1198,8 @@ proc_http(char *bind_addr, int fd)
>
> h = http_new(id, uri, mod, outfd);
> if (h == NULL) {
> + /* response sent in http_new -> http_free */
> close(outfd);
> - http_fail(id);
> } else
> for (i = 0; i < MAX_CONNECTIONS; i++) {
> if (http_conns[i] != NULL)
>
Re: rpki-client, don't double fail on getaddrinfo errors
On Tue, Mar 30, 2021 at 05:45:39PM +0200, Theo Buehler wrote:
> On Tue, Mar 30, 2021 at 05:30:19PM +0200, Claudio Jeker wrote:
> > Found the hard way. http_new() call http_free() if http_resolv() failes.
> > http_free() call http_fail() in that case since the state is not
> > STATE_DONE. In the main poll loop another http_fail() call is made. This
> > results in bad bad things.
>
> Ugh. This is ok if you want to land it separately.
>
> There is also an issue with close(outfd): http_free() closes
> conn->outfd, so you get an EBADF here on http_resolv() failure.
>
> http_new() should probably take ownership of outfd and close it on
> http_parse_uri() failure.
>
> So I think the entire h == NULL case should go away.
>
Like this?
--
:wq Claudio
Index: http.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
retrieving revision 1.11
diff -u -p -r1.11 http.c
--- http.c 29 Mar 2021 15:37:04 - 1.11
+++ http.c 30 Mar 2021 15:50:24 -
@@ -402,6 +402,7 @@ http_new(size_t id, char *uri, char *mod
if (http_parse_uri(uri, &host, &port, &path) == -1) {
free(uri);
free(modified_since);
+ close(outfd);
return NULL;
}
@@ -1197,10 +1198,7 @@ proc_http(char *bind_addr, int fd)
io_str_read(fd, &mod);
h = http_new(id, uri, mod, outfd);
- if (h == NULL) {
- close(outfd);
- http_fail(id);
- } else
+ if (h != NULL) {
for (i = 0; i < MAX_CONNECTIONS; i++) {
if (http_conns[i] != NULL)
continue;
@@ -1209,6 +1207,7 @@ proc_http(char *bind_addr, int fd)
http_conns[i] = NULL;
break;
}
+ }
}
if (pfds[MAX_CONNECTIONS].revents & POLLOUT) {
switch (msgbuf_write(&msgq)) {
Re: rpki-client, don't double fail on getaddrinfo errors
On Tue, Mar 30, 2021 at 05:51:38PM +0200, Claudio Jeker wrote:
> On Tue, Mar 30, 2021 at 05:45:39PM +0200, Theo Buehler wrote:
> > On Tue, Mar 30, 2021 at 05:30:19PM +0200, Claudio Jeker wrote:
> > > Found the hard way. http_new() call http_free() if http_resolv() failes.
> > > http_free() call http_fail() in that case since the state is not
> > > STATE_DONE. In the main poll loop another http_fail() call is made. This
> > > results in bad bad things.
> >
> > Ugh. This is ok if you want to land it separately.
> >
> > There is also an issue with close(outfd): http_free() closes
> > conn->outfd, so you get an EBADF here on http_resolv() failure.
> >
> > http_new() should probably take ownership of outfd and close it on
> > http_parse_uri() failure.
> >
> > So I think the entire h == NULL case should go away.
> >
>
> Like this?
Exactly. ok
>
> --
> :wq Claudio
>
> Index: http.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 http.c
> --- http.c29 Mar 2021 15:37:04 - 1.11
> +++ http.c30 Mar 2021 15:50:24 -
> @@ -402,6 +402,7 @@ http_new(size_t id, char *uri, char *mod
> if (http_parse_uri(uri, &host, &port, &path) == -1) {
> free(uri);
> free(modified_since);
> + close(outfd);
> return NULL;
> }
>
> @@ -1197,10 +1198,7 @@ proc_http(char *bind_addr, int fd)
> io_str_read(fd, &mod);
>
> h = http_new(id, uri, mod, outfd);
> - if (h == NULL) {
> - close(outfd);
> - http_fail(id);
> - } else
> + if (h != NULL) {
> for (i = 0; i < MAX_CONNECTIONS; i++) {
> if (http_conns[i] != NULL)
> continue;
> @@ -1209,6 +1207,7 @@ proc_http(char *bind_addr, int fd)
> http_conns[i] = NULL;
> break;
> }
> + }
> }
> if (pfds[MAX_CONNECTIONS].revents & POLLOUT) {
> switch (msgbuf_write(&msgq)) {
Re: iwm(4) A-MSDU support
Hi Stefan, * 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! Works so far fine with the following HW: 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 7c:2a:31:4d:1c:b9 Cheers Matthias
Re: iwm(4) A-MSDU support
On 2021 Mar 29 (Mon) at 19:27:15 +0200 (+0200), 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. : Been running this for about 24 hours on my x395, seems to be good. Had only one stuck wifi when first trying it, but I was also stuck on a 2.4GHz channel and live in a dense apartment building. Forcing it to move to a 5GHz channel fixed it all up, and no problems since then. iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29, msix iwm0: hw rev 0x320, fw ver 34.3125811985.0, address 0c:dd:24:83:e1:40 -- Churchill's Commentary on Man: Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue on.
Re: iwm(4) A-MSDU support
On Tue, Mar 30, 2021 at 07:36:28PM +0200, Peter Hessler wrote: > Been running this for about 24 hours on my x395, seems to be good. > > Had only one stuck wifi when first trying it, but I was also stuck on a > 2.4GHz channel and live in a dense apartment building. Forcing it to > move to a 5GHz channel fixed it all up, and no problems since then. Understanding situations where it doesn't work is actually quite important. Is it repeatable? And how big is the impact? If you can fly somewhat in Minecraft on 2 GHz, and if it consistently recovers after stuttering, I'd consider that success. This is a huge change for the device you are using; all the Rx BA logic is now handled by completely new code in the driver, with a bypass of the corresponding logic in net80211. We now let the firmware move the BA window forward and try to follow along, instead of maintaining our own (duplicated) state of the Rx BA session. net80211 is only involved in BA setup/teardown handshakes with the AP. In good conditions, I see virtually no packet loss. I've tried testing error recovery by moving far out and back to the AP. This seems to be OK. However, as with our net80211 Rx BA code we risk stuck connections if the Rx BA window doesn't resync properly after packet loss. The logic implemented here is from Intel, with very few changes (such as fixed timeout periods), so if the firmware and this new driver code work reliably on Linux, it should also work fine for us. But I cannot be sure that this code is free of bugs causing stuck connections. Like our net80211 Rx BA code, this code will have to prove itself over time...
patch: asr_debug.c prints SOA in wrong order
Both asr_private.h and asr_utils.c have mname before rname but not asr_debug.c. Index: asr_debug.c === RCS file: /cvs/src/lib/libc/asr/asr_debug.c,v retrieving revision 1.26 diff -u -p -r1.26 asr_debug.c --- asr_debug.c 3 Jul 2019 03:24:03 - 1.26 +++ asr_debug.c 30 Mar 2021 10:11:45 - @@ -101,8 +101,8 @@ print_rr(const struct asr_dns_rr *rr, ch break; case T_SOA: snprintf(buf, max, "%s %s %lu %lu %lu %lu %lu", - print_dname(rr->rr.soa.rname, tmp, sizeof tmp), - print_dname(rr->rr.soa.mname, tmp2, sizeof tmp2), + print_dname(rr->rr.soa.mname, tmp, sizeof tmp), + print_dname(rr->rr.soa.rname, tmp2, sizeof tmp2), (unsigned long)rr->rr.soa.serial, (unsigned long)rr->rr.soa.refresh, (unsigned long)rr->rr.soa.retry, -- Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
usbdevs huawei tidying
This removes a bunch of extra "HUAWEI Mobile", add model numbers according to our macros (some are used on more than one device but should be close enough), add radio type where I could figure it out. ok? Index: usbdevs === RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.735 diff -u -p -r1.735 usbdevs --- usbdevs 28 Mar 2021 12:06:35 - 1.735 +++ usbdevs 30 Mar 2021 18:35:06 - @@ -2281,32 +2281,32 @@ product HTC SMARTPHONE 0x0a51 SmartPhon product HTC ANDROID0x0ffe Android phone /* HUAWEI products */ -product HUAWEI E6180x1001 HUAWEI Mobile E618 -product HUAWEI E2200x1003 HUAWEI Mobile Modem -product HUAWEI MOBILE 0x1008 HUAWEI Mobile Modem -product HUAWEI EM770W 0x1404 HUAWEI Mobile Modem -product HUAWEI E1750 0x1406 HUAWEI Mobile Modem -product HUAWEI E1800x140c HUAWEI Mobile E180 -product HUAWEI E5100x1411 HUAWEI Mobile E510 -product HUAWEI E1810x1414 HUAWEI Mobile E181 -product HUAWEI E1752 0x1417 HUAWEI Mobile Modem -product HUAWEI E1820x1429 HUAWEI Mobile Modem -product HUAWEI E3372 0x1442 HUAWEI Mobile Modem -product HUAWEI E1610x1446 HUAWEI Mobile Modem -product HUAWEI K3765 0x1465 HUAWEI Mobile K3765 -product HUAWEI E1820 0x14ac HUAWEI Mobile Modem -product HUAWEI K4511 0x14b7 HUAWEI Mobile Modem K4511 -product HUAWEI K4510 0x14c5 HUAWEI Mobile Modem -product HUAWEI K3772 0x14cf HUAWEI Mobile K3772 -product HUAWEI E353_INIT 0x14fe HUAWEI Mobile E353 Initial -product HUAWEI E392_INIT 0x1505 HUAWEI Mobile E392 Initial -product HUAWEI K3765_INIT 0x1520 HUAWEI Mobile K3765 Initial -product HUAWEI K3772_INIT 0x1526 HUAWEI Mobile K3772 Initial -product HUAWEI MU609 0x1573 HUAWEI Mobile ME906 +product HUAWEI E6180x1001 E618 HSDPA +product HUAWEI E2200x1003 E220 HSDPA +product HUAWEI MOBILE 0x1008 Modem +product HUAWEI EM770W 0x1404 EM770W WCDMA +product HUAWEI E1750 0x1406 E1750 HSDPA +product HUAWEI E1800x140c E180 HSDPA +product HUAWEI E5100x1411 E510 HSDPA/DVB-T +product HUAWEI E1810x1414 E181 HSDPA +product HUAWEI E1752 0x1417 E1752 HSDPA +product HUAWEI E1820x1429 E182 HSDPA +product HUAWEI E3372 0x1442 E3372 LTE +product HUAWEI E1610x1446 E161 HSDPA +product HUAWEI K3765 0x1465 K3765 HSDPA +product HUAWEI E1820 0x14ac E1820 HSDPA +product HUAWEI K4511 0x14b7 K4511 HSDPA +product HUAWEI K4510 0x14c5 K4510 HSDPA +product HUAWEI K3772 0x14cf K3772 LTE +product HUAWEI E353_INIT 0x14fe E353 Initial +product HUAWEI E392_INIT 0x1505 E392 Initial +product HUAWEI K3765_INIT 0x1520 K3765 Initial +product HUAWEI K3772_INIT 0x1526 K3772 Initial +product HUAWEI MU609 0x1573 ME906 LTE product HUAWEI ME906S 0x15c1 ME906s LTE -product HUAWEI E173S 0x1c05 HUAWEI Mobile E173s -product HUAWEI E173S_INIT 0x1c0b HUAWEI Mobile E173s Initial -product HUAWEI E3030x1f01 HUAWEI Mobile E303 +product HUAWEI E173S 0x1c05 E173s HSDPA +product HUAWEI E173S_INIT 0x1c0b E173s Initial +product HUAWEI E3030x1f01 E303 HSDPA /* Huawei 3Com products */ product HUAWEI3COM WUB320G 0x0009 Aolynk WUB320g
Re: iwm(4) A-MSDU support
On 2021 Mar 30 (Tue) at 20:22:09 +0200 (+0200), Stefan Sperling wrote: :On Tue, Mar 30, 2021 at 07:36:28PM +0200, Peter Hessler wrote: :> Been running this for about 24 hours on my x395, seems to be good. :> :> Had only one stuck wifi when first trying it, but I was also stuck on a :> 2.4GHz channel and live in a dense apartment building. Forcing it to :> move to a 5GHz channel fixed it all up, and no problems since then. : :Understanding situations where it doesn't work is actually quite important. :Is it repeatable? And how big is the impact? :If you can fly somewhat in Minecraft on 2 GHz, and if it consistently :recovers after stuttering, I'd consider that success. : I can fly around pretty well in Minecraft while in 2 GHz, taking off is easy to do. However, when I go to a part of my apartment with dodgy wifi connectivity, I notice that my signal strength goes down to 23%, and I can't connect any more. I stay at HT-MCS15, even while it is flipping around trying to connect. if I try to ping the gateway I get the dreaded "ping: sendmsg: No buffer space available" error, until I down/up the interface. That does occasionally happen without this diff, so that is not a regression. No noticable packet loss in my testing, even on 2GHz during the busiest time of the day. :This is a huge change for the device you are using; all the Rx BA logic :is now handled by completely new code in the driver, with a bypass of the :corresponding logic in net80211. We now let the firmware move the BA :window forward and try to follow along, instead of maintaining our own :(duplicated) state of the Rx BA session. net80211 is only involved in :BA setup/teardown handshakes with the AP. : :In good conditions, I see virtually no packet loss. :I've tried testing error recovery by moving far out and back to the AP. :This seems to be OK. However, as with our net80211 Rx BA code we risk stuck :connections if the Rx BA window doesn't resync properly after packet loss. : :The logic implemented here is from Intel, with very few changes (such as :fixed timeout periods), so if the firmware and this new driver code work :reliably on Linux, it should also work fine for us. But I cannot be sure :that this code is free of bugs causing stuck connections. Like our net80211 :Rx BA code, this code will have to prove itself over time... : -- Misfortune, n.: The kind of fortune that never misses. -- Ambrose Bierce, "The Devil's Dictionary"
Re: athn(4): switch Tx rate control to RA
On Tue, 23 Mar 2021 18:01:27 +0100, 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. This seems to be working well on my apu2 in hostap mode: athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:xx:xx:xx However, my laptop with AR9287 was noticeably worse with this diff (dropped pings, stuttering keystrokes in interactive ssh session, estimated 20 minutes to scp(1) a 20M file...). The combination of apu2 with diff and my laptop sans diff is giving me good results though :) athn0 at pci2 dev 0 function 0 "Atheros AR9287" rev 0x01: apic 2 int 17 athn0: AR9287 rev 2 (2T2R), ROM rev 4, address 74:de:2b:xx:xx:xx On this laptop, I use a trunk(4) interface and I connect to the apu2 via authpf(8). Some configs and dmesg below. Let me know how I can be of further assistance. $ cat /etc/hostname.athn0 join myap wpakey xxx powersave up $ cat /etc/hostname.em0 up $ cat /etc/hostname.trunk0 trunkproto failover trunkport em0 trunkport athn0 dhcp up $ ifconfig athn0 athn0: flags=8943 mtu 1500 lladdr d4:be:d9:xx:xx:xx index 2 priority 4 llprio 3 trunk: trunkdev trunk0 groups: wlan media: IEEE802.11 autoselect (HT-MCS2 mode 11n) status: active ieee80211: join myap chan 7 bssid xx:xx:xx:xx:xx:xx -36dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp powersave on (100ms sleep) OpenBSD 6.9-beta (GENERIC.MP) #437: Tue Mar 30 14:45:23 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17064501248 (16273MB) avail mem = 16531947520 (15766MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebf20 (98 entries) bios0: vendor Dell Inc. version "A13" date 06/20/2014 bios0: Dell Inc. Latitude E6430s acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT DMAR ASF! SLIC BGRT acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB5(S3) USB6(S3) USB7(S3) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(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-3320M CPU @ 2.60GHz, 2592.04 MHz, 06-3a-09 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2591.60 MHz, 06-3a-09 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus -1 (RP05) acpiprt5 at acpi0: bus 11 (RP06) acpiprt6 at acpi0: bus -1 (RP07) acpiprt7 at acpi0: bus -1 (RP08) acpiprt8 at acpi0: bus -1 (PEG0) acpiprt9 at acpi0: bus -1 (PEG1) acpiprt10 at acpi0: bus -1 (PEG2) acpiprt11 at acpi0: bus -1 (PEG3) acpiprt12 at acpi0: bus 3 (RP03) acpiprt13 at acpi0: bus 7 (RP04) acpiec0 at acpi0 acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001 acpicmos0 at acpi0 "SMO8810" at acpi0 not configured "*pnp0c14" at acpi0 not configured acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpiac0 at acpi0: AC unit offline acpibat0 at acpi0: BAT0 model "DELL YJNKK18" serial 1 type LION oem "DP-SDI56" acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present "DELLABCE" at acpi0 not configured acpicpu0 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at a
Enable libz when ddb is enabled
The addition of CTF handling has made ddb depend on libz. Listing this
dependency would make it easier to build a RAMDISK with the debugger.
OK?
Index: conf/files
===
RCS file: src/sys/conf/files,v
retrieving revision 1.699
diff -u -p -r1.699 files
--- conf/files 12 Mar 2021 16:26:27 - 1.699
+++ conf/files 31 Mar 2021 05:04:19 -
@@ -1071,15 +1071,15 @@ file lib/libkern/arch/${MACHINE_ARCH}/ht
file lib/libkern/arch/${MACHINE_ARCH}/htons.S | lib/libkern/htons.c
file lib/libkern/arch/${MACHINE_ARCH}/strncasecmp.S | lib/libkern/strncasecmp.c
-file lib/libz/adler32.cppp_deflate | ipsec | crypto |
bios
+file lib/libz/adler32.cppp_deflate | ipsec | crypto |
ddb |
+ bios
file lib/libz/crc32.c
-file lib/libz/infback.cppp_deflate | ipsec | crypto
-file lib/libz/inffast.cppp_deflate | ipsec | crypto
-file lib/libz/inflate.cppp_deflate | ipsec | crypto
-file lib/libz/inftrees.c ppp_deflate | ipsec | crypto
-file lib/libz/deflate.cppp_deflate | ipsec | crypto
-file lib/libz/zutil.c ppp_deflate | ipsec | crypto
-file lib/libz/zopenbsd.c ppp_deflate | ipsec | crypto
-file lib/libz/trees.c ppp_deflate | ipsec | crypto
-file lib/libz/compress.c ppp_deflate | ipsec | crypto
-
+file lib/libz/infback.cppp_deflate | ipsec | crypto |
ddb
+file lib/libz/inffast.cppp_deflate | ipsec | crypto |
ddb
+file lib/libz/inflate.cppp_deflate | ipsec | crypto |
ddb
+file lib/libz/inftrees.c ppp_deflate | ipsec | crypto | ddb
+file lib/libz/deflate.cppp_deflate | ipsec | crypto |
ddb
+file lib/libz/zutil.c ppp_deflate | ipsec | crypto | ddb
+file lib/libz/zopenbsd.c ppp_deflate | ipsec | crypto | ddb
+file lib/libz/trees.c ppp_deflate | ipsec | crypto | ddb
+file lib/libz/compress.c ppp_deflate | ipsec | crypto | ddb
