Re: [patch(es)] fix a few typos in /src
On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote:
> Index: include/tib.h
> ===
> RCS file: /cvs/src/include/tib.h,v
> retrieving revision 1.8
> diff -u -p -r1.8 tib.h
> --- include/tib.h 14 Jul 2020 16:48:13 - 1.8
> +++ include/tib.h 22 Dec 2022 21:14:06 -
> @@ -54,7 +54,7 @@
> * Short-hand for TCB_TO_TIB(TCB_GET())
> *
> * TIB_EXTRA_ALIGN
> - * On TLS varaint 2 archs, what alignment is sufficient
> + * On TLS variant 2 archs, what alignment is sufficient
> * for the extra space that will be used for struct pthread?
> *
> * The following functions are provided by either ld.so (dynamic) or
> @@ -123,7 +123,7 @@
> *
> * [pthread structure]
> * TIB {
> - * ...cancelation and other int-sized info...
> + * ...cancellation and other int-sized info...
> * int errno
> * void *locale
> * TCB (- TCB_OFFSET) {
> @@ -169,7 +169,7 @@ struct tib {
> * struct pthread *thread
> * void *locale
> * int errno
> - * ...cancelation and other int-sized info...
> + * ...cancellation and other int-sized info...
> * }
> * [pthread structure]
> */
i took the first hunk of this diff, but did not commit the
cancelation->cancellation part. i know that US english prefers single
'l' (canceling/canceled). i'm not 100% sure about whether this applies
to "cancellation" but decided the gain was not worth it. the intent is
clear enough.
jmc
Re: hostctl: Change from fixed length to variable length
Hi,
Sorry for separating emails.
On Tue, 27 Dec 2022 11:58:34 +0900 (JST)
YASUOKA Masahiko wrote:
>> @@ -1115,12 +1116,19 @@ xs_kvop(void *xsc, int op, char *key, char *value,
>> size_t valuelen)
>> }
>> /* FALLTHROUGH */
>> case XS_LIST:
>> -for (i = 0; i < iov_cnt; i++) {
>> -if (i && strlcat(value, "\n", valuelen) >= valuelen)
>> -break;
>> -if (strlcat(value, iovp[i].iov_base,
>> -valuelen) >= valuelen)
>> +for (i = pos = 0; i < iov_cnt; i++) {
>> +if (i) {
>
> this is come from the previous, but I prefer comparing with 0
>
> + if (i > 0) {
>
>> +if (pos + 1 >= valuelen) {
>> +error = ERANGE;
>> +break;
>> +}
>> +value[pos++] = '\n';
>> +}
>> +if (strlen(iovp[i].iov_base) >= valuelen) {
>> +error = ERANGE;
>> break;
>> +}
>> +pos += strlcat([pos], iovp[i].iov_base, valuelen
>> - pos);
>> }
>> xs_resfree(, iovp, iov_cnt);
>> break;
>
Also I don't think replacing strlcat() by an own calculation is necessary.
diff --git a/sys/dev/pv/xenstore.c b/sys/dev/pv/xenstore.c
index 494eb40bfb0..01ecebdf4af 100644
--- a/sys/dev/pv/xenstore.c
+++ b/sys/dev/pv/xenstore.c
@@ -1116,11 +1116,16 @@ xs_kvop(void *xsc, int op, char *key, char *value,
size_t valuelen)
/* FALLTHROUGH */
case XS_LIST:
for (i = 0; i < iov_cnt; i++) {
- if (i && strlcat(value, "\n", valuelen) >= valuelen)
+ if (i > 0 && strlcat(value, "\n", valuelen) >=
+ valuelen) {
+ error = ERANGE;
break;
+ }
if (strlcat(value, iovp[i].iov_base,
- valuelen) >= valuelen)
+ valuelen) >= valuelen) {
+ error = ERANGE;
break;
+ }
}
xs_resfree(, iovp, iov_cnt);
break;
@@ -1128,5 +1133,5 @@ xs_kvop(void *xsc, int op, char *key, char *value, size_t
valuelen)
break;
}
- return (0);
+ return (error);
}
Re: hostctl: Change from fixed length to variable length
Hi,
On Mon, 26 Dec 2022 13:37:45 +0900 (JST)
Masato Asou wrote:
> My new patch is not returned value length from ioctl() system call
> when read the KEY's value.
>
> The hostctl command allocate 4k bytes memory for store the value. Then
> read the value by ioctl() system call. If ioctl() returned -1 end
> errno is ERANGE, then hostctl comannd reallocate twice as much space.
I will support this direction.
> The upper limit is PVBUS_KVOP_MAXSIZE (64k bytes).
Let me note that open-vm-tools also has the same hard-coded limit
https://github.com/vmware/open-vm-tools/blob/162eba6ab52d664551ffae343ef7e9a7f211ca69/open-vm-tools/lib/include/guest_msg_def.h#L108
There are 2 small feedbacks
> diff --git a/sys/dev/pv/pvbus.c b/sys/dev/pv/pvbus.c
> index 5f7c4b57fe0..c76a9e81444 100644
> --- a/sys/dev/pv/pvbus.c
> +++ b/sys/dev/pv/pvbus.c
> @@ -400,12 +400,12 @@ pvbusgetstr(size_t srclen, const char *src, char **dstp)
> /*
>* Reject size that is too short or obviously too long:
>* - at least one byte for the nul terminator.
> - * - PAGE_SIZE is an arbitrary value, but known pv backends seem
> - * to have a hard (PAGE_SIZE - x) limit in their messaging.
> + * - PVBUS_KVOP_MAXSIZE is an arbitrary value, but known pv backends
> + * seem to have a hard (PAGE_SIZE - x) limit in their messaging.
After diff, it doesn't use PAGE_SIZE any more. And VMware software
limit seems 1MB and changable by its configuration(*1). So we can't
say PVBUS_KVOP_MAXSIZE is enough.
+* - Known pv backends other than vmware has a hard limit smaller than
+* PVBUS_KVOP_MAXSIZE in their messaging. vmware has a software
+* limit at 1MB, but current open-vm-tools has a limit at 64KB
+* (=PVBUS_KVOP_MAXSIZE).
*1
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-91BF834E-CB92-4014-8CF7-29CE40F3E8A3.html
>*/
> if (srclen < 1)
> return (EINVAL);
> - else if (srclen > PAGE_SIZE)
> + else if (srclen > PVBUS_KVOP_MAXSIZE)
> return (ENAMETOOLONG);
>
> *dstp = dst = malloc(srclen + 1, M_TEMP, M_WAITOK | M_ZERO);
> @@ -1115,12 +1116,19 @@ xs_kvop(void *xsc, int op, char *key, char *value,
> size_t valuelen)
> }
> /* FALLTHROUGH */
> case XS_LIST:
> - for (i = 0; i < iov_cnt; i++) {
> - if (i && strlcat(value, "\n", valuelen) >= valuelen)
> - break;
> - if (strlcat(value, iovp[i].iov_base,
> - valuelen) >= valuelen)
> + for (i = pos = 0; i < iov_cnt; i++) {
> + if (i) {
this is come from the previous, but I prefer comparing with 0
+ if (i > 0) {
> + if (pos + 1 >= valuelen) {
> + error = ERANGE;
> + break;
> + }
> + value[pos++] = '\n';
> + }
> + if (strlen(iovp[i].iov_base) >= valuelen) {
> + error = ERANGE;
> break;
> + }
> + pos += strlcat([pos], iovp[i].iov_base, valuelen
> - pos);
> }
> xs_resfree(, iovp, iov_cnt);
> break;
Re: macppc: ansify some code (fix clang 15 errors)
On Tue, 27 Dec 2022 03:20:55 +0100, Jeremie Courreges-Anglas wrote: > This should fix warnings in the macppc build (kernel + bootloader) with > clang 15 (-Wdeprecated-non-prototype). Not build tested (no macppc > machine at hand) but should be safe. ok? OK millert@ - todd
Re: libsa: ansify some pxe code
On Tue, 27 Dec 2022 03:11:58 +0100, Jeremie Courreges-Anglas wrote: > These functions trip up -Wdeprecated-non-prototype (clang 15). We'll > probably use -Wno-deprecated-non-prototype until zlib gets fixed > upstream but let's clean up the code first. > > zlib2ansi doesn't find other errors in sys/arch/*clang archs* except for > macppc (diff for that next). OK millert@ - todd
Re: LLVM 15: mismatched bound errors
On Tue, 27 Dec 2022 01:47:25 +0100, Jeremie Courreges-Anglas wrote: > That's for the kernel part. libsa diff below, ok? Of course. OK millert@ - todd
macppc: ansify some code (fix clang 15 errors)
This should fix warnings in the macppc build (kernel + bootloader) with
clang 15 (-Wdeprecated-non-prototype). Not build tested (no macppc
machine at hand) but should be safe. ok?
Index: arch/macppc/dev/pm_direct.c
===
RCS file: /home/cvs/src/sys/arch/macppc/dev/pm_direct.c,v
retrieving revision 1.33
diff -u -p -r1.33 pm_direct.c
--- arch/macppc/dev/pm_direct.c 23 Oct 2022 08:00:10 - 1.33
+++ arch/macppc/dev/pm_direct.c 27 Dec 2022 02:14:20 -
@@ -200,11 +200,7 @@ extern voidadb_pass_up(struct adbComman
* This function dumps contents of the PMData
*/
void
-pm_printerr(ttl, rval, num, data)
- char *ttl;
- int rval;
- int num;
- char *data;
+pm_printerr(char *ttl, int rval, int num, char *data)
{
int i;
Index: arch/macppc/stand/ofdev.c
===
RCS file: /home/cvs/src/sys/arch/macppc/stand/ofdev.c,v
retrieving revision 1.28
diff -u -p -r1.28 ofdev.c
--- arch/macppc/stand/ofdev.c 12 Oct 2022 09:23:45 - 1.28
+++ arch/macppc/stand/ofdev.c 27 Dec 2022 02:15:09 -
@@ -164,8 +164,7 @@ struct fs_ops file_system[4];
int nfsys;
static u_long
-get_long(p)
- const void *p;
+get_long(const void *p)
{
const unsigned char *cp = p;
@@ -238,12 +237,8 @@ read_mac_label(struct of_dev *devp, char
* Find a valid disklabel.
*/
static int
-search_label(devp, off, buf, lp, off0)
- struct of_dev *devp;
- u_long off;
- char *buf;
- struct disklabel *lp;
- u_long off0;
+search_label(struct of_dev *devp, u_long off, char *buf, struct disklabel *lp,
+u_long off0)
{
size_t read;
struct dos_partition *p;
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: gdb: fix build with clang 15
On Tue, Dec 27, 2022 at 02:19:53AM +0100, Jeremie Courreges-Anglas wrote:
>
>
> /usr/src/gnu/usr.bin/binutils/gdb/tui/tui-stack.c:359:16: error: incompatible
> integer to pointer conversion passing 'CORE_ADDR' (aka 'unsigned long') to
> parameter of type 'CORE_ADDR *' (aka 'unsigned long *') [-Wint-conversion]
> , (CORE_ADDR) NULL) == 0)
> ^~~~
> /usr/src/gnu/usr.bin/binutils/gdb/symtab.h:1084:21: note: passing argument to
> parameter here
> CORE_ADDR *);
> ^
>
> The code wants a pointer to a "CORE_ADDR", thus the "(CORE_ADDR)" cast
> is erroneous. Just pass NULL. ok?
ok jsg@
>
>
> Index: gnu/usr.bin/binutils/gdb/tui/tui-stack.c
> ===
> RCS file: /home/cvs/src/gnu/usr.bin/binutils/gdb/tui/tui-stack.c,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 tui-stack.c
> --- gnu/usr.bin/binutils/gdb/tui/tui-stack.c 21 May 2004 19:15:20 -
> 1.1.1.1
> +++ gnu/usr.bin/binutils/gdb/tui/tui-stack.c 27 Dec 2022 01:15:51 -
> @@ -356,7 +356,7 @@ tui_show_frame_info (struct frame_info *
> else
> {
> if (find_pc_partial_function (get_frame_pc (fi), (char **) NULL,
> - , (CORE_ADDR) NULL) == 0)
> + , NULL) == 0)
> error ("No function contains program counter for selected
> frame.\n");
> else
> low = tui_get_low_disassembly_address (low, get_frame_pc (fi));
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
>
libsa: ansify some pxe code
These functions trip up -Wdeprecated-non-prototype (clang 15). We'll
probably use -Wno-deprecated-non-prototype until zlib gets fixed
upstream but let's clean up the code first.
zlib2ansi doesn't find other errors in sys/arch/*clang archs* except for
macppc (diff for that next).
ok?
Index: sys/lib/libsa/netif.c
===
RCS file: /home/cvs/src/sys/lib/libsa/netif.c,v
retrieving revision 1.13
diff -u -p -r1.13 netif.c
--- sys/lib/libsa/netif.c 25 Oct 2021 15:59:46 - 1.13
+++ sys/lib/libsa/netif.c 27 Dec 2022 02:05:49 -
@@ -260,8 +260,7 @@ netif_put(struct iodesc *desc, void *pkt
}
struct iodesc *
-socktodesc(sock)
- int sock;
+socktodesc(int sock)
{
if (sock >= SOPEN_MAX) {
errno = EBADF;
Index: sys/arch/amd64/stand/libsa/pxe.c
===
RCS file: /home/cvs/src/sys/arch/amd64/stand/libsa/pxe.c,v
retrieving revision 1.7
diff -u -p -r1.7 pxe.c
--- sys/arch/amd64/stand/libsa/pxe.c6 Mar 2016 22:41:24 - 1.7
+++ sys/arch/amd64/stand/libsa/pxe.c27 Dec 2022 02:05:49 -
@@ -241,8 +241,7 @@ pxe_netif_open(void)
}
void
-pxe_netif_close(sock)
- int sock;
+pxe_netif_close(int sock)
{
t_PXENV_UDP_CLOSE *uc = (void *) pxe_command_buf;
@@ -271,8 +270,7 @@ pxe_netif_shutdown(void)
}
struct iodesc *
-pxesocktodesc(sock)
- int sock;
+pxesocktodesc(int sock)
{
#ifdef NETIF_DEBUG
Index: sys/arch/i386/stand/libsa/pxe.c
===
RCS file: /home/cvs/src/sys/arch/i386/stand/libsa/pxe.c,v
retrieving revision 1.7
diff -u -p -r1.7 pxe.c
--- sys/arch/i386/stand/libsa/pxe.c 7 Mar 2016 05:32:47 - 1.7
+++ sys/arch/i386/stand/libsa/pxe.c 27 Dec 2022 02:05:49 -
@@ -241,8 +241,7 @@ pxe_netif_open(void)
}
void
-pxe_netif_close(sock)
- int sock;
+pxe_netif_close(int sock)
{
t_PXENV_UDP_CLOSE *uc = (void *) pxe_command_buf;
@@ -271,8 +270,7 @@ pxe_netif_shutdown(void)
}
struct iodesc *
-pxesocktodesc(sock)
- int sock;
+pxesocktodesc(int sock)
{
#ifdef NETIF_DEBUG
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: perl: fix build with clang 15
On Mon, Dec 26 2022, Andrew Hewus Fresh wrote:
> On Tue, Dec 27, 2022 at 02:22:43AM +0100, Jeremie Courreges-Anglas wrote:
>>
>> MD5.xs:375:21: error: mixing declarations and code is incompatible with
>> standards before C99 [-Werror,-Wdeclaration-after-statement]
>> unsigned char *buf = (unsigned char *)(SvPV(ST(2), len));
>>
>> The build system asks for -Werror *and* -Wdeclaration-after-statement so
>> let's fix the code. ok?
>
> I just happened to be in this local patch today updating for 5.36. This
> seems OK to me and I'll make sure I update it.
Oooh, thanks for pointing this out, I did not expect a local patch in
here. I'll commit this then.
> Upstream declares variable there that we don't use.
>
> https://github.com/afresh1/OpenBSD-perl/blob/blead/patches/GOOD/use_our_MD5.patch#L373-L374
Understood.
>
>> Index: gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs
>> ===
>> RCS file: /home/cvs/src/gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs,v
>> retrieving revision 1.20
>> diff -u -p -r1.20 MD5.xs
>> --- gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs 1 Mar 2021 23:21:24 -
>> 1.20
>> +++ gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs 27 Dec 2022 01:20:54 -
>> @@ -371,8 +371,8 @@ context(ctx, ...)
>> PPCODE:
>> if (items > 2) {
>> STRLEN len;
>> -ctx->count = SvUV(ST(1)) << 3;
>> unsigned char *buf = (unsigned char *)(SvPV(ST(2), len));
>> +ctx->count = SvUV(ST(1)) << 3;
>> ctx->state[0] = buf[ 0] | (buf[ 1]<<8) | (buf[ 2]<<16) | (buf[
>> 3]<<24);
>> ctx->state[1] = buf[ 4] | (buf[ 5]<<8) | (buf[ 6]<<16) | (buf[
>> 7]<<24);
>> ctx->state[2] = buf[ 8] | (buf[ 9]<<8) | (buf[10]<<16) |
>> (buf[11]<<24);
>>
>>
>> --
>> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: perl: fix build with clang 15
On Tue, Dec 27, 2022 at 02:22:43AM +0100, Jeremie Courreges-Anglas wrote:
>
> MD5.xs:375:21: error: mixing declarations and code is incompatible with
> standards before C99 [-Werror,-Wdeclaration-after-statement]
> unsigned char *buf = (unsigned char *)(SvPV(ST(2), len));
>
> The build system asks for -Werror *and* -Wdeclaration-after-statement so
> let's fix the code. ok?
I just happened to be in this local patch today updating for 5.36. This
seems OK to me and I'll make sure I update it.
Upstream declares variable there that we don't use.
https://github.com/afresh1/OpenBSD-perl/blob/blead/patches/GOOD/use_our_MD5.patch#L373-L374
> Index: gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs
> ===
> RCS file: /home/cvs/src/gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs,v
> retrieving revision 1.20
> diff -u -p -r1.20 MD5.xs
> --- gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs 1 Mar 2021 23:21:24 -
> 1.20
> +++ gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs 27 Dec 2022 01:20:54 -
> @@ -371,8 +371,8 @@ context(ctx, ...)
> PPCODE:
> if (items > 2) {
> STRLEN len;
> - ctx->count = SvUV(ST(1)) << 3;
> unsigned char *buf = (unsigned char *)(SvPV(ST(2), len));
> + ctx->count = SvUV(ST(1)) << 3;
> ctx->state[0] = buf[ 0] | (buf[ 1]<<8) | (buf[ 2]<<16) | (buf[
> 3]<<24);
> ctx->state[1] = buf[ 4] | (buf[ 5]<<8) | (buf[ 6]<<16) | (buf[
> 7]<<24);
> ctx->state[2] = buf[ 8] | (buf[ 9]<<8) | (buf[10]<<16) |
> (buf[11]<<24);
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
perl: fix build with clang 15
MD5.xs:375:21: error: mixing declarations and code is incompatible with
standards before C99 [-Werror,-Wdeclaration-after-statement]
unsigned char *buf = (unsigned char *)(SvPV(ST(2), len));
The build system asks for -Werror *and* -Wdeclaration-after-statement so
let's fix the code. ok?
Index: gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs
===
RCS file: /home/cvs/src/gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs,v
retrieving revision 1.20
diff -u -p -r1.20 MD5.xs
--- gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs 1 Mar 2021 23:21:24 -
1.20
+++ gnu/usr.bin/perl/cpan/Digest-MD5/MD5.xs 27 Dec 2022 01:20:54 -
@@ -371,8 +371,8 @@ context(ctx, ...)
PPCODE:
if (items > 2) {
STRLEN len;
- ctx->count = SvUV(ST(1)) << 3;
unsigned char *buf = (unsigned char *)(SvPV(ST(2), len));
+ ctx->count = SvUV(ST(1)) << 3;
ctx->state[0] = buf[ 0] | (buf[ 1]<<8) | (buf[ 2]<<16) | (buf[
3]<<24);
ctx->state[1] = buf[ 4] | (buf[ 5]<<8) | (buf[ 6]<<16) | (buf[
7]<<24);
ctx->state[2] = buf[ 8] | (buf[ 9]<<8) | (buf[10]<<16) |
(buf[11]<<24);
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
gdb: fix build with clang 15
/usr/src/gnu/usr.bin/binutils/gdb/tui/tui-stack.c:359:16: error: incompatible
integer to pointer conversion passing 'CORE_ADDR' (aka 'unsigned long') to
parameter of type 'CORE_ADDR *' (aka 'unsigned long *') [-Wint-conversion]
, (CORE_ADDR) NULL) == 0)
^~~~
/usr/src/gnu/usr.bin/binutils/gdb/symtab.h:1084:21: note: passing argument to
parameter here
CORE_ADDR *);
^
The code wants a pointer to a "CORE_ADDR", thus the "(CORE_ADDR)" cast
is erroneous. Just pass NULL. ok?
Index: gnu/usr.bin/binutils/gdb/tui/tui-stack.c
===
RCS file: /home/cvs/src/gnu/usr.bin/binutils/gdb/tui/tui-stack.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 tui-stack.c
--- gnu/usr.bin/binutils/gdb/tui/tui-stack.c21 May 2004 19:15:20 -
1.1.1.1
+++ gnu/usr.bin/binutils/gdb/tui/tui-stack.c27 Dec 2022 01:15:51 -
@@ -356,7 +356,7 @@ tui_show_frame_info (struct frame_info *
else
{
if (find_pc_partial_function (get_frame_pc (fi), (char **) NULL,
- , (CORE_ADDR) NULL) == 0)
+ , NULL) == 0)
error ("No function contains program counter for selected
frame.\n");
else
low = tui_get_low_disassembly_address (low, get_frame_pc (fi));
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Size reduction experiments for LLVM-built sparc64 kernel
On Sun, Dec 25 2022, Koakuma wrote:
> Some weekend updates:
>
> 1. The clang-built kernels seem to be working well enough that I could
>complete building a (GCC-built) userland.
That's good to know, I think I haven't tested that after we moved to
llvm 13.
> 2. I tried a larger set of LLVM patches (D51206, D128263, D130006,
>D132465, D135515, D138532, D138741, D138887, D138922, D139535, and
>D140515) and while it does reduce the kernel binary, it did not
>do it much - the kernel only gets about 10k smaller compared to
>the previous build.
>(that is, still ~77k bigger than the GCC-built binary)
That's a nice improvement but a lot of patches. patrick@ and I started
working on an update to llvm 15. No timeline yet but maybe some/all of
the changes you mentioned would already be integrated in that update?
(Or conclicting with it...)
> text databss dec hex
> 8089416 2295436 728216 3068a9926c bsd.clang+patch+noinline
> 8066232 2304032 732528 11102792a96a48
> bsd.clang+patchv2+noinline
> 7862920 2429596 730968 11023484a8347c bsd.gcc
>
> 3. Also, additionally I also tried to build the userland with clang but
>sadly it fails with some compiler errors:
>
> With `make COMPILER_VERSION=clang CC=clang build`, I'm getting:
As mentioned privately better remove sparc64 from GCC4_ARCHS in
bsd.own.mk and let the Makefiles pick up clang/clang++.
> In file included from
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:15,
> from
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:16,
> from
> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:1:
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_platform.h:25:18:
> error: missing binary operator before token "("
> In file included from
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:16,
> from
> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:1:
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:412:
> error: 'constexpr' does not name a type
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:413:
> error: 'constexpr' does not name a type
> In file included from
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang.h:20,
> from
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:63,
> from
> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:1:
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:
> In function 'typename T::Type __sanitizer::atomic_load(const volatile T*,
> __sanitizer::memory_order)':
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:54:
> error: '__ATOMIC_SEQ_CST' was not declared in this scope
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:
> In function 'void __sanitizer::atomic_store(volatile T*, typename T::Type,
> __sanitizer::memory_order)':
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:79:
> error: '__ATOMIC_SEQ_CST' was not declared in this scope
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:
> In function 'typename T::Type __sanitizer::atomic_load(const volatile T*,
> __sanitizer::memory_order) [with T = __sanitizer::atomic_uint32_t]':
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:76:
> instantiated from 'typename T::Type __sanitizer::atomic_load_relaxed(const
> volatile T*) [with T = __sanitizer::atomic_uint32_t]'
> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:27:
>instantiated from here
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:53:
> error: '__atomic_load' was not declared in this scope
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:
> In function 'typename T::Type __sanitizer::atomic_load(const volatile T*,
> __sanitizer::memory_order) [with T = __sanitizer::atomic_uintptr_t]':
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic.h:76:
> instantiated from 'typename T::Type __sanitizer::atomic_load_relaxed(const
> volatile T*) [with T = __sanitizer::atomic_uintptr_t]'
> /usr/src/gnu/lib/libclang_rt/ubsan_minimal/../../../llvm/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:34:
>instantiated from here
> /usr/src/gnu/llvm/compiler-rt/lib/sanitizer_common/sanitizer_atomic_clang_other.h:53:
> error: '__atomic_load' was not declared in this scope
>
Re: LLVM 15: mismatched bound errors
On Sat, Dec 24 2022, Patrick Wildt wrote: > On Thu, Dec 22, 2022 at 01:14:57AM +0100, Patrick Wildt wrote: >> On Tue, Dec 20, 2022 at 05:48:41PM -0700, Todd C. Miller wrote: >> > On Tue, 20 Dec 2022 23:44:08 +0100, Patrick Wildt wrote: >> > >> > > clang complains when the function is declared with a fixed array size in >> > > a parameter while the prototype is unbounded, like this: >> > > >> > > /usr/src/sys/net/pf.c:4353:54: error: argument 'sns' of type 'struct >> > > pf_src_n >> > > ode *[4]' with mismatched bound [-Werror,-Warray-parameter] >> > > struct pf_rule_actions *act, struct pf_src_node *sns[PF_SN_MAX]) >> > > ^ >> > > /usr/src/sys/net/pf.c:203:28: note: previously declared as 'struct >> > > pf_src_nod >> > > e *[]' here >> > > struct pf_src_node *[]); >> > > ^ >> > > 1 error generated. >> > > >> > > We have a few of that, and was wondering what the better solution is. >> > > clang apparently accepts using * instead of []. The alternative would >> > > be to hardcode the size in the prototype as well. Here's a diff for >> > > a three files for the first version, as example. >> > >> > Using * instead of [] is the saner approach. Hard-coding the sizes >> > into the prototype seems like a bad idea, even if clang is now smart >> > enough to complain about a mismatch. >> > >> > - todd >> >> So, here's the full diff that allows me to compile arm64 GENERIC.MP, >> with radeondrm and amdgpu disabled. > > Right, sorry for derailing the thread with a different discussion. > Here's a diff only for the array/ptr changes. That's for the kernel part. libsa diff below, ok? Index: hmac_sha1.h === RCS file: /home/cvs/src/sys/lib/libsa/hmac_sha1.h,v retrieving revision 1.1 diff -u -p -p -u -r1.1 hmac_sha1.h --- hmac_sha1.h 9 Oct 2012 12:36:50 - 1.1 +++ hmac_sha1.h 27 Dec 2022 00:45:39 - @@ -22,4 +22,4 @@ * HMAC-SHA-1 (from RFC 2202). */ void hmac_sha1(const u_int8_t *, size_t, const u_int8_t *, -size_t, u_int8_t []); +size_t, u_int8_t *); -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: LLVM 15: mismatched bound errors
On Thu, Dec 22 2022, Todd C. Miller wrote:
> On Thu, 22 Dec 2022 02:08:42 +0100, Jeremie Courreges-Anglas wrote:
>
>> https://github.com/jcourreges/openbsd-src/commit/4862df383ccb8a8e03d5c11b4f
>> b739b6a3a5a7c7
>>
>> Sadly making the size available in the declaration doesn't seem to be
>> clang any smarter (yet?). clang won't warn about passing the address of
>> array[10] to a function which access array[15] or so.
>>
>> I don't care much about the direction we end up using, but specifying
>> the size in the declaration isn't insane. We seldom pass a pointers to
>> a buffer without an accompanying buffer length.
>
> My objection to adding sizes to the prototype and function declaration
> is that it encourages things like:
>
> int foo(char buf[2048])
> {
> ...
> snprintf(buf, sizeof(buf), "See spot run, run spot run...");
> }
>
> But of course, sizeof(buf) is really sizeof(char *). The compiler
> will warn when you do this so perhaps it is not such a big problem.
> It still feels like a footgun to me.
-Wsizeof-pointer-memaccess should indeed help here.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: LLVM 15: mismatched bound errors
On Sat, Dec 24 2022, Patrick Wildt wrote: > On Thu, Dec 22, 2022 at 01:14:57AM +0100, Patrick Wildt wrote: >> On Tue, Dec 20, 2022 at 05:48:41PM -0700, Todd C. Miller wrote: >> > On Tue, 20 Dec 2022 23:44:08 +0100, Patrick Wildt wrote: >> > >> > > clang complains when the function is declared with a fixed array size in >> > > a parameter while the prototype is unbounded, like this: >> > > >> > > /usr/src/sys/net/pf.c:4353:54: error: argument 'sns' of type 'struct >> > > pf_src_n >> > > ode *[4]' with mismatched bound [-Werror,-Warray-parameter] >> > > struct pf_rule_actions *act, struct pf_src_node *sns[PF_SN_MAX]) >> > > ^ >> > > /usr/src/sys/net/pf.c:203:28: note: previously declared as 'struct >> > > pf_src_nod >> > > e *[]' here >> > > struct pf_src_node *[]); >> > > ^ >> > > 1 error generated. >> > > >> > > We have a few of that, and was wondering what the better solution is. >> > > clang apparently accepts using * instead of []. The alternative would >> > > be to hardcode the size in the prototype as well. Here's a diff for >> > > a three files for the first version, as example. >> > >> > Using * instead of [] is the saner approach. Hard-coding the sizes >> > into the prototype seems like a bad idea, even if clang is now smart >> > enough to complain about a mismatch. >> > >> > - todd >> >> So, here's the full diff that allows me to compile arm64 GENERIC.MP, >> with radeondrm and amdgpu disabled. > > Right, sorry for derailing the thread with a different discussion. > Here's a diff only for the array/ptr changes. > > ok? A bit late to this party but ok jca@, thanks. Why do you mention building arm64 GENERIC.MP "with radeondrm and amdgpu disabled"? Don't those drivers build with llvm15? -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen
On Sun, Dec 25, 2022 at 11:57:24PM -0600, Abel Abraham Camarillo Ojeda wrote: > # apmd -d > battery status: high. external power status: not connected. estimated > battery life 97% (223 minutes life time estimate) > can't disable driver messages, error: Inappropriate ioctl for device > apmevent index 0 > > (press zzz in another xterm) > system suspending > battery status: high. external power status: not connected. estimated > battery life 97% (223 minutes life time estimate) > do_etc_file(): cannot access file /etc/apm/suspend > > (press ZZZ in another xterm) > system hibernating > battery status: high. external power status: not connected. estimated > battery life 97% (223 minutes life time estimate) > do_etc_file(): cannot access file /etc/apm/hibernate > > = > > Notice also that battery life gets stuck and never updates again (not even > notices when I plug/unplug from charger) > > > acpi thread likely stuck, as kettenis surmised.
Re: [patch(es)] fix a few typos in /src
On Fri, Dec 23, 2022 at 10:33:43AM -0500, Paul Tagliamonte wrote: > Index: usr.bin/mg/search.c > === > RCS file: /cvs/src/usr.bin/mg/search.c,v > retrieving revision 1.48 > diff -u -p -r1.48 search.c > --- usr.bin/mg/search.c 20 Oct 2022 18:59:24 - 1.48 > +++ usr.bin/mg/search.c 23 Dec 2022 15:20:48 - > @@ -872,8 +872,8 @@ zapuptochar(int f, int n) > } > > /* > - * Prompt for a charcter and deletes from the point up to, optionally > - * including, the first instance of that charcters. Marks is cleared > + * Prompt for a character and deletes from the point up to, optionally > + * including, the first instance of that characters. Marks is cleared > * afterwards. > */ > int i changed "characters" to "character" here. jmc
Re: [patch(es)] fix a few typos in /src
On Fri, Dec 23, 2022 at 10:33:43AM -0500, Paul Tagliamonte wrote: > Index: usr.bin/make/arch.c > === > RCS file: /cvs/src/usr.bin/make/arch.c,v > retrieving revision 1.91 > diff -u -p -r1.91 arch.c > --- usr.bin/make/arch.c 13 Jan 2020 13:54:44 - 1.91 > +++ usr.bin/make/arch.c 23 Dec 2022 15:20:48 - > @@ -62,7 +62,7 @@ > */ > > /* > - * Once again, cacheing/hashing comes into play in the manipulation > + * Once again, caching/hashing comes into play in the manipulation > * of archives. The first time an archive is referenced, all of its members' > * headers are read and hashed and the archive closed again. All hashed > * archives are kept in a hash (archives) which is searched each time hi, i'm not taking this. i can;t convince myself that one is preferrable to the other. do we say "ka-sh" or "ka-shay"? running for cover now... jmc
Re: [patch(es)] fix a few typos in /src
On Fri, Dec 23, 2022 at 10:33:43AM -0500, Paul Tagliamonte wrote: > Index: usr.bin/find/function.c > === > RCS file: /cvs/src/usr.bin/find/function.c,v > retrieving revision 1.50 > diff -u -p -r1.50 function.c > --- usr.bin/find/function.c 23 Nov 2020 06:21:52 - 1.50 > +++ usr.bin/find/function.c 23 Dec 2022 15:20:47 - > @@ -1396,7 +1396,7 @@ c_perm(char *perm, char ***ignored, int > /* > * -print functions -- > * > - * Always true, causes the current pathame to be written to > + * Always true, causes the current pathname to be written to > * standard output. > */ > int > @@ -1576,7 +1576,7 @@ c_user(char *username, char ***ignored, > /* > * -xdev functions -- > * > - * Always true, causes find not to decend past directories that have a > + * Always true, causes find not to descend past directories that have a > * different device ID (st_dev, see stat() S5.6.2 [POSIX.1]) > */ > PLAN * > @@ -1679,7 +1679,7 @@ c_or(char *ignore, char ***ignored, int > * > * At the moment, only N_EXEC has state. Two kinds: 1) > * lists of files to feed to subprocesses 2) State on exit > - * statusses of past subprocesses. > + * statuses of past subprocesses. > */ > /* ARGSUSED1 */ > int i committed this separately as i changed "statuses" to "status". "status" is uncountable (we don;t have a separate plural), and besides the plural of "subprocesses" is enough. jmc
Re: [patch(es)] fix a few typos in /src
On Fri, Dec 23, 2022 at 10:33:43AM -0500, Paul Tagliamonte wrote: > On Fri, Dec 23, 2022 at 03:03:15PM +, Stuart Henderson wrote: > > > -struct itype *void_it; /* no type is emited > > > for void */ > > > +struct itype *void_it; /* no type is emitted > > > for void */ > > > > style(9) issue, this exceeds 80 columns > > I've reflowed the line. I shudder to think that this was done > intentionally to make it fit > doh! so without spotting this note i wondered why you'd added a fix like this, decided i didn;t want a anything to do with it, and committed only the emited -> emitted fix. then i get to this note ;( i've backed it out. if any other dev wants to take ctfconv/parse.c part of this, be my guest. i'm not touching it. jmc
Re: ksh.1: Add a missing Ns
On Mon, Dec 26, 2022 at 12:11:20PM -0500, Josiah Frentsos wrote: > Index: ksh.1 > === fixed, thanks. jmc > RCS file: /cvs/src/bin/ksh/ksh.1,v > retrieving revision 1.217 > diff -u -p -r1.217 ksh.1 > --- ksh.1 13 Sep 2022 20:26:26 - 1.217 > +++ ksh.1 26 Dec 2022 17:10:37 - > @@ -2713,9 +2713,7 @@ Exit status is set to zero. > .Cm +-x Oc > .Op Fl p > .Op Cm + > -.Oo Ar name > -.Op Ns = Ns Ar value > -.Ar ... Oc > +.Op Ar name Ns Oo = Ns Ar value Oc Ar ... > .Xc > Without arguments, > .Ic alias > @@ -3454,9 +3452,7 @@ option is used, input is saved to the hi > .It Xo > .Ic readonly > .Op Fl p > -.Oo Ar parameter > -.Op Ns = Ns Ar value > -.Ar ... Oc > +.Op Ar parameter Ns Oo = Ns Ar value Oc Ar ... > .Xc > Sets the read-only attribute of the named parameters. > If values are given, > @@ -4125,11 +4121,7 @@ Short form of > .Op Fl i Ns Op Ar n > .No \&| Fl f Op Fl tux > .Oc > -.Oo > -.Ar name > -.Op Ns = Ns Ar value > -.Ar ... > -.Oc > +.Op Ar name Ns Oo = Ns Ar value Oc Ar ... > .Xc > Display or set parameter attributes. > With no >
Re: ksh.1: Add a missing Ns
Index: ksh.1 === RCS file: /cvs/src/bin/ksh/ksh.1,v retrieving revision 1.217 diff -u -p -r1.217 ksh.1 --- ksh.1 13 Sep 2022 20:26:26 - 1.217 +++ ksh.1 26 Dec 2022 17:10:37 - @@ -2713,9 +2713,7 @@ Exit status is set to zero. .Cm +-x Oc .Op Fl p .Op Cm + -.Oo Ar name -.Op Ns = Ns Ar value -.Ar ... Oc +.Op Ar name Ns Oo = Ns Ar value Oc Ar ... .Xc Without arguments, .Ic alias @@ -3454,9 +3452,7 @@ option is used, input is saved to the hi .It Xo .Ic readonly .Op Fl p -.Oo Ar parameter -.Op Ns = Ns Ar value -.Ar ... Oc +.Op Ar parameter Ns Oo = Ns Ar value Oc Ar ... .Xc Sets the read-only attribute of the named parameters. If values are given, @@ -4125,11 +4121,7 @@ Short form of .Op Fl i Ns Op Ar n .No \&| Fl f Op Fl tux .Oc -.Oo -.Ar name -.Op Ns = Ns Ar value -.Ar ... -.Oc +.Op Ar name Ns Oo = Ns Ar value Oc Ar ... .Xc Display or set parameter attributes. With no
Re: only open /dev/vmm once in vmd(8)
Hi Dave, Applied the patch on top of the previous two you provided and all looks good. Running four proper VMs (installed 7.2, with different amount of memory allocated, one of them with rpki-client) and booted ~40 with just bsd.rd. Some log messages I am seeing, which I didn't see/notice before. Let me know if there is something specific I need to look out for. Dec 26 16:54:13 current /bsd: vm_impl_init_vmx: created vm_map @ 0xfdd1a31ff998 Dec 26 16:54:13 current /bsd: Guest EPTP = 0x509fc7501e Dec 26 16:54:13 current /bsd: vm_impl_init_vmx: created vm_map @ 0xfdd1a31ff448 Dec 26 16:54:13 current /bsd: Guest EPTP = 0x509fb5001e Dec 26 16:54:13 current /bsd: vm_impl_init_vmx: created vm_map @ 0xfdd1a31ff008 Dec 26 16:54:13 current /bsd: Guest EPTP = 0x509f9b401e Dec 26 16:54:13 current /bsd: vm_impl_init_vmx: created vm_map @ 0xfdd1a31ff228 Dec 26 16:54:13 current /bsd: Guest EPTP = 0x509f7b001e Dec 26 16:54:13 current /bsd: vm_impl_init_vmx: created vm_map @ 0xfdd1a31ff778 Dec 26 16:54:13 current /bsd: Guest EPTP = 0x509f51a01e Dec 26 16:54:13 current /bsd: vm_impl_init_vmx: created vm_map @ 0xfdd1a31ffaa8 Dec 26 16:54:13 current /bsd: Guest EPTP = 0x509f1c601e Dec 26 16:54:13 current /bsd: vm_impl_init_vmx: created vm_map @ 0xfdd1a31ffdd8 Dec 26 16:54:13 current /bsd: Guest EPTP = 0x509ee0901e Dec 26 16:54:13 current /bsd: vm_impl_init_vmx: created vm_map @ 0xfdd09e98fcd0 Dec 26 16:54:13 current /bsd: Guest EPTP = 0x509e98e01e Dec 26 16:54:13 current /bsd: vm_impl_init_vmx: created vm_map @ 0xfdd09e98f780 Dec 26 16:54:13 current /bsd: Guest EPTP = 0x509e46c01e Dec 26 16:54:13 current /bsd: vm_impl_init_vmx: created vm_map @ 0xfdd09e98f340 Dec 26 16:54:13 current /bsd: Guest EPTP = 0x509de2601e Dec 26 16:54:13 current /bsd: vmm_alloc_vpid: allocated VPID/ASID 25 Dec 26 16:54:13 current /bsd: vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported Dec 26 16:54:13 current /bsd: vmx_handle_cr: mov to cr0 @ 100148a, data=0x80010031 Dec 26 16:54:13 current /bsd: vmm_alloc_vpid: allocated VPID/ASID 26 Dec 26 16:54:13 current /bsd: vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported Dec 26 16:54:13 current /bsd: vmx_handle_cr: mov to cr0 @ 100148a, data=0x8001003 Dec 26 16:54:13 current /bsd: 1 Dec 26 16:54:13 current /bsd: vmm_alloc_vpid: allocated VPID Dec 26 16:54:13 current /bsd: /ASID 27 Dec 26 16:54:13 current /bsd: vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported Dec 26 16:54:13 current /bsd: vmx_handle_cr: mov to cr0 @ 100148a, data=0x80010031 Dec 26 16:54:13 current /bsd: vmm_alloc_vpid: allocated VPID/ASID 28 Dec 26 16:54:13 current /bsd: vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported Dec 26 16:54:13 current /bsd: vmx_handle_cr: mov to cr0 @ 100148a, data=0x80010031 Dec 26 16:54:13 current /bsd: vmm_alloc_vpid: allocated VPID/ASID 29 Dec 26 16:54:13 current /bsd: vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported Dec 26 16:54:13 current /bsd: vmx_handle_cr: mov to cr0 @ 100148a, data=0x80010031 Dec 26 16:54:13 current /bsd: vmm_alloc_vpid: allocated VPID/ASID 30 Dec 26 16:54:13 current /bsd: vmm_alloc_vpid: allocated VPID/ASID 31 Dec 26 16:54:13 current /bsd: vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported Dec 26 16:54:13 current /bsd: vmx_handle_cr: mov to cr0 @ 100148a, data=0x80010031 Dec 26 16:54:13 current /bsd: vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported Dec 26 16:54:13 current /bsd: vmx_handle_cr: mov to cr0 @ 100148a, data=0x80010031 Dec 26 16:54:13 current /bsd: vmm_alloc_vpid: allocated VPID/ASID 32 Dec 26 16:54:13 current /bsd: vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported Dec 26 16:54:13 current /bsd: vmx_handle_cr: mov to cr0 @ 100148a, data=0x80010031 Dec 26 16:54:13 current /bsd: vmm_alloc_vpid: allocated VPID/ASID 33 Dec 26 16:54:13 current /bsd: vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported Dec 26 16:54:13 current /bsd: vmm_alloc_vpid: allocated VPID/ASID 34 Dec 26 16:54:13 current /bsd: vmx_handle_cr: mov to cr0 @ 100148a, data=0x80010031 Dec 26 16:54:13 current /bsd: vmm_handle_cpuid: function 0x0a (arch. perf mon) not supported Dec 26 16:54:13 current /bsd: vmx_handle_cr: mov to cr0 @ 100148a, data=0x80010031 Dec 26 16:54:14 current /bsd: vmm_handle_cpuid: unsupported rax=0x4100 Dec 26 16:54:14 current last message repeated 5 times Dec 26 16:54:14 current /bsd: vmm_handle_cpuid: function 0x06 (thermal/power mgt) not supported Dec 26 16:54:14 current last message repeated 2 times Mischa On 2022-12-25 16:57, Dave Voutila wrote: During h2k22 there was some discussion around how vmd(8) manages vms and the vmm(4) device's role. While looking into something related, I found vmd opens /dev/vmm in each subprocess during the initial fork+execve dance. The only vmd process that needs /dev/vmm is the vmm process. The diff below changes it so that *only* the
Re: [patch(es)] fix a few typos in /src
On 2022/12/26 11:25, Theo Buehler wrote: > On Mon, Dec 26, 2022 at 07:18:45AM -0300, Crystal Kolipe wrote: > > On Mon, Dec 26, 2022 at 07:34:04AM +, Jason McIntyre wrote: > > > On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote: > > > > > > hi. i've committed the parts of this diff relating to libssl. > > > jmc > > > > > > > === > > > > Index: lib/libssl/test/pkits-test.pl > > > > === > > > > This commit contains changes to the code, it is not just a spelling fix: > > > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/test/pkits-test.pl.diff?r1=1.1=1.2=h > > No. This change was already there in 1.1.1.1 Not in 1.1.1.1 but in 1.1.1.2. cvsweb is diffing between 1.1 (equal to 1.1.1.1) and 1.2, not 1.1.1.2 which came a few days later.
Re: [patch(es)] fix a few typos in /src
On Mon, Dec 26, 2022 at 11:25:22AM +0100, Theo Buehler wrote: > On Mon, Dec 26, 2022 at 07:18:45AM -0300, Crystal Kolipe wrote: > > On Mon, Dec 26, 2022 at 07:34:04AM +, Jason McIntyre wrote: > > > On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote: > > > > > > hi. i've committed the parts of this diff relating to libssl. > > > jmc > > > > > > > === > > > > Index: lib/libssl/test/pkits-test.pl > > > > === > > > > This commit contains changes to the code, it is not just a spelling fix: > > > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/test/pkits-test.pl.diff?r1=1.1=1.2=h > > No. This change was already there in 1.1.1.1 Ah, OK, I'm seeing now that it's a CVS issue, sorry for the noise. The cvsweb script doesn't deal very well with 1.1.1.1 being set as a vendor branch.
Re: [patch(es)] fix a few typos in /src
On Mon, Dec 26, 2022 at 07:18:45AM -0300, Crystal Kolipe wrote: > On Mon, Dec 26, 2022 at 07:34:04AM +, Jason McIntyre wrote: > > On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote: > > > > hi. i've committed the parts of this diff relating to libssl. > > jmc > > > > > === > > > Index: lib/libssl/test/pkits-test.pl > > > === > > This commit contains changes to the code, it is not just a spelling fix: > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/test/pkits-test.pl.diff?r1=1.1=1.2=h No. This change was already there in 1.1.1.1
Re: [patch(es)] fix a few typos in /src
On Mon, Dec 26, 2022 at 07:34:04AM +, Jason McIntyre wrote: > On Thu, Dec 22, 2022 at 10:49:06PM -0500, Paul Tagliamonte wrote: > > hi. i've committed the parts of this diff relating to libssl. > jmc > > > === > > Index: lib/libssl/test/pkits-test.pl > > === This commit contains changes to the code, it is not just a spelling fix: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/test/pkits-test.pl.diff?r1=1.1=1.2=h
Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen
On Mon, Dec 26, 2022 at 12:51:05AM -0600, Abel Abraham Camarillo Ojeda wrote: > On Mon, Dec 26, 2022 at 12:08 AM Mike Larkin wrote: > > > On Sun, Dec 25, 2022 at 11:39:29PM -0600, Abel Abraham Camarillo Ojeda > > wrote: > > > On Sun, Dec 25, 2022 at 9:46 PM Mike Larkin wrote: > > > > > > > On Fri, Dec 23, 2022 at 03:13:53PM -0600, Abel Abraham Camarillo Ojeda > > > > wrote: > > > > > On Fri, Dec 23, 2022 at 2:46 PM Abel Abraham Camarillo Ojeda < > > > > > acam...@verlet.org> wrote: > > > > > > > > > > > Forgot to mention I don't think this is a regression, just started > > to > > > > use > > > > > > hibernate/unhibernate more often lately. > > > > > > But I think I can reproduce this at least since 6.8 (the first > > that I > > > > > > installed to this machine) > > > > > > > > > > > >> > > > > > >> > > > > > >> But still this apply https://www.openbsd.org/report.html (point > > 2) > > > > > >> > > > > > > > > > > > > By doesn't work I mean: > > > > > > > > > > > > $ zzz > > > > > > Suspending system... > > > > > > $ (nothing happened) > > > > > > > > > > > > > real mem = 17021566976 (16233MB) > > > > > >> > avail mem = 16488275968 (15724MB) > > > > > >> > random: good seed from bootblocks > > > > > >> > mpath0 at root > > > > > >> > scsibus0 at mpath0: 256 targets > > > > > >> > mainbus0 at root > > > > > >> > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xb9908000 (58 entries) > > > > > >> > bios0: vendor LENOVO version "R0GET56W (1.56 )" date 08/31/2017 > > > > > >> > > > > > >> You should try > > > > > >> > > > > > > https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-l-series-laptops/thinkpad-l470/downloads/ds120327 > > > > > >> and see if problem is still present (of course good to have backup > > > > :-)) > > > > > >> > > > > > > > > > > > > yes, forgot about that. Will update bios and retry > > > > > > > > > > > > > > > > machine now with bios updated, can reproduce issue after 1 > > unhibernate, > > > > > dmesg right now at "zzz does nothing stage": > > > > > > > > > > > > > 1. acpi thread might be stuck as kettenis points out. to verify this, > > > > try a suspend (lowercase zzz) instead of a hibernate (capital ZZZ) when > > > > it gets stuck. If you can zzz but not ZZZ, then it's not the acpi > > > > thread. > > > > > > > > Both zzz and ZZZ wont work, they only say 'Suspending/Hibernating...' > > and > > > nothing happens (don't have the exact message right now) > > > > > > any way to confirm the acpi thread is stuck? > > > > > > 2. more likely, IMO, is not being able to find a consecutive region in > > > > free memory to store the hibernate data structures. If memory gets > > > > fragmented, ZZZ will fail. It should print something to dmesg though, > > > > so check that. This matches your symptoms of "always works the first > > > > time but sometimes not on subsequent tries". > > > > > > > > > > notice also screen dimming via F5/F6 won't work (pressing F5 or F6 and > > > nothing happens) > > > > probably something like kettenis suggested then. make sure the bios is > > updated. > > > > Bios is at last version bios0: vendor LENOVO version "R0GET79W (1.79 )" > date 07/28/2022 > (issue was present also with the previous 2019-ish one) > > Any idea what else to try to gather more info? This is pretty reproducible vmstat -zi after resuming the first time? are you getting tons of acpi0 interrupts?
