Re: AMD 17h/1xh HD Audio testers wanted!
Stefan Hagen wrote (2023-03-05 09:19 CET): > Alexandre Ratchov wrote (2023-03-05 08:53 CET): > > If you've an azalia(4) attaching as "AMD 17h/1xh HD Audio", please > > test this diff and report regressions. Especially audio lock ups that > > require reboot. > > > > IIRC, MSI was disabled few years ago to "fix" such lockups, and now > > this diff suggests we need MSI on certain boards. > > At least no lockup in the first 5 minutes. I'll keep this in my tree. It took a few days, but I hit the bug now. No lockup, but audio simply stops and can not be reactivated until reboot. > OpenBSD 7.2-current (GENERIC.MP) #20: Sun Mar 5 09:10:14 CET 2023 > s...@x13.home.codevoid.de:/sys/arch/amd64/compile/GENERIC.MP > real mem = 16301219840 (15546MB) > avail mem = 15789305856 (15057MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xbf71 (68 entries) > bios0: vendor LENOVO version "R1CET73W(1.42 )" date 12/09/2022 > bios0: LENOVO 20UGS00800 > efi0 at bios0: UEFI 2.7 > efi0: Lenovo rev 0x1360 > acpi0 at bios0: ACPI 6.3 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT SSDT IVRS SSDT SSDT POAT BATB HPET APIC > MCFG SBST WSMT VFCT SSDT CRAT CDIT FPDT SSDT SSDT SSDT SSDT UEFI SSDT SSDT > acpi0: wakeup devices GPP0(S3) RESA(S3) GPP4(S4) GPP5(S3) L850(S3) GPP6(S3) > GPP7(S3) GP17(S3) XHC0(S3) XHC1(S3) LID_(S4) SLPB(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 100MHz > cpu0: mwait min=64, max=64, C-substates=1.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu2: smt 0, core 1, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache > cpu3: smt 1, core 1, package 0 > cpu4 at mainbus0: apid 4 (application processor) > cpu4: AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1700.00 MHz, 17-60-01 > cpu4: >
[PATCH] Zap 23 TAB and 19 white spaces in chat.c
Index: chat.c
===
RCS file: /cvs/src/usr.sbin/pppd/chat/chat.c,v
retrieving revision 1.35
diff -u -p -r1.35 chat.c
--- chat.c 5 Apr 2016 21:24:02 - 1.35
+++ chat.c 8 Mar 2023 03:51:44 -
@@ -19,7 +19,7 @@
* added -T and -U option and \T and \U substitution to pass a phone
* number into chat script. Two are needed for some ISDN TA applications.
* Keith Dart
- *
+ *
*
* Added SAY keyword to send output to stderr.
* This allows to turn ECHO OFF and to output specific, user selected,
@@ -43,7 +43,7 @@
* In the same vein as above, added CLR_REPORT keyword.
*
* Allow for comments. Line starting with '#' are comments and are
- * ignored. If a '#' is to be expected as the first character, the
+ * ignored. If a '#' is to be expected as the first character, the
* expect string must be quoted.
*
*
@@ -167,7 +167,7 @@ int clear_abort_next = 0;
char *report_string[MAX_REPORTS] ;
char report_buffer[50] ;
-int n_reports = 0, report_next = 0, report_gathering = 0 ;
+int n_reports = 0, report_next = 0, report_gathering = 0 ;
int clear_report_next = 0;
int say_next = 0, hup_next = 0;
@@ -321,7 +321,7 @@ main(argc, argv)
}
init();
-
+
if (chat_file != NULL) {
if (argc > 0)
usage();
@@ -641,7 +641,7 @@ int sending; /* set to 1 when sending (
t++;
if (isoctal(*t)) {
t++;
- if (isoctal(*t))
+ if (isoctal(*t))
t++;
}
}
@@ -712,7 +712,7 @@ int sending; /* set to 1 when sending (
case 'T':
if (sending && phone_num) {
- for ( phchar = phone_num; *phchar != '\0'; phchar++)
+ for ( phchar = phone_num; *phchar != '\0'; phchar++)
*s1++ = *phchar;
}
else {
@@ -723,7 +723,7 @@ int sending; /* set to 1 when sending (
case 'U':
if (sending && phone_num2) {
- for ( phchar = phone_num2; *phchar != '\0'; phchar++)
+ for ( phchar = phone_num2; *phchar != '\0'; phchar++)
*s1++ = *phchar;
}
else {
@@ -760,7 +760,7 @@ int sending; /* set to 1 when sending (
else
*s1++ = 'N';
break;
-
+
default:
if (isoctal (cur_chr)) {
cur_chr &= 0x07;
@@ -798,7 +798,7 @@ int sending; /* set to 1 when sending (
fprintf(stderr, "clean(): guessed %d and used %d\n", new_length, s1-ret);
#endif
if (new_length < s1 - ret)
- logmsg("clean(): new_length too short! %d < %d: \"%s\" -> \"%s\"",
+ logmsg("clean(): new_length too short! %d < %d: \"%s\" -> \"%s\"",
new_length, s1 - ret, s, ret);
return ret;
@@ -873,7 +873,7 @@ char *s;
++hup_next;
return;
}
-
+
if (strcmp(s, "ABORT") == 0) {
++abort_next;
return;
@@ -1002,14 +1002,14 @@ register char *s;
if (abort_next) {
char *s1;
-
+
abort_next = 0;
-
+
if (n_aborts >= MAX_ABORTS)
fatal(2, "Too many ABORT strings");
-
+
s1 = clean(s, 0);
-
+
if (strlen(s1) > strlen(s)
|| strlen(s1) + 1 > sizeof(fail_buffer))
fatal(1, "Illegal or too-long ABORT string ('%v')", s);
@@ -1026,11 +1026,11 @@ register char *s;
int i;
int old_max;
int pack = 0;
-
+
clear_abort_next = 0;
-
+
s1 = clean(s, 0);
-
+
if (strlen(s1) > strlen(s)
|| strlen(s1) + 1 > sizeof(fail_buffer))
fatal(1, "Illegal or too-long CLR_ABORT string ('%v')", s);
@@ -1054,18 +1054,18 @@ register char *s;
if (report_next) {
char *s1;
-
+
report_next = 0;
if (n_reports >= MAX_REPORTS)
fatal(2, "Too many REPORT strings");
-
+
s1 = clean(s, 0);
-
+
if (strlen(s1) > strlen(s) || strlen(s1) > sizeof fail_buffer - 1)
fatal(1, "Illegal or too-long REPORT string ('%v')", s);
-
+
report_string[n_reports++] = s1;
-
+
if (verbose)
logmsg("report (%v)", s);
return;
@@ -1076,11 +1076,11 @@ register char *s;
int i;
int old_max;
int pack = 0;
-
+
clear_report_next = 0;
-
+
s1 = clean(s, 0);
-
+
if (strlen(s1) > strlen(s) || strlen(s1) > sizeof fail_buffer - 1)
fatal(1, "Illegal or too-long REPORT string ('%v')", s);
@@ -1098,14 +1098,14 @@ register char *s;
free(s1);
if (pack)
pack_array(report_string,old_max);
-
+
return;
}
if (timeout_next) {
Re: ps(1): fix command alignment
On Tue, 7 Mar 2023, Tobias Heider wrote: > I was playing with ps today and noticed that the alignment of everything > following the "command" keyword seems to be broken currently. An easy way > to test this is running ps -axo command,uid which gives me a wrongly aligned > uid for some processes: > > /usr/X11R6/bin/X35 > X: [priv] (Xorg)0 > xenodm: :0 (xeno)0 > > It look like this was broken in 1.83 which introduces print_comm_name() but > wrongly assumes the returned value is the length difference when it actually > is the updated length value. With this fixed I get a correctly aligned output: > > /usr/X11R6/bin/X35 > X: [priv] (Xorg) 0 > xenodm: :0 (xeno 0 > > ok? Oops, yeah. ok guenther@
Re: bpf(4) "wait" timeouts
On Mon, Feb 13, 2023 at 08:30:03AM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> This diff looks good to me. Though I still have some
> doubts about accuracy of comment here:
>
>
> > return (kn->kn_data > 0);
> > @@ -1510,6 +1599,15 @@ bpf_catchpacket(struct bpf_d *d, u_char
> > ++d->bd_dcount;
> > return;
> > }
> > +
> > + /*
> > +* there's a small chance bpf_wait_cb is running
> > +* concurrently with this and two wakeups will be
> > +* generated.
> > +*/
> > + if (timeout_del(>bd_wait_tmo))
> > + bpf_put(d);
> > +
> > ROTATE_BUFFERS(d);
> > do_wakeup = 1;
> > curlen = 0;
> > @@ -1530,12 +1628,27 @@ bpf_catchpacket(struct bpf_d *d, u_char
>
> I'm still failing to spot the race the comment is talking
> about. code in bpf_wait_cb() grabs `d->bd_mtx` mutex, the
> same mutex which is held by bpf_catchpacket() caller.
oh yeah. i forgot to remove the comment.
> However my doubts about comment should not prevent you
> committing code which solves the issue and looks good.
>
> OK sashan
thank you. i'll put this in sometime in the next few days unless
someone objects.
Index: sys/net/bpf.c
===
RCS file: /cvs/src/sys/net/bpf.c,v
retrieving revision 1.220
diff -u -p -r1.220 bpf.c
--- sys/net/bpf.c 10 Feb 2023 14:34:17 - 1.220
+++ sys/net/bpf.c 8 Mar 2023 03:58:08 -
@@ -77,6 +77,10 @@
#define BPF_BUFSIZE 32768
+#define BPF_S_IDLE 0
+#define BPF_S_WAIT 1
+#define BPF_S_DONE 2
+
#define PRINET 26 /* interruptible */
/*
@@ -101,6 +105,7 @@ int bpf_setif(struct bpf_d *, struct ifr
intbpfkqfilter(dev_t, struct knote *);
void bpf_wakeup(struct bpf_d *);
void bpf_wakeup_cb(void *);
+void bpf_wait_cb(void *);
int_bpf_mtap(caddr_t, const struct mbuf *, const struct mbuf *, u_int);
void bpf_catchpacket(struct bpf_d *, u_char *, size_t, size_t,
const struct bpf_hdr *);
@@ -392,11 +397,13 @@ bpfopen(dev_t dev, int flag, int mode, s
bd->bd_sig = SIGIO;
mtx_init(>bd_mtx, IPL_NET);
task_set(>bd_wake_task, bpf_wakeup_cb, bd);
+ timeout_set(>bd_wait_tmo, bpf_wait_cb, bd);
smr_init(>bd_smr);
sigio_init(>bd_sigio);
klist_init_mutex(>bd_klist, >bd_mtx);
bd->bd_rtout = 0; /* no timeout by default */
+ bd->bd_wtout = INFSLP; /* wait for the buffer to fill by default */
refcnt_init(>bd_refcnt);
LIST_INSERT_HEAD(_d_list, bd, bd_list);
@@ -435,6 +442,7 @@ bpfclose(dev_t dev, int flag, int mode,
(d)->bd_hbuf = (d)->bd_sbuf; \
(d)->bd_hlen = (d)->bd_slen; \
(d)->bd_sbuf = (d)->bd_fbuf; \
+ (d)->bd_state = BPF_S_IDLE; \
(d)->bd_slen = 0; \
(d)->bd_fbuf = NULL;
@@ -492,7 +500,7 @@ bpfread(dev_t dev, struct uio *uio, int
ROTATE_BUFFERS(d);
break;
}
- if (d->bd_immediate && d->bd_slen != 0) {
+ if (d->bd_state == BPF_S_DONE) {
/*
* A packet(s) either arrived since the previous
* read or arrived while we were asleep.
@@ -611,6 +619,21 @@ bpf_wakeup_cb(void *xd)
bpf_put(d);
}
+void
+bpf_wait_cb(void *xd)
+{
+ struct bpf_d *d = xd;
+
+ mtx_enter(>bd_mtx);
+ if (d->bd_state == BPF_S_WAIT) {
+ d->bd_state = BPF_S_DONE;
+ bpf_wakeup(d);
+ }
+ mtx_leave(>bd_mtx);
+
+ bpf_put(d);
+}
+
int
bpfwrite(dev_t dev, struct uio *uio, int ioflag)
{
@@ -674,17 +697,64 @@ bpf_resetd(struct bpf_d *d)
MUTEX_ASSERT_LOCKED(>bd_mtx);
KASSERT(d->bd_in_uiomove == 0);
+ if (timeout_del(>bd_wait_tmo))
+ bpf_put(d);
+
if (d->bd_hbuf != NULL) {
/* Free the hold buffer. */
d->bd_fbuf = d->bd_hbuf;
d->bd_hbuf = NULL;
}
+ d->bd_state = BPF_S_IDLE;
d->bd_slen = 0;
d->bd_hlen = 0;
d->bd_rcount = 0;
d->bd_dcount = 0;
}
+static int
+bpf_set_wtout(struct bpf_d *d, uint64_t wtout)
+{
+ mtx_enter(>bd_mtx);
+ d->bd_wtout = wtout;
+ mtx_leave(>bd_mtx);
+
+ return (0);
+}
+
+static int
+bpf_set_wtimeout(struct bpf_d *d, const struct timeval *tv)
+{
+ uint64_t nsec;
+
+ if (tv->tv_sec < 0 || !timerisvalid(tv))
+ return (EINVAL);
+
+ nsec = TIMEVAL_TO_NSEC(tv);
+ if (nsec > MAXTSLP)
+ return (EOVERFLOW);
+
+ return (bpf_set_wtout(d, nsec));
+}
+
+static int
+bpf_get_wtimeout(struct bpf_d *d, struct timeval *tv)
+{
+ uint64_t nsec;
+
+ mtx_enter(>bd_mtx);
+ nsec = d->bd_wtout;
+ mtx_leave(>bd_mtx);
Re: ps(1): fix command alignment
On Wed, 08 Mar 2023 01:37:18 +0100, Tobias Heider wrote: > It look like this was broken in 1.83 which introduces print_comm_name() but > wrongly assumes the returned value is the length difference when it actually > is the updated length value. With this fixed I get a correctly aligned output OK millert@ - todd
[PATCH] Remove TAB in mk.sys
? sys.mk.diff
Index: sys.mk
===
RCS file: /cvs/src/share/mk/sys.mk,v
retrieving revision 1.93
diff -u -p -r1.93 sys.mk
--- sys.mk 4 Mar 2023 14:49:37 - 1.93
+++ sys.mk 8 Mar 2023 00:20:15 -
@@ -44,7 +44,7 @@ COMPILE.cc?= ${CXX} ${CXXFLAGS} ${CPPFLA
LINK.cc?= ${CXX} ${CXXFLAGS} ${CPPFLAGS} ${LDFLAGS}
CPP?= cpp
-CPPFLAGS?=
+CPPFLAGS?=
FC?= f77
FFLAGS?= -O2
[PATCH] White space in param.h
Index: param.h === RCS file: /cvs/src/sys/sys/param.h,v retrieving revision 1.140 diff -u -p -r1.140 param.h --- param.h 4 Mar 2023 14:49:37 - 1.140 +++ param.h 8 Mar 2023 00:17:10 - @@ -216,7 +216,7 @@ */ #define_FSHIFT 11 /* bits to right of fixed binary point */ #ifdef _KERNEL -#defineFSHIFT _FSHIFT +#defineFSHIFT _FSHIFT #endif #define FSCALE (1<<_FSHIFT)
Re: ps(1): fix command alignment
On Wed, Mar 08, 2023 at 01:37:18AM +0100, Tobias Heider wrote: > Hi, > > I was playing with ps today and noticed that the alignment of everything > following the "command" keyword seems to be broken currently. An easy way > to test this is running ps -axo command,uid which gives me a wrongly aligned > uid for some processes: > > /usr/X11R6/bin/X35 > X: [priv] (Xorg)0 > xenodm: :0 (xeno)0 > > It look like this was broken in 1.83 which introduces print_comm_name() but Oops, print.c - rev 1.85 is what i meant
ps(1): fix command alignment
Hi,
I was playing with ps today and noticed that the alignment of everything
following the "command" keyword seems to be broken currently. An easy way
to test this is running ps -axo command,uid which gives me a wrongly aligned
uid for some processes:
/usr/X11R6/bin/X35
X: [priv] (Xorg)0
xenodm: :0 (xeno)0
It look like this was broken in 1.83 which introduces print_comm_name() but
wrongly assumes the returned value is the length difference when it actually
is the updated length value. With this fixed I get a correctly aligned output:
/usr/X11R6/bin/X35
X: [priv] (Xorg) 0
xenodm: :0 (xeno 0
ok?
diff --git bin/ps/print.c bin/ps/print.c
index 21709700847..65fa9ee9eb0 100644
--- bin/ps/print.c
+++ bin/ps/print.c
@@ -182,7 +182,7 @@ command(const struct pinfo *pi, VARENT *ve)
}
putchar('(');
left--;
- left -= print_comm_name(kp, left, 0);
+ left = print_comm_name(kp, left, 0);
if (left == 0)
return;
putchar(')');
@@ -193,7 +193,7 @@ command(const struct pinfo *pi, VARENT *ve)
putchar(' ');
left--;
}
- left -= print_comm_name(kp, left, 0);
+ left = print_comm_name(kp, left, 0);
}
}
if (ve->next != NULL)
Re: ssh-pkcs11.c: fix some error messages
On Tue, 7 Mar 2023, Theo Buehler wrote:
> Some error messages don't match the function calls. There's still this
> one that looks weird. Not sure what it should say to be helpful:
> "unexpected ec signature length" perhaps?
>
> if (siglen < 64 || siglen > 132 || siglen % 2) {
> ossl_error("d2i_ECDSA_SIG failed");
Yeah, that should be:
error_f("bad signature length %lu", (u_long)siglen);
or similar.
ok for that and the others
> Index: ssh-pkcs11.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/ssh-pkcs11.c,v
> retrieving revision 1.55
> diff -u -p -r1.55 ssh-pkcs11.c
> --- ssh-pkcs11.c 18 Nov 2021 21:11:01 - 1.55
> +++ ssh-pkcs11.c 4 Mar 2023 08:21:59 -
> @@ -513,7 +513,7 @@ ecdsa_do_sign(const unsigned char *dgst,
> BIGNUM *r = NULL, *s = NULL;
>
> if ((k11 = EC_KEY_get_ex_data(ec, ec_key_idx)) == NULL) {
> - ossl_error("EC_KEY_get_key_method_data failed for ec");
> + ossl_error("EC_KEY_get_ex_data failed for ec");
> return (NULL);
> }
>
> @@ -545,7 +545,7 @@ ecdsa_do_sign(const unsigned char *dgst,
> }
> if ((r = BN_bin2bn(sig, bnlen, NULL)) == NULL ||
> (s = BN_bin2bn(sig+bnlen, bnlen, NULL)) == NULL) {
> - ossl_error("d2i_ECDSA_SIG failed");
> + ossl_error("BN_bin2bn failed");
> ECDSA_SIG_free(ret);
> ret = NULL;
> goto done;
>
>
Re: malloc: change chunk sizes to be multiple of 16 instead of power of 2
On Tue, Mar 07, 2023 at 09:02:04AM +0100, Theo Buehler wrote: > > So here's the dif with the fix. > > The new diff went through an amd64 bulk without fallout and also works > fine on some dev machines. No noticeable performance impact for my > workloads. > > It also reads fine to me (ok tb). > > Do you want it to make it into the release or can/should it wait? > Either way, it would probably be good for it to see more eyes and > tests. Thanks for testing and reviewing. I think I won't push it into the upcoming release. This should benefit from a large part of the release cycle for testing and it's already quite late in the current cycle. -Otto
ssh-pkcs11.c: fix some error messages
Some error messages don't match the function calls. There's still this
one that looks weird. Not sure what it should say to be helpful:
"unexpected ec signature length" perhaps?
if (siglen < 64 || siglen > 132 || siglen % 2) {
ossl_error("d2i_ECDSA_SIG failed");
Index: ssh-pkcs11.c
===
RCS file: /cvs/src/usr.bin/ssh/ssh-pkcs11.c,v
retrieving revision 1.55
diff -u -p -r1.55 ssh-pkcs11.c
--- ssh-pkcs11.c18 Nov 2021 21:11:01 - 1.55
+++ ssh-pkcs11.c4 Mar 2023 08:21:59 -
@@ -513,7 +513,7 @@ ecdsa_do_sign(const unsigned char *dgst,
BIGNUM *r = NULL, *s = NULL;
if ((k11 = EC_KEY_get_ex_data(ec, ec_key_idx)) == NULL) {
- ossl_error("EC_KEY_get_key_method_data failed for ec");
+ ossl_error("EC_KEY_get_ex_data failed for ec");
return (NULL);
}
@@ -545,7 +545,7 @@ ecdsa_do_sign(const unsigned char *dgst,
}
if ((r = BN_bin2bn(sig, bnlen, NULL)) == NULL ||
(s = BN_bin2bn(sig+bnlen, bnlen, NULL)) == NULL) {
- ossl_error("d2i_ECDSA_SIG failed");
+ ossl_error("BN_bin2bn failed");
ECDSA_SIG_free(ret);
ret = NULL;
goto done;
Re: route.8: add back command tags
my fault. please fix as needed. thanks, jmc On 7 March 2023 09:22:31 GMT, Klemens Nanni wrote: >http://man.openbsd.org/OpenBSD-7.2./route.8#add jumps to `add's definition, >http://man.openbsd.org/OpenBSD-current/route.8#add does not. > >Probably lost in the recent reshuffle. >Restore ":t add", etc. in the manual pager. > >OK? > >Index: route.8 >=== >RCS file: /cvs/src/sbin/route/route.8,v >retrieving revision 1.113 >diff -u -p -r1.113 route.8 >--- route.83 Mar 2023 08:08:15 - 1.113 >+++ route.87 Mar 2023 09:18:35 - >@@ -87,6 +87,7 @@ The commands are as follows: > .Nm route > .Op Fl dnqtv > .Op Fl T Ar rtable >+.Tg > .Cm add > .Op Ar modifier > .Ar destination >@@ -96,6 +97,7 @@ The commands are as follows: > .Nm route > .Op Fl dnqtv > .Op Fl T Ar rtable >+.Tg > .Cm change > .Op Ar modifier > .Ar destination >@@ -259,6 +261,8 @@ Note that priority 1 is reserved for ker > .Nm route > .Op Fl dnqtv > .Op Fl T Ar rtable >+.Tg delete >+.Tg > .Cm del Ns Op Cm ete > .Ar destination > .Op Fl priority Ar n >@@ -273,6 +277,7 @@ and/or a gateway. > .It Xo > .Nm route > .Op Fl T Ar rtable >+.Tg > .Cm exec > .Op Ar command ... > .Xc >@@ -285,6 +290,7 @@ option. > .Nm route > .Op Fl nqv > .Op Fl T Ar rtable >+.Tg > .Cm flush > .Op Ar family > .Op Fl iface Ar ifname >@@ -304,6 +310,7 @@ modifiers. > .Nm route > .Op Fl nv > .Op Fl T Ar rtable >+.Tg > .Cm get > .Ar destination > .Op Fl priority Ar n >@@ -320,6 +327,7 @@ and/or a gateway. > .Nm > .Op Fl n > .Op Fl T Ar rtable >+.Tg > .Cm monitor > .Op Ar family > .Op Fl iface >@@ -338,6 +346,7 @@ modifier. > .Ic route > .Op Fl dtv > .Op Fl T Ar rtable >+.Tg > .Cm nameserver > .Ar interface > .Op Ar address ... >@@ -353,6 +362,7 @@ a request to remove the nameservers for > .Nm route > .Op Fl nv > .Op Fl T Ar rtable >+.Tg > .Cm show > .Op Ar family > .Op Fl gateway >@@ -415,6 +425,7 @@ The mapping between letters and flags is > .It Xo > .Ic route > .Op Fl T Ar rtable >+.Tg > .Cm sourceaddr > .Op Fl inet Ns | Ns Fl inet6 > .Op Fl ifp Ar ifname >
Re: rc.d.8: fix daemon_* markup
On 2023/03/06 14:16, Klemens Nanni wrote: > 06.03.2023 13:49, Raf Czlonka пишет: > > To quote sthen@[0]: > > > > But that isn't, it is talking about _execdir, > > _flags, etc where you need to replace the > > > > [0] https://marc.info/?l=openbsd-tech=165364961710717=2 > > I find this dance in rc.d.8 not helpful: > .It Ar daemon Ns _flags > > daemon_flags and foo_flags control the same value in the end. > daemon_flags is set in rc.d scripts themselves and foo_flags can > overrule those from rc.conf.local. > > So why not mark them up as daemon_flags in rc.d.8 so that they become > more discoverable via tags? > > rc.d.8 still expains all the fuzz around replaing "daemon" with "foo" > in detail, right in the same ENVIRONMENT section around the list. > > When I read rc.d(8) to write my own script, I am looking for > daemon_flags and not foo_flags, so that makes sense and seems to have > priority over foo_flags wrt. markup since this is rc.d(8). This ENVIRONMENT section of rc.d(8) is *specifically* talking about lines added to rc.conf.local. Most readers are not writing their own scripts, and we have way too many users who say things like "I edited the rc.d(8) script to change the flags" who will run into problems at update time. I'd like to avoid any changes that reduce distinction between "foo_flags" in rc.conf(.local) and "daemon_flags" in rc.d/foo. > rc.conf.local(8) also explains the 'daemon vs. foo' dance, with the > weird markup, but there it is fine and not important, since it is not > the authorative source rc.d variables.
route.8: add back command tags
http://man.openbsd.org/OpenBSD-7.2./route.8#add jumps to `add's definition, http://man.openbsd.org/OpenBSD-current/route.8#add does not. Probably lost in the recent reshuffle. Restore ":t add", etc. in the manual pager. OK? Index: route.8 === RCS file: /cvs/src/sbin/route/route.8,v retrieving revision 1.113 diff -u -p -r1.113 route.8 --- route.8 3 Mar 2023 08:08:15 - 1.113 +++ route.8 7 Mar 2023 09:18:35 - @@ -87,6 +87,7 @@ The commands are as follows: .Nm route .Op Fl dnqtv .Op Fl T Ar rtable +.Tg .Cm add .Op Ar modifier .Ar destination @@ -96,6 +97,7 @@ The commands are as follows: .Nm route .Op Fl dnqtv .Op Fl T Ar rtable +.Tg .Cm change .Op Ar modifier .Ar destination @@ -259,6 +261,8 @@ Note that priority 1 is reserved for ker .Nm route .Op Fl dnqtv .Op Fl T Ar rtable +.Tg delete +.Tg .Cm del Ns Op Cm ete .Ar destination .Op Fl priority Ar n @@ -273,6 +277,7 @@ and/or a gateway. .It Xo .Nm route .Op Fl T Ar rtable +.Tg .Cm exec .Op Ar command ... .Xc @@ -285,6 +290,7 @@ option. .Nm route .Op Fl nqv .Op Fl T Ar rtable +.Tg .Cm flush .Op Ar family .Op Fl iface Ar ifname @@ -304,6 +310,7 @@ modifiers. .Nm route .Op Fl nv .Op Fl T Ar rtable +.Tg .Cm get .Ar destination .Op Fl priority Ar n @@ -320,6 +327,7 @@ and/or a gateway. .Nm .Op Fl n .Op Fl T Ar rtable +.Tg .Cm monitor .Op Ar family .Op Fl iface @@ -338,6 +346,7 @@ modifier. .Ic route .Op Fl dtv .Op Fl T Ar rtable +.Tg .Cm nameserver .Ar interface .Op Ar address ... @@ -353,6 +362,7 @@ a request to remove the nameservers for .Nm route .Op Fl nv .Op Fl T Ar rtable +.Tg .Cm show .Op Ar family .Op Fl gateway @@ -415,6 +425,7 @@ The mapping between letters and flags is .It Xo .Ic route .Op Fl T Ar rtable +.Tg .Cm sourceaddr .Op Fl inet Ns | Ns Fl inet6 .Op Fl ifp Ar ifname
Re: malloc: change chunk sizes to be multiple of 16 instead of power of 2
> So here's the dif with the fix. The new diff went through an amd64 bulk without fallout and also works fine on some dev machines. No noticeable performance impact for my workloads. It also reads fine to me (ok tb). Do you want it to make it into the release or can/should it wait? Either way, it would probably be good for it to see more eyes and tests.
