install rc.d script for resolvd
resolvd will not start at boot without its rc.d script. OK? Index: Makefile === RCS file: /cvs/src/etc/Makefile,v retrieving revision 1.481 diff -u -p -r1.481 Makefile --- Makefile26 Feb 2021 17:18:41 - 1.481 +++ Makefile27 Feb 2021 06:33:14 - @@ -62,7 +62,7 @@ RCDAEMONS=amd apmd bgpd bootparamd cron dvmrpd eigrpd ftpd ftpproxy ftpproxy6 hostapd hotplugd httpd identd \ ifstated iked inetd isakmpd iscsid ldapd ldattach ldomd ldpd lockd \ lpd mopd mountd mrouted nfsd npppd nsd ntpd ospf6d ospfd \ - pflogd portmap rad radiusd rarpd rbootd relayd ripd route6d \ + pflogd portmap rad radiusd rarpd rbootd relayd resolvd ripd route6d \ sasyncd sensorsd slowcgi slaacd smtpd sndiod snmpd spamd \ spamlogd sshd statd switchd syslogd tftpd tftpproxy unbound \ unwind vmd watchdogd wsmoused xenodm ypbind ypldap ypserv
Re: veb(4) support for vmd(8)?
David Gwynne wrote: > I'd vote that way, but I am biased. > > Some test reports that it's working well for people would be nice too.= This is working well in my testing as a replacement for bridge/vether usage as told in the virtualization FAQ, but I was unaware that the vport interface needed to manually be set 'up', and saw no mention of that in the manpage. dlg@ kindly walked me through that and nothing has been an issue since.
patch: adding httpd implicit file extensions
Hello, this is my first time contributing to openbsd and this mailing
list, so please excuse any newbie blunders. I recently switched my
personal website to use httpd with statically generated HTML files, but
was unhappy to find that my HTML files could only be accessed by exact
filename, including the ".html" at the end. My site previously ran on
Apache with rewrite rules to ensure that "example.com/foo" would serve
the file "/foo.html" (when "/foo" didn't exist). I wanted to keep my
original URLs working and I aesthetically prefer URLs without ".html"
suffixes, so I looked around for different options with httpd. The best
option I could find was to create symbolic links from "/foo" to
"/foo.html" and set the default media type to text/html, but this
solution was cumbersome (I had to maintain all the symbolic links) and
had undesirable side effects (all extensionless files were treated as
text/html instead of text/plain).
I decided instead to look into modifying httpd to support implicit file
extensions. My basic idea was to add a configurable setting called
`implicit extension`. When a file is not found and the file doesn't
already have the implicit extension, then httpd will look for the same
filename but with the implicit extension added at the end, and reroute
to that file if it exists. This neatly solves my problem by adding
`implicit extension ".html"` to the top of my /etc/httpd.conf file, and
`implicit extension ".php"` to the section of my website that uses PHP
scripts. For simplicity (and because my website doesn't use both HTML
and PHP in the same subdomain), I opted to only support a single
implicit extension per config block, though in the future, supporting
globs as implicit extensions might also be nice(e.g. `implicit extension
".{html,php}"`).
I've been running the code on my personal website for a while now
without any issues. If this patch is accepted, I also have a separate
small patch that displays custom HTTP error pages if you have a
/[] file (e.g. /404 or /404.html), which
works well in conjunction with this patch.
I'm happy to take any feedback or criticism on both the idea and my
implementation patch below. Hopefully other people find this useful as
well!
- Bruce Hill
Index: config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.61
diff -u -p -u -p -r1.61 config.c
--- config.c21 Sep 2020 09:42:07 - 1.61
+++ config.c26 Feb 2021 23:30:18 -
@@ -568,6 +568,13 @@ config_getserver_config(struct httpd *en
>default_type, sizeof(struct media_type));
}
+ f = SRVFLAG_IMPLICIT_EXT;
+ if ((srv_conf->flags & f) == 0) {
+ srv_conf->flags |= parent->flags & f;
+ memcpy(_conf->implicit_extension,
+ >implicit_extension,
sizeof(parent->implicit_extension));
+ }
+
f = SRVFLAG_PATH_REWRITE|SRVFLAG_NO_PATH_REWRITE;
if ((srv_conf->flags & f) == 0) {
srv_conf->flags |= parent->flags & f;
Index: httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.153
diff -u -p -u -p -r1.153 httpd.h
--- httpd.h 29 Oct 2020 12:30:52 - 1.153
+++ httpd.h 26 Feb 2021 23:30:19 -
@@ -57,6 +57,7 @@
#define HTTPD_REALM_MAX255
#define HTTPD_LOCATION_MAX 255
#define HTTPD_DEFAULT_TYPE { "bin", "application", "octet-stream", NULL }
+#define HTTPD_IMPLICIT_EXT ""
#define HTTPD_LOGVIS VIS_NL|VIS_TAB|VIS_CSTYLE
#define HTTPD_TLS_CERT "/etc/ssl/server.crt"
#define HTTPD_TLS_KEY "/etc/ssl/private/server.key"
@@ -391,6 +392,7 @@ SPLAY_HEAD(client_tree, client);
#define SRVFLAG_DEFAULT_TYPE 0x0080
#define SRVFLAG_PATH_REWRITE 0x0100
#define SRVFLAG_NO_PATH_REWRITE0x0200
+#define SRVFLAG_IMPLICIT_EXT 0x0400
#define SRVFLAG_LOCATION_FOUND 0x4000
#define SRVFLAG_LOCATION_NOT_FOUND 0x8000
@@ -399,8 +401,8 @@ SPLAY_HEAD(client_tree, client);
"\05ROOT\06LOCATION\07FCGI\10NO_FCGI\11LOG\12NO_LOG" \
"\14SYSLOG\15NO_SYSLOG\16TLS\17ACCESS_LOG\20ERROR_LOG"\
"\21AUTH\22NO_AUTH\23BLOCK\24NO_BLOCK\25LOCATION_MATCH" \
- "\26SERVER_MATCH\27SERVER_HSTS\30DEFAULT_TYPE\31PATH\32NO_PATH" \
- "\37LOCATION_FOUND\40LOCATION_NOT_FOUND"
+ "\26SERVER_MATCH\27SERVER_HSTS\30DEFAULT_TYPE\31PATH\32NO_PATH" \
+ "\33IMPLICIT_EXTENSION\37LOCATION_FOUND\40LOCATION_NOT_FOUND"
#define TCPFLAG_NODELAY 0x01
#define TCPFLAG_NNODELAY 0x02
@@ -481,6 +483,7 @@ struct server_config {
char accesslog[PATH_MAX];
char errorlog[PATH_MAX];
struct media_typedefault_type;
+ char
Re: Sky Lake-E PCI ids.
On Fri, Feb 26, 2021 at 11:12:17AM +0100, Karel Gardas wrote: > On 2/26/21 7:24 AM, Jonathan Gray wrote: > > As the ids are used on more than just Skylake-E here is another diff. > > Though I think these ids are shared with Core X Skylake. So perhaps > > giving up on a marketing name is indeed the thing to do. > > Indeed, Intel made quite a mess in this, but I think this your combination > is probably the best one, > although we risk to show "Xeon" on user system with high-end Core X cpus. > The thing > is those makes minority of all the chips in the family and technically they > are crippled Xeons anyway, > so if I may I would vote for this diff. > > Thanks a lot for dealing with this mess. thanks, committed > > > Index: pcidevs > > === > > RCS file: /cvs/src/sys/dev/pci/pcidevs,v > > retrieving revision 1.1956 > > diff -u -p -r1.1956 pcidevs > > --- pcidevs 22 Feb 2021 01:17:23 - 1.1956 > > +++ pcidevs 26 Feb 2021 05:39:05 - > > @@ -4188,6 +4188,61 @@ product INTEL ATOMC2000_PCU_SMB 0x1f3c A > > product INTEL I354_BP_1GBPS 0x1f40 I354 > > product INTEL I354_SGMII 0x1f41 I354 SGMII > > product INTEL I354_BP_2_5GBPS 0x1f45 I354 > > +product INTEL XEONS_UBOX_1 0x2014 Xeon Scalable Ubox > > +product INTEL XEONS_UBOX_2 0x2015 Xeon Scalable Ubox > > +product INTEL XEONS_UBOX_3 0x2016 Xeon Scalable Ubox > > > >
Re: veb(4) support for vmd(8)?
> On 27 Feb 2021, at 9:57 am, Mike Larkin wrote: > > On Sat, Feb 27, 2021 at 09:44:03AM +1000, David Gwynne wrote: >> >> >>> On 27 Feb 2021, at 7:50 am, Klemens Nanni wrote: >>> >>> On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wrote: i think this is enough to let vmd wire guests up to veb interfaces. >>> But please update vm.conf(5) to mention veb(4) and vport(4) in as well >>> SWITCH CONFIGURATION. >> >> How would you fit wording about vport(4) in? >> >>> >>> OK kn >> > > Do we want to just talk only about veb/vport and remove all the old discussion > around bridge/vether? I'd vote that way, but I am biased. Some test reports that it's working well for people would be nice too.
Re: veb(4) support for vmd(8)?
On Fri, 26 Feb 2021 22:50:29 +0100 Klemens Nanni : > On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wrote: > > i think this is enough to let vmd wire guests up to veb interfaces. > But please update vm.conf(5) to mention veb(4) and vport(4) in as well > SWITCH CONFIGURATION. > > OK kn > The virtualization FAQ could be updated too when 6.9 is released if bridge should be replaced with veb.
Re: ip_fragment ip6_fragment
I like it. I would like it more if you named the mbuf list variable "fml".
ok by me.
> On 26 Feb 2021, at 9:08 pm, Alexander Bluhm wrote:
>
> Hi,
>
> I always bothered me that ip_fragment() and ip6_fragment() behave
> sligtly differently. Unify them and use an mlist to simplify the
> fragment list.
>
> - The functions ip_fragment() and ip6_fragment() always consume the mbuf.
> - They free the mbuf and mbuf list in case of an error.
> - They care about the counter.
> - Adjust the code a bit to make v4 and v6 look similar.
> - Maybe there was an mbuf leak when pf_route6() called pf_refragment6()
> and it failed. Now the mbuf is always freed by ip6_fragment().
>
> ok?
>
> bluhm
>
> Index: net/if_bridge.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_bridge.c,v
> retrieving revision 1.352
> diff -u -p -r1.352 if_bridge.c
> --- net/if_bridge.c 25 Feb 2021 02:48:21 - 1.352
> +++ net/if_bridge.c 26 Feb 2021 10:41:57 -
> @@ -1853,7 +1853,7 @@ bridge_fragment(struct ifnet *brifp, str
> struct mbuf *m)
> {
> struct llc llc;
> - struct mbuf *m0;
> + struct mbuf_list ml;
> int error = 0;
> int hassnap = 0;
> u_int16_t etype;
> @@ -1911,40 +1911,32 @@ bridge_fragment(struct ifnet *brifp, str
> return;
> }
>
> - error = ip_fragment(m, ifp, ifp->if_mtu);
> - if (error) {
> - m = NULL;
> - goto dropit;
> - }
> + error = ip_fragment(m, , ifp, ifp->if_mtu);
> + if (error)
> + return;
>
> - for (; m; m = m0) {
> - m0 = m->m_nextpkt;
> - m->m_nextpkt = NULL;
> - if (error == 0) {
> - if (hassnap) {
> - M_PREPEND(m, LLC_SNAPFRAMELEN, M_DONTWAIT);
> - if (m == NULL) {
> - error = ENOBUFS;
> - continue;
> - }
> - bcopy(, mtod(m, caddr_t),
> - LLC_SNAPFRAMELEN);
> - }
> - M_PREPEND(m, sizeof(*eh), M_DONTWAIT);
> + while ((m = ml_dequeue()) != NULL) {
> + if (hassnap) {
> + M_PREPEND(m, LLC_SNAPFRAMELEN, M_DONTWAIT);
> if (m == NULL) {
> error = ENOBUFS;
> - continue;
> + break;
> }
> - bcopy(eh, mtod(m, caddr_t), sizeof(*eh));
> - error = bridge_ifenqueue(brifp, ifp, m);
> - if (error) {
> - continue;
> - }
> - } else
> - m_freem(m);
> + bcopy(, mtod(m, caddr_t), LLC_SNAPFRAMELEN);
> + }
> + M_PREPEND(m, sizeof(*eh), M_DONTWAIT);
> + if (m == NULL) {
> + error = ENOBUFS;
> + break;
> + }
> + bcopy(eh, mtod(m, caddr_t), sizeof(*eh));
> + error = bridge_ifenqueue(brifp, ifp, m);
> + if (error)
> + break;
> }
> -
> - if (error == 0)
> + if (error)
> + ml_purge();
> + else
> ipstat_inc(ips_fragmented);
>
> return;
> Index: net/pf.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf.c,v
> retrieving revision 1.1112
> diff -u -p -r1.1112 pf.c
> --- net/pf.c 23 Feb 2021 11:43:40 - 1.1112
> +++ net/pf.c 26 Feb 2021 10:41:57 -
> @@ -5969,7 +5969,8 @@ pf_rtlabel_match(struct pf_addr *addr, s
> void
> pf_route(struct pf_pdesc *pd, struct pf_state *s)
> {
> - struct mbuf *m0, *m1;
> + struct mbuf *m0;
> + struct mbuf_list ml;
> struct sockaddr_in *dst, sin;
> struct rtentry *rt = NULL;
> struct ip *ip;
> @@ -6078,23 +6079,18 @@ pf_route(struct pf_pdesc *pd, struct pf_
> goto bad;
> }
>
> - m1 = m0;
> - error = ip_fragment(m0, ifp, ifp->if_mtu);
> - if (error) {
> - m0 = NULL;
> - goto bad;
> - }
> + error = ip_fragment(m0, , ifp, ifp->if_mtu);
> + if (error)
> + goto done;
>
> - for (m0 = m1; m0; m0 = m1) {
> - m1 = m0->m_nextpkt;
> - m0->m_nextpkt = NULL;
> - if (error == 0)
> - error = ifp->if_output(ifp, m0, sintosa(dst), rt);
> - else
> - m_freem(m0);
> + while ((m0 = ml_dequeue()) != NULL) {
> + error = ifp->if_output(ifp, m0, sintosa(dst), rt);
> + if (error)
> + break;
> }
> -
> - if (error == 0)
>
Re: veb(4) support for vmd(8)?
On Sat, Feb 27, 2021 at 09:44:03AM +1000, David Gwynne wrote: > > > > On 27 Feb 2021, at 7:50 am, Klemens Nanni wrote: > > > > On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wrote: > >> i think this is enough to let vmd wire guests up to veb interfaces. > > But please update vm.conf(5) to mention veb(4) and vport(4) in as well > > SWITCH CONFIGURATION. > > How would you fit wording about vport(4) in? I was too vague, it'd be just veb(4), I guess. I wouldn't go into any of the bridge/switch driver's specific configuration in vmd(8), i.e. explicitly omit any mention of vether(4) or vport(4). How about this (quietly moving vmctl(8) from bridge(4) to veb(4) while at it...) Index: vmd/vm.conf.5 === RCS file: /cvs/src/usr.sbin/vmd/vm.conf.5,v retrieving revision 1.55 diff -u -p -r1.55 vm.conf.5 --- vmd/vm.conf.5 23 Sep 2020 19:18:18 - 1.55 +++ vmd/vm.conf.5 27 Feb 2021 00:07:20 - @@ -376,9 +376,10 @@ Set the owner to the specified group. .Sh SWITCH CONFIGURATION A virtual switch allows VMs to communicate with other network interfaces on the host system via either -.Xr bridge 4 +.Xr bridge 4 , +.Xr switch 4 or -.Xr switch 4 . +.Xr veb 4 . The network interface for each virtual switch defined in .Nm is pre-configured using @@ -435,9 +436,10 @@ as described in .Xr ifconfig 8 . .It Cm interface Ar name Set the +.Xr bridge 4 , .Xr switch 4 or -.Xr bridge 4 +.Xr veb 4 network interface of this switch. If the type is changed to .Ar switch0 , Index: vmctl/vmctl.8 === RCS file: /cvs/src/usr.sbin/vmctl/vmctl.8,v retrieving revision 1.72 diff -u -p -r1.72 vmctl.8 --- vmctl/vmctl.8 16 Feb 2020 11:03:25 - 1.72 +++ vmctl/vmctl.8 27 Feb 2021 00:07:41 - @@ -280,7 +280,7 @@ This tap/vio interface mapping allows guest network traffic to be manipulated by the host. Any valid host-side interface configuration may be performed on these tap interfaces, such as bridging (via -.Xr bridge 4 ) , +.Xr veb 4 ) , or using .Xr pf 4 nat-to rules to create private or host-side NATed networks, as desired. @@ -423,7 +423,7 @@ Terminate VM number 1: # vmctl stop 1 .Ed .Sh SEE ALSO -.Xr bridge 4 , +.Xr veb 4 , .Xr pf 4 , .Xr tap 4 , .Xr vio 4 ,
Re: veb(4) support for vmd(8)?
On Sat, Feb 27, 2021 at 09:44:03AM +1000, David Gwynne wrote: > > > > On 27 Feb 2021, at 7:50 am, Klemens Nanni wrote: > > > > On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wrote: > >> i think this is enough to let vmd wire guests up to veb interfaces. > > But please update vm.conf(5) to mention veb(4) and vport(4) in as well > > SWITCH CONFIGURATION. > > How would you fit wording about vport(4) in? > > > > > OK kn > Do we want to just talk only about veb/vport and remove all the old discussion around bridge/vether?
Re: veb(4) support for vmd(8)?
> On 27 Feb 2021, at 7:50 am, Klemens Nanni wrote: > > On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wrote: >> i think this is enough to let vmd wire guests up to veb interfaces. > But please update vm.conf(5) to mention veb(4) and vport(4) in as well > SWITCH CONFIGURATION. How would you fit wording about vport(4) in? > > OK kn
Re: 2 diffs for dev/acpi/dsdt.c
On Fri, 26 Feb 2021, YASUOKA Masahiko wrote: > Hi, > > My vaio repeatedly crashed by "Data modified on freelist"(*1) or other > memory corruptions. After my long time debug, I found the route cause > is a handling of references of LocalX, like the following: > > If ((SMRW (0x0B, 0x16, 0x21, RefOf (Local0)) == Zero)) > > In the called control method, "RefOf (Local1)" is referred as Arg3, is > stored a value like the following: > > Arg3 = \_SB.PCI0.LPCB.EC0.SMD0 > > In aml_store(), lvalue is reset if lvalue is a LocalX. But since that > was done before resolving the reference, lvalue was not reset if > lvalue is a reference of LocalX. > I can't ok the diff, but I did test that it doesn't do anything bad on one of my boxes if it helps dmesg below. -- OpenBSD 6.9-beta (GENERIC.MP) #0: Fri Feb 26 02:20:57 EST 2021 user@domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8192258048 (7812MB) avail mem = 7928631296 (7561MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xbc4b1000 (82 entries) bios0: vendor Dell Inc. version "1.5.0" date 07/09/2018 bios0: Dell Inc. Inspiron 7375 acpi0 at bios0: ACPI 5.0Undefined scope: \\_SB_.PCI0.LPC0.EC0_ acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SLIC MSDM SSDT CRAT CDIT UEFI ASF! BOOT HPET APIC MCFG SLIC WSMT VFCT IVRS SSDT SSDT SSDT SSDT FPDT SSDT BGRT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GP17(S4) XHC0(S0) XHC1(S0) GP18(S4) LID_(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx, 1996.61 MHz, 17-11-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx, 1996.26 MHz, 17-11-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx, 1996.25 MHz, 17-11-00 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx, 1996.26 MHz, 17-11-00 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 64KB
Re: veb(4) support for vmd(8)?
On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wrote: > i think this is enough to let vmd wire guests up to veb interfaces. But please update vm.conf(5) to mention veb(4) and vport(4) in as well SWITCH CONFIGURATION. OK kn
veb(4) support for vmd(8)?
i think this is enough to let vmd wire guests up to veb interfaces.
please remember that veb is not the same as bridge, so some care
has to be taken when replacing bridge with veb. the biggest difference
to note is that if you want the host to talk layer 3 (ie, ip, dhcp,
etc) with the guests, the host must have a vport(4) interface set
up for l3 and added to the veb(4). if you used vether for that, just
replace the vether interfaces with vports.
you can also have guests isolated from the host by not having vport
interfaces on their veb. you can still add a physical interface to the
veb to let guests talk l2 to the real world without having them talk to
the host they're running on.
lastly, veb doesnt filter (non-vport) ports by default. if you're
using pf and bridge to filter between guests, you have to allow pf
to run on veb by setting the link1 flag. care must be taken if
you're also filtering with pf on a vport(4) interface. if anyone is
having trouble with this bit and wants some more pointers, let me know.
i suspect you'll learn more from bitter experience though.
Index: config.c
===
RCS file: /cvs/src/usr.sbin/vmd/config.c,v
retrieving revision 1.58
diff -u -p -r1.58 config.c
--- config.c11 May 2019 19:55:14 - 1.58
+++ config.c26 Feb 2021 21:17:19 -
@@ -40,7 +40,7 @@
#include "vmd.h"
/* Supported bridge types */
-const char *vmd_descsw[] = { "switch", "bridge", NULL };
+const char *vmd_descsw[] = { "switch", "bridge", "veb", NULL };
static int config_init_localprefix(struct vmd_config *);
Index: priv.c
===
RCS file: /cvs/src/usr.sbin/vmd/priv.c,v
retrieving revision 1.15
diff -u -p -r1.15 priv.c
--- priv.c 28 Jun 2019 13:32:51 - 1.15
+++ priv.c 26 Feb 2021 21:17:19 -
@@ -81,7 +81,8 @@ priv_run(struct privsep *ps, struct priv
int
priv_dispatch_parent(int fd, struct privsep_proc *p, struct imsg *imsg)
{
- const char *desct[] = { "tap", "switch", "bridge", NULL };
+ const char *desct[] = { "tap", "switch", "bridge",
+"veb", NULL };
struct privsep *ps = p->p_ps;
struct vmop_ifreqvfr;
struct vmd *env = ps->ps_env;
Re: Add /dev/video0 to fbtab
On Thu, Feb 25, 2021 at 10:36:02PM +0100, Marcus Glocker wrote: > On Thu, Feb 25, 2021 at 09:14:06PM +, Stuart Henderson wrote: > > > On 2021/02/25 22:02, Marcus Glocker wrote: > > > On Thu, Feb 25, 2021 at 08:00:32PM +, Stuart Henderson wrote: > > > > > > > On 2021/02/25 20:10, Marcus Glocker wrote: > > > > > We had this discussion recently when fbtab(5) for xenodm(1) was fixed > > > > > 6 weeks ago, but we didn't come to an agreement yet. tb@ asked me the > > > > > same question yesterday whether we can add video(1) to fbtab to avoid > > > > > manual chown of /dev/video0, which I think a lot of people do today. > > > > > Therefore here another try to bring this up. > > > > > > > > I'm not sure this is something I would expect to be chmod'ed > > > > automatically.. It's a very different class of device than things > > > > currently in fbtab or Give/TakeConsole. > > > > > > > > At least if this is done we'll have to document it somewhere for people > > > > using ports like multimedia/motion. > > > > > > Um - I don't know this port, but glancing over it, it's a daemon running > > > under the _motion user which is accessing /dev/video*? So people > > > using that today are chowning /dev/video* to _motion? > > > > chown or chgrp - yes. > > I see. I wouldn't know what is the right place to document that the > video device would be owned by the console or xenodm login user. What > would you suggest, in the impacted port itself or centrally, like in the > video(4) man page? I guess I would document it in video(4). Index: etc/etc.amd64/fbtab === RCS file: /cvs/src/etc/etc.amd64/fbtab,v retrieving revision 1.8 diff -u -p -u -p -r1.8 fbtab --- etc/etc.amd64/fbtab 12 Feb 2021 10:26:33 - 1.8 +++ etc/etc.amd64/fbtab 26 Feb 2021 20:16:55 - @@ -1 +1,2 @@ -/dev/ttyC0 0600 /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/ttyC4:/dev/drm0:/dev/drmR128:/dev/dri/card0:/dev/dri/renderD128 +/dev/ttyC0 0600 /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/ttyC4:/dev/drm0:/dev/drmR128:/dev/dri/card0:/dev/dri/renderD128:/dev/video0 +/dev/ttyC4 0600/dev/video0 Index: etc/etc.i386/fbtab === RCS file: /cvs/src/etc/etc.i386/fbtab,v retrieving revision 1.15 diff -u -p -u -p -r1.15 fbtab --- etc/etc.i386/fbtab 12 Feb 2021 10:26:34 - 1.15 +++ etc/etc.i386/fbtab 26 Feb 2021 20:16:55 - @@ -1 +1,2 @@ -/dev/ttyC0 0600 /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/ttyC4:/dev/drm0:/dev/drmR128:/dev/dri/card0:/dev/dri/renderD128 +/dev/ttyC0 0600 /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/ttyC4:/dev/drm0:/dev/drmR128:/dev/dri/card0:/dev/dri/renderD128:/dev/video0 +/dev/ttyC4 0600/dev/video0 Index: etc/etc.macppc/fbtab === RCS file: /cvs/src/etc/etc.macppc/fbtab,v retrieving revision 1.13 diff -u -p -u -p -r1.13 fbtab --- etc/etc.macppc/fbtab12 Feb 2021 10:26:34 - 1.13 +++ etc/etc.macppc/fbtab26 Feb 2021 20:16:55 - @@ -1,3 +1,4 @@ /dev/ttya 0600/dev/console /dev/tty00 0600/dev/console -/dev/ttyC0 0600 /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/ttyC4:/dev/drm0:/dev/drmR128:/dev/dri/card0:/dev/dri/renderD128 +/dev/ttyC0 0600 /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/ttyC4:/dev/drm0:/dev/drmR128:/dev/dri/card0:/dev/dri/renderD128:/dev/video0 +/dev/ttyC4 0600/dev/video0 Index: share/man/man4/video.4 === RCS file: /cvs/src/share/man/man4/video.4,v retrieving revision 1.19 diff -u -p -u -p -r1.19 video.4 --- share/man/man4/video.4 29 Dec 2020 12:28:23 - 1.19 +++ share/man/man4/video.4 26 Feb 2021 20:16:56 - @@ -53,6 +53,15 @@ variable: kern.video.record=0# Recording is blanked (default) kern.video.record=1# Recording is enabled .Ed +.Pp +Primary console login or +.Xr xenodm 4 +login will change the +.Pa /dev/video0 +permissions to be owned by the login user by using +.Xr login_fbtab 3 . +This allows the usage of the primary video device without any need to change +the video device permissions manually. .Sh IOCTLS The following .Xr ioctl 2 @@ -455,11 +464,13 @@ ioctl command without blocking. .Sh FILES .Bl -tag -width /dev/video -compact .It Pa /dev/video +.It Pa /etc/fbtab .El .Sh SEE ALSO .Xr video 1 , .Xr ioctl 2 , -.Xr uvideo 4 +.Xr uvideo 4 , +.Xr fbtab 5 .Sh HISTORY The .Nm
Userspace syscall dispatch
Hello Is there functionality in OpenBSD similar to Linux's "PR_SET_SYSCALL_USER_DISPATCH" [1] which provides a way for userspace to handle foreign system calls? I am looking to run foreign software on OpenBSD after Linux compat was removed. I think that this is a good middle ground as it would allow developers to port these applications in userspace rather than adding more code to the kernel. Please let me know if this is functionality that is welcome in the OpenBSD kernel, I'd be interested in working on both the kernel and userspace code to support this. [1] https://lwn.net/ml/linux-kernel/20200712044516.2347844-2-kris...@collabora.com/ Thanks K
Re: OpenBSD perl 5.32.1 - Call for Testing
On Sat, Feb 20, 2021 at 02:11:45PM -0800, Andrew Hewus Fresh wrote:
> I've probably missed making it in for 6.9, but it is again time for
> testing a perl update so it can become /usr/bin/perl
It was pointed out that there is still time to get this in for 6.9, and
sthen@ says it looks OK in a bulk ports build, so I'll be working on
preparing the import this weekend. Please let me know of any reasons
to hold off.
>
> Several good changes this time:
> https://metacpan.org/pod/distribution/perl/pod/perl5320delta.pod
> https://metacpan.org/pod/release/SHAY/perl-5.32.1/pod/perldelta.pod
>
> * A new "isa" operator
> * A new feature "no indirect" that disables indirect object notation
> * Chained comparisons ( $x < $y <= $z )
> * Unicode 13.0
> * IO::Compress now comes with the streamzip utility.
>
> Plus a bunch of other unicode and regex things as well as new versions
> of many modules.
>
> It also includes the recent PERL_HASH fix for 64bit strict alignment
> architectures and removes several local patches that were merged
> upstream.
>
> It would be nice to get feedback on some of the architectures I don't
> have, and a bulk ports build to see what sort of fallout happens there.
>
> The logs for what I do have are here:
> https://github.com/afresh1/OpenBSD-perl/tree/blead/build_logs/perl-5.32.1
>
> Which are alpha, amd64, arm64, armv7, macppc, octeon, and sparc64.
>
> The issues I had in 5.30 with capturing output from forked processes on my
> alpha are still there, could just be that it's slow.
>
> For running the perl test suite, you can follow the instructions on
> github, repeated here:
>
> https://github.com/afresh1/OpenBSD-perl
>
> download the patches and scripts
> https://github.com/afresh1/OpenBSD-perl/archive/blead.tar.gz
> and extract someplace
> or git clone https://github.com/afresh1/OpenBSD-perl.git
> download perl-5.30.0.tar.gz into the same directory
> https://cpan.metacpan.org/authors/id/S/SH/SHAY/perl-5.32.1.tar.gz
> cd to someplace you have room
> run /path/to/OpenBSD-perl/build_perl
> wait
> send me the log file(s) it generates
>
>
> You can download a pre-patched version of perl that can be extracted to
> replace
> src/gnu/usr.bin/perl for building a system with the new perl:
> https://cvs.afresh1.com/~andrew/perl-update/OpenBSD-perl-5.32.1.tar.gz
>
> I also have what should be a mostly correct sets/lists patch for building a
> release.
> https://cvs.afresh1.com/~andrew/perl-update/OpenBSD-perl-5.32.1-sets.patch
>
> There are also several files that are no longer part of the perl distribution:
>
> rm -r /usr/bin/podselect \
> /usr/lib/libperl.so.20.0 \
> /usr/lib/libperl.so.21.0 \
> /usr/libdata/perl5/*/CORE/dquote_inline.h \
> /usr/libdata/perl5/*/Tie \
> /usr/libdata/perl5/*/auto/Tie \
> /usr/libdata/perl5/Pod/Find.pm \
> /usr/libdata/perl5/Pod/InputObjects.pm \
> /usr/libdata/perl5/Pod/ParseUtils.pm \
> /usr/libdata/perl5/Pod/Parser.pm \
> /usr/libdata/perl5/Pod/PlainText.pm \
> /usr/libdata/perl5/Pod/Select.pm \
> /usr/libdata/perl5/pod/perlce.pod \
> /usr/libdata/perl5/unicore/Heavy.pl \
> /usr/libdata/perl5/unicore/lib/Lb/EB.pl \
> /usr/libdata/perl5/unicore/lib/Perl/_PerlNon.pl \
> /usr/libdata/perl5/unicore/lib/Sc/Armn.pl \
> /usr/libdata/perl5/utf8_heavy.pl \
> /usr/share/man/man1/podselect.1 \
> /usr/share/man/man3p/Pod::Find.3p \
> /usr/share/man/man3p/Pod::InputObjects.3p \
> /usr/share/man/man3p/Pod::ParseUtils.3p \
> /usr/share/man/man3p/Pod::Parser.3p \
> /usr/share/man/man3p/Pod::PlainText.3p \
> /usr/share/man/man3p/Pod::Select.3p
>
>
> There's also patch file that should apply to a -current tree updating to
> perl 5.32.1. You'll still need the sets lists patch if you're planning
> to build a release.
>
> https://cvs.afresh1.com/~andrew/perl-update/OpenBSD-perl-5.32.1.patch
>
> Unfortunately the patch doesn't actually apply due to non-ascii files in
> the diff, not quite sure the magic incantation to make that work, so I
> recommend replacing src/gnu/usr.bin/perl with the extracted tar.gz
> linked above.
>
> If it did apply, you would copy the patch to /usr/src/perl-5.32.1.patch
> (or adjust the paths below)
>
> cd /usr/src/
> patch -p0 -uNE < perl-5.32.1.patch
>
> # Remove patch cruft
> find gnu/usr.bin/perl -name '*.orig' -delete
>
> # Add and remove binary and zero sized files that patch doesn't understand
> grep -B1 -e '^Index:' -e 'Binary files /tmp/.* and /dev/null differ' \
> perl-5.32.1.patch | sed -ne 's/^diff -N //p' |
> while read f; do if [ -e $f ]; then rm $f; else touch $f; fi; done
>
> cd gnu/usr.bin/perl && find -d . \
> \( -type d -o -path '*/CVS' -prune \) \
> ! -name CVS \
> -exec test -e {}/CVS \; \
> -execdir sh -c 'test $( ls -1 {} | grep -v '^CVS/$' | wc -l ) -eq 0' \; \
>
Variablise \n and some regression tests
This diff puts the hardcoded '\n' character which is found throughout mg
into a buffer specific variable. The diff should not produce any behavourial
difference in mg, it is only to facilitate other work I am doing on mg.
In order for me to validate that there is no behavioural difference I
created some regression tests:
https://mg-regress.s3-eu-west-1.amazonaws.com/regress.dir.007.tgz
If you want to run the regressions tests, the instructions are in
the file: regress/mg.regress.tests. The tests are performed by the mg
eval-current-buffer function, they are not 'make' style tests. I will add
more tests as time allows.
Are there any objections to the diff? Or oks?
Feedback on the tests, or more tests added would be appreciated.
Mark
Index: buffer.c
===
RCS file: /cvs/src/usr.bin/mg/buffer.c,v
retrieving revision 1.107
diff -u -p -u -p -r1.107 buffer.c
--- buffer.c24 Jun 2019 14:57:56 - 1.107
+++ buffer.c26 Feb 2021 14:33:43 -
@@ -589,6 +589,8 @@ bnew(const char *bname)
bheadp = bp;
bp->b_dotline = bp->b_markline = 1;
bp->b_lines = 1;
+ bp->b_nlseq = "\n";/* use unix default */
+ bp->b_nlchr = bp->b_nlseq;
if ((bp->b_bname = strdup(bname)) == NULL) {
dobeep();
ewprintf("Can't get %d bytes", strlen(bname) + 1);
@@ -1022,7 +1024,7 @@ diffbuffer(int f, int n)
ttext += llength(lp);
}
if (lforw(lp) != lpend) /* no implied \n on last line */
- *ttext++ = '\n';
+ *ttext++ = *curbp->b_nlchr;
}
bp = bfind("*Diff*", TRUE);
Index: cscope.c
===
RCS file: /cvs/src/usr.bin/mg/cscope.c,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 cscope.c
--- cscope.c3 Jul 2019 03:24:02 - 1.18
+++ cscope.c26 Feb 2021 14:33:43 -
@@ -226,7 +226,7 @@ cscreatelist(int f, int n)
addline(bp, title);
addline(bp, "");
while ((len = getline(, , fpipe)) != -1) {
- if (line[len - 1] == '\n')
+ if (line[len - 1] == *bp->b_nlchr)
line[len - 1] = '\0';
addline(bp, line);
}
@@ -459,7 +459,7 @@ do_cscope(int i)
addline(bp, "");
addline(bp,
"---");
while ((len = getline(, , fpipe)) != -1) {
- if (buf[len - 1] == '\n')
+ if (buf[len - 1] == *bp->b_nlchr)
buf[len - 1] = '\0';
if (addentry(bp, buf) != TRUE) {
free(buf);
Index: def.h
===
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.167
diff -u -p -u -p -r1.167 def.h
--- def.h 23 Feb 2021 08:10:51 - 1.167
+++ def.h 26 Feb 2021 14:33:43 -
@@ -267,6 +267,8 @@ struct buffer {
char b_flag;/* Flags */
char b_fname[NFILEN]; /* File name */
char b_cwd[NFILEN]; /* working directory */
+ char*b_nlseq; /* Newline sequence of chars */
+ char*b_nlchr; /* 1st newline character */
struct fileinfo b_fi; /* File attributes */
struct undoq b_undo;/* Undo actions list */
struct undo_rec *b_undoptr;
Index: dired.c
===
RCS file: /cvs/src/usr.bin/mg/dired.c,v
retrieving revision 1.96
diff -u -p -u -p -r1.96 dired.c
--- dired.c 26 Feb 2021 07:21:23 - 1.96
+++ dired.c 26 Feb 2021 14:33:43 -
@@ -698,11 +698,12 @@ d_exec(int space, struct buffer *bp, con
if ((fin = fdopen(fds[0], "r")) == NULL)
goto out;
while (fgets(buf, sizeof(buf), fin) != NULL) {
- cp = strrchr(buf, '\n');
+ cp = strrchr(buf, *bp->b_nlchr);
if (cp == NULL && !feof(fin)) { /* too long a line */
int c;
addlinef(bp, "%*s%s...", space, "", buf);
- while ((c = getc(fin)) != EOF && c != '\n')
+ while ((c = getc(fin)) != EOF &&
+ c != *bp->b_nlchr)
;
continue;
} else if (cp)
Index: echo.c
===
RCS file: /cvs/src/usr.bin/mg/echo.c,v
retrieving revision 1.66
diff -u -p -u -p -r1.66 echo.c
--- echo.c 24 Oct 2016
Re: Userspace syscall dispatch
There is nothing beyond SIGILL. Why would we want such a thing? We are operating in a source-code-available world. Why would any one us want to encourage a must-run-binaries future? The history of syscall-compatibility in BSD operating systems has been forgotten. Back in the NetBSD days, Chris Torek had written 32-bit sparc code which was not part of 4.4BSD. His unmerged changes modified various parts of the kernel to be more like SunOS. To merge the code and transition the ABI to native, I created the first compat layer, including a stack-trick for argument rewriting. The SunOS compat later convered into BSDOS, hp300, and eventually linux compat. These approaches were eventually copied by other BSD's. None of the compat layers were ever complete -- maintaining such layers is always purely reactionary -- they will always be incomplete, very small numbers of developers use a small amount of their time to handle increasingly ugly edge cases on a best-effort basis, when an application requests something new. The compatibility is never 100%, therefore applications can hid edge cases and perform incorrectly. Therefore as time went by, we increasingly considered these incomplete poorly-maintained layers in the kernel, used by very few, as being BIG RISK, and deleted the code. Not interested in trying again. If you want to run binary garbage, setup a VM running an ACCURATE implimentation of the operating system the binary is intended to run on. Keegan Saunders wrote: > Hello > > Is there functionality in OpenBSD similar to Linux's > "PR_SET_SYSCALL_USER_DISPATCH" [1] which provides a way for userspace to > handle foreign system calls? > > I am looking to run foreign software on OpenBSD after Linux compat was > removed. I think that this is a good middle ground as it would allow > developers to port these applications in userspace rather than adding more > code to the kernel. > > Please let me know if this is functionality that is welcome in the OpenBSD > kernel, I'd be interested in working on both the kernel and userspace code to > support this. > > [1] > https://lwn.net/ml/linux-kernel/20200712044516.2347844-2-kris...@collabora.com/ > > Thanks > K
ixl(4): add missing pci dev id for X710 10GBase-T
Hi,
The diff below adds a missing PCI device ID for an X710 10GBase NIC into
the ixl(4) driver. The interfaces attach and run properly with this
diff.
ixl0 at pci11 dev 0 function 0 "Intel X710 10GBaseT" rev 0x02: port 0, FW
8.1.63299 API 1.12, msix, 8 queues, address 3c:ec:ef:1f:c3:ba
ixl1 at pci11 dev 0 function 1 "Intel X710 10GBaseT" rev 0x02: port 2, FW
8.1.63299 API 1.12, msix, 8 queues, address 3c:ec:ef:1f:c3:bb
# ifconfig ixl
ixl0: flags=8843 mtu 1500
lladdr 3c:ec:ef:1f:c3:ba
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 192.168.123.1 netmask 0xff00 broadcast 192.168.123.255
ixl1: flags=8843 mtu 1500
lladdr 3c:ec:ef:1f:c3:bb
index 2 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 192.168.124.1 netmask 0xff00 broadcast 192.168.124.255
OK?
bye,
Jan
Index: dev/pci/if_ixl.c
===
RCS file: /cvs/src/sys/dev/pci/if_ixl.c,v
retrieving revision 1.72
diff -u -p -r1.72 if_ixl.c
--- dev/pci/if_ixl.c25 Jan 2021 11:11:22 - 1.72
+++ dev/pci/if_ixl.c26 Feb 2021 09:51:56 -
@@ -1622,6 +1622,7 @@ static const struct ixl_device ixl_devic
{ _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X710_T4_10G },
{ _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_XXV710_25G_BP },
{ _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_XXV710_25G_SFP28, },
+ { _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X710_10G_T, },
{ _722, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X722_10G_KX },
{ _722, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X722_10G_QSFP },
{ _722, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X722_10G_SFP_1 },
Index: dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1956
diff -u -p -r1.1956 pcidevs
--- dev/pci/pcidevs 22 Feb 2021 01:17:23 - 1.1956
+++ dev/pci/pcidevs 26 Feb 2021 09:49:01 -
@@ -3962,6 +3962,7 @@ product INTEL I219_V140x15fa I219-V
product INTEL I219_LM130x15fb I219-LM
product INTEL I219_V13 0x15fc I219-V
product INTEL I225_BLANK_NVM 0x15fd I225
+product INTEL X710_10G_T 0x15ff X710 10GBaseT
product INTEL CORE5G_H_PCIE_X160x1601 Core 5G PCIE
product INTEL CORE5G_M_GT1_1 0x1602 HD Graphics
product INTEL CORE5G_THERM 0x1603 Core 5G Thermal
Index: dev/pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1949
diff -u -p -r1.1949 pcidevs.h
--- dev/pci/pcidevs.h 22 Feb 2021 01:18:01 - 1.1949
+++ dev/pci/pcidevs.h 26 Feb 2021 09:49:05 -
@@ -3967,6 +3967,7 @@
#definePCI_PRODUCT_INTEL_I219_LM13 0x15fb /* I219-LM */
#definePCI_PRODUCT_INTEL_I219_V13 0x15fc /* I219-V */
#definePCI_PRODUCT_INTEL_I225_BLANK_NVM0x15fd /* I225
*/
+#definePCI_PRODUCT_INTEL_X710_10G_T0x15ff /* X710
10GBaseT */
#definePCI_PRODUCT_INTEL_CORE5G_H_PCIE_X16 0x1601 /* Core
5G PCIE */
#definePCI_PRODUCT_INTEL_CORE5G_M_GT1_10x1602 /* HD
Graphics */
#definePCI_PRODUCT_INTEL_CORE5G_THERM 0x1603 /* Core 5G
Thermal */
Index: dev/pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1944
diff -u -p -r1.1944 pcidevs_data.h
--- dev/pci/pcidevs_data.h 22 Feb 2021 01:18:01 - 1.1944
+++ dev/pci/pcidevs_data.h 26 Feb 2021 09:49:05 -
@@ -13292,6 +13292,10 @@ static const struct pci_known_product pc
"I225",
},
{
+ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X710_10G_T,
+ "X710 10GBaseT",
+ },
+ {
PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_CORE5G_H_PCIE_X16,
"Core 5G PCIE",
},
Mesa leak in intel iris driver
Bring in a change which was backported to Mesa 20.1 but not 20.0.
This is for inteldrm with >= gen8/broadwell hardware.
/var/log/Xorg.0.log with 'DRI driver: iris' and 'xdriinfo' will
show 'Screen 0: iris' if you are using the iris driver.
commit 17991448a2eb0930b106068bffc366946a05556e
Author: Kenneth Graunke
Date: Wed Jun 5 13:12:58 2019 -0700
iris: Delete shader variants when deleting the API-facing shader
We were space-leaking iris_compiled_shader objects, leaving them around
basically forever - long after the associated iris_uncompiled_shader was
deleted. Perhaps even more importantly, this left the BO containing the
assembly referenced, meaning those were never reclaimed either. For
long running applications, this can leak quite a bit of memory.
Now, when freeing iris_uncompiled_shader, we hunt down any associated
iris_compiled_shader objects and pitch those (and their BO) as well.
One issue is that the shader variants can still be bound, because we
haven't done a draw that updates the compiled shaders yet. This can
cause issues because state changes want to look at the old program to
know what to flag dirty. It's a bit tricky to get right, so instead
we defer variant deletion until the shaders are properly unbound, by
stashing them on a "dead" list and tidying that each time we try and
delete some shader variants.
This ensures long running programs delete their shaders eventually.
Fixes: ed4ffb97158 ("iris: rework program cache interface")
Reviewed-by: Matt Turner
Part-of:
(cherry picked from commit 128cbcd3a7ba543d644ed3189dcd668900b270f4)
Index: src/gallium/drivers/iris/iris_context.h
===
RCS file: /cvs/xenocara/lib/mesa/src/gallium/drivers/iris/iris_context.h,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 iris_context.h
--- src/gallium/drivers/iris/iris_context.h 22 Sep 2020 01:31:05 -
1.1.1.3
+++ src/gallium/drivers/iris/iris_context.h 26 Feb 2021 13:06:09 -
@@ -406,6 +406,8 @@ struct iris_binding_table {
* (iris_uncompiled_shader), due to state-based recompiles (brw_*_prog_key).
*/
struct iris_compiled_shader {
+ struct list_head link;
+
/** Reference to the uploaded assembly. */
struct iris_state_ref assembly;
@@ -664,6 +666,9 @@ struct iris_context {
struct iris_compiled_shader *prog[MESA_SHADER_STAGES];
struct brw_vue_map *last_vue_map;
+ /** List of shader variants whose deletion has been deferred for now */
+ struct list_head deleted_variants[MESA_SHADER_STAGES];
+
struct u_upload_mgr *uploader;
struct hash_table *cache;
@@ -945,6 +950,8 @@ struct iris_compiled_shader *iris_upload
const void *iris_find_previous_compile(const struct iris_context *ice,
enum iris_program_cache_id cache_id,
unsigned program_string_id);
+void iris_delete_shader_variants(struct iris_context *ice,
+ struct iris_uncompiled_shader *ish);
bool iris_blorp_lookup_shader(struct blorp_batch *blorp_batch,
const void *key,
uint32_t key_size,
Index: src/gallium/drivers/iris/iris_program.c
===
RCS file: /cvs/xenocara/lib/mesa/src/gallium/drivers/iris/iris_program.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 iris_program.c
--- src/gallium/drivers/iris/iris_program.c 22 Sep 2020 01:31:05 -
1.1.1.3
+++ src/gallium/drivers/iris/iris_program.c 26 Feb 2021 13:06:09 -
@@ -1812,9 +1812,6 @@ get_vue_prog_data(struct iris_context *i
return (void *) ice->shaders.prog[stage]->prog_data;
}
-// XXX: iris_compiled_shaders are space-leaking :(
-// XXX: do remember to unbind them if deleting them.
-
/**
* Update the current shader variants for the given state.
*
@@ -2387,6 +2384,8 @@ iris_delete_shader_state(struct pipe_con
pipe_resource_reference(>const_data, NULL);
pipe_resource_reference(>const_data_state.res, NULL);
}
+
+ iris_delete_shader_variants(ice, ish);
ralloc_free(ish->nir);
free(ish);
Index: src/gallium/drivers/iris/iris_program_cache.c
===
RCS file: /cvs/xenocara/lib/mesa/src/gallium/drivers/iris/iris_program_cache.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 iris_program_cache.c
--- src/gallium/drivers/iris/iris_program_cache.c 22 Sep 2020 01:31:06
- 1.1.1.3
+++ src/gallium/drivers/iris/iris_program_cache.c 26 Feb 2021 13:06:09
-
@@ -115,6 +115,59 @@ iris_find_previous_compile(const struct
return NULL;
}
+void
+iris_delete_shader_variants(struct iris_context *ice,
+
Re: mg: minibuffer anomaly
I consider the name "null" for a goto section as too misleading.
I would prefer something like "nokey" or "skipkey".
Cheers,
Emil Engler
On Thu, Feb 25, 2021 at 07:40:01PM +, Mark Lumsden wrote:
> I was testing mg's goto-line function via the minibuffer (M-x goto-line) and
> I just kept my finger on the '0' key. After a brief time '0's started
> appearing in the main buffer, where the cursor had been. For a second I
> thought there had been an issue with memory allocation but after looking at
> the code I see what happens is when the memory allocated to the minibuffer
> fills up, a message "Line too long." should show in the minibuffer. It
> probably did, but since I was pressing the '0' key it disappeared instantly
> and I didn't realise that mg had tried to inform me of my error. mg then
> continued to accept my '0's as normal input.
>
> This diff soaks up the user input while the the maximum character length
> boundary is crossed in the minbuffer and allows the user to see the error
> message and respond accordingly.
>
> There may be other ways to handle this situation (like not pressing the '0'
> key so many times) but I think having mg do something is better than
> it *seemingly* not do anything. Any suggestions/preferences/better
> solutions?
>
> Mark
>
> Index: echo.c
> ===
> RCS file: /cvs/src/usr.bin/mg/echo.c,v
> retrieving revision 1.66
> diff -u -p -u -p -r1.66 echo.c
> --- echo.c24 Oct 2016 17:18:42 - 1.66
> +++ echo.c25 Feb 2021 19:06:21 -
> @@ -336,8 +336,8 @@ veread(const char *fp, char *buf, size_t
> }
> if (!dynbuf && epos + 1 >= nbuf) {
> dobeep();
> - ewprintf("Line too long");
> - return (emptyval);
> + ewprintf("Line too long. Press Enter.");
> + goto null;
> }
> for (t = epos; t > cpos; t--)
> buf[t] = buf[t - 1];
> @@ -492,8 +492,8 @@ veread(const char *fp, char *buf, size_t
> }
> if (!dynbuf && epos + 1 >= nbuf) {
> dobeep();
> - ewprintf("Line too long");
> - return (emptyval);
> + ewprintf("Line too long. Press Enter.");
> + goto null;
> }
> for (i = epos; i > cpos; i--)
> buf[i] = buf[i - 1];
> @@ -507,6 +507,9 @@ veread(const char *fp, char *buf, size_t
> ttmove(rr, cc);
> ttflush();
> }
> +
> +null:/* soak up any continuing key strokes */
> +;
> }
> done:
> if (cwin == TRUE) {
>
ip_fragment ip6_fragment
Hi,
I always bothered me that ip_fragment() and ip6_fragment() behave
sligtly differently. Unify them and use an mlist to simplify the
fragment list.
- The functions ip_fragment() and ip6_fragment() always consume the mbuf.
- They free the mbuf and mbuf list in case of an error.
- They care about the counter.
- Adjust the code a bit to make v4 and v6 look similar.
- Maybe there was an mbuf leak when pf_route6() called pf_refragment6()
and it failed. Now the mbuf is always freed by ip6_fragment().
ok?
bluhm
Index: net/if_bridge.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.352
diff -u -p -r1.352 if_bridge.c
--- net/if_bridge.c 25 Feb 2021 02:48:21 - 1.352
+++ net/if_bridge.c 26 Feb 2021 10:41:57 -
@@ -1853,7 +1853,7 @@ bridge_fragment(struct ifnet *brifp, str
struct mbuf *m)
{
struct llc llc;
- struct mbuf *m0;
+ struct mbuf_list ml;
int error = 0;
int hassnap = 0;
u_int16_t etype;
@@ -1911,40 +1911,32 @@ bridge_fragment(struct ifnet *brifp, str
return;
}
- error = ip_fragment(m, ifp, ifp->if_mtu);
- if (error) {
- m = NULL;
- goto dropit;
- }
+ error = ip_fragment(m, , ifp, ifp->if_mtu);
+ if (error)
+ return;
- for (; m; m = m0) {
- m0 = m->m_nextpkt;
- m->m_nextpkt = NULL;
- if (error == 0) {
- if (hassnap) {
- M_PREPEND(m, LLC_SNAPFRAMELEN, M_DONTWAIT);
- if (m == NULL) {
- error = ENOBUFS;
- continue;
- }
- bcopy(, mtod(m, caddr_t),
- LLC_SNAPFRAMELEN);
- }
- M_PREPEND(m, sizeof(*eh), M_DONTWAIT);
+ while ((m = ml_dequeue()) != NULL) {
+ if (hassnap) {
+ M_PREPEND(m, LLC_SNAPFRAMELEN, M_DONTWAIT);
if (m == NULL) {
error = ENOBUFS;
- continue;
+ break;
}
- bcopy(eh, mtod(m, caddr_t), sizeof(*eh));
- error = bridge_ifenqueue(brifp, ifp, m);
- if (error) {
- continue;
- }
- } else
- m_freem(m);
+ bcopy(, mtod(m, caddr_t), LLC_SNAPFRAMELEN);
+ }
+ M_PREPEND(m, sizeof(*eh), M_DONTWAIT);
+ if (m == NULL) {
+ error = ENOBUFS;
+ break;
+ }
+ bcopy(eh, mtod(m, caddr_t), sizeof(*eh));
+ error = bridge_ifenqueue(brifp, ifp, m);
+ if (error)
+ break;
}
-
- if (error == 0)
+ if (error)
+ ml_purge();
+ else
ipstat_inc(ips_fragmented);
return;
Index: net/pf.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf.c,v
retrieving revision 1.1112
diff -u -p -r1.1112 pf.c
--- net/pf.c23 Feb 2021 11:43:40 - 1.1112
+++ net/pf.c26 Feb 2021 10:41:57 -
@@ -5969,7 +5969,8 @@ pf_rtlabel_match(struct pf_addr *addr, s
void
pf_route(struct pf_pdesc *pd, struct pf_state *s)
{
- struct mbuf *m0, *m1;
+ struct mbuf *m0;
+ struct mbuf_list ml;
struct sockaddr_in *dst, sin;
struct rtentry *rt = NULL;
struct ip *ip;
@@ -6078,23 +6079,18 @@ pf_route(struct pf_pdesc *pd, struct pf_
goto bad;
}
- m1 = m0;
- error = ip_fragment(m0, ifp, ifp->if_mtu);
- if (error) {
- m0 = NULL;
- goto bad;
- }
+ error = ip_fragment(m0, , ifp, ifp->if_mtu);
+ if (error)
+ goto done;
- for (m0 = m1; m0; m0 = m1) {
- m1 = m0->m_nextpkt;
- m0->m_nextpkt = NULL;
- if (error == 0)
- error = ifp->if_output(ifp, m0, sintosa(dst), rt);
- else
- m_freem(m0);
+ while ((m0 = ml_dequeue()) != NULL) {
+ error = ifp->if_output(ifp, m0, sintosa(dst), rt);
+ if (error)
+ break;
}
-
- if (error == 0)
+ if (error)
+ ml_purge();
+ else
ipstat_inc(ips_fragmented);
done:
Index: net/pf_norm.c
===
RCS file:
Re: Sky Lake-E PCI ids.
On 2/26/21 7:24 AM, Jonathan Gray wrote: As the ids are used on more than just Skylake-E here is another diff. Though I think these ids are shared with Core X Skylake. So perhaps giving up on a marketing name is indeed the thing to do. Indeed, Intel made quite a mess in this, but I think this your combination is probably the best one, although we risk to show "Xeon" on user system with high-end Core X cpus. The thing is those makes minority of all the chips in the family and technically they are crippled Xeons anyway, so if I may I would vote for this diff. Thanks a lot for dealing with this mess. Index: pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1956 diff -u -p -r1.1956 pcidevs --- pcidevs 22 Feb 2021 01:17:23 - 1.1956 +++ pcidevs 26 Feb 2021 05:39:05 - @@ -4188,6 +4188,61 @@ product INTEL ATOMC2000_PCU_SMB 0x1f3c A product INTEL I354_BP_1GBPS 0x1f40 I354 product INTEL I354_SGMII 0x1f41 I354 SGMII product INTEL I354_BP_2_5GBPS 0x1f45 I354 +product INTEL XEONS_UBOX_1 0x2014 Xeon Scalable Ubox +product INTEL XEONS_UBOX_2 0x2015 Xeon Scalable Ubox +product INTEL XEONS_UBOX_3 0x2016 Xeon Scalable Ubox
