Re: rpki-client: don't leak d->uri in add_delta()
Yep.
Theo Buehler wrote:
> d->uri was allocated by xstrdup(), so needs to be freed. Was going back
> and forth between the below and adding free(d->uri).
>
> Index: rrdp_notification.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/rrdp_notification.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 rrdp_notification.c
> --- rrdp_notification.c 2 Apr 2021 02:20:17 - 1.2
> +++ rrdp_notification.c 2 Apr 2021 02:30:37 -
> @@ -62,6 +62,8 @@ struct notification_xml {
> enum notification_scope scope;
> };
>
> +static void free_delta(struct delta_item *);
> +
> static int
> add_delta(struct notification_xml *nxml, const char *uri,
> const char hash[SHA256_DIGEST_LENGTH], long long serial)
> @@ -85,7 +87,7 @@ add_delta(struct notification_xml *nxml,
> TAILQ_FOREACH(n, &nxml->delta_q, q) {
> if (n->serial == serial) {
> warnx("duplicate delta serial %lld ", serial);
> - free(d);
> + free_delta(d);
> return 0;
> }
> if (n->serial > serial) {
>
rpki-client: don't leak d->uri in add_delta()
d->uri was allocated by xstrdup(), so needs to be freed. Was going back
and forth between the below and adding free(d->uri).
Index: rrdp_notification.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/rrdp_notification.c,v
retrieving revision 1.2
diff -u -p -r1.2 rrdp_notification.c
--- rrdp_notification.c 2 Apr 2021 02:20:17 - 1.2
+++ rrdp_notification.c 2 Apr 2021 02:30:37 -
@@ -62,6 +62,8 @@ struct notification_xml {
enum notification_scope scope;
};
+static voidfree_delta(struct delta_item *);
+
static int
add_delta(struct notification_xml *nxml, const char *uri,
const char hash[SHA256_DIGEST_LENGTH], long long serial)
@@ -85,7 +87,7 @@ add_delta(struct notification_xml *nxml,
TAILQ_FOREACH(n, &nxml->delta_q, q) {
if (n->serial == serial) {
warnx("duplicate delta serial %lld ", serial);
- free(d);
+ free_delta(d);
return 0;
}
if (n->serial > serial) {
Re: vmm.4: document supported ioctls
On Thu, Apr 01, 2021 at 08:34:37PM -0400, Dave Voutila wrote: > I've updated the diff using your feedback. See below. Thanks, OK kn
Re: vmm.4: document supported ioctls
Klemens Nanni writes: > On Thu, Apr 01, 2021 at 06:49:07AM -0400, Dave Voutila wrote: >> This diff documents the ioctl(2) values supported by vmm(4). Besides >> vmd(8) there's at least one application I've seen (Solo5) directly using >> vmm(4). >> >> For now I've tried to have short summary-level details, enough to >> provide a general idea of purpose. The data structures aren't included >> in the doc, but the mention of at least points to >> where they're defined for now. > That seems fair. > >> Feedback on my mdoc macro usage or verbiage? OK? > See inline, but you can also use `mandoc -T lint ./vmm.4' and any > warnings and errors. > Very cool, did not know that. I've updated the diff using your feedback. See below. >> Index: share/man/man4/man4.amd64/vmm.4 >> === >> RCS file: /cvs/src/share/man/man4/man4.amd64/vmm.4,v >> retrieving revision 1.5 >> diff -u -p -r1.5 vmm.4 >> --- share/man/man4/man4.amd64/vmm.4 6 Dec 2015 19:06:17 - 1.5 >> +++ share/man/man4/man4.amd64/vmm.4 1 Apr 2021 10:36:50 - >> @@ -22,6 +22,8 @@ >> .Nd virtual machine monitor >> .Sh SYNOPSIS >> .Cd "vmm0at mainbus0" >> +.Pp >> +.In machine/vmmvar.h >> .Sh DESCRIPTION >> The >> .Nm >> @@ -67,6 +69,45 @@ driver requires at least one CPU with ha >> capabilities and nested or extended paging capabilities to be >> present on the host. >> For more information, consult the CPU vendor's documentation. >> +.Pp >> +The following >> +.Xr ioctl 2 >> +commands are provided for managing >> +.Nm >> +guests: >> +.Pp >> +.Bl -tag -width Ds -offset indent >> +.It Dv VMM_IOC_CREATE Fa "struct vm_create_params *" >> +Create a VM, initializing >> +.Xr vmm 4 > That's the page itself, just use .Nm here like you did in the last > sentence. > >> +if not yet started. (Does not start the VCPU.) >> +.It Dv VMM_IOC_RUN Fa "struct vm_run_params *" >> +Run a VCPU for a defined VM. Returns on VM-exit, the VCPU stopped, or > I'd use imperative mood, i.e. omit "s"^ and add^ "when", I guess. > Good idea. It reads better like that. >> +an error occurred > New sentences go to new lines. Got it. > >> +.It Dv VMM_IOC_INFO Fa "struct vm_info_params *" >> +Get information about the VMs currently hosted by >> +.Xr vmm 4 > This and all following sentences lack punctuation; with .Nm as per > above that'd be ".Nm ." (mind the space between macro and dot if the > line ends with a macro). > >> +.It Dv VMM_IOC_TERM Fa "struct vm_terminate_params *" >> +Terminate a given VM >> +.It Dv VMM_IOC_RESETCPU Fa "struct vm_resetcpu_params *" >> +Reset a VCPU to power-on-init state using the provided register state >> +.It Dv VMM_IOC_INTR Fa "struct vm_intr_params *" >> +Signal a pending interrupt for a VCPU >> +.It Dv VMM_IOC_READREGS Fa "struct vm_rwregs_params *" >> +Read registers of a VCPU >> +.It Dv VMM_IOC_WRITEREGS Fa "struct vm_rwregs_params *" >> +Write registers values of a VCPU >> +.It Dv VMM_IOC_READVMPARAMS Fa "struct vm_revmparams_params *" >> +Read paravirtualized hardware parameters (such as >> +.Xr pvclock 4 >> +version) for a VM >> +.It Dv VMM_IOC_WRITEVMPARAMS Fa "struct vm_rwvmparams_params *" >> +Write paravirtualized hardware parameters (such as >> +.Xr pvclock 4 >> +guest physical addresss) for a VM >> +.It Dv VMM_IOC_MPROTECT_EPT Fa "struct vm_mprotect_ept_params *" >> +Set access protections on guest page table entries >> +(only supported on hosts providing EPT or RVI) > Missing .El here. Done. > >> .Sh SEE ALSO >> .Xr cpu 4 , >> .Xr intro 4 , >> OK? -dv Index: share/man/man4/man4.amd64/vmm.4 === RCS file: /cvs/src/share/man/man4/man4.amd64/vmm.4,v retrieving revision 1.5 diff -u -p -r1.5 vmm.4 --- share/man/man4/man4.amd64/vmm.4 6 Dec 2015 19:06:17 - 1.5 +++ share/man/man4/man4.amd64/vmm.4 2 Apr 2021 00:28:26 - @@ -22,6 +22,8 @@ .Nd virtual machine monitor .Sh SYNOPSIS .Cd "vmm0at mainbus0" +.Pp +.In machine/vmmvar.h .Sh DESCRIPTION The .Nm @@ -67,6 +69,45 @@ driver requires at least one CPU with ha capabilities and nested or extended paging capabilities to be present on the host. For more information, consult the CPU vendor's documentation. +.Pp +The following +.Xr ioctl 2 +commands are provided for managing +.Nm +guests: +.Bl -tag -width Ds -offset indent +.It Dv VMM_IOC_CREATE Fa "struct vm_create_params *" +Create a VM, initializing +.Nm +if not yet started. (Does not start the VCPU.) +.It Dv VMM_IOC_RUN Fa "struct vm_run_params *" +Run a VCPU for a defined VM. +Return on VM-exit, when the VCPU stopped, or an error occurred +.It Dv VMM_IOC_INFO Fa "struct vm_info_params *" +Get information about the VMs currently hosted by +.Nm . +.It Dv VMM_IOC_TERM Fa "struct vm_terminate_params *" +Terminate a given VM. +.It Dv VMM_IOC_RESETCPU Fa "struct vm_resetcpu_params *" +Reset a VCPU to power-on-init state using the provided register state. +.It Dv VMM_IOC
Re: monotonic time going back by wrong skews
On Thu, Apr 01, 2021 at 06:43:30PM -0500, Scott Cheloha wrote: > On Thu, Apr 01, 2021 at 03:41:24PM -0400, Josh Rickmar wrote: > > On Thu, Apr 01, 2021 at 03:22:00PM -0400, Josh Rickmar wrote: > > > On Thu, Apr 01, 2021 at 02:15:48PM -0500, Scott Cheloha wrote: > > > > On Sat, Mar 27, 2021 at 02:20:21AM +, Stefmorino wrote: > > > > > > Feel free to share your raw data. > > > > > > > > > > Also includes some standard sendbug dumps: https://0x0.st/-qng.tgz > > > > > > > > Thanks! > > > > > > > > TL;DR: > > > > > > > > Two things: > > > > > > > > 1. Could you check whether Linux will use the TSC as a clocksource on > > > >this machine? The dmesg output on any given distribution should > > > >contain lines about the TSC. > > > > > > > >[...] > > > > > > > Hey, thanks for the reminder to try this out with Linux. Will give it > > > a shot shortly. > > > > > > As for the BIOS, 1.58 is the current version (found here): > > > > > > https://support.lenovo.com/us/en/downloads/ds503790 > > > > > > This same issue was happening with all older BIOS versions that I have > > > used as well. > > Okay, not great news, but at least the behavior is consistent. > > > Seems Linux doesn't like it either: > > > > localhost:~# dmesg | egrep -i 'tsc|clocksource' > > [0.00] tsc: Fast TSC calibration using PIT > > [0.00] tsc: Detected 1996.173 MHz processor > > [0.043227] clocksource: refined-jiffies: mask: 0x max_cycles: > > 0x, max_idle_ms: 6370452778343963 ns > > [0.114728] clocksource: hpet: mask: 0x max_cycles: 0x, > > max_idle_ns: 133484873504 ns > > [0.131435] clocksource: tsc-early: mask: 0x max_cycles: > > 0x398c1ebcd00, max_idle_ns: 881590807727 ns > > [0.244772] TSC synchronization [CPU#0 -> CPU#1]: > > [0.244772] Measured 7296391160 warp between CPUs, turning off TSC clock. > > [0.244772] tsc: Marking TSC unstable due to check_tsc_sync_source_failed > > [0.252185] clocksource: jiffies: mask: 0x max_cycles: > > 0x, max_idle_ns: 6370867519511994 ns > > [0.316884] clocksource: Switched to clocksource hpet > > [0.335046] clocksource: acpi_pm: mask: 0xff max_cycles: 0xff, > > max_idle_ns: 2085701024 ns > > Hmmm. Being able to work around this would be nice. > > FreeBSD has code that uses WRMSR to synchronize the TSC: > > https://cgit.freebsd.org/src/commit/sys/x86/x86/tsc.c?id=b2c63698d4b81576e0c8842263ee86e86cd34e76 > > My guess is that support for writing the TSC is not implemented by > every hypervisor, so we would need to be very careful in deciding when > to try it. Otherwise we end up with protection faults and other crap > we don't want. > > Doing this via TSC_ADJUST (instead of writing the TSC directly) is > nicer because you just check for the CPUID level and bit. No > guesswork. But we can't in your case because, as I said, no > TSC_ADJUST support on your CPU. This seems to be a common problem among most Ryzen Thinkpads. https://bugzilla.kernel.org/show_bug.cgi?id=202525 Oddly enough, the A485/A585 seems to have gotten a BIOS patch (v1.28, Nov 2019) that fixes this, but no other models that I can see.
Re: update xterm to version 367
Matthieu Herrb writes: > On Sat, Mar 27, 2021 at 10:22:15AM +0100, Matthieu Herrb wrote: >> Patch #367 - 2021/03/26 >> >> ok ? comments ? > > Hi, > > I could use some actual test results. I'd like to commit the update. No issues on my end. My workflow is pretty basic, but no visible regressions from v366. -dv
Re: monotonic time going back by wrong skews
On Thu, Apr 01, 2021 at 03:41:24PM -0400, Josh Rickmar wrote: > On Thu, Apr 01, 2021 at 03:22:00PM -0400, Josh Rickmar wrote: > > On Thu, Apr 01, 2021 at 02:15:48PM -0500, Scott Cheloha wrote: > > > On Sat, Mar 27, 2021 at 02:20:21AM +, Stefmorino wrote: > > > > > Feel free to share your raw data. > > > > > > > > Also includes some standard sendbug dumps: https://0x0.st/-qng.tgz > > > > > > Thanks! > > > > > > TL;DR: > > > > > > Two things: > > > > > > 1. Could you check whether Linux will use the TSC as a clocksource on > > >this machine? The dmesg output on any given distribution should > > >contain lines about the TSC. > > > > > >[...] > > > > > Hey, thanks for the reminder to try this out with Linux. Will give it > > a shot shortly. > > > > As for the BIOS, 1.58 is the current version (found here): > > > > https://support.lenovo.com/us/en/downloads/ds503790 > > > > This same issue was happening with all older BIOS versions that I have > > used as well. Okay, not great news, but at least the behavior is consistent. > Seems Linux doesn't like it either: > > localhost:~# dmesg | egrep -i 'tsc|clocksource' > [0.00] tsc: Fast TSC calibration using PIT > [0.00] tsc: Detected 1996.173 MHz processor > [0.043227] clocksource: refined-jiffies: mask: 0x max_cycles: > 0x, max_idle_ms: 6370452778343963 ns > [0.114728] clocksource: hpet: mask: 0x max_cycles: 0x, > max_idle_ns: 133484873504 ns > [0.131435] clocksource: tsc-early: mask: 0x max_cycles: > 0x398c1ebcd00, max_idle_ns: 881590807727 ns > [0.244772] TSC synchronization [CPU#0 -> CPU#1]: > [0.244772] Measured 7296391160 warp between CPUs, turning off TSC clock. > [0.244772] tsc: Marking TSC unstable due to check_tsc_sync_source_failed > [0.252185] clocksource: jiffies: mask: 0x max_cycles: 0x, > max_idle_ns: 6370867519511994 ns > [0.316884] clocksource: Switched to clocksource hpet > [0.335046] clocksource: acpi_pm: mask: 0xff max_cycles: 0xff, > max_idle_ns: 2085701024 ns Hmmm. Being able to work around this would be nice. FreeBSD has code that uses WRMSR to synchronize the TSC: https://cgit.freebsd.org/src/commit/sys/x86/x86/tsc.c?id=b2c63698d4b81576e0c8842263ee86e86cd34e76 My guess is that support for writing the TSC is not implemented by every hypervisor, so we would need to be very careful in deciding when to try it. Otherwise we end up with protection faults and other crap we don't want. Doing this via TSC_ADJUST (instead of writing the TSC directly) is nicer because you just check for the CPUID level and bit. No guesswork. But we can't in your case because, as I said, no TSC_ADJUST support on your CPU.
Re: update xterm to version 367
Matthieu Herrb wrote: > On Sat, Mar 27, 2021 at 10:22:15AM +0100, Matthieu Herrb wrote: > > Patch #367 - 2021/03/26 > > > > ok ? comments ? > > Hi, > > I could use some actual test results. I'd like to commit the update. > > -- > Matthieu Herrb Sorry, had this in mind to test and hadn't gotten to it. I've run it through my usual paces on amd64 and aarch64. Font sizes, Japanese character display, tmux with split frames. On amd64, also Japanese text entry, I ran around a bit in games/cataclysm-dda in text mode, and ran a few of the vttest scripts. No regresions noticed. Tim.
Re: iwm(4) A-MSDU support
Stefan Sperling wrote: > This patch attempts to add support for receiving A-MSDUs to iwm(4). > If you are using iwm(4) then please run with this patch and let me > know if it causes regressions. Thanks! > > ACHTUNG: This patch breaks iwx(4)! Don't use it there! For this reason, > the patch can neither be committed nor be put into snapshots!!! > > Our net80211 stack de-aggregates A-MSDUs in software. This works fine with > iwm 7k and 8k devices. However, iwm 9k devices de-aggregate A-MSDUs in > hardware and net80211 is currently unable to handle this. > > Our current iwm 9k code only works because long ago I disabled reception > of A-MSDUs for all devices. Unfortunately, the only way to get A-MSDUs > working on 9k hardware is to add a bunch of driver-specific code which > handles de-aggregation. Otherwise, net80211 will drop frames which appear > to arrive out of order, or appear as duplicates even though they were > simply part of the same A-MSDU and thus share a sequence number. > The driver can re-order frames correctly based on information provided > by firmware. I'd rather implement this than letting these devices miss > out on A-MSDUs because the Rx speed advantage can be significant, around > 80/90 Mbps (but this will very much depend on the AP). > > If these A-* acronyms don't make sense and you'd like to know more, here > is a fairly good explanation: https://mrncciew.com/2013/04/11/a-mpdu-a-msdu/ > Note that we care about the nested case, which is also mentioned in this > article but not explained in detail. It's simply an A-MSDU stashed inside > an A-MPDU. If an AP can do 11AC, then it should support this. > > iwx(4) hardware has the same problem. > If this patch works fine on iwm(4) then I can port the changes to iwx(4), > do another round of testing, and eventually commit to both drivers at > the same time. > > Some of the changes below are based on code from the Linux iwlwifi driver. > I am not entirely happy with some of its style. But the code should be in > good enough shape to be tested. No regression noticed here for several days under my normal workload. iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi iwm0: hw rev 0x210, fw ver 17.3216344376.0, address dc:53:60:4a:b1:ea Tim.
Re: monotonic time going back by wrong skews
On Thu, Apr 01, 2021 at 03:22:00PM -0400, Josh Rickmar wrote: > On Thu, Apr 01, 2021 at 02:15:48PM -0500, Scott Cheloha wrote: > > On Sat, Mar 27, 2021 at 02:20:21AM +, Stefmorino wrote: > > > > Feel free to share your raw data. > > > > > > Also includes some standard sendbug dumps: https://0x0.st/-qng.tgz > > > > Thanks! > > > > TL;DR: > > > > Two things: > > > > 1. Could you check whether Linux will use the TSC as a clocksource on > >this machine? The dmesg output on any given distribution should > >contain lines about the TSC. > > > >Feel free to use my easy five-step method. You don't even need to > >install Linux, we just need to boot installation media and look at > >the dmesg: > > > >A. Grab the latest Alpine Linux ISO: > > > > $ ftp > > https://dl-cdn.alpinelinux.org/alpine/v3.13/releases/x86_64/alpine-standard-3.13.4-x86_64.iso > > > >B. Write the ISO to a USB key to create your bootable installation media. > > > > Achtung! Danger! Don't wipe out the wrong disk! Change /dev/sdNc > > to match the special device for your USB stick! > > > > # dd if=alpine-standard-3.13.4-x86_64.iso of=/dev/sdNc bs=1m > > > >C. Reboot. > > > > # shutdown -r now > > > >D. Boot from the USB stick. How you do this varies by device. Log in as > > root. The Alpine installation ramdisk has no root password. > > > >E. Examine the Linux dmesg for lines about the TSC, clocksources: > > > > # dmesg | egrep -i 'tsc|clocksource' > > > > 2. Second, is there a more recent BIOS revision for this machine? > >Perhaps (assuming this is in fact a BIOS problem) Lenovo is aware > >of it and has fixed it. This is unlikely but worth a look. > > > > Long version: > > > > I think two points form a pattern. Bear with me. > > > > Both you and Josh Rickmar (CC'd) have Lenovo laptops with the same CPU > > (AMD Ryzen 5 2500U) and the same BIOS (LENOVO version "R0UET78W (1.58 > > )" date 11/17/2020). > > > > Looking at the data here, both machines exhibit the same problem with > > the TSC: the APs are all nearly synchronized outside of small > > measurement errors while the BSP is way off. > > > > This makes me wonder whether this is a firmware/BIOS bug. Perhaps the > > BIOS is fussing with the TSC on CPU0 before we boot. Is there a new > > BIOS revision available from Lenovo? > > > > I'd also be interested to know if a recent Linux kernel would even use > > the TSC on this laptop as a clocksource or if the kernel complains and > > falls back to using the HPET. > > > > There is a little chit-chat here and there about adding support to > > OpenBSD for fixing the TSC skew during synchronization at boot/resume. > > One way to do this is with the TSC_ADJUST MSR... > > > > ... but that won't work here in your case. The CPU on this particular > > laptop does not have TSC_ADJUST support, so if we wanted to correct > > the TSC skew we'd have to use WRMSR to modify the TSC directly. > > > > I'm uncertain about whether using WRMSR to reset the TSC on a given > > logical processor is universally supported on all amd64 machines or > > if it's a special feature a la the TSC_ADJUST MSR. > > > > -Scott > > Hey, thanks for the reminder to try this out with Linux. Will give it > a shot shortly. > > As for the BIOS, 1.58 is the current version (found here): > > https://support.lenovo.com/us/en/downloads/ds503790 > > This same issue was happening with all older BIOS versions that I have > used as well. > Seems Linux doesn't like it either: localhost:~# dmesg | egrep -i 'tsc|clocksource' [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 1996.173 MHz processor [0.043227] clocksource: refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ms: 6370452778343963 ns [0.114728] clocksource: hpet: mask: 0x max_cycles: 0x, max_idle_ns: 133484873504 ns [0.131435] clocksource: tsc-early: mask: 0x max_cycles: 0x398c1ebcd00, max_idle_ns: 881590807727 ns [0.244772] TSC synchronization [CPU#0 -> CPU#1]: [0.244772] Measured 7296391160 warp between CPUs, turning off TSC clock. [0.244772] tsc: Marking TSC unstable due to check_tsc_sync_source_failed [0.252185] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 6370867519511994 ns [0.316884] clocksource: Switched to clocksource hpet [0.335046] clocksource: acpi_pm: mask: 0xff max_cycles: 0xff, max_idle_ns: 2085701024 ns
Re: monotonic time going back by wrong skews
On Thu, Apr 01, 2021 at 02:15:48PM -0500, Scott Cheloha wrote: > On Sat, Mar 27, 2021 at 02:20:21AM +, Stefmorino wrote: > > > Feel free to share your raw data. > > > > Also includes some standard sendbug dumps: https://0x0.st/-qng.tgz > > Thanks! > > TL;DR: > > Two things: > > 1. Could you check whether Linux will use the TSC as a clocksource on >this machine? The dmesg output on any given distribution should >contain lines about the TSC. > >Feel free to use my easy five-step method. You don't even need to >install Linux, we just need to boot installation media and look at >the dmesg: > >A. Grab the latest Alpine Linux ISO: > > $ ftp > https://dl-cdn.alpinelinux.org/alpine/v3.13/releases/x86_64/alpine-standard-3.13.4-x86_64.iso > >B. Write the ISO to a USB key to create your bootable installation media. > > Achtung! Danger! Don't wipe out the wrong disk! Change /dev/sdNc > to match the special device for your USB stick! > > # dd if=alpine-standard-3.13.4-x86_64.iso of=/dev/sdNc bs=1m > >C. Reboot. > > # shutdown -r now > >D. Boot from the USB stick. How you do this varies by device. Log in as > root. The Alpine installation ramdisk has no root password. > >E. Examine the Linux dmesg for lines about the TSC, clocksources: > > # dmesg | egrep -i 'tsc|clocksource' > > 2. Second, is there a more recent BIOS revision for this machine? >Perhaps (assuming this is in fact a BIOS problem) Lenovo is aware >of it and has fixed it. This is unlikely but worth a look. > > Long version: > > I think two points form a pattern. Bear with me. > > Both you and Josh Rickmar (CC'd) have Lenovo laptops with the same CPU > (AMD Ryzen 5 2500U) and the same BIOS (LENOVO version "R0UET78W (1.58 > )" date 11/17/2020). > > Looking at the data here, both machines exhibit the same problem with > the TSC: the APs are all nearly synchronized outside of small > measurement errors while the BSP is way off. > > This makes me wonder whether this is a firmware/BIOS bug. Perhaps the > BIOS is fussing with the TSC on CPU0 before we boot. Is there a new > BIOS revision available from Lenovo? > > I'd also be interested to know if a recent Linux kernel would even use > the TSC on this laptop as a clocksource or if the kernel complains and > falls back to using the HPET. > > There is a little chit-chat here and there about adding support to > OpenBSD for fixing the TSC skew during synchronization at boot/resume. > One way to do this is with the TSC_ADJUST MSR... > > ... but that won't work here in your case. The CPU on this particular > laptop does not have TSC_ADJUST support, so if we wanted to correct > the TSC skew we'd have to use WRMSR to modify the TSC directly. > > I'm uncertain about whether using WRMSR to reset the TSC on a given > logical processor is universally supported on all amd64 machines or > if it's a special feature a la the TSC_ADJUST MSR. > > -Scott Hey, thanks for the reminder to try this out with Linux. Will give it a shot shortly. As for the BIOS, 1.58 is the current version (found here): https://support.lenovo.com/us/en/downloads/ds503790 This same issue was happening with all older BIOS versions that I have used as well.
Re: monotonic time going back by wrong skews
On Sat, Mar 27, 2021 at 02:20:21AM +, Stefmorino wrote: > > Feel free to share your raw data. > > Also includes some standard sendbug dumps: https://0x0.st/-qng.tgz Thanks! TL;DR: Two things: 1. Could you check whether Linux will use the TSC as a clocksource on this machine? The dmesg output on any given distribution should contain lines about the TSC. Feel free to use my easy five-step method. You don't even need to install Linux, we just need to boot installation media and look at the dmesg: A. Grab the latest Alpine Linux ISO: $ ftp https://dl-cdn.alpinelinux.org/alpine/v3.13/releases/x86_64/alpine-standard-3.13.4-x86_64.iso B. Write the ISO to a USB key to create your bootable installation media. Achtung! Danger! Don't wipe out the wrong disk! Change /dev/sdNc to match the special device for your USB stick! # dd if=alpine-standard-3.13.4-x86_64.iso of=/dev/sdNc bs=1m C. Reboot. # shutdown -r now D. Boot from the USB stick. How you do this varies by device. Log in as root. The Alpine installation ramdisk has no root password. E. Examine the Linux dmesg for lines about the TSC, clocksources: # dmesg | egrep -i 'tsc|clocksource' 2. Second, is there a more recent BIOS revision for this machine? Perhaps (assuming this is in fact a BIOS problem) Lenovo is aware of it and has fixed it. This is unlikely but worth a look. Long version: I think two points form a pattern. Bear with me. Both you and Josh Rickmar (CC'd) have Lenovo laptops with the same CPU (AMD Ryzen 5 2500U) and the same BIOS (LENOVO version "R0UET78W (1.58 )" date 11/17/2020). Looking at the data here, both machines exhibit the same problem with the TSC: the APs are all nearly synchronized outside of small measurement errors while the BSP is way off. This makes me wonder whether this is a firmware/BIOS bug. Perhaps the BIOS is fussing with the TSC on CPU0 before we boot. Is there a new BIOS revision available from Lenovo? I'd also be interested to know if a recent Linux kernel would even use the TSC on this laptop as a clocksource or if the kernel complains and falls back to using the HPET. There is a little chit-chat here and there about adding support to OpenBSD for fixing the TSC skew during synchronization at boot/resume. One way to do this is with the TSC_ADJUST MSR... ... but that won't work here in your case. The CPU on this particular laptop does not have TSC_ADJUST support, so if we wanted to correct the TSC skew we'd have to use WRMSR to modify the TSC directly. I'm uncertain about whether using WRMSR to reset the TSC on a given logical processor is universally supported on all amd64 machines or if it's a special feature a la the TSC_ADJUST MSR. -Scott
Re: patch: asr_debug.c prints SOA in wrong order
Op Tue, 30 Mar 2021 12:15:42 +0200 schreef Boudewijn Dijkstra : Both asr_private.h and asr_utils.c have mname before rname but not asr_debug.c. And another thing while we're here: since 2019 the flag RES_USE_CD exists, but this was never added to asr_debug.c. New patch follows. Index: asr_debug.c === RCS file: /cvs/src/lib/libc/asr/asr_debug.c,v retrieving revision 1.26 diff -u -p -r1.26 asr_debug.c --- asr_debug.c 3 Jul 2019 03:24:03 - 1.26 +++ asr_debug.c 1 Apr 2021 12:02:17 - @@ -101,8 +101,8 @@ print_rr(const struct asr_dns_rr *rr, ch break; case T_SOA: snprintf(buf, max, "%s %s %lu %lu %lu %lu %lu", - print_dname(rr->rr.soa.rname, tmp, sizeof tmp), - print_dname(rr->rr.soa.mname, tmp2, sizeof tmp2), + print_dname(rr->rr.soa.mname, tmp, sizeof tmp), + print_dname(rr->rr.soa.rname, tmp2, sizeof tmp2), (unsigned long)rr->rr.soa.serial, (unsigned long)rr->rr.soa.refresh, (unsigned long)rr->rr.soa.retry, @@ -285,6 +285,7 @@ _asr_dump_config(FILE *f, struct asr *a) PRINTOPT(RES_NOALIASES, "NOALIASES"); PRINTOPT(RES_USE_EDNS0, "USE_EDNS0"); PRINTOPT(RES_USE_DNSSEC, "USE_DNSSEC"); + PRINTOPT(RES_USE_CD, "USE_CD"); if (o) fprintf(f, " 0x%08x", o); fprintf(f, "\n"); -- Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
dig(1): implement ZONEMD
Implement ZONEMD (RFC8976), based on DS (ds_43.c)
OK?
There are example zones here that nsd can serve:
https://github.com/verisign/zonemd-test-cases
diff --git lib/dns/include/dns/types.h lib/dns/include/dns/types.h
index b8b117fb16d..63ea8d67f51 100644
--- lib/dns/include/dns/types.h
+++ lib/dns/include/dns/types.h
@@ -138,6 +138,7 @@ enum {
dns_rdatatype_cdnskey = 60,
dns_rdatatype_openpgpkey = 61,
dns_rdatatype_csync = 62,
+ dns_rdatatype_zonemd = 63,
dns_rdatatype_spf = 99,
dns_rdatatype_unspec = 103,
dns_rdatatype_nid = 104,
diff --git lib/dns/rdata.c lib/dns/rdata.c
index 22d8f9c824b..04777f3cb8e 100644
--- lib/dns/rdata.c
+++ lib/dns/rdata.c
@@ -833,7 +833,8 @@ dns_rdatatype_fromtext(dns_rdatatype_t *typep,
isc_textregion_t *source) {
{"unspec", 103},
{"uri", 256},
{"wks", 11},
- {"x25", 19}
+ {"x25", 19},
+ {"zonemd", 63},
};
const dns_rdata_type_lookup_t *p;
unsigned int n;
@@ -1003,6 +1004,8 @@ dns_rdatatype_totext(dns_rdatatype_t type, isc_buffer_t
*target) {
return (isc_str_tobuffer("OPENPGPKEY", target));
case 62:
return (isc_str_tobuffer("CSYNC", target));
+ case 63:
+ return (isc_str_tobuffer("ZONEMD", target));
case 99:
return (isc_str_tobuffer("SPF", target));
case 100:
diff --git lib/dns/rdata/generic/zonemd_63.c lib/dns/rdata/generic/zonemd_63.c
new file mode 100644
index 000..fae3c9cf452
--- /dev/null
+++ lib/dns/rdata/generic/zonemd_63.c
@@ -0,0 +1,118 @@
+/*
+ * Copyright (C) Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
+ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
+ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/* $Id: ds_43.c,v 1.13 2020/02/26 18:47:59 florian Exp $ */
+
+/* RFC8976 */
+
+#ifndef RDATA_GENERIC_ZONEMD_63_C
+#define RDATA_GENERIC_ZONEMD_63_C
+
+#defineDNS_ZONEMD_DIGEST_SHA384(1)
+
+static inline isc_result_t
+totext_zonemd(ARGS_TOTEXT) {
+ isc_region_t sr;
+ char buf[sizeof("4294967295 ")];
+ uint32_t n;
+
+ REQUIRE(rdata->type == dns_rdatatype_zonemd);
+ REQUIRE(rdata->length > 6);
+
+ dns_rdata_toregion(rdata, &sr);
+
+ /* serial */
+ n = uint32_fromregion(&sr);
+ isc_region_consume(&sr, 4);
+ snprintf(buf, sizeof(buf), "%u ", n);
+ RETERR(isc_str_tobuffer(buf, target));
+
+ /* scheme */
+ n = uint8_fromregion(&sr);
+ isc_region_consume(&sr, 1);
+ snprintf(buf, sizeof(buf), "%u ", n);
+ RETERR(isc_str_tobuffer(buf, target));
+
+ /* hash algo */
+ n = uint8_fromregion(&sr);
+ isc_region_consume(&sr, 1);
+ snprintf(buf, sizeof(buf), "%u", n);
+ RETERR(isc_str_tobuffer(buf, target));
+
+ /* Digest */
+ if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
+ RETERR(isc_str_tobuffer(" (", target));
+ RETERR(isc_str_tobuffer(tctx->linebreak, target));
+ if ((tctx->flags & DNS_STYLEFLAG_NOCRYPTO) == 0) {
+ if (tctx->width == 0) /* No splitting */
+ RETERR(isc_hex_totext(&sr, 0, "", target));
+ else
+ RETERR(isc_hex_totext(&sr, tctx->width - 2,
+ tctx->linebreak, target));
+ } else
+ RETERR(isc_str_tobuffer("[omitted]", target));
+ if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
+ RETERR(isc_str_tobuffer(" )", target));
+ return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+fromwire_zonemd(ARGS_FROMWIRE) {
+ isc_region_t sr;
+
+ REQUIRE(type == dns_rdatatype_zonemd);
+
+ UNUSED(type);
+ UNUSED(rdclass);
+ UNUSED(dctx);
+ UNUSED(options);
+
+ isc_buffer_activeregion(source, &sr);
+ /*
+* serial: 4
+* scheme: 1
+* hash algorith: 1
+* digest: at least 1
+*/
+ if (sr.length < 7)
+ return (ISC_R_UNEXPECTEDEND);
+
+ if (sr.base[5] == DNS_ZONEMD_DIGEST_SHA384) {
+ if (sr.length < 6 + ISC_SHA384_DIGESTLENGTH)
+ return (ISC_R_UNEXPECTEDEND);
+ e
Re: update xterm to version 367
Matthieu Herrb writes: > On Sat, Mar 27, 2021 at 10:22:15AM +0100, Matthieu Herrb wrote: >> Patch #367 - 2021/03/26 >> >> ok ? comments ? > > Hi, > > I could use some actual test results. I'd like to commit the update. Seems to be working fine here!
Re: smtpd: default mta ciphers
On Thu, 01 Apr 2021 16:34:33 +0200, Eric Faurot wrote: > If not cipher list is specified for a relay rule, fallback to > the global cipher list if defined, rather than libtls default. > This is closer to the previous behavior. OK millert@ - todd
smtpd: default mta ciphers
If not cipher list is specified for a relay rule, fallback to
the global cipher list if defined, rather than libtls default.
This is closer to the previous behavior.
Eric.
Index: mta.c
===
RCS file: /cvs/src/usr.sbin/smtpd/mta.c,v
retrieving revision 1.236
diff -u -p -r1.236 mta.c
--- mta.c 31 Mar 2021 17:47:16 - 1.236
+++ mta.c 31 Mar 2021 19:14:13 -
@@ -491,6 +491,7 @@ mta_setup_dispatcher(struct dispatcher *
struct tls_config *config;
struct pki *pki;
struct ca *ca;
+ const char *ciphers;
uint32_t protos;
if (dispatcher->type != DISPATCHER_REMOTE)
@@ -501,8 +502,10 @@ mta_setup_dispatcher(struct dispatcher *
if ((config = tls_config_new()) == NULL)
fatal("smtpd: tls_config_new");
- if (remote->tls_ciphers &&
- tls_config_set_ciphers(config, remote->tls_ciphers) == -1)
+ ciphers = env->sc_tls_ciphers;
+ if (remote->tls_ciphers)
+ ciphers = remote->tls_ciphers;
+ if (ciphers && tls_config_set_ciphers(config, ciphers) == -1)
err(1, "%s", tls_config_error(config));
if (remote->tls_protocols &&
Updates for elf(5)
In revision 1.35 EI_BRAND was removed in conjunction with EI_OSABI and EI_ABIVERSION being added, but it looks like this has not been reflected in elf(5). The only place EI_BRAND appears in OpenBSD's current source tree is this man page, as such I think it's worth removing. For a quick comparison to other systems FreeBSD still mentions EI_BRAND but NetBSD does not (and never appeared to document this in any man page). With regards to EI_OSABI and EI_ABIVERSION FreeBSD covers the defined values whereas NetBSD does not as they note only ELFOSABI_SYSV is used. On the other hand FreeBSD does indeed mark native binaries as ELFOSABI_FREEBSD. Further afield in Linux EI_BRAND was removed, EI_OSABI and EI_ABIVERSION defined values are covered similar to FreeBSD. The diff below removes mention of EI_BRAND and uncomments the EI_OSABI and EI_ABIVERSION parts which appear to have been present since the initial appearance of this man page. In addition I've added the mention of the Modesto and OpenBSD EI_OSABI values as they are defined in sys/sys/exec_elf.h. diff --git a/share/man/man5/elf.5 b/share/man/man5/elf.5 index 57b0bf0da4d..6ce92ef9bb4 100644 --- a/share/man/man5/elf.5 +++ b/share/man/man5/elf.5 @@ -207,51 +207,56 @@ Invalid version. .It Dv EV_CURRENT Current version. .El -.\" .It Dv EI_OSABI -.\" This byte identifies the operating system -.\" and ABI to which the object is targeted. -.\" Some fields in other ELF structures have flags -.\" and values that have platform specific meanings; -.\" the interpretation of those fields is determined by the value of this byte. -.\" The following values are currently defined: -.\" .Pp -.\" .Bl -tag -width "ELFOSABI_STANDALONE" -compact -.\" .It Dv ELFOSABI_SYSV -.\" UNIX System V ABI. -.\" .It Dv ELFOSABI_HPUX -.\" HP-UX operating system ABI. -.\" .It Dv ELFOSABI_NETBSD -.\" .Nx -.\" operating system ABI. -.\" .It Dv ELFOSABI_LINUX -.\" GNU/Linux operating system ABI. -.\" .It Dv ELFOSABI_HURD -.\" GNU/Hurd operating system ABI. -.\" .It Dv ELFOSABI_86OPEN -.\" 86Open Common IA32 ABI. -.\" .It Dv ELFOSABI_SOLARIS -.\" Solaris operating system ABI. -.\" .It Dv ELFOSABI_MONTEREY -.\" Monterey project ABI. -.\" .It Dv ELFOSABI_IRIX -.\" IRIX operating system ABI. -.\" .It Dv ELFOSABI_FREEBSD -.\" .Fx -.\" operating system ABI. -.\" .It Dv ELFOSABI_TRU64 -.\" TRU64 UNIX operating system ABI. -.\" .It Dv ELFOSABI_ARM -.\" ARM architecture ABI. -.\" .It Dv ELFOSABI_STANDALONE -.\" Stand-alone (embedded) ABI. -.\" .El -.\" .It Dv EI_ABIVERSION -.\" This byte identifies the version of the ABI -.\" to which the object is targeted. -.\" This field is used to distinguish among incompatible versions of an ABI. -.\" The interpretation of this version number -.\" is dependent on the ABI identified by the EI_OSABI field. -.\" Applications conforming to this specification use the value 0. +.It Dv EI_OSABI +This byte identifies the operating system +and ABI to which the object is targeted. +Some fields in other ELF structures have flags +and values that have platform specific meanings; +the interpretation of those fields is determined by the value of this byte. +The following values are currently defined: +.Pp +.Bl -tag -width "ELFOSABI_STANDALONE" -compact +.It Dv ELFOSABI_SYSV +UNIX System V ABI. +.It Dv ELFOSABI_HPUX +HP-UX operating system ABI. +.It Dv ELFOSABI_NETBSD +.Nx +operating system ABI. +.It Dv ELFOSABI_LINUX +GNU/Linux operating system ABI. +.It Dv ELFOSABI_HURD +GNU/Hurd operating system ABI. +.It Dv ELFOSABI_86OPEN +86Open Common IA32 ABI. +.It Dv ELFOSABI_SOLARIS +Solaris operating system ABI. +.It Dv ELFOSABI_MONTEREY +Monterey project ABI. +.It Dv ELFOSABI_IRIX +IRIX operating system ABI. +.It Dv ELFOSABI_FREEBSD +.Fx +operating system ABI. +.It Dv ELFOSABI_TRU64 +TRU64 UNIX operating system ABI. +.It Dv ELFOSABI_MODESTO +Modesto operating system ABI. +.It Dv ELFOSABI_OPENBSD +.Ox +operating system ABI. +.It Dv ELFOSABI_ARM +ARM architecture ABI. +.It Dv ELFOSABI_STANDALONE +Stand-alone (embedded) ABI. +.El +.It Dv EI_ABIVERSION +This byte identifies the version of the ABI +to which the object is targeted. +This field is used to distinguish among incompatible versions of an ABI. +The interpretation of this version number +is dependent on the ABI identified by the EI_OSABI field. +Applications conforming to this specification use the value 0. .It Dv EI_PAD Start of padding. These bytes are reserved and set to zero. @@ -259,8 +264,6 @@ Programs which read them should ignore them. The value for EI_PAD will change in the future if currently unused bytes are given meanings. -.It Dv EI_BRAND -Start of architecture identification. .It Dv EI_NIDENT The size of the e_ident array. .El
iscsid issues with Synology NAS
Second try
Hello,
I’m having issues getting iscsid to work with my Synology NAS on
amd64/6.9-beta.
The first issue was that the NAS was returning an error code. Turns out
it didn’t like missing the default SessionType=Normal.
The second issue was that the login sequence never completed. It seems
we keep hardcoding MaxConnections and MaxRecvDataSegmentLength in
connection.c:conn_gen_kvp() instead of negotiating to the lowest value.
So I just bypassed that function entirely and hardcoded all the default
settings in initiator.c.
This makes the login step complete, but then nothing else happens after
that. I would expect a new scsi device to be attached so I could use it.
I did notice that MaxConnection shows as 0, but the NAS does show the
connection as established.
b1# iscsictl show
Initiator: ISID base 80d3cf6f qalifier 6e7d
Session 'disk2':
SessionType: normal MaxConnections: 0
TargetName: iqn.2000-01.com.synology:Target.02
TargetAddr: 192.168.0.4:iscsi
InitiatorName: iqn.1995-11.org.openbsd.iscsid:b1
InitiatorAddr: 192.168.0.9
command successful
b1$ cat /etc/iscsi.conf
target disk2 {
initiatoraddr 192.168.0.9
targetaddr 192.168.0.4
targetname "iqn.2000-01.com.synology:Target.02"
}
Any suggestions on where to go from here?
Thanks,
-David
b1$ doas /usr/sbin/iscsid -dv
startup
session_fsm[disk2]: INIT ev start timeout 0
sess_fsm[disk2]: INIT ev start
new connection to 192.168.0.4:3260
conn_fsm[disk2]: FREE ev connect
conn_fsm[disk2]: new state XPT_WAIT
sess_fsm[disk2]: new state FREE
sess_fsm: done
conn_fsm[disk2]: XPT_WAIT ev connected
conn_fsm[disk2]: new state IN_LOGIN
conn_parse_kvp: AuthMethod = None
conn_parse_kvp: TargetAlias = Synology Target
conn_parse_kvp: TargetPortalGroupTag = 1
SET_NUM: TargetPortalGroupTag = 1
conn_parse_kvp: HeaderDigest = None
conn_parse_kvp: DataDigest = None
conn_parse_kvp: MaxConnections = 1
SET_NUM: MaxConnections = 1
conn_parse_kvp: ImmediateData = Yes
SET_BOOL: ImmediateData = 1
conn_parse_kvp: MaxRecvDataSegmentLength = 262144
SET_NUM: MaxRecvDataSegmentLength = 262144
conn_parse_kvp: MaxBurstLength = 262144
SET_NUM: MaxBurstLength = 262144
conn_parse_kvp: FirstBurstLength = 65536
SET_NUM: FirstBurstLength = 65536
conn_parse_kvp: DefaultTime2Wait = 2
SET_NUM: DefaultTime2Wait = 2
conn_parse_kvp: DefaultTime2Retain = 20
SET_NUM: DefaultTime2Retain = 20
conn_parse_kvp: MaxOutstandingR2T = 1
SET_NUM: MaxOutstandingR2T = 1
conn_parse_kvp: DataPDUInOrder = Yes
SET_BOOL: DataPDUInOrder = 1
conn_parse_kvp: DataSequenceInOrder = Yes
SET_BOOL: DataSequenceInOrder = 1
conn_parse_kvp: ErrorRecoveryLevel = 0
SET_NUM: ErrorRecoveryLevel = 0
conn_fsm[disk2]: IN_LOGIN ev logged in
session_fsm[disk2]: FREE ev connection logged in timeout 0
conn_fsm[disk2]: new state LOGGED_IN
sess_fsm[disk2]: FREE ev connection logged in
sess_fsm[disk2]: new state LOGGED_IN
sess_fsm: done
Index: initiator.c
===
RCS file: /cvs/src/usr.sbin/iscsid/initiator.c,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 initiator.c
--- initiator.c 16 Jan 2015 15:57:06 - 1.15
+++ initiator.c 31 Mar 2021 03:24:44 -
@@ -254,11 +254,10 @@ struct kvp *
initiator_login_kvp(struct connection *c, u_int8_t stage)
{
struct kvp *kvp;
- size_t nkvp;
switch (stage) {
case ISCSI_LOGIN_STG_SECNEG:
- if (!(kvp = calloc(4, sizeof(*kvp
+ if (!(kvp = calloc(5, sizeof(*kvp
return NULL;
kvp[0].key = "AuthMethod";
kvp[0].value = "None";
@@ -269,20 +268,39 @@ initiator_login_kvp(struct connection *c
kvp[2].key = "SessionType";
kvp[2].value = "Discovery";
} else {
- kvp[2].key = "TargetName";
- kvp[2].value = c->session->config.TargetName;
+ kvp[2].key = "SessionType";
+ kvp[2].value = "Normal";
+ kvp[3].key = "TargetName";
+ kvp[3].value = c->session->config.TargetName;
}
break;
case ISCSI_LOGIN_STG_OPNEG:
- if (conn_gen_kvp(c, NULL, &nkvp) == -1)
- return NULL;
- nkvp += 1; /* add slot for terminator */
- if (!(kvp = calloc(nkvp, sizeof(*kvp
- return NULL;
- if (conn_gen_kvp(c, kvp, &nkvp) == -1) {
- free(kvp);
+ if (!(kvp = calloc(13, sizeof(*kvp
return NULL;
- }
+ kvp[0].key = "HeaderDigest";
+ kvp[0].value = "None";
+ kvp[1].key = "DataDigest";
+ kvp[1].value = "None";
+ kvp[2].key = "ImmediateData";
+ kvp[2].value = "Yes";
+ kvp[3].key = "MaxBurstLength";
+
Re: update xterm to version 367
On Sat, Mar 27, 2021 at 10:22:15AM +0100, Matthieu Herrb wrote: > Patch #367 - 2021/03/26 > > ok ? comments ? Hi, I could use some actual test results. I'd like to commit the update. -- Matthieu Herrb
Re: vmm.4: document supported ioctls
Thanks Dave, I like the description and listing the ioctl, and referencing vmmvar.h is a good idea Cheers Adam On Thu, Apr 1, 2021 at 18:49, Dave Voutila wrote: > This diff documents the ioctl(2) values supported by vmm(4). Besides > vmd(8) there's at least one application I've seen (Solo5) directly using > vmm(4). > > For now I've tried to have short summary-level details, enough to > provide a general idea of purpose. The data structures aren't included > in the doc, but the mention of at least points to > where they're defined for now. > > Feedback on my mdoc macro usage or verbiage? OK? > > -dv > > Index: share/man/man4/man4.amd64/vmm.4 > === > RCS file: /cvs/src/share/man/man4/man4.amd64/vmm.4,v > retrieving revision 1.5 > diff -u -p -r1.5 vmm.4 > --- share/man/man4/man4.amd64/vmm.4 6 Dec 2015 19:06:17 - 1.5 > +++ share/man/man4/man4.amd64/vmm.4 1 Apr 2021 10:36:50 - > @@ -22,6 +22,8 @@ > .Nd virtual machine monitor > .Sh SYNOPSIS > .Cd "vmm0 at mainbus0" > +.Pp > +.In machine/vmmvar.h > .Sh DESCRIPTION > The > .Nm > @@ -67,6 +69,45 @@ driver requires at least one CPU with ha > capabilities and nested or extended paging capabilities to be > present on the host. > For more information, consult the CPU vendor's documentation. > +.Pp > +The following > +.Xr ioctl 2 > +commands are provided for managing > +.Nm > +guests: > +.Pp > +.Bl -tag -width Ds -offset indent > +.It Dv VMM_IOC_CREATE Fa "struct vm_create_params *" > +Create a VM, initializing > +.Xr vmm 4 > +if not yet started. (Does not start the VCPU.) > +.It Dv VMM_IOC_RUN Fa "struct vm_run_params *" > +Run a VCPU for a defined VM. Returns on VM-exit, the VCPU stopped, or > +an error occurred > +.It Dv VMM_IOC_INFO Fa "struct vm_info_params *" > +Get information about the VMs currently hosted by > +.Xr vmm 4 > +.It Dv VMM_IOC_TERM Fa "struct vm_terminate_params *" > +Terminate a given VM > +.It Dv VMM_IOC_RESETCPU Fa "struct vm_resetcpu_params *" > +Reset a VCPU to power-on-init state using the provided register state > +.It Dv VMM_IOC_INTR Fa "struct vm_intr_params *" > +Signal a pending interrupt for a VCPU > +.It Dv VMM_IOC_READREGS Fa "struct vm_rwregs_params *" > +Read registers of a VCPU > +.It Dv VMM_IOC_WRITEREGS Fa "struct vm_rwregs_params *" > +Write registers values of a VCPU > +.It Dv VMM_IOC_READVMPARAMS Fa "struct vm_revmparams_params *" > +Read paravirtualized hardware parameters (such as > +.Xr pvclock 4 > +version) for a VM > +.It Dv VMM_IOC_WRITEVMPARAMS Fa "struct vm_rwvmparams_params *" > +Write paravirtualized hardware parameters (such as > +.Xr pvclock 4 > +guest physical addresss) for a VM > +.It Dv VMM_IOC_MPROTECT_EPT Fa "struct vm_mprotect_ept_params *" > +Set access protections on guest page table entries > +(only supported on hosts providing EPT or RVI) > .Sh SEE ALSO > .Xr cpu 4 , > .Xr intro 4 ,
cwfg: Clean up nonexistent/unused properties handling
Never used since import and probably just ported over from NetBSD as-is;
"design-capacity" does not exist in the device tree binding.
"monitor-interval-ms" defaults to 250ms as per binding and could be used
in the sensor_task_register() call, but the framework only supports whole
seconds and I see no advantage changing our current poll interval of 5s.
Linux doesn't bother with "design-capacity" either but incorporates
"monitor-interval-ms" in their SOC readings for example.
NetBSD reads "design-capacity" but does not use it, it also reads the old
"monitor-interval" (seconds, not "-ms") and passes its unchanged value as
event timeout to sysmon_envsys_register(9), their equivalent to our
sensor_task_register().
Feedback? Objections? OK?
Index: cwfg.c
===
RCS file: /cvs/src/sys/dev/fdt/cwfg.c,v
retrieving revision 1.5
diff -u -p -r1.5 cwfg.c
--- cwfg.c 1 Apr 2021 10:34:21 - 1.5
+++ cwfg.c 1 Apr 2021 10:47:33 -
@@ -89,16 +89,10 @@ struct cwfg_softc {
uint8_t sc_batinfo[BATINFO_SIZE];
- uint32_tsc_monitor_interval;
- uint32_tsc_design_capacity;
-
struct ksensor sc_sensor[CWFG_NSENSORS];
struct ksensordev sc_sensordev;
};
-#defineCWFG_MONITOR_INTERVAL_DEFAULT 5000
-#defineCWFG_DESIGN_CAPACITY_DEFAULT2000
-
int cwfg_match(struct device *, void *, void *);
void cwfg_attach(struct device *, struct device *, void *);
@@ -180,11 +174,6 @@ cwfg_attach(struct device *parent, struc
return;
}
free(batinfo, M_TEMP, len);
-
- sc->sc_monitor_interval = OF_getpropint(sc->sc_node,
- "cellwise,monitor-interval-ms", CWFG_MONITOR_INTERVAL_DEFAULT);
- sc->sc_design_capacity = OF_getpropint(sc->sc_node,
- "cellwise,design-capacity", CWFG_DESIGN_CAPACITY_DEFAULT);
if (cwfg_init(sc) != 0) {
printf(": failed to initialize device\n");
Re: wcwidth of soft hyphen
On Thu, Apr 01 2021 09:30:36 +0200, Martijn van Duren wrote: > However, based on the description by the Unicode Consortium I think > OpenBSD does the right thing and xterm and others should be fixed, practically, I doubt this will happen. I don't think the glibc people will be convinced to break compatibility to their older versions, for example. I explicitly mentioned I don't wish to engage in a discussion about which way is _correct_ - I am interested in interoperability with real, existing systems. -- Lauri Tirkkonen | lotheac @ IRCnet
Re: vmm.4: document supported ioctls
On Thu, Apr 01, 2021 at 06:49:07AM -0400, Dave Voutila wrote: > This diff documents the ioctl(2) values supported by vmm(4). Besides > vmd(8) there's at least one application I've seen (Solo5) directly using > vmm(4). > > For now I've tried to have short summary-level details, enough to > provide a general idea of purpose. The data structures aren't included > in the doc, but the mention of at least points to > where they're defined for now. That seems fair. > Feedback on my mdoc macro usage or verbiage? OK? See inline, but you can also use `mandoc -T lint ./vmm.4' and any warnings and errors. > Index: share/man/man4/man4.amd64/vmm.4 > === > RCS file: /cvs/src/share/man/man4/man4.amd64/vmm.4,v > retrieving revision 1.5 > diff -u -p -r1.5 vmm.4 > --- share/man/man4/man4.amd64/vmm.4 6 Dec 2015 19:06:17 - 1.5 > +++ share/man/man4/man4.amd64/vmm.4 1 Apr 2021 10:36:50 - > @@ -22,6 +22,8 @@ > .Nd virtual machine monitor > .Sh SYNOPSIS > .Cd "vmm0at mainbus0" > +.Pp > +.In machine/vmmvar.h > .Sh DESCRIPTION > The > .Nm > @@ -67,6 +69,45 @@ driver requires at least one CPU with ha > capabilities and nested or extended paging capabilities to be > present on the host. > For more information, consult the CPU vendor's documentation. > +.Pp > +The following > +.Xr ioctl 2 > +commands are provided for managing > +.Nm > +guests: > +.Pp > +.Bl -tag -width Ds -offset indent > +.It Dv VMM_IOC_CREATE Fa "struct vm_create_params *" > +Create a VM, initializing > +.Xr vmm 4 That's the page itself, just use .Nm here like you did in the last sentence. > +if not yet started. (Does not start the VCPU.) > +.It Dv VMM_IOC_RUN Fa "struct vm_run_params *" > +Run a VCPU for a defined VM. Returns on VM-exit, the VCPU stopped, or I'd use imperative mood, i.e. omit "s"^ and add^ "when", I guess. > +an error occurred New sentences go to new lines. > +.It Dv VMM_IOC_INFO Fa "struct vm_info_params *" > +Get information about the VMs currently hosted by > +.Xr vmm 4 This and all following sentences lack punctuation; with .Nm as per above that'd be ".Nm ." (mind the space between macro and dot if the line ends with a macro). > +.It Dv VMM_IOC_TERM Fa "struct vm_terminate_params *" > +Terminate a given VM > +.It Dv VMM_IOC_RESETCPU Fa "struct vm_resetcpu_params *" > +Reset a VCPU to power-on-init state using the provided register state > +.It Dv VMM_IOC_INTR Fa "struct vm_intr_params *" > +Signal a pending interrupt for a VCPU > +.It Dv VMM_IOC_READREGS Fa "struct vm_rwregs_params *" > +Read registers of a VCPU > +.It Dv VMM_IOC_WRITEREGS Fa "struct vm_rwregs_params *" > +Write registers values of a VCPU > +.It Dv VMM_IOC_READVMPARAMS Fa "struct vm_revmparams_params *" > +Read paravirtualized hardware parameters (such as > +.Xr pvclock 4 > +version) for a VM > +.It Dv VMM_IOC_WRITEVMPARAMS Fa "struct vm_rwvmparams_params *" > +Write paravirtualized hardware parameters (such as > +.Xr pvclock 4 > +guest physical addresss) for a VM > +.It Dv VMM_IOC_MPROTECT_EPT Fa "struct vm_mprotect_ept_params *" > +Set access protections on guest page table entries > +(only supported on hosts providing EPT or RVI) Missing .El here. > .Sh SEE ALSO > .Xr cpu 4 , > .Xr intro 4 , >
vmm.4: document supported ioctls
This diff documents the ioctl(2) values supported by vmm(4). Besides vmd(8) there's at least one application I've seen (Solo5) directly using vmm(4). For now I've tried to have short summary-level details, enough to provide a general idea of purpose. The data structures aren't included in the doc, but the mention of at least points to where they're defined for now. Feedback on my mdoc macro usage or verbiage? OK? -dv Index: share/man/man4/man4.amd64/vmm.4 === RCS file: /cvs/src/share/man/man4/man4.amd64/vmm.4,v retrieving revision 1.5 diff -u -p -r1.5 vmm.4 --- share/man/man4/man4.amd64/vmm.4 6 Dec 2015 19:06:17 - 1.5 +++ share/man/man4/man4.amd64/vmm.4 1 Apr 2021 10:36:50 - @@ -22,6 +22,8 @@ .Nd virtual machine monitor .Sh SYNOPSIS .Cd "vmm0at mainbus0" +.Pp +.In machine/vmmvar.h .Sh DESCRIPTION The .Nm @@ -67,6 +69,45 @@ driver requires at least one CPU with ha capabilities and nested or extended paging capabilities to be present on the host. For more information, consult the CPU vendor's documentation. +.Pp +The following +.Xr ioctl 2 +commands are provided for managing +.Nm +guests: +.Pp +.Bl -tag -width Ds -offset indent +.It Dv VMM_IOC_CREATE Fa "struct vm_create_params *" +Create a VM, initializing +.Xr vmm 4 +if not yet started. (Does not start the VCPU.) +.It Dv VMM_IOC_RUN Fa "struct vm_run_params *" +Run a VCPU for a defined VM. Returns on VM-exit, the VCPU stopped, or +an error occurred +.It Dv VMM_IOC_INFO Fa "struct vm_info_params *" +Get information about the VMs currently hosted by +.Xr vmm 4 +.It Dv VMM_IOC_TERM Fa "struct vm_terminate_params *" +Terminate a given VM +.It Dv VMM_IOC_RESETCPU Fa "struct vm_resetcpu_params *" +Reset a VCPU to power-on-init state using the provided register state +.It Dv VMM_IOC_INTR Fa "struct vm_intr_params *" +Signal a pending interrupt for a VCPU +.It Dv VMM_IOC_READREGS Fa "struct vm_rwregs_params *" +Read registers of a VCPU +.It Dv VMM_IOC_WRITEREGS Fa "struct vm_rwregs_params *" +Write registers values of a VCPU +.It Dv VMM_IOC_READVMPARAMS Fa "struct vm_revmparams_params *" +Read paravirtualized hardware parameters (such as +.Xr pvclock 4 +version) for a VM +.It Dv VMM_IOC_WRITEVMPARAMS Fa "struct vm_rwvmparams_params *" +Write paravirtualized hardware parameters (such as +.Xr pvclock 4 +guest physical addresss) for a VM +.It Dv VMM_IOC_MPROTECT_EPT Fa "struct vm_mprotect_ept_params *" +Set access protections on guest page table entries +(only supported on hosts providing EPT or RVI) .Sh SEE ALSO .Xr cpu 4 , .Xr intro 4 ,
wcwidth of soft hyphen
When using terminal software on non-OpenBSD to connect to my OpenBSD IRC
machine, I noticed that sometimes the local terminal disagrees with the remote
tmux and application (in this case, irssi) about the character width of some
lines, causing different kinds of breakage. Those lines happened to contain soft
hyphens (U+00AD), which behave as follows across a few different operating
systems:
OpenBSD-CURRENT:iswprint(SHY) = 1 iswcntrl(SHY) = 1 wcwidth(SHY) = 0
NetBSD 9.1: iswprint(SHY) = 1 iswcntrl(SHY) = 0 wcwidth(SHY) = 1
FreeBSD 12.2: iswprint(SHY) = 0 iswcntrl(SHY) = 1 wcwidth(SHY) = -1
glibc (Debian sid): iswprint(SHY) = 1 iswcntrl(SHY) = 0 wcwidth(SHY) = 1
musl (Alpine 3.13.3): iswprint(SHY) = 1 iswcntrl(SHY) = 0 wcwidth(SHY) = 1
On Windows, PowerShell, PuTTY and MinTTY (shipped with the default install of
git from git-scm.com as part of MSYS2) render the soft hyphen as a visible
character with a width of 1 column.
The OpenBSD wcwidth(SHY) of 0 is what the problem comes down to (FreeBSD's
return values are also strange, but this is an OpenBSD list). There is a lot of
background discussion about whether or not Unicode intends the SHY to be
printable or not, and whether it should have width of 0 or 1, in eg. [0] and
[1], but for better or worse, it seems most other systems decided that SHY has a
width of 1 and should be a visible character (at least in terminal contexts).
Therefore, in the interest of interoperability, I propose the following diff to
special-case SHY into having a width of 1. I don't intend to go down the rabbit
hole of a discussion regarding what the 'correct' width is, but the discrepancy
with other systems causes real problems, and I think those other systems made
their decisions years ago (see eg. [0] for glibc).
Diff below only for gen_ctype_utf8.pl; I am not including the resulting
en_US.UTF-8.src diff, because it seems there is a Unicode 12.1.0 to 13.0.0
update that happens on regeneration of that file, and that is orthogonal to this
change (essentially: [2], which has not been committed yet)
[0]: https://sourceware.org/bugzilla/show_bug.cgi?id=22073
[1]: https://jkorpela.fi/shy.html
[2]: https://marc.info/?l=openbsd-tech&m=161534047428793&w=2
diff --git a/share/locale/ctype/gen_ctype_utf8.pl
b/share/locale/ctype/gen_ctype_utf8.pl
index e23472efb2c..c593dc628ee 100755
--- a/share/locale/ctype/gen_ctype_utf8.pl
+++ b/share/locale/ctype/gen_ctype_utf8.pl
@@ -404,6 +404,9 @@ sub codepoint_columns
# Several fonts provide glyphs in this range
return 1 if $code >= 0xe000 and $code <= 0xf8ff;
+ # Soft hyphen (SHY) is in category Cf, which implies width 0, but since
+ # it is width 1 in nearly every other environment, set it here.
+ return 1 if $code == 0x00ad;
return 0 if $charinfo->{category} eq 'Mn';
return 0 if $charinfo->{category} eq 'Me';
--
Lauri Tirkkonen | lotheac @ IRCnet
small malloc diff
Hi,
here's a small malloc diff. Most important part is an extra internal
consistency check. I have been running this for a few week already,
-Otto
Index: stdlib/malloc.3
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
retrieving revision 1.127
diff -u -p -r1.127 malloc.3
--- stdlib/malloc.3 25 Feb 2021 15:20:18 - 1.127
+++ stdlib/malloc.3 1 Apr 2021 09:21:59 -
@@ -366,7 +366,8 @@ If a program changes behavior if any of
are used,
it is buggy.
.Pp
-The default number of free pages cached is 64 per malloc pool.
+The default size of the cache is 64 single page allocations.
+It also caches a number of larger regions.
Multi-threaded programs use multiple pools.
.Sh RETURN VALUES
Upon successful completion, the allocation functions
Index: stdlib/malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.269
diff -u -p -r1.269 malloc.c
--- stdlib/malloc.c 9 Mar 2021 07:39:28 - 1.269
+++ stdlib/malloc.c 1 Apr 2021 09:22:00 -
@@ -1404,6 +1404,8 @@ ofree(struct dir_info **argpool, void *p
} else {
/* Validate and optionally canary check */
struct chunk_info *info = (struct chunk_info *)r->size;
+ if (info->size != sz)
+ wrterror(pool, "internal struct corrupt");
find_chunknum(pool, info, p, mopts.chunk_canaries);
if (!clear) {
void *tmp;
@@ -1608,6 +1610,7 @@ orealloc(struct dir_info **argpool, void
}
if (munmap((char *)r->p + rnewsz, roldsz - rnewsz))
wrterror(pool, "munmap %p", (char *)r->p +
rnewsz);
+ STATS_SUB(d->malloc_used, roldsz - rnewsz);
r->size = gnewsz;
if (MALLOC_MOVE_COND(gnewsz)) {
void *pp = MALLOC_MOVE(r->p, gnewsz);
Re: iscsid issues with Synology NAS
On 01.04., Claudio Jeker wrote:
> On Thu, Apr 01, 2021 at 07:27:10AM +0200, Bruno Flueckiger wrote:
> > On 31.03., David Alten wrote:
> > > Hello,
> > >
> > > I???m having issues getting iscsid to work with my Synology NAS.
> > >
> > > The first issue was that the NAS was returning an error code. Turns out
> > > it didn???t like not?? missing the default SessionType=Normal.
> > >
> > > The second issue was that the login sequence never comleted. It seems we
> > > keep hardcoding MaxConnections and MaxRecvDataSegmentLength in
> > > connection.c:conn_gen_kvp() instead of negotiating to the lowest value.
> > > So I just bypassed that function entirely and hardcoded all the default
> > > settings in initiator.c.
> > >
> > > This makes the login step complete, but then nothing else happens after
> > > that. I would expect a new scsi device to be attached so I could use it.
> > >
> > > I did notice that MaxConnection shows as 0, but the NAS does show the
> > > connection as established.
> > >
> > > b1# iscsictl show?? ??
> > > Initiator: ISID base 80d3cf6f qalifier 6e7d
> > >
> > > Session 'disk2':
> > > ?? ?? SessionType: normal MaxConnections: 0
> > > ?? ?? TargetName: iqn.2000-01.com.synology:Target.02
> > > ?? ?? TargetAddr: 192.168.0.4:iscsi
> > > ?? ?? InitiatorName: iqn.1995-11.org.openbsd.iscsid:b1
> > > ?? ?? InitiatorAddr: 192.168.0.9
> > > command successful
> > >
> > > b1$ cat /etc/iscsi.conf?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> > > ?? ?? ?? ?? ?? ?? ?? ??
> > > ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> > > target disk2 {
> > > ?? ?? ?? ?? initiatoraddr 192.168.0.9
> > > ?? ?? ?? ?? targetaddr 192.168.0.4
> > > ?? ?? ?? ?? targetname "iqn.2000-01.com.synology:Target.02"
> > > }
> > > Any suggestions on where to go from here?
> > >
> > > Thanks,
> > >
> > > -David
> > >
> >
> > Hi David,
> >
> > I had the same problem some years ago when I tried to attach an iSCSI
> > LUN from my Synology to my APU box. I wrote the patch below which fixed
> > the problem for me. Maybe you can give it a try?
> >
>
> Can someone send me a full pcap file of the negotiation with the synology
> nas device? It seems there is something not quite right in the negotiation
> code but the proposed diffs don't look correct either.
>
> --
> :wq Claudio
>
This is the captures I've used four years ago to analyze the connection
problem between iscsid and my Synology device:
https://www.bsdhowto.ch/downloads/synology_target.pcap
My theory was that the target code expects a confirmation for the
paramters it sends during the login phase. But iscsid keeps responding
with the only two parameters it started the login. As a workaround I
added the "missing" parameters.
Cheers,
Bruno
Re: iscsid issues with Synology NAS
On Thu, Apr 01, 2021 at 07:27:10AM +0200, Bruno Flueckiger wrote:
> On 31.03., David Alten wrote:
> > Hello,
> >
> > I???m having issues getting iscsid to work with my Synology NAS.
> >
> > The first issue was that the NAS was returning an error code. Turns out
> > it didn???t like not?? missing the default SessionType=Normal.
> >
> > The second issue was that the login sequence never comleted. It seems we
> > keep hardcoding MaxConnections and MaxRecvDataSegmentLength in
> > connection.c:conn_gen_kvp() instead of negotiating to the lowest value.
> > So I just bypassed that function entirely and hardcoded all the default
> > settings in initiator.c.
> >
> > This makes the login step complete, but then nothing else happens after
> > that. I would expect a new scsi device to be attached so I could use it.
> >
> > I did notice that MaxConnection shows as 0, but the NAS does show the
> > connection as established.
> >
> > b1# iscsictl show?? ??
> > Initiator: ISID base 80d3cf6f qalifier 6e7d
> >
> > Session 'disk2':
> > ?? ?? SessionType: normal MaxConnections: 0
> > ?? ?? TargetName: iqn.2000-01.com.synology:Target.02
> > ?? ?? TargetAddr: 192.168.0.4:iscsi
> > ?? ?? InitiatorName: iqn.1995-11.org.openbsd.iscsid:b1
> > ?? ?? InitiatorAddr: 192.168.0.9
> > command successful
> >
> > b1$ cat /etc/iscsi.conf?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> > ?? ?? ?? ?? ?? ?? ?? ??
> > ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> > target disk2 {
> > ?? ?? ?? ?? initiatoraddr 192.168.0.9
> > ?? ?? ?? ?? targetaddr 192.168.0.4
> > ?? ?? ?? ?? targetname "iqn.2000-01.com.synology:Target.02"
> > }
> > Any suggestions on where to go from here?
> >
> > Thanks,
> >
> > -David
> >
>
> Hi David,
>
> I had the same problem some years ago when I tried to attach an iSCSI
> LUN from my Synology to my APU box. I wrote the patch below which fixed
> the problem for me. Maybe you can give it a try?
>
Can someone send me a full pcap file of the negotiation with the synology
nas device? It seems there is something not quite right in the negotiation
code but the proposed diffs don't look correct either.
--
:wq Claudio
Re: wcwidth of soft hyphen
When it comes to these discussions I prefer to go back to the standards and not just looking at the surrounding discussions. The standard[0] states the following in section 23.2: Hyphenation. U+00AD soft hyphen (SHY ) indicates an intraword break point, where aline break is preferred if a word must be hyphenated or otherwise broken across lines. Suchbreak points are generally determined by an automatic hyphenator. SHY can be used withany script, but its use is generally limited to situations where users need to override thebehavior of such a hyphenator. The visible rendering of a line break at an intraword breakpoint, whether automatically determined or indicated by a SHY, depends on the surrounding characters, the rules governing the script and language used, and, at times, the meaningof the word. The precise rules are outside the scope of this standard, but see Unicode Stan-dard Annex #14, "Unicode Line Breaking Algorithm," for additional information. A com-mon default rendering is to insert a hyphen before the line break, but this is insufficient or even incorrect in many situations Where Annex #14 section 5.4[1] states begins with: Unlike U+2010 HYPHEN, which always has a visible rendition, the character U+00AD SOFT HYPHEN (SHY) is an invisible format character that merely indicates a preferred intraword line break position ... Depending on the language and the word, that may produce different visible results[2] So going by this phrase the character should not be printed and have no incluence on the text if it´s not used as a linebreak. The problem arises on how the terminal handles this character. In the case of xterm it appears to always print the character (printf "\302\255"), which according to Annex #14 is wrong. If you were to use another terminal which honours the this guideline OpenBSD would be correct and glibc etc is wrong. There´s also something to say for the way FreeBSD handles it, but that would break things even more on some OpenBSD applications, like ls(1), where a wcwidth of -1 would print a ´?´, which is even worse. Maybe this should be revisited and just skip these characters completely, but that´s outside the scope of this discussion. In conclusion: As long as the output device isn´t the database used to determine how things are displayed there´s no 100% guarantee that the software calculating the column width is doing the right thing. However, based on the description by the Unicode Consortium I think OpenBSD does the right thing and xterm and others should be fixed, especially if they just do a dumb printing of the characters without taking the proper line breaking rules into account and just keep on printing until the end of the screen and then continue on the next line. This goes double if the printing of the hyphen must cause visible changes (like spelling) according to the language rules. martijn@ On Thu, 2021-04-01 at 08:27 +0300, Lauri Tirkkonen wrote: > When using terminal software on non-OpenBSD to connect to my OpenBSD IRC > machine, I noticed that sometimes the local terminal disagrees with the remote > tmux and application (in this case, irssi) about the character width of some > lines, causing different kinds of breakage. Those lines happened to contain > soft > hyphens (U+00AD), which behave as follows across a few different operating > systems: > > OpenBSD-CURRENT:iswprint(SHY) = 1 iswcntrl(SHY) = 1 wcwidth(SHY) = 0 > NetBSD 9.1: iswprint(SHY) = 1 iswcntrl(SHY) = 0 wcwidth(SHY) = 1 > FreeBSD 12.2: iswprint(SHY) = 0 iswcntrl(SHY) = 1 wcwidth(SHY) = -1 > glibc (Debian sid): iswprint(SHY) = 1 iswcntrl(SHY) = 0 wcwidth(SHY) = 1 > musl (Alpine 3.13.3): iswprint(SHY) = 1 iswcntrl(SHY) = 0 wcwidth(SHY) = 1 > > On Windows, PowerShell, PuTTY and MinTTY (shipped with the default install of > git from git-scm.com as part of MSYS2) render the soft hyphen as a visible > character with a width of 1 column. > > The OpenBSD wcwidth(SHY) of 0 is what the problem comes down to (FreeBSD's > return values are also strange, but this is an OpenBSD list). There is a lot > of > background discussion about whether or not Unicode intends the SHY to be > printable or not, and whether it should have width of 0 or 1, in eg. [0] and > [1], but for better or worse, it seems most other systems decided that SHY > has a > width of 1 and should be a visible character (at least in terminal contexts). > > Therefore, in the interest of interoperability, I propose the following diff > to > special-case SHY into having a width of 1. I don't intend to go down the > rabbit > hole of a discussion regarding what the 'correct' width is, but the > discrepancy > with other systems causes real problems, and I think those other systems made > their decisions years ago (see eg. [0] for glibc). > > Diff below only for gen_ctype_utf8.pl; I am not including the resulting > en_US.UTF-8.src diff, because it seems there is a Unicode 12.1.0 to 13.0.0 >
Recognize bge(4) BCM57766 revs
Recognize bge(4) BCM5776 revs of chips..
unknown BCM57766 (0x57766000)
unknown BCM57766 (0x57766001)
Index: if_bge.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.393
diff -u -p -u -p -r1.393 if_bge.c
--- if_bge.c12 Dec 2020 11:48:52 - 1.393
+++ if_bge.c24 Feb 2021 05:12:56 -
@@ -403,6 +403,8 @@ static const struct bge_revision {
{ BGE_CHIPID_BCM5906_A2, "BCM5906 A2" },
{ BGE_CHIPID_BCM57765_A0, "BCM57765 A0" },
{ BGE_CHIPID_BCM57765_B0, "BCM57765 B0" },
+ { BGE_CHIPID_BCM57766_A0, "BCM57766 A0" },
+ { BGE_CHIPID_BCM57766_A1, "BCM57766 A1" },
{ BGE_CHIPID_BCM57780_A0, "BCM57780 A0" },
{ BGE_CHIPID_BCM57780_A1, "BCM57780 A1" },
Index: if_bgereg.h
===
RCS file: /home/cvs/src/sys/dev/pci/if_bgereg.h,v
retrieving revision 1.131
diff -u -p -u -p -r1.131 if_bgereg.h
--- if_bgereg.h 18 Jun 2020 17:13:32 - 1.131
+++ if_bgereg.h 24 Feb 2021 05:13:38 -
@@ -310,6 +310,8 @@
#defineBGE_CHIPID_BCM5762_A0 0x05762000
#defineBGE_CHIPID_BCM57765_A0 0x57785000
#defineBGE_CHIPID_BCM57765_B0 0x57785100
+#defineBGE_CHIPID_BCM57766_A0 0x57766000
+#defineBGE_CHIPID_BCM57766_A1 0x57766001
/* shorthand one */
#defineBGE_ASICREV(x) ((x) >> 12)
