Re: bgpd config regress powerpc64
On Wed, Apr 14, 2021 at 11:56:08PM +0200, Alexander Bluhm wrote:
> Hi,
>
> On powerpc64 regress/usr.sbin/bgpd/config fails. It parses a config
> file, writes bgpd's config to stdout and compares it with an expected
> output.
>
> On powerpc64 the order of the set of communities is different.
>
> The parser uses memcmp(3) to sort a struct of integers. This depends
> of the endianess. The correct way is to compare the integer fields
> in native byte order.
>
> With this diff, the resulting order is the same on i386 and poerpc64.
> Also on powerpc64 the fix does not change bgpd's output. memcmp(3)
> and field comparison are equivalent on big endian architectures.
>
> ok?
OK claudio@
There are more places where communities are memcmp (filterset_cmp(),
filterset_equal()) but in these cases only equality matters.
filterset_add() needs to ensure that equal filterset lists are always
sorted the same way.
> Index: usr.sbin/bgpd/parse.y
> ===
> RCS file: /mount/openbsd/cvs/src/usr.sbin/bgpd/parse.y,v
> retrieving revision 1.414
> diff -u -p -r1.414 parse.y
> --- usr.sbin/bgpd/parse.y 2 Mar 2021 09:45:07 - 1.414
> +++ usr.sbin/bgpd/parse.y 14 Apr 2021 21:09:47 -
> @@ -3558,6 +3558,28 @@ symget(const char *nam)
> }
>
> static int
> +cmpcommunity(struct community *a, struct community *b)
> +{
> + if (a->flags > b->flags)
> + return 1;
> + if (a->flags < b->flags)
> + return -1;
> + if (a->data1 > b->data1)
> + return 1;
> + if (a->data1 < b->data1)
> + return -1;
> + if (a->data2 > b->data2)
> + return 1;
> + if (a->data2 < b->data2)
> + return -1;
> + if (a->data3 > b->data3)
> + return 1;
> + if (a->data3 < b->data3)
> + return -1;
> + return 0;
> +}
> +
> +static int
> getcommunity(char *s, int large, u_int32_t *val, u_int32_t *flag)
> {
> long longmax = USHRT_MAX;
> @@ -4396,16 +4418,17 @@ filterset_add(struct filter_set_head *sh
> switch (s->type) {
> case ACTION_SET_COMMUNITY:
> case ACTION_DEL_COMMUNITY:
> - if (memcmp(>action.community,
> - >action.community,
> - sizeof(s->action.community)) < 0) {
> + switch (cmpcommunity(>action.community,
> + >action.community)) {
> + case -1:
> TAILQ_INSERT_BEFORE(t, s, entry);
> return;
> - } else if (memcmp(>action.community,
> - >action.community,
> - sizeof(s->action.community)) == 0)
> + case 0:
> break;
> - continue;
> + case 1:
> + continue;
> + }
> + break;
> case ACTION_SET_NEXTHOP:
> /* only last nexthop per AF matters */
> if (s->action.nexthop.aid <
> Index: regress/usr.sbin/bgpd/config/bgpd.conf.10.ok
> ===
> RCS file:
> /mount/openbsd/cvs/src/regress/usr.sbin/bgpd/config/bgpd.conf.10.ok,v
> retrieving revision 1.6
> diff -u -p -r1.6 bgpd.conf.10.ok
> --- regress/usr.sbin/bgpd/config/bgpd.conf.10.ok 17 Jul 2019 10:27:50
> - 1.6
> +++ regress/usr.sbin/bgpd/config/bgpd.conf.10.ok 14 Apr 2021 21:14:42
> -
> @@ -40,4 +40,4 @@ match from any large-community 1234:5678
> match from any large-community 1234:5678:1 large-community 1234:5678:2
> large-community 1234:5678:3
> match from any community 1234:1 large-community 1234:5678:1
> match from any large-community 1234:5678:1 community 1234:1
> -match from any set { community delete 1234:5678 community delete 1234:*
> community delete *:5678 community delete local-as:5678 community delete
> local-as:neighbor-as large-community delete 1234:15:5678 large-community
> delete *:15:5678 large-community delete local-as:15:5678 large-community
> delete local-as:15:* large-community delete local-as:15:neighbor-as
> large-community delete local-as:*:* community 1234:5678 community
> local-as:5678 community local-as:neighbor-as large-community 1234:15:5678
> large-community local-as:15:5678 large-community local-as:15:neighbor-as }
> +match from any set { community delete 1234:5678 large-community delete
> 1234:15:5678 community delete *:5678 large-community delete *:15:5678
> community delete local-as:5678 large-community delete local-as:15:5678
> community delete 1234:* community
Re: tcpdump wireguard big endian
On Wed, 14 Apr 2021 17:42:57 +0200
Alexander Bluhm wrote:
> Hi,
>
> regress/sys/net/wg fails on powerpc64 as tcpdump(8) cannot parse
> wireguard packets. EXTRACT_LE_32BITS() converts the type from
> little endian to host endian. So we need the constants in host
> endianess.
>
> ok?
Makes sense. I haven't tested on my side, but it reads OK.
> bluhm
>
> Index: print-wg.c
> ===
> RCS file: /mount/openbsd/cvs/src/usr.sbin/tcpdump/print-wg.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 print-wg.c
> --- print-wg.c20 Jul 2020 02:24:24 - 1.5
> +++ print-wg.c14 Apr 2021 15:35:19 -
> @@ -25,10 +25,10 @@
> #include "interface.h"
> #include "extract.h"
>
> -#define INITIATION htole32(1)
> -#define RESPONSE htole32(2)
> -#define COOKIE htole32(3)
> -#define DATA htole32(4)
> +#define INITIATION 1
> +#define RESPONSE 2
> +#define COOKIE 3
> +#define DATA 4
>
> struct wg_initiation {
> uint32_ttype;
>
Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)
Am Thu, Apr 15, 2021 at 12:47:44AM +0200 schrieb Patrick Wildt:
> On Wed, Apr 14, 2021 at 11:20:56PM +0200, Patrick Wildt wrote:
> > Am Wed, Apr 14, 2021 at 10:55:14PM +0200 schrieb Mark Kettenis:
> > > > Date: Wed, 14 Apr 2021 22:25:16 +0200
> > > > From: Patrick Wildt
> > > >
> > > > Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt:
> > > > > Hi,
> > > > >
> > > > > Parallels 16 for Mac supports the Apple M1 SoC now, and since it does
> > > > > provide an EFI 'BIOS', our images boot out of the box (once converted
> > > > > to 'hdd' or supplied as USB stick).
> > > > >
> > > > > Unfortunately virtio doesn't attach, because Parallels seems to
> > > > > provide
> > > > > a 'new' version 2. The following diff adds support for version 2 and
> > > > > I used it to install the VM over vio(4) network. And I was able to
> > > > > install packages over vio(4) network. Disk is ahci(4), USB
> > > > > passthrough
> > > > > is xhci(4), so that works nicely out of the box.
> > > > >
> > > > > Not sure if we want this for 6.9 or not. I think it wouldn't break
> > > > > the
> > > > > current version 1, so I think it shouldn't hurt.
> > > > >
> > > > > If you're wondering why I'm 'so late' with this: jcs@ asked me to have
> > > > > a look at the official Parallels for M1 release, and I just did that.
> > > > > So I couldn't be any faster than this anyway.
> > > > >
> > > > > Opinions?
> > > > >
> > > > > Patrick
> > > >
> > > > Obviously I forgot to pay dmesg tax ;)
> > > >
>
> Things change a little when you run 'machine acpi' in efiboot.
And here's the DSDT (thanks to jcs@). I think audio (HDEF) should be
easy, I believe we only need to attach Azalia to that device, rest
hopefully 'just works'. PNP0D20 is ehci, that should be easy as
well. Not sure about video... There's also an Ethernet device.
Btw, this is just a bit of ACPI info dump, which is unrelated to this
diff.
/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20200925 (64-bit version)
* Copyright (c) 2000 - 2020 Intel Corporation
*
* Disassembling to symbolic ASL+ operators
*
* Disassembly of DSDT.2, Wed Apr 14 17:46:36 2021
*
* Original Table Header:
* Signature"DSDT"
* Length 0x0AC6 (2758)
* Revision 0x02
* Checksum 0x9D
* OEM ID "PRLS "
* OEM Table ID "PRLS_OEM"
* OEM Revision 0x0003 (3)
* Compiler ID "INTL"
* Compiler Version 0x20160527 (538314023)
*/
DefinitionBlock ("", "DSDT", 2, "PRLS ", "PRLS_OEM", 0x0003)
{
Scope (_SB)
{
OperationRegion (MBOX, SystemMemory, 0x0210, 0x4000)
Field (MBOX, DWordAcc, NoLock, Preserve)
{
MVER, 32,
RAM,32,
CPUM, 32,
MUSB, 32,
MUFS, 32,
MAHC, 32,
VRAM, 32,
MSER, 32,
MHDA, 32,
GPU,32,
LOON, 32,
TOOL, 32,
NET,32
}
Device (CP00)
{
Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware ID
Name (_UID, Zero) // _UID: Unique ID
}
Device (CP01)
{
Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
}
Device (CP02)
{
Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware ID
Name (_UID, 0x02) // _UID: Unique ID
}
Device (CP03)
{
Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware ID
Name (_UID, 0x03) // _UID: Unique ID
}
Device (CP04)
{
Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware ID
Name (_UID, 0x04) // _UID: Unique ID
}
Device (CP05)
{
Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware ID
Name (_UID, 0x05) // _UID: Unique ID
}
Device (CP06)
{
Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware ID
Name (_UID, 0x06) // _UID: Unique ID
}
Device (CP07)
{
Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware ID
Name (_UID, 0x07) // _UID: Unique ID
}
Device (PWRB)
{
Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */) // _HID:
Hardware ID
}
OperationRegion (PWRM, SystemMemory, 0x02108000, 0x4000)
Field (PWRM, AnyAcc, NoLock, Preserve)
{
BATC, 32,
PONL, 32,
Offset (0x100),
Offset (0x110),
TEMP, 16,
VOLT, 16,
CURR, 16,
ACUR, 16,
Offset (0x11A),
Offset (0x11C),
Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)
On Wed, Apr 14, 2021 at 11:20:56PM +0200, Patrick Wildt wrote: > Am Wed, Apr 14, 2021 at 10:55:14PM +0200 schrieb Mark Kettenis: > > > Date: Wed, 14 Apr 2021 22:25:16 +0200 > > > From: Patrick Wildt > > > > > > Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt: > > > > Hi, > > > > > > > > Parallels 16 for Mac supports the Apple M1 SoC now, and since it does > > > > provide an EFI 'BIOS', our images boot out of the box (once converted > > > > to 'hdd' or supplied as USB stick). > > > > > > > > Unfortunately virtio doesn't attach, because Parallels seems to provide > > > > a 'new' version 2. The following diff adds support for version 2 and > > > > I used it to install the VM over vio(4) network. And I was able to > > > > install packages over vio(4) network. Disk is ahci(4), USB passthrough > > > > is xhci(4), so that works nicely out of the box. > > > > > > > > Not sure if we want this for 6.9 or not. I think it wouldn't break the > > > > current version 1, so I think it shouldn't hurt. > > > > > > > > If you're wondering why I'm 'so late' with this: jcs@ asked me to have > > > > a look at the official Parallels for M1 release, and I just did that. > > > > So I couldn't be any faster than this anyway. > > > > > > > > Opinions? > > > > > > > > Patrick > > > > > > Obviously I forgot to pay dmesg tax ;) > > > Things change a little when you run 'machine acpi' in efiboot. OpenBSD 6.9 (GENERIC.MP) #295: Wed Apr 14 22:06:35 CEST 2021 patr...@lx2k.blueri.se:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 516284416 (492MB) avail mem = 468021248 (446MB) random: good seed from bootblocks mainbus0 at root: ACPI psci0 at mainbus0: PSCI 1.0 cpu0 at mainbus0 mpidr 0: Unknown, MIDR 0x410f cpu0: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache cpu0: 12288KB 128b/line 12-way L2 cache cpu0: TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2 cpu1 at mainbus0 mpidr 1: Unknown, MIDR 0x410f cpu1: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache cpu1: 12288KB 128b/line 12-way L2 cache cpu1: TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2 efi0 at mainbus0: UEFI 2.7 efi0: EDK II rev 0x1 smbios0 at efi0: SMBIOS 3.0.0 smbios0: vendor Parallels Software International Inc. version "16.5.0 (50692)" date Mar 25 2021 smbios0: Parallels Parallels ARM Virtual Machine apm0 at mainbus0 ampintc0 at mainbus0 nirq 128, ncpu 2 ipi: 0, 1: "interrupt-controller" agtimer0 at mainbus0: 24000 kHz acpi0 at mainbus0: ACPI 6.1 acpi0: sleep states acpi0: tables DSDT FACP DBG2 GTDT APIC acpi0: wakeup devices "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured acpibtn0 at acpi0: PWRB acpige0 at acpi0 irq 48 "PRL4005" at acpi0 not configured "PRL4000" at acpi0 not configured "PRL4006" at acpi0 not configured "PRL4009" at acpi0 not configured "PNP0D20" at acpi0 not configured ahci0 at acpi0 AHC0 addr 0x214/0x2000 irq 34: AHCI 1.1 ahci0: port 0: 1.5Gb/s ahci0: port 1: 1.5Gb/s ahci0: port 2: 1.5Gb/s scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: t10.ATA_OpenBSD-0_SSD_SM7VVT660WEM5DW1GGN0 sd0: 65536MB, 512 bytes/sector, 134217728 sectors, thin sd1 at scsibus0 targ 1 lun 0: t10.ATA_miniroot69_NQGN5C6P8H5MSAW6W3PG sd1: 33MB, 512 bytes/sector, 67584 sectors, thin cd0 at scsibus0 targ 2 lun 0: <, Virtual DVD-ROM, R103> removable "ACPI000E" at acpi0 not configured xhci0 at acpi0 XHC0 addr 0x216/0x1000 irq 36, xHCI 1.10 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 simplefb0 at mainbus0: 1024x768, 32bpp wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) uhidev0 at uhub0 port 1 configuration 1 interface 0 "Parallels Virtual Mouse" rev 3.00/1.00 addr 2 uhidev0: iclass 3/0, 1 report id ums0 at uhidev0 reportid 1: 8 buttons, Z and W dir wsmouse0 at ums0 mux 0 uhidev1 at uhub0 port 1 configuration 1 interface 1 "Parallels Virtual Mouse" rev 3.00/1.00 addr 2 uhidev1: iclass 3/0, 2 report ids ums1 at uhidev1 reportid 2: 8 buttons, Z and W dir wsmouse1 at ums1 mux 0 uhidev2 at uhub0 port 1 configuration 1 interface 2 "Parallels Virtual Mouse" rev 3.00/1.00 addr 2 uhidev2: iclass 3/0, 3 report ids uhid0 at uhidev2 reportid 3: input=13, output=0, feature=0 uhidev3 at uhub0 port 2 configuration 1 interface 0 "Parallels Virtual Keyboard" rev 3.00/1.00 addr 3 uhidev3: iclass 3/1 ukbd0 at uhidev3: 8 variable keys, 5 key codes wskbd0 at ukbd0:
Re: xfail lib/libc/setjmp-fpu regress on powerpc64
On Wed, Apr 14, 2021 at 08:33:43PM +0200, Mark Kettenis wrote:
> The ELFv2 ABI on powerpc64 explicitly states that when returning
> through setjmp(3) from longjmp(3), the "limited access bits" are *not*
> restored to the values they had before setjmp(3) was called.
>
> This means that the tests here are expected to fail according to the
> ABI.
>
> Now we may opt to restore them anyway. But it should be obvious that
> relying on this behaviour is not portable.
>
> Thoughts?
OK bluhm@
> Index: regress/lib/libc/setjmp-fpu/Makefile
> ===
> RCS file: /cvs/src/regress/lib/libc/setjmp-fpu/Makefile,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile
> --- regress/lib/libc/setjmp-fpu/Makefile 17 Dec 2020 00:51:11 -
> 1.5
> +++ regress/lib/libc/setjmp-fpu/Makefile 14 Apr 2021 18:28:12 -
> @@ -15,4 +15,12 @@ run-$p: $p
> ./$p
> .endfor
>
> +.if ${MACHINE} == powerpc64
> +# The powerpc64 ELFv2 ABI explicitly states that exception enable bits
> +# and rounding control bits are not restored by longjmp(3)
> +.for p in ${PROGS:M*jmp}
> +REGRESS_EXPECTED_FAILURES += run-$p
> +.endfor
> +.endif
> +
> .include
bgpd config regress powerpc64
Hi,
On powerpc64 regress/usr.sbin/bgpd/config fails. It parses a config
file, writes bgpd's config to stdout and compares it with an expected
output.
On powerpc64 the order of the set of communities is different.
The parser uses memcmp(3) to sort a struct of integers. This depends
of the endianess. The correct way is to compare the integer fields
in native byte order.
With this diff, the resulting order is the same on i386 and poerpc64.
Also on powerpc64 the fix does not change bgpd's output. memcmp(3)
and field comparison are equivalent on big endian architectures.
ok?
bluhm
Index: usr.sbin/bgpd/parse.y
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.414
diff -u -p -r1.414 parse.y
--- usr.sbin/bgpd/parse.y 2 Mar 2021 09:45:07 - 1.414
+++ usr.sbin/bgpd/parse.y 14 Apr 2021 21:09:47 -
@@ -3558,6 +3558,28 @@ symget(const char *nam)
}
static int
+cmpcommunity(struct community *a, struct community *b)
+{
+ if (a->flags > b->flags)
+ return 1;
+ if (a->flags < b->flags)
+ return -1;
+ if (a->data1 > b->data1)
+ return 1;
+ if (a->data1 < b->data1)
+ return -1;
+ if (a->data2 > b->data2)
+ return 1;
+ if (a->data2 < b->data2)
+ return -1;
+ if (a->data3 > b->data3)
+ return 1;
+ if (a->data3 < b->data3)
+ return -1;
+ return 0;
+}
+
+static int
getcommunity(char *s, int large, u_int32_t *val, u_int32_t *flag)
{
long longmax = USHRT_MAX;
@@ -4396,16 +4418,17 @@ filterset_add(struct filter_set_head *sh
switch (s->type) {
case ACTION_SET_COMMUNITY:
case ACTION_DEL_COMMUNITY:
- if (memcmp(>action.community,
- >action.community,
- sizeof(s->action.community)) < 0) {
+ switch (cmpcommunity(>action.community,
+ >action.community)) {
+ case -1:
TAILQ_INSERT_BEFORE(t, s, entry);
return;
- } else if (memcmp(>action.community,
- >action.community,
- sizeof(s->action.community)) == 0)
+ case 0:
break;
- continue;
+ case 1:
+ continue;
+ }
+ break;
case ACTION_SET_NEXTHOP:
/* only last nexthop per AF matters */
if (s->action.nexthop.aid <
Index: regress/usr.sbin/bgpd/config/bgpd.conf.10.ok
===
RCS file: /mount/openbsd/cvs/src/regress/usr.sbin/bgpd/config/bgpd.conf.10.ok,v
retrieving revision 1.6
diff -u -p -r1.6 bgpd.conf.10.ok
--- regress/usr.sbin/bgpd/config/bgpd.conf.10.ok17 Jul 2019 10:27:50
- 1.6
+++ regress/usr.sbin/bgpd/config/bgpd.conf.10.ok14 Apr 2021 21:14:42
-
@@ -40,4 +40,4 @@ match from any large-community 1234:5678
match from any large-community 1234:5678:1 large-community 1234:5678:2
large-community 1234:5678:3
match from any community 1234:1 large-community 1234:5678:1
match from any large-community 1234:5678:1 community 1234:1
-match from any set { community delete 1234:5678 community delete 1234:*
community delete *:5678 community delete local-as:5678 community delete
local-as:neighbor-as large-community delete 1234:15:5678 large-community delete
*:15:5678 large-community delete local-as:15:5678 large-community delete
local-as:15:* large-community delete local-as:15:neighbor-as large-community
delete local-as:*:* community 1234:5678 community local-as:5678 community
local-as:neighbor-as large-community 1234:15:5678 large-community
local-as:15:5678 large-community local-as:15:neighbor-as }
+match from any set { community delete 1234:5678 large-community delete
1234:15:5678 community delete *:5678 large-community delete *:15:5678 community
delete local-as:5678 large-community delete local-as:15:5678 community delete
1234:* community delete local-as:neighbor-as large-community delete
local-as:15:* large-community delete local-as:*:* large-community delete
local-as:15:neighbor-as community 1234:5678 large-community 1234:15:5678
community local-as:5678 large-community local-as:15:5678 community
local-as:neighbor-as large-community local-as:15:neighbor-as }
Index: regress/usr.sbin/bgpd/config/bgpd.conf.11.ok
Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)
Am Wed, Apr 14, 2021 at 10:55:14PM +0200 schrieb Mark Kettenis: > > Date: Wed, 14 Apr 2021 22:25:16 +0200 > > From: Patrick Wildt > > > > Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt: > > > Hi, > > > > > > Parallels 16 for Mac supports the Apple M1 SoC now, and since it does > > > provide an EFI 'BIOS', our images boot out of the box (once converted > > > to 'hdd' or supplied as USB stick). > > > > > > Unfortunately virtio doesn't attach, because Parallels seems to provide > > > a 'new' version 2. The following diff adds support for version 2 and > > > I used it to install the VM over vio(4) network. And I was able to > > > install packages over vio(4) network. Disk is ahci(4), USB passthrough > > > is xhci(4), so that works nicely out of the box. > > > > > > Not sure if we want this for 6.9 or not. I think it wouldn't break the > > > current version 1, so I think it shouldn't hurt. > > > > > > If you're wondering why I'm 'so late' with this: jcs@ asked me to have > > > a look at the official Parallels for M1 release, and I just did that. > > > So I couldn't be any faster than this anyway. > > > > > > Opinions? > > > > > > Patrick > > > > Obviously I forgot to pay dmesg tax ;) > > > > OpenBSD 6.9 (GENERIC.MP) #295: Wed Apr 14 22:06:35 CEST 2021 > > patr...@lx2k.blueri.se:/usr/src/sys/arch/arm64/compile/GENERIC.MP > > real mem = 516423680 (492MB) > > avail mem = 468152320 (446MB) > > random: boothowto does not indicate good seed > > mainbus0 at root: Parallels ARM Virtual Machine > > psci0 at mainbus0: PSCI 1.0 > > cpu0 at mainbus0 mpidr 0: Unknown, MIDR 0x410f > > cpu0: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache > > cpu0: 12288KB 128b/line 12-way L2 cache > > cpu0: > > TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2 > > cpu1 at mainbus0 mpidr 1: Unknown, MIDR 0x410f > > cpu1: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache > > cpu1: 12288KB 128b/line 12-way L2 cache > > cpu1: > > TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2 > > efi0 at mainbus0: UEFI 2.7 > > efi0: EDK II rev 0x1 > > smbios0 at efi0: SMBIOS 3.0.0 > > smbios0: vendor Parallels Software International Inc. version "16.5.0 > > (50692)" date Mar 25 2021 > > smbios0: Parallels Parallels ARM Virtual Machine > > apm0 at mainbus0 > > ampintc0 at mainbus0 nirq 128, ncpu 2 ipi: 0, 1: "interrupt-controller" > > agtimer0 at mainbus0: 24000 kHz > > "soc" at mainbus0 not configured > > "clk24mhz" at mainbus0 not configured > > pluart0 at mainbus0 > > ahci0 at mainbus0: AHCI 1.1 > > ahci0: port 0: 1.5Gb/s > > ahci0: port 1: 1.5Gb/s > > scsibus0 at ahci0: 32 targets > > sd0 at scsibus0 targ 0 lun 0: > > t10.ATA_OpenBSD-0_SSD_Y15J1M1AG4B4S7VMR61V > > sd0: 8192MB, 512 bytes/sector, 16777216 sectors, thin > > sd1 at scsibus0 targ 1 lun 0: > > t10.ATA_miniroot69_NQGN5C6P8H5MSAW6W3PG > > sd1: 33MB, 512 bytes/sector, 67584 sectors, thin > > ehci0 at mainbus0 > > usb0 at ehci0: USB revision 2.0 > > uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev > > 2.00/1.00 addr 1 > > xhci0 at mainbus0, xHCI 1.10 > > usb1 at xhci0: USB revision 3.0 > > uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev > > 3.00/1.00 addr 1 > > "gpu" at mainbus0 not configured > > "toolgate" at mainbus0 not configured > > virtio0 at mainbus0: Virtio Memory Balloon Device > > viomb0 at virtio0 > > virtio1 at mainbus0: Virtio Network Device > > vio0 at virtio1: address 00:1c:42:8a:67:34 > > simplefb0 at mainbus0: 1024x768, 32bpp > > wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation) > > wsdisplay0: screen 1-5 added (std, vt100 emulation) > > uhidev0 at uhub1 port 1 configuration 1 interface 0 "Parallels Virtual > > Mouse" rev 3.00/1.00 addr 2 > > uhidev0: iclass 3/0, 1 report id > > ums0 at uhidev0 reportid 1: 8 buttons, Z and W dir > > wsmouse0 at ums0 mux 0 > > uhidev1 at uhub1 port 1 configuration 1 interface 1 "Parallels Virtual > > Mouse" rev 3.00/1.00 addr 2 > > uhidev1: iclass 3/0, 2 report ids > > ums1 at uhidev1 reportid 2: 8 buttons, Z and W dir > > wsmouse1 at ums1 mux 0 > > uhidev2 at uhub1 port 2 configuration 1 interface 0 "Parallels Virtual > > Keyboard" rev 3.00/1.00 addr 3 > > uhidev2: iclass 3/1 > > ukbd0 at uhidev2: 8 variable keys, 5 key codes > > wskbd0 at ukbd0: console keyboard, using wsdisplay0 > > uvideo0 at uhub1 port 3 configuration 1 interface 0 "Parallels FaceTime HD > > Camera" rev 3.10/1.00 addr 4 > > video0 at uvideo0 > > vscsi0 at root > > scsibus1 at vscsi0: 256 targets > > softraid0 at root > > scsibus2 at softraid0: 256 targets > > root on sd0a (4a24f1a721df244f.a) swap on sd0b dump on sd0b > > Automatic boot in progress: starting file system
Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)
On Wed, 14 Apr 2021 at 22:55:14 +0200, Mark Kettenis wrote: > > cpu0 at mainbus0 mpidr 0: Unknown, MIDR 0x410f > > That's a strange ARM CPU ;). > > If you have some time, can you run a make -j in /usr/src/lib/libc? > I'm curious if cc or ld crashes in a virtual machine. I just built all of libc with -j2 within Parallels on my M1 MBA without any crashes.
Re: wcwidth of soft hyphen
Since the discussion seems to have died out, I take my patch will not be accepted. The decision appears to be that OpenBSD is right and everyone else is wrong in this matter. Given that, and the calls to change the behavior of other OSes and terminal emulators around SHY: are you going to at least patch xterm in-tree so that it does not render SHY? Or must it remain broken? -- Lauri Tirkkonen | lotheac @ IRCnet
Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)
> Date: Wed, 14 Apr 2021 22:25:16 +0200 > From: Patrick Wildt > > Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt: > > Hi, > > > > Parallels 16 for Mac supports the Apple M1 SoC now, and since it does > > provide an EFI 'BIOS', our images boot out of the box (once converted > > to 'hdd' or supplied as USB stick). > > > > Unfortunately virtio doesn't attach, because Parallels seems to provide > > a 'new' version 2. The following diff adds support for version 2 and > > I used it to install the VM over vio(4) network. And I was able to > > install packages over vio(4) network. Disk is ahci(4), USB passthrough > > is xhci(4), so that works nicely out of the box. > > > > Not sure if we want this for 6.9 or not. I think it wouldn't break the > > current version 1, so I think it shouldn't hurt. > > > > If you're wondering why I'm 'so late' with this: jcs@ asked me to have > > a look at the official Parallels for M1 release, and I just did that. > > So I couldn't be any faster than this anyway. > > > > Opinions? > > > > Patrick > > Obviously I forgot to pay dmesg tax ;) > > OpenBSD 6.9 (GENERIC.MP) #295: Wed Apr 14 22:06:35 CEST 2021 > patr...@lx2k.blueri.se:/usr/src/sys/arch/arm64/compile/GENERIC.MP > real mem = 516423680 (492MB) > avail mem = 468152320 (446MB) > random: boothowto does not indicate good seed > mainbus0 at root: Parallels ARM Virtual Machine > psci0 at mainbus0: PSCI 1.0 > cpu0 at mainbus0 mpidr 0: Unknown, MIDR 0x410f > cpu0: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache > cpu0: 12288KB 128b/line 12-way L2 cache > cpu0: > TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2 > cpu1 at mainbus0 mpidr 1: Unknown, MIDR 0x410f > cpu1: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache > cpu1: 12288KB 128b/line 12-way L2 cache > cpu1: > TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2 > efi0 at mainbus0: UEFI 2.7 > efi0: EDK II rev 0x1 > smbios0 at efi0: SMBIOS 3.0.0 > smbios0: vendor Parallels Software International Inc. version "16.5.0 > (50692)" date Mar 25 2021 > smbios0: Parallels Parallels ARM Virtual Machine > apm0 at mainbus0 > ampintc0 at mainbus0 nirq 128, ncpu 2 ipi: 0, 1: "interrupt-controller" > agtimer0 at mainbus0: 24000 kHz > "soc" at mainbus0 not configured > "clk24mhz" at mainbus0 not configured > pluart0 at mainbus0 > ahci0 at mainbus0: AHCI 1.1 > ahci0: port 0: 1.5Gb/s > ahci0: port 1: 1.5Gb/s > scsibus0 at ahci0: 32 targets > sd0 at scsibus0 targ 0 lun 0: > t10.ATA_OpenBSD-0_SSD_Y15J1M1AG4B4S7VMR61V > sd0: 8192MB, 512 bytes/sector, 16777216 sectors, thin > sd1 at scsibus0 targ 1 lun 0: > t10.ATA_miniroot69_NQGN5C6P8H5MSAW6W3PG > sd1: 33MB, 512 bytes/sector, 67584 sectors, thin > ehci0 at mainbus0 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev > 2.00/1.00 addr 1 > xhci0 at mainbus0, xHCI 1.10 > usb1 at xhci0: USB revision 3.0 > uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev > 3.00/1.00 addr 1 > "gpu" at mainbus0 not configured > "toolgate" at mainbus0 not configured > virtio0 at mainbus0: Virtio Memory Balloon Device > viomb0 at virtio0 > virtio1 at mainbus0: Virtio Network Device > vio0 at virtio1: address 00:1c:42:8a:67:34 > simplefb0 at mainbus0: 1024x768, 32bpp > wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation) > wsdisplay0: screen 1-5 added (std, vt100 emulation) > uhidev0 at uhub1 port 1 configuration 1 interface 0 "Parallels Virtual Mouse" > rev 3.00/1.00 addr 2 > uhidev0: iclass 3/0, 1 report id > ums0 at uhidev0 reportid 1: 8 buttons, Z and W dir > wsmouse0 at ums0 mux 0 > uhidev1 at uhub1 port 1 configuration 1 interface 1 "Parallels Virtual Mouse" > rev 3.00/1.00 addr 2 > uhidev1: iclass 3/0, 2 report ids > ums1 at uhidev1 reportid 2: 8 buttons, Z and W dir > wsmouse1 at ums1 mux 0 > uhidev2 at uhub1 port 2 configuration 1 interface 0 "Parallels Virtual > Keyboard" rev 3.00/1.00 addr 3 > uhidev2: iclass 3/1 > ukbd0 at uhidev2: 8 variable keys, 5 key codes > wskbd0 at ukbd0: console keyboard, using wsdisplay0 > uvideo0 at uhub1 port 3 configuration 1 interface 0 "Parallels FaceTime HD > Camera" rev 3.10/1.00 addr 4 > video0 at uvideo0 > vscsi0 at root > scsibus1 at vscsi0: 256 targets > softraid0 at root > scsibus2 at softraid0: 256 targets > root on sd0a (4a24f1a721df244f.a) swap on sd0b dump on sd0b > Automatic boot in progress: starting file system checks. > /dev/sd0a (4a24f1a721df244f.a): file system is clean; not checking > /dev/sd0e (4a24f1a721df244f.e): file system is clean; not checking > /dev/sd0d (4a24f1a721df244f.d): file system is clean; not checking > pf enabled > starting network > vio0: 10.211.55.4 lease accepted from
Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)
Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt: > Hi, > > Parallels 16 for Mac supports the Apple M1 SoC now, and since it does > provide an EFI 'BIOS', our images boot out of the box (once converted > to 'hdd' or supplied as USB stick). > > Unfortunately virtio doesn't attach, because Parallels seems to provide > a 'new' version 2. The following diff adds support for version 2 and > I used it to install the VM over vio(4) network. And I was able to > install packages over vio(4) network. Disk is ahci(4), USB passthrough > is xhci(4), so that works nicely out of the box. > > Not sure if we want this for 6.9 or not. I think it wouldn't break the > current version 1, so I think it shouldn't hurt. > > If you're wondering why I'm 'so late' with this: jcs@ asked me to have > a look at the official Parallels for M1 release, and I just did that. > So I couldn't be any faster than this anyway. > > Opinions? > > Patrick Obviously I forgot to pay dmesg tax ;) OpenBSD 6.9 (GENERIC.MP) #295: Wed Apr 14 22:06:35 CEST 2021 patr...@lx2k.blueri.se:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 516423680 (492MB) avail mem = 468152320 (446MB) random: boothowto does not indicate good seed mainbus0 at root: Parallels ARM Virtual Machine psci0 at mainbus0: PSCI 1.0 cpu0 at mainbus0 mpidr 0: Unknown, MIDR 0x410f cpu0: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache cpu0: 12288KB 128b/line 12-way L2 cache cpu0: TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2 cpu1 at mainbus0 mpidr 1: Unknown, MIDR 0x410f cpu1: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache cpu1: 12288KB 128b/line 12-way L2 cache cpu1: TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2 efi0 at mainbus0: UEFI 2.7 efi0: EDK II rev 0x1 smbios0 at efi0: SMBIOS 3.0.0 smbios0: vendor Parallels Software International Inc. version "16.5.0 (50692)" date Mar 25 2021 smbios0: Parallels Parallels ARM Virtual Machine apm0 at mainbus0 ampintc0 at mainbus0 nirq 128, ncpu 2 ipi: 0, 1: "interrupt-controller" agtimer0 at mainbus0: 24000 kHz "soc" at mainbus0 not configured "clk24mhz" at mainbus0 not configured pluart0 at mainbus0 ahci0 at mainbus0: AHCI 1.1 ahci0: port 0: 1.5Gb/s ahci0: port 1: 1.5Gb/s scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: t10.ATA_OpenBSD-0_SSD_Y15J1M1AG4B4S7VMR61V sd0: 8192MB, 512 bytes/sector, 16777216 sectors, thin sd1 at scsibus0 targ 1 lun 0: t10.ATA_miniroot69_NQGN5C6P8H5MSAW6W3PG sd1: 33MB, 512 bytes/sector, 67584 sectors, thin ehci0 at mainbus0 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1 xhci0 at mainbus0, xHCI 1.10 usb1 at xhci0: USB revision 3.0 uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 "gpu" at mainbus0 not configured "toolgate" at mainbus0 not configured virtio0 at mainbus0: Virtio Memory Balloon Device viomb0 at virtio0 virtio1 at mainbus0: Virtio Network Device vio0 at virtio1: address 00:1c:42:8a:67:34 simplefb0 at mainbus0: 1024x768, 32bpp wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) uhidev0 at uhub1 port 1 configuration 1 interface 0 "Parallels Virtual Mouse" rev 3.00/1.00 addr 2 uhidev0: iclass 3/0, 1 report id ums0 at uhidev0 reportid 1: 8 buttons, Z and W dir wsmouse0 at ums0 mux 0 uhidev1 at uhub1 port 1 configuration 1 interface 1 "Parallels Virtual Mouse" rev 3.00/1.00 addr 2 uhidev1: iclass 3/0, 2 report ids ums1 at uhidev1 reportid 2: 8 buttons, Z and W dir wsmouse1 at ums1 mux 0 uhidev2 at uhub1 port 2 configuration 1 interface 0 "Parallels Virtual Keyboard" rev 3.00/1.00 addr 3 uhidev2: iclass 3/1 ukbd0 at uhidev2: 8 variable keys, 5 key codes wskbd0 at ukbd0: console keyboard, using wsdisplay0 uvideo0 at uhub1 port 3 configuration 1 interface 0 "Parallels FaceTime HD Camera" rev 3.10/1.00 addr 4 video0 at uvideo0 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (4a24f1a721df244f.a) swap on sd0b dump on sd0b Automatic boot in progress: starting file system checks. /dev/sd0a (4a24f1a721df244f.a): file system is clean; not checking /dev/sd0e (4a24f1a721df244f.e): file system is clean; not checking /dev/sd0d (4a24f1a721df244f.d): file system is clean; not checking pf enabled starting network vio0: 10.211.55.4 lease accepted from 10.211.55.1 (00:1c:42:00:00:18) reordering libraries: done. starting early daemons: syslogd pflogd ntpd. starting RPC daemons:. savecore: no core dump checking quotas: done. clearing /tmp kern.securelevel: 0 -> 1 creating runtime link editor directory cache. preserving editor files.
virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)
Hi,
Parallels 16 for Mac supports the Apple M1 SoC now, and since it does
provide an EFI 'BIOS', our images boot out of the box (once converted
to 'hdd' or supplied as USB stick).
Unfortunately virtio doesn't attach, because Parallels seems to provide
a 'new' version 2. The following diff adds support for version 2 and
I used it to install the VM over vio(4) network. And I was able to
install packages over vio(4) network. Disk is ahci(4), USB passthrough
is xhci(4), so that works nicely out of the box.
Not sure if we want this for 6.9 or not. I think it wouldn't break the
current version 1, so I think it shouldn't hurt.
If you're wondering why I'm 'so late' with this: jcs@ asked me to have
a look at the official Parallels for M1 release, and I just did that.
So I couldn't be any faster than this anyway.
Opinions?
Patrick
diff --git a/sys/dev/fdt/virtio_mmio.c b/sys/dev/fdt/virtio_mmio.c
index 88e45436c00..e474bad9e6b 100644
--- a/sys/dev/fdt/virtio_mmio.c
+++ b/sys/dev/fdt/virtio_mmio.c
@@ -58,10 +58,17 @@
#define VIRTIO_MMIO_QUEUE_NUM 0x038
#define VIRTIO_MMIO_QUEUE_ALIGN0x03c
#define VIRTIO_MMIO_QUEUE_PFN 0x040
+#define VIRTIO_MMIO_QUEUE_READY0x044
#define VIRTIO_MMIO_QUEUE_NOTIFY 0x050
#define VIRTIO_MMIO_INTERRUPT_STATUS 0x060
#define VIRTIO_MMIO_INTERRUPT_ACK 0x064
#define VIRTIO_MMIO_STATUS 0x070
+#define VIRTIO_MMIO_QUEUE_DESC_LOW 0x080
+#define VIRTIO_MMIO_QUEUE_DESC_HIGH0x084
+#define VIRTIO_MMIO_QUEUE_AVAIL_LOW0x090
+#define VIRTIO_MMIO_QUEUE_AVAIL_HIGH 0x094
+#define VIRTIO_MMIO_QUEUE_USED_LOW 0x0a0
+#define VIRTIO_MMIO_QUEUE_USED_HIGH0x0a4
#define VIRTIO_MMIO_CONFIG 0x100
#define VIRTIO_MMIO_INT_VRING (1 << 0)
@@ -106,6 +113,7 @@ struct virtio_mmio_softc {
void*sc_ih;
int sc_config_offset;
+ uint32_tsc_version;
};
struct cfattach virtio_mmio_ca = {
@@ -159,10 +167,31 @@ virtio_mmio_setup_queue(struct virtio_softc *vsc, struct
virtqueue *vq,
vq->vq_index);
bus_space_write_4(sc->sc_iot, sc->sc_ioh, VIRTIO_MMIO_QUEUE_NUM,
bus_space_read_4(sc->sc_iot, sc->sc_ioh,
VIRTIO_MMIO_QUEUE_NUM_MAX));
- bus_space_write_4(sc->sc_iot, sc->sc_ioh, VIRTIO_MMIO_QUEUE_ALIGN,
- PAGE_SIZE);
- bus_space_write_4(sc->sc_iot, sc->sc_ioh, VIRTIO_MMIO_QUEUE_PFN,
- addr / VIRTIO_PAGE_SIZE);
+ if (sc->sc_version == 1) {
+ bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+ VIRTIO_MMIO_QUEUE_ALIGN, PAGE_SIZE);
+ bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+ VIRTIO_MMIO_QUEUE_PFN, addr / VIRTIO_PAGE_SIZE);
+ } else {
+ bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+ VIRTIO_MMIO_QUEUE_DESC_LOW, addr);
+ bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+ VIRTIO_MMIO_QUEUE_DESC_HIGH, addr >> 32);
+ bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+ VIRTIO_MMIO_QUEUE_AVAIL_LOW,
+ addr + vq->vq_availoffset);
+ bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+ VIRTIO_MMIO_QUEUE_AVAIL_HIGH,
+ (addr + vq->vq_availoffset) >> 32);
+ bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+ VIRTIO_MMIO_QUEUE_USED_LOW,
+ addr + vq->vq_usedoffset);
+ bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+ VIRTIO_MMIO_QUEUE_USED_HIGH,
+ (addr + vq->vq_usedoffset) >> 32);
+ bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+ VIRTIO_MMIO_QUEUE_READY, 1);
+ }
}
void
@@ -192,7 +221,7 @@ virtio_mmio_attach(struct device *parent, struct device
*self, void *aux)
struct fdt_attach_args *faa = aux;
struct virtio_mmio_softc *sc = (struct virtio_mmio_softc *)self;
struct virtio_softc *vsc = >sc_sc;
- uint32_t id, magic, version;
+ uint32_t id, magic;
if (faa->fa_nreg < 1) {
printf(": no register data\n");
@@ -213,17 +242,19 @@ virtio_mmio_attach(struct device *parent, struct device
*self, void *aux)
return;
}
- version = bus_space_read_4(sc->sc_iot, sc->sc_ioh, VIRTIO_MMIO_VERSION);
- if (version != 1) {
- printf(": unknown version 0x%02x; giving up\n", version);
+ sc->sc_version = bus_space_read_4(sc->sc_iot, sc->sc_ioh,
+ VIRTIO_MMIO_VERSION);
+ if (sc->sc_version < 1 || sc->sc_version > 2) {
+ printf(": unknown version 0x%02x; giving up\n", sc->sc_version);
return;
}
id = bus_space_read_4(sc->sc_iot, sc->sc_ioh, VIRTIO_MMIO_DEVICE_ID);
printf(": Virtio %s Device", virtio_device_string(id));
- bus_space_write_4(sc->sc_iot, sc->sc_ioh,
Re: wcwidth of soft hyphen
On Wed, 2021-04-14 at 20:10 +0300, Lauri Tirkkonen wrote:
> Since the discussion seems to have died out, I take my patch will not be
> accepted.
>
> The decision appears to be that OpenBSD is right and everyone else is wrong in
> this matter. Given that, and the calls to change the behavior of other OSes
> and
> terminal emulators around SHY: are you going to at least patch xterm in-tree
> so
> that it does not render SHY?
>
> Or must it remain broken?
>
Looking closer at the xterm source corroborated my previous reasoning.
>From xterm's wcwidth.c:
/*
* Provide a way to change the behavior of soft-hyphen.
*/
void mk_wcwidth_init(int mode)
{
use_latin1 = (mode == 0);
}
and
*- SOFT HYPHEN (U+00AD) has a column width of 1 in Latin-1, 0 in Unicode.
* An initialization function is used to switch between the two.
So it is the intention of xterm to not display the soft hyphen in
unicode mode.
This is also corrobarated by charproc.c5799 where the error occurs:
if (ch == 0xad) {
/*
* Only display soft-hyphen if it happens to be at
* the right-margin. While that means that only
* the displayed character could be selected for
* pasting, a well-behaved application would never
* send this, anyway...
*/
The problem here is that on line 5795 we have:
last_chomp = CharWidth(buf[n]);
which expands to:
CharWidth(n) (((n) < 256) ? (IsLatin1(n) ? 1 : 0) : my_wcwidth((wchar_t) (n)))
and
#define IsLatin1(n) (((n) >= 32 && (n) <= 126) || ((n) >= 160 && (n) <= 255))
So here's the big oops: CharWidth doesn't know we're in UTF-8 mode and
we never reach my_wcwidth.
Diff below fixes this behaviour for me and restores the printing
behaviour when I run xterm with +u8 to reset utf-8 mode.
However, I'm no xterm hacker and it's quite a beast, so this needs
proper testing and scrutiny from someone who knows the code to make
sure there's no use of uninitialized variables. (CC matthieu@)
No intention of pushing this for 6.9, but maybe someone brave is
willing to dive in here after me.
martijn@
Index: charproc.c
===
RCS file: /cvs/xenocara/app/xterm/charproc.c,v
retrieving revision 1.49
diff -u -p -r1.49 charproc.c
--- charproc.c 2 Apr 2021 18:44:19 - 1.49
+++ charproc.c 14 Apr 2021 19:24:14 -
@@ -2305,7 +2305,7 @@ doparsing(XtermWidget xw, unsigned c, st
*/
if (c >= 0x300
&& screen->wide_chars
- && CharWidth(c) == 0
+ && CharWidth(screen, c) == 0
&& !isWideControl(c)) {
int prev, test;
Boolean used = True;
@@ -2330,9 +2330,9 @@ doparsing(XtermWidget xw, unsigned c, st
prev = (int) XTERM_CELL(use_row, use_col);
test = do_precomposition(prev, (int) c);
TRACE(("do_precomposition (U+%04X [%d], U+%04X [%d]) -> U+%04X
[%d]\n",
- prev, CharWidth(prev),
- (int) c, CharWidth(c),
- test, CharWidth(test)));
+ prev, CharWidth(screen, prev),
+ (int) c, CharWidth(screen, c),
+ test, CharWidth(screen, test)));
} else {
prev = -1;
test = -1;
@@ -2342,7 +2342,7 @@ doparsing(XtermWidget xw, unsigned c, st
* only if it does not change the width of the base character
*/
if (test != -1
- && CharWidth(test) == CharWidth(prev)) {
+ && CharWidth(screen, test) == CharWidth(screen, prev)) {
putXtermCell(screen, use_row, use_col, test);
} else if (screen->char_was_written
|| getXtermCell(screen, use_row, use_col) >= ' ') {
@@ -4551,7 +4551,7 @@ doparsing(XtermWidget xw, unsigned c, st
value = zero_if_default(0);
TRACE(("CASE_DECFRA - Fill rectangular area\n"));
- if (nparam > 0 && CharWidth(value) > 0) {
+ if (nparam > 0 && CharWidth(screen, value) > 0) {
xtermParseRect(xw, ParamPair(1), );
ScrnFillRectangle(xw, , value, xw->flags, True);
}
@@ -4860,7 +4860,7 @@ doparsing(XtermWidget xw, unsigned c, st
case CASE_REP:
TRACE(("CASE_REP\n"));
- if (CharWidth(sp->lastchar) > 0) {
+ if (CharWidth(screen, sp->lastchar) > 0) {
IChar repeated[2];
count = one_if_default(0);
repeated[0] = (IChar) sp->lastchar;
@@ -5792,7 +5792,7 @@ dotext(XtermWidget xw,
buf[n] <= 0xa0) {
Re: rpki-client skip deltas if session_id does not match
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.14 20:18:25 +0200:
> There is no need to queue up any deltas if the session-id differes from
> the one on disk. New session-id will always result in a snapshot download.
> This may help in some situation to skip queuing many deltas that are just
> discarded.
ok
>
> --
> :wq Claudio
>
> Index: rrdp_notification.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/rrdp_notification.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 rrdp_notification.c
> --- rrdp_notification.c 2 Apr 2021 08:07:47 - 1.3
> +++ rrdp_notification.c 14 Apr 2021 18:08:32 -
> @@ -243,7 +243,9 @@ start_delta_elem(struct notification_xml
>
> /* optimisation, add only deltas that could be interesting */
> if (nxml->repository->serial != 0 &&
> - nxml->repository->serial < delta_serial) {
> + nxml->repository->serial < delta_serial &&
> + nxml->repository->session_id != NULL &&
> + strcmp(nxml->session_id, nxml->repository->session_id) == 0) {
> if (add_delta(nxml, delta_uri, delta_hash, delta_serial) == 0)
> PARSE_FAIL(p, "parse failed - adding delta failed");
> }
>
Re: add PCI IDs for Thinkpad X1 Extreme Gen 3, enable WLAN
On Wed, Apr 14, 2021 at 11:01:47AM +0200, Ivo Sbalzarini wrote:
> as suggested over at misc@ (thanks, Stuart!), I am sending a
> patch below to add the PCI IDs of the Thunderbolt and WiFi
> devices in Lenovo Thinkpad X1 Extreme Gen 3 laptops, and to
> enable the Intel AX201 wireless LAN in the iwx driver.
>
> I have this tested and running without apparent problems on
> my machine. Would appreciate if someone could take a look at
> the diffs.
>
> Thanks!
> - ivo
Committed, thank you!
>
>
>
>
> Index: if_iwx.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 if_iwx.c
> --- if_iwx.c 17 Mar 2021 15:59:27 - 1.50
> +++ if_iwx.c 14 Apr 2021 06:51:35 -
> @@ -7711,6 +7711,7 @@ static const struct pci_matchid iwx_devi
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_2 },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_3 },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_4,},
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_5,},
> };
>
> static const struct pci_matchid iwx_subsystem_id_ax201[] = {
> @@ -7751,6 +7752,7 @@ iwx_match(struct device *parent, iwx_mat
> case PCI_PRODUCT_INTEL_WL_22500_2: /* AX201 */
> case PCI_PRODUCT_INTEL_WL_22500_3: /* AX201 */
> case PCI_PRODUCT_INTEL_WL_22500_4: /* AX201 */
> + case PCI_PRODUCT_INTEL_WL_22500_5: /* AX201 */
> for (i = 0; i < nitems(iwx_subsystem_id_ax201); i++) {
> if (svid == iwx_subsystem_id_ax201[i].pm_vid &&
> spid == iwx_subsystem_id_ax201[i].pm_pid)
> @@ -7938,6 +7940,7 @@ iwx_attach(struct device *parent, struct
> break;
> case PCI_PRODUCT_INTEL_WL_22500_2:
> case PCI_PRODUCT_INTEL_WL_22500_3:
> + case PCI_PRODUCT_INTEL_WL_22500_5:
> if (sc->sc_hw_rev != IWX_CSR_HW_REV_TYPE_QUZ) {
> printf("%s: unsupported AX201 adapter\n", DEVNAME(sc));
> return;
> Index: pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1963
> diff -u -p -r1.1963 pcidevs
> --- pcidevs 9 Apr 2021 20:58:20 - 1.1963
> +++ pcidevs 14 Apr 2021 06:51:36 -
> @@ -3965,6 +3965,9 @@ product INTEL I219_V4 0x15d8 I219-V
> product INTEL JHL63400x15d9 JHL6340 Thunderbolt 3
> product INTEL JHL6340_PCIE 0x15da JHL6340 Thunderbolt 3
> product INTEL JHL6340_XHCI 0x15db JHL6340 Thunderbolt 3
> +product INTEL JHL75400x15eb JHL7540 Thunderbolt 3
> +product INTEL JHL7540_PCIE 0x15ea JHL7540 Thunderbolt 3
> +product INTEL JHL7540_XHCI 0x15ec JHL7540 Thunderbolt 3
> product INTEL I219_LM8 0x15df I219-LM
> product INTEL I219_V80x15e0 I219-V
> product INTEL I219_LM9 0x15e1 I219-LM
> @@ -5001,6 +5004,7 @@ product INTEL 495SERIES_LP_XHCI 0x34ed 4
> product INTEL 495SERIES_LP_XDCI 0x34ee 495 Series xDCI
> product INTEL 495SERIES_LP_SRAM 0x34ef 495 Series Shared SRAM
> product INTEL WL_22500_4 0x34f0 Wi-Fi 6 AX201
> +product INTEL WL_22500_5 0x06f0 Wi-Fi 6 AX201
> product INTEL 495SERIES_LP_SDXC 0x34f8 495 Series SDXC
> product INTEL 495SERIES_LP_GSPI_30x34fb 495 Series GSPI
> product INTEL 495SERIES_LP_ISH 0x34fc 495 Series ISH
>
>
>
xfail lib/libc/setjmp-fpu regress on powerpc64
The ELFv2 ABI on powerpc64 explicitly states that when returning
through setjmp(3) from longjmp(3), the "limited access bits" are *not*
restored to the values they had before setjmp(3) was called.
This means that the tests here are expected to fail according to the
ABI.
Now we may opt to restore them anyway. But it should be obvious that
relying on this behaviour is not portable.
Thoughts?
Index: regress/lib/libc/setjmp-fpu/Makefile
===
RCS file: /cvs/src/regress/lib/libc/setjmp-fpu/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- regress/lib/libc/setjmp-fpu/Makefile17 Dec 2020 00:51:11 -
1.5
+++ regress/lib/libc/setjmp-fpu/Makefile14 Apr 2021 18:28:12 -
@@ -15,4 +15,12 @@ run-$p: $p
./$p
.endfor
+.if ${MACHINE} == powerpc64
+# The powerpc64 ELFv2 ABI explicitly states that exception enable bits
+# and rounding control bits are not restored by longjmp(3)
+.for p in ${PROGS:M*jmp}
+REGRESS_EXPECTED_FAILURES += run-$p
+.endfor
+.endif
+
.include
rpki-client skip deltas if session_id does not match
There is no need to queue up any deltas if the session-id differes from
the one on disk. New session-id will always result in a snapshot download.
This may help in some situation to skip queuing many deltas that are just
discarded.
--
:wq Claudio
Index: rrdp_notification.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/rrdp_notification.c,v
retrieving revision 1.3
diff -u -p -r1.3 rrdp_notification.c
--- rrdp_notification.c 2 Apr 2021 08:07:47 - 1.3
+++ rrdp_notification.c 14 Apr 2021 18:08:32 -
@@ -243,7 +243,9 @@ start_delta_elem(struct notification_xml
/* optimisation, add only deltas that could be interesting */
if (nxml->repository->serial != 0 &&
- nxml->repository->serial < delta_serial) {
+ nxml->repository->serial < delta_serial &&
+ nxml->repository->session_id != NULL &&
+ strcmp(nxml->session_id, nxml->repository->session_id) == 0) {
if (add_delta(nxml, delta_uri, delta_hash, delta_serial) == 0)
PARSE_FAIL(p, "parse failed - adding delta failed");
}
ld.so: NULL dereference on corrupt library
A bogus libvorbisenc.so.3.1 causes ld.so(1) to crash on my Pinebook Pro
which saw a few NVMe/power related panics:
$ ogg123 song62.ogg
Segmentation fault (core dumped)
$ egdb -q ogg123 ogg123.core
Reading symbols from ogg123...(no debugging symbols found)...done.
[New process 512916]
Core was generated by `ogg123'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000d388623e4 in _dl_find_symbol_obj (obj=0xcfae56000,
sl=0x7dd728) at /usr/src/libexec/ld.so/resolve.c:614
614 for (si = obj->buckets_elf[sl->sl_elf_hash %
obj->nbuckets];
(gdb) p obj->buckets_elf
There is no member named buckets_elf.
(`buckets_elf' is a macro)
(gdb) p obj->hash_u.u_elf.buckets
$1 = (const Elf_Hash_Word *) 0x0
(gdb) p obj->nbuckets
$2 = 0
Backtrace for completeness:
(gdb) bt
#0 0x000d388623e4 in _dl_find_symbol_obj (obj=0xcfae56000,
sl=0x7dd728) at /usr/src/libexec/ld.so/resolve.c:614
#1 0x000d38862210 in _dl_find_symbol (name=0xd9e9e6919
"malloc_options", flags=16, ref_sym=0xd9e9d23f8, req_obj=0xcfae52000) at
/usr/src/libexec/ld.so/resolve.c:704
#2 0x000d388603b8 in _dl_md_reloc (object=,
rel=, relsz=) at
/usr/src/libexec/ld.so/aarch64/rtld_machine.c:170
#3 0x000d38864714 in _dl_rtld (object=0xcfae52000) at
/usr/src/libexec/ld.so/loader.c:722
#4 0x000d388646dc in _dl_rtld (object=0xcfae52400) at
/usr/src/libexec/ld.so/loader.c:712
#5 0x000d388646dc in _dl_rtld (object=0xd6d641400) at
/usr/src/libexec/ld.so/loader.c:712
#6 0x000d388646dc in _dl_rtld (object=0xcfae52800) at
/usr/src/libexec/ld.so/loader.c:712
#7 0x000d388646dc in _dl_rtld (object=0xcfae53c00) at
/usr/src/libexec/ld.so/loader.c:712
#8 0x000d388646dc in _dl_rtld (object=0xcfae56800) at
/usr/src/libexec/ld.so/loader.c:712
#9 0x000d388646dc in _dl_rtld (object=0xcfae56400) at
/usr/src/libexec/ld.so/loader.c:712
#10 0x000d388646dc in _dl_rtld (object=0xcfae56c00) at
/usr/src/libexec/ld.so/loader.c:712
#11 0x000d388646dc in _dl_rtld (object=0xd0b867400) at
/usr/src/libexec/ld.so/loader.c:712
#12 0x000d388646dc in _dl_rtld (object=0xd6d63f400) at
/usr/src/libexec/ld.so/loader.c:712
#13 0x000d388646dc in _dl_rtld (object=0xcfae53400) at
/usr/src/libexec/ld.so/loader.c:712
#14 0x000d388646dc in _dl_rtld (object=0xd6d63f800) at
/usr/src/libexec/ld.so/loader.c:712
#15 0x000d388646dc in _dl_rtld (object=0xcfae52c00) at
/usr/src/libexec/ld.so/loader.c:712
#16 0x000d388646dc in _dl_rtld (object=0xcfae53000) at
/usr/src/libexec/ld.so/loader.c:712
#17 0x000d388646dc in _dl_rtld (object=0xd0b867c00) at
/usr/src/libexec/ld.so/loader.c:712
#18 0x000d388646dc in _dl_rtld (object=0xd6d64) at
/usr/src/libexec/ld.so/loader.c:712
#19 0x000d388646dc in _dl_rtld (object=0xd6d640c00) at
/usr/src/libexec/ld.so/loader.c:712
#20 0x000d388646dc in _dl_rtld (object=0xd0b867000) at
/usr/src/libexec/ld.so/loader.c:712
#21 0x000d388646dc in _dl_rtld (object=0xcfae56000) at
/usr/src/libexec/ld.so/loader.c:712
#22 0x000d388646dc in _dl_rtld (object=0xd0b867800) at
/usr/src/libexec/ld.so/loader.c:712
#23 0x000d3886b618 in _dl_boot (argv=,
envp=, dyn_loff=56782815232, dl_data=0x7ddde4) at
/usr/src/libexec/ld.so/loader.c:663
#24 0x000d3886a044 in _dl_start () at
/usr/src/libexec/ld.so/aarch64/ldasm.S:59
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
libvorbis being the culprit wasn't clear at all, but I went through
pkg_check(1) to see checksum mismatches in the "libvorbis" package.
tl;dr: I Upgraded to the latest snapshot, saved the currupted libraries,
deinstalled all packages with `pkg_delete -X', installed "vorbis-tools"
for ogg123(1) (pulling in "libvorbis") and the song played fine using
valid files.
Forcing the corrupted library I can reproduce, though:
$ LD_PRELOAD=./libvorbisenc.so.3.1 ogg123 song62.ogg
Segmentation fault (core dumped)
So that's really this shared object and not any other currupted files.
I'm not familiar with ld.so internals but the NULL dereference seems
easy to avoid based on the condition that is used to set the `buckets'
member in resolve.c:408f:
if (object->Dyn.info[DT_HASH] != 0) {
Elf_Hash_Word *hashtab =
(Elf_Hash_Word *)(object->Dyn.info[DT_HASH] + obase);
object->nchains = hashtab[1];
if (object->nbuckets == 0) {
object->nbuckets = hashtab[0];
object->buckets_elf = hashtab + 2;
object->chains_elf =
tcpdump wireguard big endian
Hi,
regress/sys/net/wg fails on powerpc64 as tcpdump(8) cannot parse
wireguard packets. EXTRACT_LE_32BITS() converts the type from
little endian to host endian. So we need the constants in host
endianess.
ok?
bluhm
Index: print-wg.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tcpdump/print-wg.c,v
retrieving revision 1.5
diff -u -p -r1.5 print-wg.c
--- print-wg.c 20 Jul 2020 02:24:24 - 1.5
+++ print-wg.c 14 Apr 2021 15:35:19 -
@@ -25,10 +25,10 @@
#include "interface.h"
#include "extract.h"
-#define INITIATION htole32(1)
-#define RESPONSE htole32(2)
-#define COOKIE htole32(3)
-#define DATA htole32(4)
+#define INITIATION 1
+#define RESPONSE 2
+#define COOKIE 3
+#define DATA 4
struct wg_initiation {
uint32_ttype;
Re: Manpage fix: passwd.1
On Wed, 14 Apr 2021 11:09:02 +0200, Benjamin Baier wrote: > don't mention _PASSWORD_LEN in passwd manpage. > It's also no longer true, since Rev1.52, local_passwd.c uses 1024 > bytes for the password array. Committed, thanks. - todd
iwi(4) patch for testing
Given the recent fixes required for ipw(4), I suspect that iwi(4)
has similar issues and requires the patch below to actually pass
any packets.
While here, add a missing error check in the association sequence.
Could anyone test iwi(4) without this patch to confirm that it is
broken, and again with this patch to confirm that this fixes things?
Thinkpads which may contain this device are the following, at least
according to Levono (as far as I know the 60/61 series shipped with
wpi or iwn already):
- R50, R50e, R50p, R51, R51e, R52
- R60, R60e, R61, R61e, R61i
- T40, T40p, T41, T41p, T42, T42p, T43, T43p
- T60, T60p, T61, T61p
- X31, X32, X40, X41, X41 Tablet
- X60, X60s, X60 Tablet, X61, X61s, X61 Tablet
- X300
- Z60m, Z61e, Z61m, Z61p, Z61t
diff 99d61435bea38c80c9830f1a5599f26f7b71e8ce /usr/src
blob - 8ed15f30328a703731e0ca1fd82e58f4d358019c
file + sys/dev/pci/if_iwi.c
--- sys/dev/pci/if_iwi.c
+++ sys/dev/pci/if_iwi.c
@@ -725,9 +725,13 @@ int
iwi_newstate(struct ieee80211com *ic, enum ieee80211_state nstate, int arg)
{
struct iwi_softc *sc = ic->ic_softc;
+ struct ifnet *ifp = >ic_if;
enum ieee80211_state ostate;
uint32_t tmp;
+ if (LINK_STATE_IS_UP(ifp->if_link_state))
+ ieee80211_set_link_state(ic, LINK_STATE_DOWN);
+
ostate = ic->ic_state;
switch (nstate) {
@@ -736,7 +740,10 @@ iwi_newstate(struct ieee80211com *ic, enum ieee80211_s
break;
case IEEE80211_S_AUTH:
- iwi_auth_and_assoc(sc);
+ if (iwi_auth_and_assoc(sc)) {
+ ieee80211_begin_scan(>ic_if);
+ return 0;
+ }
break;
case IEEE80211_S_RUN:
@@ -752,6 +759,14 @@ iwi_newstate(struct ieee80211com *ic, enum ieee80211_s
/* assoc led on */
tmp = MEM_READ_4(sc, IWI_MEM_EVENT_CTL) & IWI_LED_MASK;
MEM_WRITE_4(sc, IWI_MEM_EVENT_CTL, tmp | IWI_LED_ASSOC);
+
+ if (!(ic->ic_flags & IEEE80211_F_RSNON)) {
+ /*
+* NB: When RSN is enabled, we defer setting
+* the link up until the port is valid.
+*/
+ ieee80211_set_link_state(ic, LINK_STATE_UP);
+ }
break;
case IEEE80211_S_INIT:
Manpage fix: passwd.1
Hi, don't mention _PASSWORD_LEN in passwd manpage. It's also no longer true, since Rev1.52, local_passwd.c uses 1024 bytes for the password array. Greetings Ben Index: passwd.1 === RCS file: /var/cvs/src/usr.bin/passwd/passwd.1,v retrieving revision 1.46 diff -u -p -r1.46 passwd.1 --- passwd.123 Apr 2019 17:52:12 - 1.46 +++ passwd.114 Apr 2021 08:59:39 - @@ -51,9 +51,6 @@ The new password must be entered twice t .Pp The new password should be at least six characters long and not purely alphabetic. -Its total length must be less than -.Dv _PASSWORD_LEN -(currently 128 characters). A mixture of both lower and uppercase letters, numbers, and meta-characters is encouraged. .Pp
add PCI IDs for Thinkpad X1 Extreme Gen 3, enable WLAN
as suggested over at misc@ (thanks, Stuart!), I am sending a
patch below to add the PCI IDs of the Thunderbolt and WiFi
devices in Lenovo Thinkpad X1 Extreme Gen 3 laptops, and to
enable the Intel AX201 wireless LAN in the iwx driver.
I have this tested and running without apparent problems on
my machine. Would appreciate if someone could take a look at
the diffs.
Thanks!
- ivo
Index: if_iwx.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v
retrieving revision 1.50
diff -u -p -r1.50 if_iwx.c
--- if_iwx.c17 Mar 2021 15:59:27 - 1.50
+++ if_iwx.c14 Apr 2021 06:51:35 -
@@ -7711,6 +7711,7 @@ static const struct pci_matchid iwx_devi
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_2 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_3 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_4,},
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_5,},
};
static const struct pci_matchid iwx_subsystem_id_ax201[] = {
@@ -7751,6 +7752,7 @@ iwx_match(struct device *parent, iwx_mat
case PCI_PRODUCT_INTEL_WL_22500_2: /* AX201 */
case PCI_PRODUCT_INTEL_WL_22500_3: /* AX201 */
case PCI_PRODUCT_INTEL_WL_22500_4: /* AX201 */
+ case PCI_PRODUCT_INTEL_WL_22500_5: /* AX201 */
for (i = 0; i < nitems(iwx_subsystem_id_ax201); i++) {
if (svid == iwx_subsystem_id_ax201[i].pm_vid &&
spid == iwx_subsystem_id_ax201[i].pm_pid)
@@ -7938,6 +7940,7 @@ iwx_attach(struct device *parent, struct
break;
case PCI_PRODUCT_INTEL_WL_22500_2:
case PCI_PRODUCT_INTEL_WL_22500_3:
+ case PCI_PRODUCT_INTEL_WL_22500_5:
if (sc->sc_hw_rev != IWX_CSR_HW_REV_TYPE_QUZ) {
printf("%s: unsupported AX201 adapter\n", DEVNAME(sc));
return;
Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1963
diff -u -p -r1.1963 pcidevs
--- pcidevs 9 Apr 2021 20:58:20 - 1.1963
+++ pcidevs 14 Apr 2021 06:51:36 -
@@ -3965,6 +3965,9 @@ product INTEL I219_V4 0x15d8 I219-V
product INTEL JHL6340 0x15d9 JHL6340 Thunderbolt 3
product INTEL JHL6340_PCIE 0x15da JHL6340 Thunderbolt 3
product INTEL JHL6340_XHCI 0x15db JHL6340 Thunderbolt 3
+product INTEL JHL7540 0x15eb JHL7540 Thunderbolt 3
+product INTEL JHL7540_PCIE 0x15ea JHL7540 Thunderbolt 3
+product INTEL JHL7540_XHCI 0x15ec JHL7540 Thunderbolt 3
product INTEL I219_LM8 0x15df I219-LM
product INTEL I219_V8 0x15e0 I219-V
product INTEL I219_LM9 0x15e1 I219-LM
@@ -5001,6 +5004,7 @@ product INTEL 495SERIES_LP_XHCI 0x34ed 4
product INTEL 495SERIES_LP_XDCI0x34ee 495 Series xDCI
product INTEL 495SERIES_LP_SRAM0x34ef 495 Series Shared SRAM
product INTEL WL_22500_4 0x34f0 Wi-Fi 6 AX201
+product INTEL WL_22500_5 0x06f0 Wi-Fi 6 AX201
product INTEL 495SERIES_LP_SDXC0x34f8 495 Series SDXC
product INTEL 495SERIES_LP_GSPI_3 0x34fb 495 Series GSPI
product INTEL 495SERIES_LP_ISH 0x34fc 495 Series ISH
