Re: Wireguard - VPN up after reboot

2020-12-22 Thread Solene Rapenne
On Tue, 22 Dec 2020 09:50:04 +
"Salvatore Cuzzilla" :

> Hi Everyone,
> 
> I'm happily using 'Wireguard' to setup few VPNs.
> I store the required configuration within /etc/hostname.wg0 & I startup the 
> tunnel with 'doas sh
> /etc/netstart wg0'.
> 
> Everything is working like expected. 
> However, upon system reload the connectivity is lost.
> The wg0 interface comes up but the tunnel stays in a sort of 'waiting'
> state.
> 
> The only way I figure out to bring it up is either re-launching 'doas sh 
> /etc/netstart wg0' or
> pinging the tunnel default gateway.
> 
> Is there any decent/clean way to avoid manual intervention?
> 
> ---
> :wq,
> Salvatore.
> 

I had the same issue, you must avoid using hostname for
the remote address of the wireguard peer, because at this
stage you can't resolve hostnames.



Re: acme-client(1) make -F flag use more obvious

2020-12-16 Thread Solene Rapenne
On Tue, 15 Dec 2020 10:18:41 +0100
Solene Rapenne :

> This is a small change to acme-client(1) because I find
> the explanation of -F flag not being obvious that you
> need it when you add/remove an alternative name in your
> domain config.
> 
> Maybe wording could be better, if a native English
> speaker could give it a look.
> 
> ok?
> 

I added 's to domain and specified -F only works for new domains.

While there, I propose to change the proposed crontab to once a day
instead of every hour. The certificates can be renewed 1 full month
before expiracy, I think trying to renew every hour is too much.

Index: acme-client.1
===
RCS file: /home/reposync/src/usr.sbin/acme-client/acme-client.1,v
retrieving revision 1.36
diff -u -p -r1.36 acme-client.1
--- acme-client.1   4 Nov 2020 10:34:18 -   1.36
+++ acme-client.1   16 Dec 2020 08:42:36 -
@@ -68,6 +68,9 @@ The options are as follows:
 .Bl -tag -width Ds
 .It Fl F
 Force certificate renewal, even if it's too soon.
+This is required if new domain's alternatives names
+were added to
+.Xr acme-client.conf 5 .
 .It Fl f Ar configfile
 Specify an alternative configuration file.
 .It Fl n
@@ -123,7 +126,7 @@ On renewal,
 .Xr httpd 8
 is reloaded:
 .Bd -literal -offset indent
-~  *   *   *   *   acme-client example.com && \e
+~  ~   *   *   *   acme-client example.com && \e
rcctl reload httpd
 .Ed
 .Sh SEE ALSO



acme-client(1) make -F flag use more obvious

2020-12-15 Thread Solene Rapenne
This is a small change to acme-client(1) because I find
the explanation of -F flag not being obvious that you
need it when you add/remove an alternative name in your
domain config.

Maybe wording could be better, if a native English
speaker could give it a look.

ok?

Index: acme-client.1
===
RCS file: /home/reposync/src/usr.sbin/acme-client/acme-client.1,v
retrieving revision 1.36
diff -u -p -r1.36 acme-client.1
--- acme-client.1   4 Nov 2020 10:34:18 -   1.36
+++ acme-client.1   15 Dec 2020 09:14:07 -
@@ -68,6 +68,9 @@ The options are as follows:
 .Bl -tag -width Ds
 .It Fl F
 Force certificate renewal, even if it's too soon.
+This is required if the domain alternatives names changed
+in
+.Xr acme-client.conf 5 .
 .It Fl f Ar configfile
 Specify an alternative configuration file.
 .It Fl n



Re: syspatch exit state

2020-12-07 Thread Solene Rapenne
On Mon, 7 Dec 2020 13:39:30 +0100
Antoine Jacoutot :


> Index: syspatch.8
> ===
> RCS file: /cvs/src/usr.sbin/syspatch/syspatch.8,v
> retrieving revision 1.21
> diff -u -p -r1.21 syspatch.8
> --- syspatch.825 Jul 2020 15:45:44 -  1.21
> +++ syspatch.87 Dec 2020 12:39:07 -
> @@ -64,6 +64,8 @@ of installed patches.
>  .El
>  .Sh EXIT STATUS
>  .Ex -std syspatch
> +In particular, 2 indicates that applying patches was requested but no
> +additional patch was installed.
>  .Sh SEE ALSO
>  .Xr signify 1 ,
>  .Xr installurl 5 ,
> Index: syspatch.sh
> ===
> RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
> retrieving revision 1.166
> diff -u -p -r1.166 syspatch.sh
> --- syspatch.sh   27 Oct 2020 17:42:05 -  1.166
> +++ syspatch.sh   7 Dec 2020 12:39:07 -
> @@ -320,6 +320,7 @@ if ((OPTIND == 1)); then
>   [[ -f ${_D}/rollback.tgz ]] || rm -r ${_D}
>   done
>   _PATCHES=$(ls_missing) # can't use errexit in a for loop
> + [[ -n ${_PATCHES} ]] || exit 2
>   for _PATCH in ${_PATCHES}; do
>   apply_patch ${_OSrev}-${_PATCH}
>   _PATCH_APPLIED=true
> 
> 

In my opinion, if committed it deserves an entry in
https://www.openbsd.org/faq/current.html



Re: clean /dev from /etc/daily ?

2020-11-23 Thread Solene Rapenne
On Mon, 23 Nov 2020 14:46:29 +
Stuart Henderson :

> On 2020/11/23 09:31, Bryan Steele wrote:
> > On Mon, Nov 23, 2020 at 03:25:34PM +0100, Otto Moerbeek wrote:  
> > > tOn Mon, Nov 23, 2020 at 01:53:01PM +0100, Solene Rapenne wrote:
> > >   
> > > > A common mistake when using dd is to create a file in /dev which
> > > > fills up the space of / and may stay silent until / gets filled up
> > > > by something else that will fail.
> > > > 
> > > > Would it be OK to add this in /etc/daily?
> > > > 
> > > > find /dev -type f ! -name MAKEDEV -delete
> > > > 
> > > > AFAIK /dev should have only MAKEDEV as a regular file.
> > > > hier(7) says /dev only have block and character devices
> > > > with the exception of MAKEDEV.
> > > >   
> > > 
> > > reporting is good, but deleting not.
> > > 
> > >   -Otto  
> > 
> > ^^
> > 
> > I like this option a lot more, as users will get an opportunity to
> > learn.  
> 
> I don't object to reporting (I do object to automatically deleting),
> but realistically for many people who would make this mistake, the
> daily mails are just going to build up unread in /var/mail/$USER...
> 

That's exactly why I thought removing them was better than reporting.
The disk usage is already reported daily.

With the script being run during night, this would also only be
useful for workstation that stay online at the time the script
is run.

In conclusion, it was a bad idea.



clean /dev from /etc/daily ?

2020-11-23 Thread Solene Rapenne
A common mistake when using dd is to create a file in /dev which
fills up the space of / and may stay silent until / gets filled up
by something else that will fail.

Would it be OK to add this in /etc/daily?

find /dev -type f ! -name MAKEDEV -delete

AFAIK /dev should have only MAKEDEV as a regular file.
hier(7) says /dev only have block and character devices
with the exception of MAKEDEV.



Re: AUDIORECDEVICE environment variable in sndio lib

2020-11-17 Thread Solene Rapenne
On Tue, 17 Nov 2020 18:23:55 +0100
"Peter J. Philipp" :

 
> This is a good suggestion!  Thanks!  I have updated the patch.  I also
> appreciate Solene's offer for manpage addition, thanks!
> 
> New diff follows... let me know if it can be done better, I won't be able
> to update it until tomorrow.
> 
> -peter

I suggest this change.

I added the new variable after MIDIDEVICE in the ENVIRONMENT section
to keep order of appearance in the document.

Index: sndio.7
===
RCS file: /home/reposync/src/lib/libsndio/sndio.7,v
retrieving revision 1.24
diff -u -p -r1.24 sndio.7
--- sndio.7 18 Jul 2020 05:01:14 -  1.24
+++ sndio.7 17 Nov 2020 18:32:34 -
@@ -157,6 +157,10 @@ If it is not set, the program first trie
 .Li snd/0 .
 If that fails, it then tries to use
 .Li rsnd/0 .
+The
+.Ev AUDIORECDEVICE
+environment variable
+defines a device to use prior to the audio device when recording.
 .Pp
 Similarly, if no MIDI descriptor is provided to a program
 or when the reserved word
@@ -196,6 +200,9 @@ Audio device descriptor to use
 when no descriptor is explicitly specified to a program.
 .It Ev MIDIDEVICE
 MIDI port descriptor to use
+when no descriptor is explicitly specified to a program.
+.It Ev AUDIORECDEVICE
+Audio recording device descriptor to use
 when no descriptor is explicitly specified to a program.
 .El
 .Pp



Re: AUDIORECDEVICE environment variable in sndio lib

2020-11-17 Thread Solene Rapenne
On Tue, 17 Nov 2020 17:13:49 +0100
"Peter J. Philipp" :

> Hi,
> 
> I have a mic on snd/1 and speakers on snd/0.  I had tried a lot of different
> settings with audacity port but couldn't get this to work, so I chose the
> method of last resort.  Below is a patch to allow an AUDIORECDEVICE 
> environment
> variable specifying the wanted microphone.
> 
> -peter

I have no opinion about the diff itself, but this would require
a man page update that I propose myself to write if the diff is OK.

It works fine for me, I've been able to use my DAC and my usb
microphone in audacity. It was something that I wanted to be able
to do since long time and I'm very happy to see it possible.



Re: accton(8) requires a reboot after being enabled

2020-10-30 Thread Solene Rapenne
Following diff changes accton(8) behavior.

If the file given as parameter doesn't exists, accton will create it.
Then it will check the ownership and will make it root:wheel if
it's different.

I added a check to be sure it's run as root because it's has no use if
not run as root.

I don't often write C, if the logic is good but the C implementation
wrong I'm open to critic.

The -f test and touch in /etc/rc won't be needed anymore with this
change.


Index: accton.8
===
RCS file: /home/reposync/src/usr.sbin/accton/accton.8,v
retrieving revision 1.11
diff -u -p -r1.11 accton.8
--- accton.810 Nov 2019 20:51:53 -  1.11
+++ accton.830 Oct 2020 17:27:36 -
@@ -36,7 +36,7 @@
 .Nm accton
 .Op Ar file
 .Sh DESCRIPTION
-With an argument naming an existing
+With an argument naming a
 .Ar file ,
 .Nm
 causes system accounting information for every process executed
Index: accton.c
===
RCS file: /home/reposync/src/usr.sbin/accton/accton.c,v
retrieving revision 1.8
diff -u -p -r1.8 accton.c
--- accton.c27 Oct 2009 23:59:50 -  1.8
+++ accton.c30 Oct 2020 17:26:31 -
@@ -27,6 +27,7 @@
  * SUCH DAMAGE.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -47,6 +48,10 @@ int
 main(int argc, char *argv[])
 {
int ch;
+   struct stat info_file;
+
+   if(getuid() != 0)
+   err(1, "need root privileges");
 
while ((ch = getopt(argc, argv, "")) != -1)
switch(ch) {
@@ -63,6 +68,15 @@ main(int argc, char *argv[])
err(1, NULL);
break;
case 1:
+   if(stat(*argv,_file) != 0)
+   if(fopen(*argv,"w"))
+   if(stat(*argv,_file))
+   err(1, "file %s couldn't be created", 
*argv);
+
+   if (info_file.st_uid != 0 || info_file.st_gid != 0)
+   if(chown(*argv, 0, 0) != 0)
+   err(1, "Impossible to fix %s ownership", *argv);
+
if (acct(*argv))
err(1, "%s", *argv);
break;



accton(8) requires a reboot after being enabled

2020-10-30 Thread Solene Rapenne
reading accton(8) it's not clear that if you
enable it you need to restart the system for
accounting to be effective.

Here is a change to add the explanation, but
I'm not sure if the wording is correct.

Index: accton.8
===
RCS file: /home/reposync/src/usr.sbin/accton/accton.8,v
retrieving revision 1.11
diff -u -p -r1.11 accton.8
--- accton.810 Nov 2019 20:51:53 -  1.11
+++ accton.830 Oct 2020 15:22:14 -
@@ -43,6 +43,10 @@ causes system accounting information for
 to be placed at the end of the file.
 If no argument is given, accounting is turned off.
 .Pp
+Accounting is done if it was enabled when system booted.
+If you activate accounting, a reboot is required for it to become
+effective.
+.Pp
 To have
 .Nm
 enabled at boot time, use



Re: patch: httpd(8) use LOG_FTP for transfers, like $DEITY intended

2020-10-26 Thread Solene Rapenne
On Mon, 26 Oct 2020 17:32:41 +0100
:

> #?patch
> #
> # This patch corrects the logging of transfers, of OpenBSD's httpd(8),
> # to xferlog, where it belongs.
> #
> # A simple patch to a waaay overcomplicated bit of software (with insane
> # defaults to boot; security anyone?).
> # 
> # --zeurkous, Sat Oct 24 17:51:55 UTC 2020.
> #
> --- src/usr.sbin/httpd/..v/OPENBSD_6_6/server.c   Fri Jun 28 13:32:47 2019
> +++ src/usr.sbin/httpd/server.c   Sat Oct 24 17:45:43 2020
> @@ -1241,7 +1241,7 @@
>   if (srv_conf->flags & SRVFLAG_SYSLOG) {
>   va_start(ap, emsg);
>   if (cmd == IMSG_LOG_ACCESS)
> - vlog(LOG_INFO, emsg, ap);
> + vlog(LOG_FTP, emsg, ap);
>   else
>   vlog(LOG_DEBUG, emsg, ap);
>   va_end(ap);
> 


if this makes it into the tree, syslog(3) must be
updated to explain LOG_FTP is also logging httpd



Re: RFC: kern.video.record

2020-09-19 Thread Solene Rapenne
On Sun, 13 Sep 2020 09:23:36 +0100
Laurence Tratt :

> Since I recently opened my big fat mouth and suggested that
> "kern.video.record" (analogous to kern.audio.record) might be a good idea, I
> decided to put together a quick prototype (heavily based on the
> kern.audio.record code). This at least roughly works for me but raises some
> questions such as:

I vote for keeping both so we can enable audio only or video only
and be sure about what is enabled and able to record our environment



current.html: i586 requirement for i386 architecture

2020-08-07 Thread Solene Rapenne
Now that i386 platform requires i586 CPU, I guess we should mention
it in current.html (the page i386.html should be updated accordingly
at 6.8 release)

Index: current.html
===
RCS file: /home/reposync/www/faq/current.html,v
retrieving revision 1.1048
diff -u -p -r1.1048 current.html
--- current.html11 Jul 2020 16:53:47 -  1.1048
+++ current.html7 Aug 2020 13:43:25 -
@@ -57,6 +57,16 @@ use a snapshot to recover.
 Most of these changes will have to be performed as root.
 
 
+2020/08/03 - i386 requirements raised to i586
+
+Due to llvm upgrade to version 10 in base system, the minimal
+CPU instruction sets requirements for i386 architecture has been
+raised from i386 to i586.
+
+In concrete terms for Intel and AMD CPUs, Intel Pentium and AMD K5
+are now the minimal requirements for i386 architecture.
+
+
 2020/05/29 - [ports] net/isc-bind example files dropped
 
 Outdated example configuration (including some "standard" zone files and



Re: [PATCH]: Add a check for upgrade feature to sysupgrade(8)

2020-08-03 Thread Solene Rapenne
On Mon, 3 Aug 2020 13:28:38 +0200
Emil Engler :

> ## Abstract
> This patch adds an argument to sysupgrade(8) which makes it possible
> to check if an upgrade is available, similar to "syspatch -c".
> This works both, for snapshots and releases.
> 
> ## Usage
> Add "-c" to sysupgrade.
> If the script exits with a zero, an upgrade is available. If it fails
> you are already on the newest version or an upgrade cannot be pulled
> for whatever reason.
> 
> ## Motivation
> I want a cronjob on my desktop (which is on -current) that checks
> regularly if a new snapshot is available and notifies me if this is
> the case. syspatch(8) already has such a feature, so why not add
> one to sysupgrade? Also it could be useful on -stable and -release
> systems.

it seems to me you could use this in your crontab

sysupgrade -n | grep "Already on last snapshot" || sh send_mail_new_snasphot.sh



add a section exit status in syspatch.8

2020-07-21 Thread Solene Rapenne
this diff adds an EXIT STATUS section to syspatch man page.

syspatch exit with 1 on errors and 2 if syspatch updates itself.

If syspatch does nothing (because no syspatch) or install syspatches
successfully, the exit status is 0 in both case. Should we emphase
on this? I guess « Did syspatch install something? » is a common
question and the exit status can't help.


Index: syspatch.8
===
RCS file: /cvs/src/usr.sbin/syspatch/syspatch.8,v
retrieving revision 1.20
diff -u -p -r1.20 syspatch.8
--- syspatch.8  15 Jun 2019 16:54:19 -  1.20
+++ syspatch.8  19 Jul 2020 22:07:40 -
@@ -62,6 +62,8 @@ Directories containing the rollback tarb
 .Xr diff 1
 of installed patches.
 .El
+.Sh EXIT STATUS
+.Ex -std syspatch
 .Sh SEE ALSO
 .Xr signify 1 ,
 .Xr installurl 5 ,



Re: ssh-keygen(1): -a is missing in SYNOPSIS and small wording change

2020-07-13 Thread Solene Rapenne
On Thu, 25 Jun 2020 18:02:23 +0100
Jason McIntyre :

> On Thu, Jun 25, 2020 at 06:40:36PM +0200, Solene Rapenne wrote:
> > I found that ssh-keygen(1) missed mention of -a flag in SYNOPSIS.
> >   
> 
> i think this got accidently removed in -r1.184:
> 
>   remove single letter flags for moduli operations
> 
> > The following patch adds mention to [-a rounds] with default (no
> > flag), -p, -c, -K and -A
> >   
> 
> i'm definitely not the right person to ok that
> 
> > All the functions triggered by these flags use the rounds variable
> > defined with -a parameter (default 0)
> > 
> > 
> > I also propose a small wording change, in the sentence:
> > "After a key is generated, instructions below detail [...]"
> > 
> > I thought below refered to the list of options after that sentence,
> > but it may be a mistake of mine here.
> >   
> 
> i wanted to ask about this text too. it's unclear to me. after a key is
> generated, ssh-keygen asks where to save it. i wonder why we use the
> wording "should be placed to be activated"? it seems odd, but maybe
> there's a reason.
> 
> jmc

I don't really understand the whole sentence but I thought it was
due to my english understanding.

New patch adding [-a rounds] in ssh-keygen usage(). I'm not sure
if the first line of usage() output is ok or too long now.

Index: ssh-keygen.1
===
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.1,v
retrieving revision 1.203
diff -u -p -r1.203 ssh-keygen.1
--- ssh-keygen.13 Apr 2020 02:26:56 -   1.203
+++ ssh-keygen.113 Jul 2020 20:34:14 -
@@ -44,6 +44,7 @@
 .Sh SYNOPSIS
 .Nm ssh-keygen
 .Op Fl q
+.Op Fl a Ar rounds
 .Op Fl b Ar bits
 .Op Fl C Ar comment
 .Op Fl f Ar output_keyfile
@@ -54,6 +55,7 @@
 .Op Fl w Ar provider
 .Nm ssh-keygen
 .Fl p
+.Op Fl a Ar rounds
 .Op Fl f Ar keyfile
 .Op Fl m Ar format
 .Op Fl N Ar new_passphrase
@@ -71,6 +73,7 @@
 .Op Fl f Ar input_keyfile
 .Nm ssh-keygen
 .Fl c
+.Op Fl a Ar rounds
 .Op Fl C Ar comment
 .Op Fl f Ar keyfile
 .Op Fl P Ar passphrase
@@ -93,6 +96,7 @@
 .Op Fl f Ar known_hosts_file
 .Nm ssh-keygen
 .Fl K
+.Op Fl a Ar rounds
 .Op Fl w Ar provider
 .Nm ssh-keygen
 .Fl R Ar hostname
@@ -125,6 +129,7 @@
 .Op Fl f Ar input_keyfile
 .Nm ssh-keygen
 .Fl A
+.Op Fl a Ar rounds
 .Op Fl f Ar prefix_path
 .Nm ssh-keygen
 .Fl k
@@ -248,7 +253,9 @@ keys may be converted using this option 
 .Fl p
 (change passphrase) flag.
 .Pp
-After a key is generated, instructions below detail where the keys
+After a key is generated,
+.Nm
+will ask where the keys
 should be placed to be activated.
 .Pp
 The options are as follows:
Index: ssh-keygen.c
===
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.c,v
retrieving revision 1.413
diff -u -p -r1.413 ssh-keygen.c
--- ssh-keygen.c26 Jun 2020 05:02:03 -  1.413
+++ ssh-keygen.c13 Jul 2020 20:34:15 -
@@ -3013,15 +3013,15 @@ static void
 usage(void)
 {
fprintf(stderr,
-   "usage: ssh-keygen [-q] [-b bits] [-C comment] [-f output_keyfile] 
[-m format]\n"
+   "usage: ssh-keygen [-q] [-a rounds] [-b bits] [-C comment] [-f 
output_keyfile] [-m format]\n"
"  [-t dsa | ecdsa | ecdsa-sk | ed25519 | 
ed25519-sk | rsa]\n"
"  [-N new_passphrase] [-O option] [-w provider]\n"
-   "   ssh-keygen -p [-f keyfile] [-m format] [-N 
new_passphrase]\n"
+   "   ssh-keygen -p [-a rounds] [-f keyfile] [-m format] [-N 
new_passphrase]\n"
"   [-P old_passphrase]\n"
"   ssh-keygen -i [-f input_keyfile] [-m key_format]\n"
"   ssh-keygen -e [-f input_keyfile] [-m key_format]\n"
"   ssh-keygen -y [-f input_keyfile]\n"
-   "   ssh-keygen -c [-C comment] [-f keyfile] [-P passphrase]\n"
+   "   ssh-keygen -c [-a rounds] [-C comment] [-f keyfile] [-P 
passphrase]\n"
"   ssh-keygen -l [-v] [-E fingerprint_hash] [-f 
input_keyfile]\n"
"   ssh-keygen -B [-f input_keyfile]\n");
 #ifdef ENABLE_PKCS11
@@ -3031,7 +3031,7 @@ usage(void)
fprintf(stderr,
"   ssh-keygen -F hostname [-lv] [-f known_hosts_file]\n"
"   ssh-keygen -H [-f known_hosts_file]\n"
-   "   ssh-keygen -K [-w provider]\n"
+   "   ssh-keygen -K [-a rounds] [-w provider]\n"
"   ssh-keygen -R hostname [-f known_hosts_file]\n"
"   ssh-keygen -r hostname [-g] [-f input_keyfile]\n"
 #ifdef WITH_OPENSS

Re: UPgrading pkg to 6.7 missed a package

2020-07-13 Thread Solene Rapenne
On Mon, 13 Jul 2020 15:39:39 -0400
sven falempin :

> Readers,
> 
> pkg_add -u
> failed to upgrade
> 
> p5-DBD-MariaDB-1.2
> to
> p5-DBD-MariaDB-1.21p0
> 
> p5-DBD-MariaDB-1.2 is previous released so maybe it is too old and my fault
> , but it is
> odd that pkg_add -u p5-DBD-MariaDB does nothing when p5-DBD-MariaDB-1.2 is
> in the package list
> 
> and p5-DBD-MariaDB-1.21p0.tgz available in the package depot.
> 
> Best.
> 

Could you share the error from pkg_add and a dmesg?



Re: fsck_ffs: faster with lots of cylinder groups

2020-07-12 Thread Solene Rapenne
On Sun, 12 Jul 2020 09:13:47 +0200
Otto Moerbeek :

> On Mon, Jun 29, 2020 at 02:30:41PM +0200, Otto Moerbeek wrote:
> 
> > On Sun, Jun 21, 2020 at 03:35:21PM +0200, Otto Moerbeek wrote:
> >   
> > > Hi,
> > > 
> > > both phase 1 and phase 5 need cylinder group metadata.  This diff
> > > keeps the cg data read in phase 1 in memory to be used by phase 5 if
> > > possible. From FreeBSD. 
> > > 
> > >   -Otto
> > > 
> > > On an empty 30T fileystem:
> > > 
> > > $ time obj/fsck_ffs -f /dev/sd3a
> > > 2m44.10s real 0m13.21s user 0m07.38s system
> > > 
> > > $ time doas obj/fsck_ffs -f /dev/sd3a
> > > 1m32.81s real 0m12.86s user 0m05.25s system
> > > 
> > > The difference will be less if a fileystem is filled up, but still nice.  
> > 
> > Any takers?  
> 
> No feedback. I'm getting discouraged in doing more filesystem work...
> 
> What to do?
> 
> 1) Abondon the diff
> 2) Commit without ok
> 
> I did quite extensive testing, but both options are unsatisfactory.
> 
>   -Otto

I'm not sure how to test your diff.
Would running fsck on a sane filesystem enough?

Are you using Vms that you halt to force a
fsck on them? Would this be a good test too?



Re: Destructive Install Process (fdisk)

2020-06-25 Thread Solene Rapenne
On Thu, 25 Jun 2020 19:27:22 -0400
David Blevins :

> OpenBSD Community,
> 
> I've been experimenting with the OpenBSD 6.7 install process (though
> this "issue" is likely present in earlier version) and have noticed
> that the fdisk program in the installation program will destructively
> edit the hard drive upon selecting either MBR or GPT partitioning.
> I have repeatedly wiped a test hard drive's partitioning scheme as a
> consequence of this, in spite of only desiring to examine the
> partitioning scheme.
> 

This is explained in the INSTALL.amd64 file (I guess you use amd64)
https://ftp.fr.openbsd.org/pub/OpenBSD/6.7/amd64/INSTALL.amd64

The installation program will ask you if you want to use the
whole disk for OpenBSD.  If you don't need to or don't intend
to share the disk with other operating systems, answer "w"
here to use "MBR" partitioning or "g" to use "GPT"
partitioning. The installation program will then create a single
partition spanning the whole disk, dedicated to OpenBSD.

> Additionally, I have noticed that (per warnings in the installation
> program) GPT partitioning does not work on my system.  Does anyone
> have insight into this issue, and if so is there any interest in
> a fix for GPT partitioning?
> 
> -David Blevins

You shoud provide information about your system. I never had issue
with GPT.



ssh-keygen(1): -a is missing in SYNOPSIS and small wording change

2020-06-25 Thread Solene Rapenne
I found that ssh-keygen(1) missed mention of -a flag in SYNOPSIS.

The following patch adds mention to [-a rounds] with default (no
flag), -p, -c, -K and -A

All the functions triggered by these flags use the rounds variable
defined with -a parameter (default 0)


I also propose a small wording change, in the sentence:
"After a key is generated, instructions below detail [...]"

I thought below refered to the list of options after that sentence,
but it may be a mistake of mine here.


Index: ssh-keygen.1
===
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.1,v
retrieving revision 1.203
diff -u -p -r1.203 ssh-keygen.1
--- ssh-keygen.13 Apr 2020 02:26:56 -   1.203
+++ ssh-keygen.125 Jun 2020 16:28:54 -
@@ -44,6 +44,7 @@
 .Sh SYNOPSIS
 .Nm ssh-keygen
 .Op Fl q
+.Op Fl a Ar rounds
 .Op Fl b Ar bits
 .Op Fl C Ar comment
 .Op Fl f Ar output_keyfile
@@ -54,6 +55,7 @@
 .Op Fl w Ar provider
 .Nm ssh-keygen
 .Fl p
+.Op Fl a Ar rounds
 .Op Fl f Ar keyfile
 .Op Fl m Ar format
 .Op Fl N Ar new_passphrase
@@ -71,6 +73,7 @@
 .Op Fl f Ar input_keyfile
 .Nm ssh-keygen
 .Fl c
+.Op Fl a Ar rounds
 .Op Fl C Ar comment
 .Op Fl f Ar keyfile
 .Op Fl P Ar passphrase
@@ -93,6 +96,7 @@
 .Op Fl f Ar known_hosts_file
 .Nm ssh-keygen
 .Fl K
+.Op Fl a Ar rounds
 .Op Fl w Ar provider
 .Nm ssh-keygen
 .Fl R Ar hostname
@@ -125,6 +129,7 @@
 .Op Fl f Ar input_keyfile
 .Nm ssh-keygen
 .Fl A
+.Op Fl a Ar rounds
 .Op Fl f Ar prefix_path
 .Nm ssh-keygen
 .Fl k
@@ -248,7 +253,9 @@ keys may be converted using this option 
 .Fl p
 (change passphrase) flag.
 .Pp
-After a key is generated, instructions below detail where the keys
+After a key is generated,
+.Nm
+will ask where the keys
 should be placed to be activated.
 .Pp
 The options are as follows:



Re: improve pkg_add bandwidth usage with some mirrors

2020-06-19 Thread Solene Rapenne
On Fri, 19 Jun 2020 14:42:54 +0200
Theo Buehler :

> On Fri, Jun 19, 2020 at 11:42:44AM -, Christian Weisgerber wrote:
>  [...]  
>  [...]  
>  [...]  
> 
> Yes, jsing wanted to take a closer look.  I will commit the diff
> tonight UTC unless I hear an objection (I have an ok beck).
> 

I confirm that with this patch pkg_add doesn't download extra bytes.



improve pkg_add bandwidth usage with some mirrors

2020-06-17 Thread Solene Rapenne
I propose a small diff for pkg_add when using http/https mirrors.
Don't wait 30 seconds for the ftp process to stop when closing
file handler, send SIGHUP immediately after closing the file handler.

Running pkg_add -u neovim (already installed and up to date) I got
those results of bandwidth usage

using mirror https://mirror.one.com/pub/OpenBSD/
62513 kB without diff
9050  kB with diff

using mirror https://ftp.fr.openbsd.org/pub/OpenBSD
6530 kB without diff
6373 kB with diff

The 2500 kB difference between the two mirrors with the diff is
explained by the html directory listing which is different
between servers. mirror.one.com list is 3800 kB while
ftp.fr.openbsd.org only 1387 kB.

I can't explain why but when using mirror.one.com the ftp command will
continuously fetch packages until completion or stop if ftp is killed
after 30 seconds. This extra downloaded data is useless.

I came with the following diff, but maybe the real issue is ftp(1)
not stopping immediately if output is closed?

Index: OpenBSD/PackageRepository.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm,v
retrieving revision 1.171
diff -u -p -r1.171 PackageRepository.pm
--- OpenBSD/PackageRepository.pm8 Nov 2019 14:50:58 -   1.171
+++ OpenBSD/PackageRepository.pm17 Jun 2020 09:21:41 -
@@ -206,12 +206,8 @@ sub close
my ($self, $object, $hint) = @_;
close($object->{fh}) if defined $object->{fh};
if (defined $object->{pid2}) {
-   local $SIG{ALRM} = sub {
-   kill HUP => $object->{pid2};
-   };
-   alarm(30);
+   kill HUP => $object->{pid2};
waitpid($object->{pid2}, 0);
-   alarm(0);
}
$self->parse_problems($object->{errors}, $hint, $object)
if defined $object->{errors};



Re: Avoid offline cpu in automatic frequency scheduling

2020-05-28 Thread Solene Rapenne
On Thu, 28 May 2020 11:43:07 -0400
Bryan Steele :

> On Thu, May 28, 2020 at 04:29:19PM +0200, Solene Rapenne wrote:
> > the macro CPU_INFO_FOREACH loop over every CPU but the frequency
> > algorithm will raise frequency if one cpu usage goes over a
> > threshold but also if the sum of cpu usage goes over another
> > threshold.
> > 
> > In the current case, if you have offline cpu (because of hw.smt=0),
> > the total will still sum all the idle cpu and it's unlikely that
> > the total threshold is ever reached before the per cpu one.
> > 
> > so, this diff skip offline cpus in the loop (robert@ gave me the big
> > clue to use cpu_is_online in the loop)  
> 
> Thanks for finding this solene! Nice work.
> 
> I've been aware of some issues on AMD with the automatic frequency
> scaling and haven't been able to narrow them down. This may not solve
> all of them, but does appear to improve things on Ryzen CPUs which
> have many cores/threads and no BIOS knob to disable SMT.
> 
> Assuming others agree with the approach..
> 
> ok brynet@

I think this should help CPU with a lot of cores. If I got the
algorithm right this is doing this:

if 1 cpu has idle < 25% then scale up
OR
if sum cpu idle < 33% then scale up

when it scales up, it will bump a ticker to 5 and set perf to 100% and
check again in the next 100ms. Everytime the loop doesn't need to scale
up (but is still at 100% freq) it decrement the ticket. Once the ticket
is 0 or less, then the frequency goes to minimum.

with the current state, if you have offline cpu, you can never go under
50% of the total idle. So the only way to scale up is to have 1 CPU
with less than 25% idle.

It's a lot of magic numbers without explanation here. I'm curious if
this could be improved. I guess that changing them would tip the
balance between responsiveness and battery saving.



Re: Avoid offline cpu in automatic frequency scheduling

2020-05-28 Thread Solene Rapenne
On Thu, 28 May 2020 16:29:19 +0200
Solene Rapenne :

> so, this diff skip offline cpus in the loop (robert@ gave me the big
> clue to use cpu_is_online in the loop)

apologies, it was claudio@ but robert@ helped too.



Avoid offline cpu in automatic frequency scheduling

2020-05-28 Thread Solene Rapenne
the macro CPU_INFO_FOREACH loop over every CPU but the frequency
algorithm will raise frequency if one cpu usage goes over a threshold
but also if the sum of cpu usage goes over another threshold.

In the current case, if you have offline cpu (because of hw.smt=0), the
total will still sum all the idle cpu and it's unlikely that the total
threshold is ever reached before the per cpu one.

so, this diff skip offline cpus in the loop (robert@ gave me the big
clue to use cpu_is_online in the loop)

Index: sched_bsd.c
===
RCS file: /cvs/src/sys/kern/sched_bsd.c,v
retrieving revision 1.62
diff -u -p -r1.62 sched_bsd.c
--- sched_bsd.c 30 Jan 2020 08:51:27 -  1.62
+++ sched_bsd.c 28 May 2020 14:21:25 -
@@ -576,6 +576,8 @@ setperf_auto(void *v)
j = 0;
speedup = 0;
CPU_INFO_FOREACH(cii, ci) {
+   if (!cpu_is_online(ci))
+   continue;
total = 0;
for (i = 0; i < CPUSTATES; i++) {
total += ci->ci_schedstate.spc_cp_time[i];



sysupgrade change to allow installing from url

2020-05-25 Thread Solene Rapenne
Hi,

I don't know if this will be accepted but I propose to add a -u [url]
parameter to use older snapshots from an archive server for example.

I wanted to add an optional parameter to -s at first but in case of
sysupgrade -s [installurl] the install url would have been mistaken by
this.

If you specify a -u url and installurl at the same time, -u url
superseed installurl.

This would allow easier bisecting using older snapshots.

Index: sysupgrade.8
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
retrieving revision 1.10
diff -u -p -r1.10 sysupgrade.8
--- sysupgrade.83 Oct 2019 12:43:58 -   1.10
+++ sysupgrade.825 May 2020 13:23:06 -
@@ -24,6 +24,7 @@
 .Nm
 .Op Fl fkn
 .Op Fl r | s
+.Op Fl u Pa url
 .Op Ar installurl
 .Sh DESCRIPTION
 .Nm
@@ -66,6 +67,13 @@ This is the default if the system is cur
 .It Fl s
 Upgrade to a snapshot.
 This is the default if the system is currently running a snapshot.
+.It Fl u Pa url
+Fetch and verify the files downloaded from 
+.Pa url .
+This is superseeding
+.Op Pa installurl ,
+its usage is intended for installing older snapshots available under url not 
following
+the usual installurl format.
 .El
 .Sh FILES
 .Bl -tag -width "/auto_upgrade.conf" -compact
Index: sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.37
diff -u -p -r1.37 sysupgrade.sh
--- sysupgrade.sh   26 Jan 2020 22:08:36 -  1.37
+++ sysupgrade.sh   25 May 2020 13:23:06 -
@@ -34,7 +34,7 @@ ug_err()
 
 usage()
 {
-   ug_err "usage: ${0##*/} [-fkn] [-r | -s] [installurl]"
+   ug_err "usage: ${0##*/} [-fkn] [-r | -s] [-u url] [installurl]"
 }
 
 unpriv()
@@ -79,13 +79,14 @@ FORCE=false
 KEEP=false
 REBOOT=true
 
-while getopts fknrs arg; do
+while getopts fknrsu: arg; do
case ${arg} in
f)  FORCE=true;;
k)  KEEP=true;;
n)  REBOOT=false;;
r)  RELEASE=true;;
s)  SNAP=true;;
+   u)  SNAPURL=${OPTARG};;
*)  usage;;
esac
 done
@@ -121,7 +122,11 @@ else
 fi
 
 if $SNAP; then
-   URL=${MIRROR}/snapshots/${ARCH}/
+   if [[ -n "$SNAPURL" ]]; then
+   URL=$SNAPURL
+   else
+   URL=${MIRROR}/snapshots/${ARCH}/
+   fi
 else
URL=${MIRROR}/${NEXT_VERSION}/${ARCH}/
 fi



Re: iwn/athn/wpi: fix CCMP replay check with HW crypto

2020-05-15 Thread Solene Rapenne
Le Fri, 15 May 2020 11:02:46 +0200,
Stefan Sperling  a écrit :

> On Fri, May 08, 2020 at 10:53:30AM +0200, Stefan Sperling wrote:
> > So the diff below contains just the reordering fix for drivers using
> > hardware acceleration for WPA.  
> 
> Is there anybody who wants to OK this?
> 
> To recap:
> 
> Currently, CCMP replay checking is skipped for aggregated 11n frames
> on drivers which use CCMP hardware acceleration: athn(4) and iwn(4).
> 
> This diff makes reply checking in that case possible without false
> positives, by updating the last-seen packet number after the
> aggregated subframes, which may be received out of order, have been
> put back into their intended order by ieee80211_input_ba(). The old
> code only works in the single-frame case for 11a/b/g modes where no
> such legitimate re-transmissions can occur.
> 
> > diff refs/heads/master refs/heads/pn
> > blob - 9193ae3c7b5101a86b85b1b3ba48489d75f5150c
> > blob + 8bc189dc146562f7ab0af2f1690fa02676aecfcd
> > --- sys/dev/ic/ar5008.c
> > +++ sys/dev/ic/ar5008.c
> > @@ -794,9 +794,8 @@ ar5008_ccmp_decap(struct athn_softc *sc, struct
> > mbuf * struct ieee80211_frame *wh;
> > struct ieee80211_rx_ba *ba;
> > uint64_t pn, *prsc;
> > -   u_int8_t *ivp, *mmie;
> > +   u_int8_t *ivp;
> > uint8_t tid;
> > -   uint16_t kid;
> > int hdrlen, hasqos;
> > uintptr_t entry;
> >  
> > @@ -805,35 +804,8 @@ ar5008_ccmp_decap(struct athn_softc *sc,
> > struct mbuf * ivp = mtod(m, u_int8_t *) + hdrlen;
> >  
> > /* find key for decryption */
> > -   if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) {
> > -   k = >ni_pairwise_key;
> > -   } else if ((wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK) !=
> > -   IEEE80211_FC0_TYPE_MGT) {
> > -   /* retrieve group data key id from IV field */
> > -   /* check that IV field is present */
> > -   if (m->m_len < hdrlen + 4)
> > -   return 1;
> > -   kid = ivp[3] >> 6;
> > -   k = >ic_nw_keys[kid];
> > -   } else {
> > -   /* retrieve integrity group key id from MMIE */
> > -   if (m->m_len < sizeof(*wh) + IEEE80211_MMIE_LEN) {
> > -   return 1;
> > -   }
> > -   /* it is assumed management frames are contiguous
> > */
> > -   mmie = (u_int8_t *)wh + m->m_len -
> > IEEE80211_MMIE_LEN;
> > -   /* check that MMIE is valid */
> > -   if (mmie[0] != IEEE80211_ELEMID_MMIE || mmie[1] !=
> > 16) {
> > -   return 1;
> > -   }
> > -   kid = LE_READ_2([2]);
> > -   if (kid != 4 && kid != 5) {
> > -   return 1;
> > -   }
> > -   k = >ic_nw_keys[kid];
> > -   }
> > -
> > -   if (k->k_cipher != IEEE80211_CIPHER_CCMP)
> > +   k = ieee80211_get_rxkey(ic, m, ni);
> > +   if (k == NULL || k->k_cipher != IEEE80211_CIPHER_CCMP)
> > return 1;
> >  
> > /* Sanity checks to ensure this is really a key we
> > installed. */ @@ -853,7 +825,7 @@ ar5008_ccmp_decap(struct
> > athn_softc *sc, struct mbuf * hasqos = ieee80211_has_qos(wh);
> > tid = hasqos ? ieee80211_get_qos(wh) & IEEE80211_QOS_TID :
> > 0; ba = hasqos ? >ni_rx_ba[tid] : NULL;
> > -   prsc = >k_rsc[0];
> > +   prsc = >k_rsc[tid];
> >  
> > /* Extract the 48-bit PN from the CCMP header. */
> > pn = (uint64_t)ivp[0]   |
> > @@ -863,30 +835,12 @@ ar5008_ccmp_decap(struct athn_softc *sc,
> > struct mbuf * (uint64_t)ivp[6] << 32 |
> >  (uint64_t)ivp[7] << 40;
> > if (pn <= *prsc) {
> > -   if (hasqos && ba->ba_state == IEEE80211_BA_AGREED)
> > {
> > -   /*
> > -* This is an A-MPDU subframe.
> > -* Such frames may be received out of
> > order due to
> > -* legitimate retransmissions of failed
> > subframes
> > -* in previous A-MPDUs. Duplicates will be
> > handled
> > -* in ieee80211_inputm() as part of A-MPDU
> > reordering.
> > -*
> > -* XXX TODO We can probably do better than
> > this! Store
> > -* re-ordered PN in BA agreement state and
> > check it?
> > -*/
> > -   } else {
> > -   ic->ic_stats.is_ccmp_replays++;
> > -   return 1;
> > -   }
> > +   ic->ic_stats.is_ccmp_replays++;
> > +   return 1;
> > }
> > -   /* Update last seen packet number. */
> > -   *prsc = pn;
> > +   /* Last seen packet number is updated in
> > ieee80211_inputm(). */ 
> > -   /* Clear Protected bit and strip IV. */
> > -   wh->i_fc[1] &= ~IEEE80211_FC1_PROTECTED;
> > -   memmove(mtod(m, caddr_t) + IEEE80211_CCMP_HDRLEN, wh,
> > hdrlen);
> > -   m_adj(m, IEEE80211_CCMP_HDRLEN);
> > -   /* Strip MIC. */
> > +   /* Strip MIC. IV will be stripped by ieee80211_inputm(). */
> > m_adj(m, -IEEE80211_CCMP_MICLEN);
> > return 0;
> >  }
> > blob - 6b6331d167a881a526b9d0a30f7f452882fee19a

Re: userland clock_gettime proof of concept

2020-05-14 Thread Solene Rapenne
Le Wed, 13 May 2020 17:03:01 +0300,
Paul Irofti  a écrit :

> Hi,
> 
> By far one of the most popular and frequently used system calls is
> clock_gettime(2). As a result the cost of kernel-userland transitions
> out weight the actual work, thus I am proposing we make the data
> available directly from userland without passing through a system
> call.
> 
> This has been a subject of discussion multiple times across the years
> and last I heard from it was at the p2k19 hackthon that I hosted in
> Bucharest where espie@ sent me a diff from one of his students(?).
> Being busy with organization I have not had the time to look at it and
> I am thus getting back to it just now due to robert@ prodding me again
> on the subject. The proposed diff is mine, not the student's.
> 
> 
> The technical bits. 
> 
> Please keep in mind that this is only proof of concept. I am looking
> for ways to improve the current diff. As it is, it requires a flag day
> because it makes use of ELF aux vectors to export the data from the
> kernel.
> 
> I have also played with exposing the data via separate ELF sections
> and with kbind-mmap alternatives. The frist also involves a flag day
> and is more intrusive in my opinion, and the second I could not get
> to work. I think that would be the less intrusive way of doing it,
> possibly without a flag day, so if anyone knows how, please let me
> know.
> 
> The supported clocks are just those that do not require process
> specific data. Those can also be handled later if this diff is
> decided to be a good thing.
> 
> Clock update inside the kernel is done at the end of tc_windup().
> There might be better places to do it. Let me know where.
> 
> The update currently does the work of clock_gettime(), but it can
> probably be changed to only update the timehands and move the logic
> elsewhere. Note that if we expose only the timehands to userland, most
> of the bintime functionality has to also be made available there. Or
> so I think.
> 
> In userland, I wrapped the clock_gettime(2) syscall in libc. There, I
> search for the auxiliary vector and fetch the timespec data from it.
> As you can see in the diff, parts from the elf_exec header will have
> to be exposed to userland if we do it this way.
> 
> 
> Results.
> 
> To test this diff you need to do a full release(8). I have tested this
> with multiple programs. Test programs, base programs and packages.
> None the less, this diff touches many important areas of our tree and
> is very fragile. I also probably missed changing some parts that
> required change due to libc or elf changes.
> 
> If you see regressions, which you probably will, please let me know.

With the patch, system crashes reliably at boot when prompting for login

I followed release(8) instructions, did I miss something?

cd /sys/arch/$(machine)/compile/GENERIC.MP
make obj
make config
make && make install
reboot

cd /usrc/src
make obj
make build
sysmerge
cd /dev && ./MAKEDEV all

cd /usr/xenocara
make bootstrap
make obj
make build
reboot

I got a first panic like « panic init died (signal 0, exit 11)
when I typed reboot.

Now, if I start the system with the new kernel (old kernel.sp
still work), I get either a panic init died or I have ddb but 
can't type in it. This happens after full boot sequence when 
I'm prompted for login: I tried to disable all pkg_services 
and xdm and it still crash at this step, I can't login.

2 screenshots of crashes errors

https://perso.pw/IMG_20200514_110104.jpg 
https://perso.pw/IMG_20200514_110451.jpg 


dmesg output (from bsd.sp kernel which still boots)

OpenBSD 6.7 (GENERIC) #179: Thu May  7 11:02:37 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 8033624064 (7661MB)
avail mem = 611776 (7417MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec070 (76 entries)
bios0: vendor American Megatrends Inc. version "FB" date 06/25/2014
bios0: Gigabyte Technology Co., Ltd. H81M-D2V
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SSDT SSDT MCFG HPET SSDT SSDT
acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4)
RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S4)
EHC2(S4) XHC_(S4) HDEF(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24
bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0:
apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz,
3592.14 MHz, 06-3c-03 cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, 

Re: Audio over hdmi

2020-04-25 Thread Solene Rapenne
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc  a écrit :

> Hi,
> 
> I decided to take a look at what was missing to make audio over hdmi 
> working on OpenBSD.
> 
> After enabling AZALIA_DEBUG in the kernel config I commented the code 
> that disables HDMI codecs like the following :
> 
> 
> --- azalia.c.orig Thu Apr 23 11:44:52 2020
> +++ azalia.c  Fri Apr 24 12:53:15 2020
> @@ -926,9 +926,11 @@
>   c = -1;
>   for (i = 0; i < az->ncodecs; i++) {
>   codec = >codecs[i];
> +/*
>   if ((codec->audiofunc < 0) ||
>   (codec->codec_type == AZ_CODEC_TYPE_HDMI))
>   continue;
> +*/
>   if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
>   if (c < 0)
>   c = i;
> 
> 
> And after rebooting with the modified kernel audio over HDMI was
> working out of the box (see the following diff).
> 
> I suspect that it is pure luck, what could I miss ?
> Could someone test it on Intel based computers ?
> 

hello,

I tried your diff but I'm not sure how to play sound on the screen.

From the FAQ i changed sndiod default output device

# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod

but if I run aucat I get the error "default: couldn't open audio device"


dmesg

OpenBSD 6.7-beta (GENERIC.MP) #0: Sat Apr 25 12:02:14 CEST 2020
solene@solene.perso.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8323534848 (7937MB)
avail mem = 8058654720 (7685MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xaf07e000 (63 entries)
bios0: vendor LENOVO version "N24ET51W (1.26 )" date 08/30/2019
bios0: LENOVO 20L5CTO1WW
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT 
SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM 
DMAR ASF! FPDT UEFI BGRT
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) 
RP06(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.82 MHz, 06-8e-0a
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu3: 

resolv.conf(5) says options inet6 does nothing

2020-04-23 Thread Solene Rapenne
Is there a reason to keep this part in resolv.conf(5) about an option
doing nothing?

> options inet6
> Enables support for IPv6-only applications, by setting RES_USE_INET6
> in _res.options (see res_init(3)). On OpenBSD this option does
> nothing.

If we can remove it, here is the diff.

Index: resolv.conf.5
===
RCS file: /home/cvs/src/share/man/man5/resolv.conf.5,v
retrieving revision 1.59
diff -u -p -r1.59 resolv.conf.5
--- resolv.conf.5   24 Jan 2020 06:16:47 -  1.59
+++ resolv.conf.5   23 Apr 2020 15:09:42 -
@@ -258,13 +258,6 @@ particularly if there is a reduced MTU,
 as is often the case with
 .Xr pppoe 4
 or with tunnels.
-.It Cm inet6
-Enables support for IPv6-only applications, by setting RES_USE_INET6 in
-_res.options (see
-.Xr res_init 3 ) .
-On
-.Ox
-this option does nothing.
 .It Cm insecure1
 Do not require IP source address on the reply packet to be equal to the
 server's address.



Re: [PATCH] make cwm parse /etc/ssh/ssh_known_hosts (global known hosts) as well as user's known_hosts

2020-02-12 Thread Solene Rapenne
On Wed, Feb 12, 2020 at 07:15:36PM +0100, Franz Bettag wrote:
> Dear OpenBSD folks,
> 
> appended you will find a patch allowing cwm to also parse the contents
> of /etc/ssh/ssh_known_hosts and thus extend the ssh menu.
> 
> the diff was taken against the latest source on the github xenocara repo.
> 
> comments and/or feedback is much appreciated.
> 
> thanks for considering this. :)
> 
> best regards

seems people agreed to remove this feature 3 weeks ago but it's still
not committed.

https://marc.info/?l=openbsd-tech=157972423522573=2



bump smtpd version?

2020-01-30 Thread Solene Rapenne
on https://opensmtpd.org/ the OpenBSD version file says 6.6.2 while we
currently have 6.6.1 in CVS.

Should we bump to 6.6.2?

Index: smtpd.h
===
RCS file: /data/cvs/src/usr.sbin/smtpd/smtpd.h,v
retrieving revision 1.650
diff -u -p -r1.650 smtpd.h
--- smtpd.h 8 Jan 2020 01:41:11 -   1.650
+++ smtpd.h 30 Jan 2020 13:00:21 -
@@ -51,7 +51,7 @@
 #define SMTPD_QUEUE_EXPIRY  (4 * 24 * 60 * 60)
 #define SMTPD_SOCKET"/var/run/smtpd.sock"
 #defineSMTPD_NAME   "OpenSMTPD"
-#defineSMTPD_VERSION"6.6.1"
+#defineSMTPD_VERSION"6.6.2"
 #define SMTPD_SESSION_TIMEOUT   300
 #define SMTPD_BACKLOG   5
 



Re: [UPDATE] xterm 351

2019-12-24 Thread Solene Rapenne
Le Mon, 23 Dec 2019 17:34:10 +0100,
Matthieu Herrb  a écrit :

> Hi,
> 
> the diff below (also available as https://xenocara.org/xterm-351.diff)
> updates xterm to version 351 (from current version 344 in xenocara).
> 
> For a detailed change log see
> https://invisible-island.net/xterm/xterm.log.html
> 
> Please test and report. Oks welcome too.
>

I did try a few ncurses programs on top of my usual workflow and no
issue so far.
ok solene@



Re: sysupgrade: Allow to use another directory for the sets

2019-11-20 Thread Solene Rapenne
On Tue, Nov 12, 2019 at 07:02:56PM +0100, Renaud Allard wrote:
> 
> 
> On 12/11/2019 08:29, Theo de Raadt wrote:
> > 
> > Renaud, please test it for me like this:
> > 
> >   sysupgrade -d /
> > 
> > This interface is dangerously incorrect.
> > 
> 
> What about this one?

> Index: sysupgrade.8
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
> retrieving revision 1.10
> diff -u -p -r1.10 sysupgrade.8
> --- sysupgrade.8  3 Oct 2019 12:43:58 -   1.10
> +++ sysupgrade.8  12 Nov 2019 18:01:04 -
> @@ -24,6 +24,7 @@
>  .Nm
>  .Op Fl fkn
>  .Op Fl r | s
> +.Op Fl d Ar directory
>  .Op Ar installurl
>  .Sh DESCRIPTION
>  .Nm
> @@ -48,6 +49,13 @@ triggering a one-shot upgrade using the 
>  .Pp
>  The options are as follows:
>  .Bl -tag -width Ds
> +.It Fl d Ar directory
> +Choose the prefix of the
> +.Ar directory
> +in which the sets will be downloaded.
> +_sysupgrade will be appended to that name.
> +Default is
> +.Pa /home .
>  .It Fl f
>  Force an already applied upgrade.
>  The default is to upgrade to latest snapshot only if available.
> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.32
> diff -u -p -r1.32 sysupgrade.sh
> --- sysupgrade.sh 11 Nov 2019 18:26:52 -  1.32
> +++ sysupgrade.sh 12 Nov 2019 18:01:04 -
> @@ -25,7 +25,6 @@ umask 0022
>  export PATH=/usr/bin:/bin:/usr/sbin:/sbin
>  
>  ARCH=$(uname -m)
> -SETSDIR=/home/_sysupgrade
>  
>  ug_err()
>  {
> @@ -34,7 +33,7 @@ ug_err()
>  
>  usage()
>  {
> - ug_err "usage: ${0##*/} [-fkn] [-r | -s] [installurl]"
> + ug_err "usage: ${0##*/} [-fkn] [-r | -s] [-d directory] [installurl]"
>  }
>  
>  unpriv()
> @@ -73,14 +72,16 @@ rmel() {
>   echo -n "$_c"
>  }
>  
> +SETSDIR=/home/_sysupgrade
>  RELEASE=false
>  SNAP=false
>  FORCE=false
>  KEEP=false
>  REBOOT=true
>  
> -while getopts fknrs arg; do
> +while getopts d:fknrs arg; do
>   case ${arg} in
> + d)  SETSDIR=${OPTARG}/_sysupgrade;;
>   f)  FORCE=true;;
>   k)  KEEP=true;;
>   n)  REBOOT=false;;
> @@ -195,7 +196,7 @@ ${KEEP} && > keep
>  
>  cat <<__EOT >/auto_upgrade.conf
>  Location of sets = disk
> -Pathname to the sets = /home/_sysupgrade/
> +Pathname to the sets = ${SETSDIR}
>  Set name(s) = done
>  Directory does not contain SHA256.sig. Continue without verification = yes
>  __EOT
> @@ -203,7 +204,7 @@ __EOT
>  if ! ${KEEP}; then
>   CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
>   cat <<__EOT > /etc/rc.firsttime
> -rm -f /home/_sysupgrade/{${CLEAN}}
> +rm -f ${SETSDIR}/{${CLEAN}}
>  __EOT
>  fi
>  

I see no objection to this diff. Changes are minimal and it allows using
another destination safely (_sysupgrade gets appended to the chosen base
directory)

ok solene@



Re: sysupgrade: Allow to use another directory for the sets

2019-11-20 Thread Solene Rapenne
On Wed, Nov 20, 2019 at 10:55:28AM +0100, Renaud Allard wrote:
> Hi Solene,
> 
> On 11/20/19 10:46 AM, Solene Rapenne wrote:
> > wouldn't be easier for people using non standard locations to write a
> > small wrapper script like this (not tested, written in the mail)
> > 
> > #!/bin/sh
> > 
> > MYDEST=/var/sysupgrade
> > 
> > install -d -o root -g wheel $MYDEST
> > rm -fr /home/_sysupgrade
> > ln -s $MYDEST /home/_sysupgrade
> > 
> > sysupgrade -n
> > if [ $? -eq 0 ]
> > then
> > sed -i'' "s,/home/_sysupgrade,$MYDEST" /auto_upgrade.conf
> > reboot
> > fi
> > 
> 
> It is indeed a solution, but that still means you have to download the sets
> in /home and then move them. This can be problematic if space on /home is
> constrained or in the case of slow flash disks for example.
> 


no, this script makes /home/_sysupgrade a symbolic link to the real
location where you want to store the sets. So /home doesn't require more
space than the requirement for an additional symlink.



Re: sysupgrade: Allow to use another directory for the sets

2019-11-20 Thread Solene Rapenne
On Wed, Nov 20, 2019 at 10:37:02AM +0100, Raimo Niskanen wrote:
> On Tue, Nov 19, 2019 at 09:00:33AM +, Stuart Henderson wrote:
> > On 2019/11/18 14:45, Raimo Niskanen wrote:
> > > On Mon, Nov 18, 2019 at 01:23:27PM +0100, Renaud Allard wrote:
> > > > 
> > > > 
> > > > On 11/18/19 10:08 AM, Raimo Niskanen wrote:
> > > > 
> > > > > A configuration parameter could be accomplished through an optional 
> > > > > symlink
> > > > > /etc/_sysupgrade that the sysadmin can create to point at the 
> > > > > installation's
> > > > > sysupgrade directory.  The sysupgrade script would test -s 
> > > > > /etc/_sysupgrade
> > > > > and if there is a symlink readlink -f /etc/_sysupgrade to get SETSDIR.
> > > > > 
> > > > 
> > > > As it was said earlier, this doesn't solve the removal issue. With your 
> > > > patch, please try "ln -s /home/_sysupgrade / ; sysupgrade".
> > > > 
> > > 
> > > This is actually not yet in my patch.  I just want to, as a first step
> > > towards either of our solutions, patch to have the /home/_sysupgrade 
> > > literal
> > > in only one place in the sysupgrade script, which would facilitate 
> > > patching
> > > the sysupgrade script before calling it, as a poor man's solution.
> > > Plus, the script gets cleaner.
> > > 
> > > The symlink suggestion is a future patch.
> > > 
> > > But I think your suggestion to instead specify the parent directory of the
> > > _syspatch directory should be sufficient to remedy the removal issue both
> > > for your command line suggestion, as for this future patch symlink
> > > suggestion.
> > > 
> > > It is a pity nobody else has responded to that prefix suggestion of yours!
> > 
> > It does avoid the removal issue but it seems an awkward user interface to
> > pass the parent directory. Perhaps better to enforce that the path matches
> > */_sysupgrade, though this also doesn't feel quite right. Perhaps add
> > /_sysupgrade if it wasn't already present...
> > 
> > > I think the feature itself is more important than if it is implemented
> > > with a command line argument or a symlink.
> > > 
> > > Other than that.  What do you or anyone else think about my argument that
> > > the location of the system upgrade download directory is an installation
> > > configuration that will not change between upgrades and hence it would be
> > > nice to not have to remember the command line argument for every future
> > > sysupgrade.
> > 
> > Generally agree, but I'm not keen on a proliferation of tiny pseudo-config
> > files, and this feels maybe part of something bigger. A similar argument
> > could be made for the choice of release/stable vs snaps (-s / -r here,
> > -Dsnap in pkg_add) which could be in some kind of "system config" alongside
> > source URLs (base, packages, firmware), a list of sets, maybe some pkg_add
> > related things (whether to install debug packages?), ...
> 
> In that case, in the current state of the matter, since there is no such
> common config file yet, and all other tols use command line arguments for
> similar features, we should use a command line argument here too, like
> Renaud Allard proposes.  Until there is a suitable config file.
> 
> Since the prefix solution is regarded as awkward, and we want go guard
> against clumsy admins using / as sysupgrade directory which would remove
> kernels from the updated installation, why not normalize the -d argument
> with readlink -f and simply check that it is not / .  There are of
> course othere directories that are inappropriate to use, but the person
> doing the upgrade has to be trusted to some degree...
> 
> And I see no reason to not at least apply my minimalistic patch suggestion
> that simply defines the upgrade directory in only one place in sysupgrade.
> -- 
> 
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> 

wouldn't be easier for people using non standard locations to write a
small wrapper script like this (not tested, written in the mail)

#!/bin/sh

MYDEST=/var/sysupgrade

install -d -o root -g wheel $MYDEST
rm -fr /home/_sysupgrade
ln -s $MYDEST /home/_sysupgrade

sysupgrade -n
if [ $? -eq 0 ]
then
sed -i'' "s,/home/_sysupgrade,$MYDEST" /auto_upgrade.conf
reboot
fi



Re: _pbuild user to have priority=5

2019-11-14 Thread Solene Rapenne
On Wed, Nov 06, 2019 at 02:38:52PM +0100, Marc Espie wrote:
> On Sat, Nov 02, 2019 at 02:35:28PM +0100, Solene Rapenne wrote:
> > On Sat, Nov 02, 2019 at 01:18:53PM +, Stuart Henderson wrote:
> > > On 2019/11/01 19:16, Theo de Raadt wrote:
> > > > Ted Unangst  wrote:
> > > > 
> > > > > Theo de Raadt wrote:
> > > > > > What about all the other users who aren't in staff?
> > > > > > 
> > > > > > I think the approach is right.  Push non-interactive down.
> > > > > 
> > > > > The same then for src build user?
> > > > 
> > > > Well, that's different.  Most of us building the src tree are waiting
> > > > eagerly for it to finish aren't we?
> > > 
> > > That's the same for ports building!
> > > 
> > 
> > if you don't do anything else than compiling ports, that shouldn't be
> > slower.
> > If you are doing something else (GUI user, web server, community server
> > with people connected doing IRC) , then you don't get angry due to
> > unresponsive system.
> > 
> > Lowering staff priority would only help the one user case.
> 
> I agree with solene on that one.
> 
> This is actually useful even if you're just building ports, because
> you get a more responsive text-editor and stuff like that which is useful
> when you're fixing things that broke while dpb is still going.
> 
> I see a noticeable difference in vim showing me syntax coloring correctly
> while dpb is running.
> 
> Source is somewhat different. make build/release is sequential by nature,
> as you can't really fix a part while something else is still building.
> 

any other people noticed a difference with the priority change?



mg(1) tell make-backup-files is on by default

2019-11-08 Thread Solene Rapenne
Someone on reddit had issue with this config file, there was no backup
file, in file directory or in ~/.mg.d

make-backup-files
backup-to-home-directory

in fact, having "make-backup-files" disables backups.


I've looked at the mg logic for backup files and I could sort that the
default make-backup-files value is 0

/funmap.c: {makebkfile, "make-backup-files", 0},

but in file.c there is a statement with a default to TRUE

 * Save the contents of the current buffer back into its associated
 * file.
  */
  static int  makebackup = TRUE;


I don't really get the logic here, nor when the configuration file and
that TRUE variable get in touch.

What I propose is to update the manual that make-backup-files is true by
default, so toggling it disable backups.


Index: mg.1
===
RCS file: /data/cvs/src/usr.bin/mg/mg.1,v
retrieving revision 1.117
diff -u -p -r1.117 mg.1
--- mg.12 Jul 2019 16:25:39 -   1.117
+++ mg.18 Nov 2019 17:16:47 -
@@ -688,6 +688,7 @@ Bind a key mapping in the local (topmost
 Unbind a key mapping in the local (topmost) mode.
 .It make-backup-files
 Toggle generation of backup files.
+Enabled by default.
 .It make-directory
 Prompt the user for a path or directory name which is then created.
 .It mark-paragraph



upgrade66.html missing acme-client.conf staging api url change

2019-11-08 Thread Solene Rapenne
The staging api changed too. I know people who did not update that url,
it's not especially obvious because the old url doesn't contain v01.

ok ?

Index: upgrade66.html
===
RCS file: /data/cvs/www/faq/upgrade66.html,v
retrieving revision 1.15
diff -u -p -r1.15 upgrade66.html
--- upgrade66.html  30 Oct 2019 04:11:00 -  1.15
+++ upgrade66.html  8 Nov 2019 17:12:01 -
@@ -147,6 +147,14 @@ any post-release fixes.
   
   https://acme-v02.api.letsencrypt.org/directory
+  The staging api url should also be changed from
+  
+  https://acme-staging.api.letsencrypt.org/directory
+  to
+  
+  https://acme-staging-v02.api.letsencrypt.org/directory
   
   The -A and -D flags have been removed from
   https://man.openbsd.org/OpenBSD-6.6/acme-client.1;>



Re: _pbuild user to have priority=5

2019-11-02 Thread Solene Rapenne
On Sat, Nov 02, 2019 at 01:18:53PM +, Stuart Henderson wrote:
> On 2019/11/01 19:16, Theo de Raadt wrote:
> > Ted Unangst  wrote:
> > 
> > > Theo de Raadt wrote:
> > > > What about all the other users who aren't in staff?
> > > > 
> > > > I think the approach is right.  Push non-interactive down.
> > > 
> > > The same then for src build user?
> > 
> > Well, that's different.  Most of us building the src tree are waiting
> > eagerly for it to finish aren't we?
> 
> That's the same for ports building!
> 

if you don't do anything else than compiling ports, that shouldn't be
slower.
If you are doing something else (GUI user, web server, community server
with people connected doing IRC) , then you don't get angry due to
unresponsive system.

Lowering staff priority would only help the one user case.



Re: _pbuild user to have priority=5

2019-11-01 Thread Solene Rapenne
On Fri, Nov 01, 2019 at 10:06:48PM -, Christian Weisgerber wrote:
> On 2019-10-31, Solene Rapenne  wrote:
> 
> > I suggest adding a priority=5 to _pbuild user.
> 
> Is this the right place?  Or should dpb do this?
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

using the _pbuild class it applies for package building using make and
also when using dpb (which uses make). I don't understand why it should
be handled by dpb.



_pbuild user to have priority=5

2019-10-31 Thread Solene Rapenne
I suggest adding a priority=5 to _pbuild user.
I tried on a macppc, a core 2 duo laptop and i7 laptop.

It helped a lot the macppc and core2 to stay responsive on ssh or being
barely usable while building. On the i7, the benefits are less. At best
this allows firefox to stay responsive on bloated "webapps" and avoid a
few audio stuttering.

I only see benefits and no drawback.

Index: etc.alpha/login.conf
===
RCS file: /data/cvs/src/etc/etc.alpha/login.conf,v
retrieving revision 1.7
diff -u -p -r1.7 login.conf
--- etc.alpha/login.conf2 Jun 2019 06:46:17 -   1.7
+++ etc.alpha/login.conf31 Oct 2019 22:34:15 -
@@ -95,6 +95,7 @@ pbuild:\
:datasize-cur=1024M:\
:maxproc-max=1024:\
:maxproc-cur=256:\
+   :priority=5:\
:tc=default:
 
 #
Index: etc.amd64/login.conf
===
RCS file: /data/cvs/src/etc/etc.amd64/login.conf,v
retrieving revision 1.12
diff -u -p -r1.12 login.conf
--- etc.amd64/login.conf19 Aug 2019 20:59:14 -  1.12
+++ etc.amd64/login.conf31 Oct 2019 22:34:20 -
@@ -95,6 +95,7 @@ pbuild:\
:datasize-cur=6144M:\
:maxproc-max=1024:\
:maxproc-cur=384:\
+   :priority=5:\
:tc=default:
 
 #
Index: etc.arm64/login.conf
===
RCS file: /data/cvs/src/etc/etc.arm64/login.conf,v
retrieving revision 1.6
diff -u -p -r1.6 login.conf
--- etc.arm64/login.conf7 Oct 2019 17:52:59 -   1.6
+++ etc.arm64/login.conf31 Oct 2019 22:34:24 -
@@ -95,6 +95,7 @@ pbuild:\
:datasize-cur=6144M:\
:maxproc-max=1024:\
:maxproc-cur=384:\
+   :priority=5:\
:tc=default:
 
 #
Index: etc.armv7/login.conf
===
RCS file: /data/cvs/src/etc/etc.armv7/login.conf,v
retrieving revision 1.7
diff -u -p -r1.7 login.conf
--- etc.armv7/login.conf2 Jun 2019 06:46:17 -   1.7
+++ etc.armv7/login.conf31 Oct 2019 22:34:27 -
@@ -95,6 +95,7 @@ pbuild:\
:datasize-cur=1024M:\
:maxproc-max=1024:\
:maxproc-cur=256:\
+   :priority=5:\
:tc=default:
 
 #
Index: etc.hppa/login.conf
===
RCS file: /data/cvs/src/etc/etc.hppa/login.conf,v
retrieving revision 1.9
diff -u -p -r1.9 login.conf
--- etc.hppa/login.conf 2 Jun 2019 06:46:17 -   1.9
+++ etc.hppa/login.conf 31 Oct 2019 22:34:31 -
@@ -95,6 +95,7 @@ pbuild:\
:datasize-cur=1024M:\
:maxproc-max=1024:\
:maxproc-cur=256:\
+   :priority=5:\
:tc=default:
 
 #
Index: etc.i386/login.conf
===
RCS file: /data/cvs/src/etc/etc.i386/login.conf,v
retrieving revision 1.8
diff -u -p -r1.8 login.conf
--- etc.i386/login.conf 2 Jun 2019 06:46:18 -   1.8
+++ etc.i386/login.conf 31 Oct 2019 22:34:36 -
@@ -95,6 +95,7 @@ pbuild:\
:datasize-cur=2048M:\
:maxproc-max=1024:\
:maxproc-cur=256:\
+   :priority=5:\
:tc=default:
 
 #
Index: etc.landisk/login.conf
===
RCS file: /data/cvs/src/etc/etc.landisk/login.conf,v
retrieving revision 1.7
diff -u -p -r1.7 login.conf
--- etc.landisk/login.conf  2 Jun 2019 06:46:18 -   1.7
+++ etc.landisk/login.conf  31 Oct 2019 22:34:39 -
@@ -95,6 +95,7 @@ pbuild:\
:datasize-cur=1024M:\
:maxproc-max=1024:\
:maxproc-cur=256:\
+   :priority=5:\
:tc=default:
 
 #
Index: etc.loongson/login.conf
===
RCS file: /data/cvs/src/etc/etc.loongson/login.conf,v
retrieving revision 1.9
diff -u -p -r1.9 login.conf
--- etc.loongson/login.conf 18 Oct 2019 03:40:22 -  1.9
+++ etc.loongson/login.conf 31 Oct 2019 22:34:42 -
@@ -95,6 +95,7 @@ pbuild:\
:datasize-cur=4096M:\
:maxproc-max=1024:\
:maxproc-cur=256:\
+   :priority=5:\
:tc=default:
 
 #
Index: etc.luna88k/login.conf
===
RCS file: /data/cvs/src/etc/etc.luna88k/login.conf,v
retrieving revision 1.7
diff -u -p -r1.7 login.conf
--- etc.luna88k/login.conf  2 Jun 2019 06:46:18 -   1.7
+++ etc.luna88k/login.conf  31 Oct 2019 22:34:45 -
@@ -95,6 +95,7 @@ pbuild:\
:datasize-cur=1024M:\
:maxproc-max=1024:\
:maxproc-cur=256:\
+   :priority=5:\
:tc=default:
 
 #
Index: etc.macppc/login.conf
===
RCS file: /data/cvs/src/etc/etc.macppc/login.conf,v
retrieving revision 1.8
diff -u -p -r1.8 login.conf
--- etc.macppc/login.conf   2 Jun 2019 06:46:18 - 

/etc/examples/sysctl.conf wrong Xref + key lacking information

2019-09-10 Thread Solene Rapenne
Hi

I looked at /etc/examples/sysctl.conf on an amd64 system and found 2
things:

- file refers to sysctl(3) and sysctl(8). sysctl(3) doesn't exists but
  sysctl(2) exists, I think we want a 2

Index: sysctl.conf
===
RCS file: /data/cvs/src/etc/examples/sysctl.conf,v
retrieving revision 1.4
diff -u -p -r1.4 sysctl.conf
--- sysctl.conf 3 Apr 2015 15:50:28 -   1.4
+++ sysctl.conf 10 Sep 2019 10:50:13 -
@@ -1,7 +1,7 @@
 #  $OpenBSD: sysctl.conf,v 1.4 2015/04/03 15:50:28 millert Exp $
 #
 # This file contains a list of sysctl options the user wants set at
-# boot time.  See sysctl(3) and sysctl(8) for more information on
+# boot time.  See sysctl(2) and sysctl(8) for more information on
 # the many available variables.
 #
 #net.inet.ip.forwarding=1  # 1=Permit forwarding (routing) of IPv4 packets


- the default value 1 for key machdep.pwraction=1 is not documented,
  comment says # ACPI power button action: 0=none, 2=suspend

this is defined in etc/etc.amd64/sysctl.conf, I guess the default is
1=shutdown

Index: etc/etc.amd64/sysctl.conf
===
RCS file: /data/cvs/src/etc/etc.amd64/sysctl.conf,v
retrieving revision 1.8
diff -u -p -r1.8 sysctl.conf
--- etc/etc.amd64/sysctl.conf   19 Jan 2019 20:50:38 -  1.8
+++ etc/etc.amd64/sysctl.conf   10 Sep 2019 10:58:36 -
@@ -1,4 +1,4 @@
 #machdep.allowaperture=2   # See xf86(4)
 #machdep.kbdreset=1# permit console CTRL-ALT-DEL to do a nice halt
 #machdep.lidaction=0   # 1=suspend, 2=hibernate laptop upon lid closing
-#machdep.pwraction=1   # ACPI power button action: 0=none, 2=suspend
+#machdep.pwraction=1   # ACPI power button action: 0=none, 1=shutdown, 
2=suspend



Re: add caveats section in newfs about endianess

2019-08-28 Thread Solene Rapenne
> Or, you could explain this more as an attribute of the filesystem:
> 
> FFS filesystems are byte-order dependent, and thus not portable to
> systems with a different endianness.
> 
> (two n in endianness)
> 
> 

what about this text in mount_ffs(8) where it makes more sense?


Index: mount_ffs.8
===
RCS file: /data/cvs/src/sbin/mount_ffs/mount_ffs.8,v
retrieving revision 1.18
diff -u -p -r1.18 mount_ffs.8
--- mount_ffs.8 6 Oct 2016 13:16:21 -   1.18
+++ mount_ffs.8 28 Aug 2019 17:19:48 -
@@ -77,6 +77,10 @@ For example, /dev/sd0a and 3eb7f9da875cb
 .Sq a
 partition.
 .Pp
+As FFS filesystems are byte-order dependent, 
+.Nm
+will error on a system using a different endianness.
+.Pp
 This command is normally executed per file system by
 .Xr rc 8
 at boot time using the



Re: FAQ: aarch64 stable packages

2019-08-25 Thread Solene Rapenne
On Sun, Aug 25, 2019 at 09:09:58PM +0200, Alessandro Gallo wrote:
> Hi,
> 
> Looks like stable packages for aarch64 are now available (?):
> 
> https://ftp.openbsd.org/pub/OpenBSD/6.5/packages-stable/aarch64
> 
> The following diff updates the relevant section of the FAQ:
> 
> Index: faq10.html
> ===
> RCS file: /cvs/www/faq/faq10.html,v
> retrieving revision 1.288
> diff -u -p -u -p -r1.288 faq10.html
> --- faq10.html14 Aug 2019 13:07:46 -  1.288
> +++ faq10.html25 Aug 2019 19:06:52 -
> @@ -90,8 +90,8 @@ there are two options:
>  new packages will include any security fixes.
>  Simply call  href="https://man.openbsd.org/pkg_add;>pkg_add(1) with
>  the -u flag to get the new files.
> -Note that updated -stable packages are only available for the amd64 and
> -i386 architectures.
> +Note that updated -stable packages are only available for the amd64,
> +i386, and aarch64 architectures.
>Use the -stable ports tree
>  
>  Fetch (or update) your ports tree,
> 
> Thanks
> 

Indeed, we also provide aarch64 packages now :)

Thx for spotting this lack, it's committed.



add caveats section in newfs about endianess

2019-08-19 Thread Solene Rapenne
This diff had a section about endianess of newfs.
This is not written anywhere that ffs is dependent of endianess.

Related bug report
https://marc.info/?l=openbsd-bugs=150242795204995=2


Index: newfs.8
===
RCS file: /data/cvs/src/sbin/newfs/newfs.8,v
retrieving revision 1.75
diff -u -p -r1.75 newfs.8
--- newfs.8 23 Apr 2019 18:13:11 -  1.75
+++ newfs.8 19 Aug 2019 15:49:15 -
@@ -345,3 +345,8 @@ The
 .Nm
 command appeared in
 .Bx 4.2 .
+.Sh CAVEATS
+The created filesystem can only be mounted on systems running architectures
+of the same endianess as the one on which
+.Nm
+has been used.



Re: apmd C getopt flag unused?

2019-08-07 Thread Solene Rapenne
On Wed, Aug 07, 2019 at 12:40:03PM +0200, Claudio Jeker wrote:
> On Wed, Aug 07, 2019 at 12:33:58PM +0200, Solene Rapenne wrote:
> > I found case 'C' in getopt in amd which is not documented and seems to
> > be an alias for -A.
> > 
> > Ok for removing?
> 
> Please don't, I think many people still use the old apmd -C (at least I do
> have it on a few systems). Also you should remove it from the getopt
> string.

OK

For history, commit message removing -C flag and making it fallback on
-A 
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/apmd/apmd.c?rev=1.71=text/x-cvsweb-markup



Re: apmd C getopt flag unused?

2019-08-07 Thread Solene Rapenne
On Wed, Aug 07, 2019 at 12:33:58PM +0200, Solene Rapenne wrote:
> I found case 'C' in getopt in amd which is not documented and seems to
> be an alias for -A.
> 
> Ok for removing?
> 
> Index: apmd.c
> ===
> RCS file: /data/cvs/src/usr.sbin/apmd/apmd.c,v
> retrieving revision 1.84
> diff -u -p -r1.84 apmd.c
> --- apmd.c4 Dec 2018 18:00:57 -   1.84
> +++ apmd.c7 Aug 2019 10:30:49 -
> @@ -417,7 +417,6 @@ main(int argc, char *argv[])
>   statonly = 1;
>   break;
>   case 'A':
> - case 'C':
>   if (doperf != PERF_NONE)
>   usage();
>   doperf = PERF_AUTO;
> 

I sent my mail to quick. C is "PERF_COOL" profile but it doesn't seem
used anymore because case 'A' and 'C' have PERF_AUTO but there is still
a few lines about PERF_COOL.

If someone confirms me it's obsolete, I'll do a proper diff for cleaning
this.



apmd C getopt flag unused?

2019-08-07 Thread Solene Rapenne
I found case 'C' in getopt in amd which is not documented and seems to
be an alias for -A.

Ok for removing?

Index: apmd.c
===
RCS file: /data/cvs/src/usr.sbin/apmd/apmd.c,v
retrieving revision 1.84
diff -u -p -r1.84 apmd.c
--- apmd.c  4 Dec 2018 18:00:57 -   1.84
+++ apmd.c  7 Aug 2019 10:30:49 -
@@ -417,7 +417,6 @@ main(int argc, char *argv[])
statonly = 1;
break;
case 'A':
-   case 'C':
if (doperf != PERF_NONE)
usage();
doperf = PERF_AUTO;



systat is not flushing output

2019-07-19 Thread Solene Rapenne
I wanted to use systat -b -d 10 iostat 1 | something to parse output in
real time but it was not possible, systat doesn't flush output.

otto@ suggested this change, I tried it and it works.

This flush output at the end of writing a page in raw mode (-B or -b
flags).

ok?

Index: engine.c
===
RCS file: /data/cvs/src/usr.bin/systat/engine.c,v
retrieving revision 1.23
diff -u -p -r1.23 engine.c
--- engine.c17 Jan 2019 05:56:29 -  1.23
+++ engine.c19 Jul 2019 15:03:28 -
@@ -245,6 +245,7 @@ end_page(void)
if (rawmode) {
linepos = 0;
clear_linebuf();
+fflush(stdout);
} else {
move(home_line, 0);
print_cmdline();



Re: taking kernel config into consideration when reorder

2019-07-18 Thread Solene Rapenne
On Thu, Jul 18, 2019 at 07:15:50PM +0300, Gregory Edigarov wrote:
> Hello,
> 
> Just tired a of rebooting into UKC a bit.
> 
> diff --git a/libexec/reorder_kernel/reorder_kernel.sh
> b/libexec/reorder_kernel/reorder_kernel.sh
> index ecd8d8fc563..7354350505a 100644
> --- a/libexec/reorder_kernel/reorder_kernel.sh
> +++ b/libexec/reorder_kernel/reorder_kernel.sh
> @@ -66,5 +66,9 @@ make newbsd
>  make newinstall
>  sync
> 
> +if [[ -f /etc/kernel.conf ]]; then
> +   config -ef /bsd < /etc/kernel.conf
> +fi
> +
>  echo "\nKernel has been relinked and is active on next reboot.\n"
>  cat $SHA256
>
What is that /etc/kernel.conf file? No man page mentions it.



Re: sync acme-client.conf.5 with the example about LE API url

2019-07-04 Thread Solene Rapenne
On Thu, Jul 04, 2019 at 10:52:50PM +0200, Sebastian Benoit wrote:
> Solene Rapenne(sol...@perso.pw) on 2019.07.04 06:56:44 +0200:
> > The example uses acme-v02.api.letsencrypt.org while acme-client.conf(5)
> > still uses v01.
> 
> ups.
> 
> ok benno@
> 
thanks!

I reply in thread because I receive okays but it's committed :)



sync acme-client.conf.5 with the example about LE API url

2019-07-03 Thread Solene Rapenne
The example uses acme-v02.api.letsencrypt.org while acme-client.conf(5)
still uses v01.

Index: acme-client.conf.5
===
RCS file: /data/cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
retrieving revision 1.20
diff -u -p -r1.20 acme-client.conf.5
--- acme-client.conf.5  17 Jun 2019 12:42:52 -  1.20
+++ acme-client.conf.5  4 Jul 2019 04:51:15 -
@@ -63,7 +63,7 @@ Macros are not expanded inside quotes.
 .Pp
 For example:
 .Bd -literal -offset indent
-api_url="https://acme-v01.api.letsencrypt.org/directory;
+api_url="https://acme-v02.api.letsencrypt.org/directory;
 authority letsencrypt {
api url $api_url
account key "/etc/acme/letsencrypt-privkey.pem"



Re: anoncvs.html: tell reader to use -d if updating first time from tgz

2019-06-28 Thread Solene Rapenne
On Fri, Jun 28, 2019 at 01:19:30PM +0200, Solene Rapenne wrote:
> Hi
> 
> in anoncvs.html, if the user choose to use tgz sources instead of a
> checkout, the update examples won't work because no cvs server will be
> set without passing -d parameter to the cvs command.
> 
> Not sure about the wording, if a good english speaker can word it
> better, go on :)
> 
> Index: build/mirrors/anoncvs.html.head
> ===
> RCS file: /data/cvs/www/build/mirrors/anoncvs.html.head,v
> retrieving revision 1.77
> diff -u -p -r1.77 anoncvs.html.head
> --- build/mirrors/anoncvs.html.head   27 May 2019 22:55:27 -  1.77
> +++ build/mirrors/anoncvs.html.head   28 Jun 2019 11:16:24 -
> @@ -109,7 +109,8 @@ For more information on the flavors of O
>  Choose the Anonymous CVS server you are going to use from the
>  list of servers below, then you can start using cvs.
>  If you begin with src.tar.gz and sys.tar.gz as 
> mentioned
> -above, you can skip the initial checkout and proceed to updating.
> +above, you can skip the initial checkout and proceed to updating, 
> if you do
> +so, the first time you update you must specify a cvs server as in the 
> checkout example.
>  
>  
>  Warning:
> 

nand1 from irc told me it's already written later in the page.


If you are updating a source tree that you initially fetched
from a different server, or from a tar file, you must
add the -d [cvsroot] option to cvs.


not sure if this could be moved under "Updating an existin tree", this
would make more sense to tell this before people need it



anoncvs.html: tell reader to use -d if updating first time from tgz

2019-06-28 Thread Solene Rapenne
Hi

in anoncvs.html, if the user choose to use tgz sources instead of a
checkout, the update examples won't work because no cvs server will be
set without passing -d parameter to the cvs command.

Not sure about the wording, if a good english speaker can word it
better, go on :)

Index: build/mirrors/anoncvs.html.head
===
RCS file: /data/cvs/www/build/mirrors/anoncvs.html.head,v
retrieving revision 1.77
diff -u -p -r1.77 anoncvs.html.head
--- build/mirrors/anoncvs.html.head 27 May 2019 22:55:27 -  1.77
+++ build/mirrors/anoncvs.html.head 28 Jun 2019 11:16:24 -
@@ -109,7 +109,8 @@ For more information on the flavors of O
 Choose the Anonymous CVS server you are going to use from the
 list of servers below, then you can start using cvs.
 If you begin with src.tar.gz and sys.tar.gz as 
mentioned
-above, you can skip the initial checkout and proceed to updating.
+above, you can skip the initial checkout and proceed to updating, 
if you do
+so, the first time you update you must specify a cvs server as in the checkout 
example.
 
 
 Warning:



Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority

2019-06-03 Thread Solene Rapenne
On Sat, Jun 01, 2019 at 06:55:20PM -0300, Martin Pieuchot wrote:
> Diff below exists mainly for documentation and test purposes.  If
> you're not interested about how to break the scheduler internals in
> pieces, don't read further and go straight to testing!

I'm running it since a few hours.

- games/gzdoom feels smoother with this patch (stuttering was certainly
  related to audio)
- mpd playback doesn't seem interrupted under heavy load as it
  occasionnaly did

this may be coincidences or placebo effect.



Re: scheduler small changes

2019-05-16 Thread Solene Rapenne
On Wed, May 15, 2019 at 09:05:32AM -0500, Amit Kulkarni wrote:
> Hi,
> 
> This effort is heavily based on top of Gregor's and Michal's diffs. Tried to 
> incorporate feedback given by different people to them in 2011/2016. Split 
> the new code in a ifdef, so people can do a straight comparison, tried very 
> hard not to delete existing code, just shifted it around. Main motivation was 
> to find if it is possible to do incremental improvements in scheduler. After 
> sometime, have still not understood completely the load avg part, 
> p_priority/p_usrpri calculations, the cpuset code. Looked heavily at 
> Dragonfly (simpler than FreeBSD) and FreeBSD code. As a newcomer, OpenBSD 
> code is way easier to read. Thanks for the detailed explanations given to 
> Michal and also in later diffs posted to tech@, they helped a lot when trying 
> to understand the decisions made by other devs, the commit messages help a 
> little but the explanations help a lot more. This invites discussions and end 
> users learn a lot more in the process.
> 
> This diff survived multiple tens of kernel builds, a bsd.sp build, bsd.rd 
> build, a bsd.mp without these changes, userland/xenocara, a make regress a 
> few days ago all on 3 desktops on amd64. Ran under all possible scenarios 
> listed in previous sentence. No major invasive changes attempted, all tools 
> should work as is, if its broken, please let me know. This is faster than 
> current, but not sure by how much, placebo effect in play.
> 
> I think  there is a bug in resched_proc() which is fixed in mi_switch(), a 
> quick enhancement in cpu_switchto(), p_slptime, and precise round robin 
> interval for each proc unless preempted or it yields().
> 
> Tried to fiddle with different time slices other than hz/10, not sure if it 
> will work on other arches, but tried to stay within MI code, so it should 
> work. Other than counting no idea to verify a proc is actually switched away 
> after its rr interval is over. Just went by what is there in the existing 
> code. Tried giving higher slice like 200 ms, but didn't want to exceed the 
> rucheck() in kern_resource 1 sec limit.
> 
> Tried to do rudimentary work on affinity without having a affinity field in 
> struct proc or struct schedstate_percpu (like Dragonfly/FreeBSD does). 
> Observed the unbalance in runqs. Affinity works most of the time under light 
> load. There's a problem when I try to comment out sched_steal_proc(), in 
> kern_sched, that is the problem with this iteration of the diff.
> 
> Not sure if the reduction from 32 queues to a single TAILQ would be accepted, 
> but tried it anyway, it is definitely faster. This code tries to reduce the 
> complexity in deciding which queue to place the proc on. There is no current 
> support for a real-time queue or other types of scheduling classes, so IMHO 
> this is a simplification.
> 
> Tried to give detailed explanation of thinking. Sent the complete diff, but 
> will split diff, if parts of it are found to be valid.
> 
> In any case, a request to please accept a small change in top, to display 
> p_priority directly.
> 
> Thanks
> 
> 

Hi,

I tried your diff. It makes game games/gzdoom unplayable because of too
much stuttering. I did not feel any change apart for this case on my
intel i7 8550-U.



Re: tmux: cannot select pane after prefix-b q

2019-05-07 Thread Solene Rapenne
On Tue, May 07, 2019 at 11:55:51AM +0100, Nicholas Marriott wrote:
> Hi
> 
> You have the right idea general idea of the problem. display-panes
> blocks the queue until it is finished, so the key press isn't processed
> until then, which is too late.
> 
> But your change defeats the purpose, the idea is that new key presses
> should be queued after the commands inserted by previous key presses,
> not before them.
> 
> Identify mode (display-panes) can just be treated specially I think.
> 
> Please try the diff below.
> 
> Thanks!
> 
> 
> Index: server-client.c
> ===
> RCS file: /cvs/src/usr.bin/tmux/server-client.c,v
> retrieving revision 1.279
> diff -u -p -r1.279 server-client.c
> --- server-client.c   3 May 2019 20:44:24 -   1.279
> +++ server-client.c   7 May 2019 10:50:07 -
> @@ -986,7 +986,7 @@ server_client_assume_paste(struct sessio
>   * Handle data key input from client. This owns and can modify the key event 
> it
>   * is given and is responsible for freeing it.
>   */
> -enum cmd_retval
> +static enum cmd_retval
>  server_client_key_callback(struct cmdq_item *item, void *data)
>  {
>   struct client   *c = item->client;
> @@ -1204,6 +1204,44 @@ forward_key:
>  out:
>   free(event);
>   return (CMD_RETURN_NORMAL);
> +}
> +
> +/* Handle a key event. */
> +int
> +server_client_handle_key(struct client *c, struct key_event *event)
> +{
> + struct session  *s = c->session;
> + struct window   *w;
> + struct window_pane  *wp = NULL;
> + struct cmdq_item*item;
> +
> + /* Check the client is good to accept input. */
> + if (s == NULL || (c->flags & (CLIENT_DEAD|CLIENT_SUSPENDED)) != 0)
> + return (0);
> + w = s->curw->window;
> +
> + /*
> +  * Key presses in identify mode are a special case. The queue might be
> +  * blocked so they need to processed immediately rather than queued.
> +  */
> + if (c->flags & CLIENT_IDENTIFY) {
> + if (c->flags & CLIENT_READONLY)
> + return (0);
> + if (event->key >= '0' && event->key <= '9') {
> + window_unzoom(w);
> + wp = window_pane_at_index(w, event->key - '0');
> + }
> + server_client_clear_identify(c, wp);
> + return (0);
> + }
> +
> + /*
> +  * Add the key to the queue so it happens after any commands queued by
> +  * previous keys.
> +  */
> + item = cmdq_get_callback(server_client_key_callback, event);
> + cmdq_append(c, item);
> + return (1);
>  }
>  
>  /* Client functions that need to happen every loop. */
> Index: tmux.h
> ===
> RCS file: /cvs/src/usr.bin/tmux/tmux.h,v
> retrieving revision 1.888
> diff -u -p -r1.888 tmux.h
> --- tmux.h7 May 2019 10:25:15 -   1.888
> +++ tmux.h7 May 2019 10:50:09 -
> @@ -2012,7 +2012,7 @@ void server_client_set_identify(struct 
>  void  server_client_set_key_table(struct client *, const char *);
>  const char *server_client_get_key_table(struct client *);
>  int   server_client_check_nested(struct client *);
> -enum cmd_retval server_client_key_callback(struct cmdq_item *, void *);
> +int   server_client_handle_key(struct client *, struct key_event *);
>  struct client *server_client_create(int);
>  int   server_client_open(struct client *, char **);
>  void  server_client_unref(struct client *);
> Index: tty-keys.c
> ===
> RCS file: /cvs/src/usr.bin/tmux/tty-keys.c,v
> retrieving revision 1.112
> diff -u -p -r1.112 tty-keys.c
> --- tty-keys.c3 May 2019 18:00:19 -   1.112
> +++ tty-keys.c7 May 2019 10:50:09 -
> @@ -573,7 +573,6 @@ tty_keys_next(struct tty *tty)
>   cc_t bspace;
>   int  delay, expired = 0, n;
>   key_code key;
> - struct cmdq_item*item;
>   struct mouse_event   m = { 0 };
>   struct key_event*event;
>  
> @@ -732,9 +731,8 @@ complete_key:
>   event = xmalloc(sizeof *event);
>   event->key = key;
>   memcpy(>m, , sizeof event->m);
> -
> - item = cmdq_get_callback(server_client_key_callback, event);
> - cmdq_append(c, item);
> + if (!server_client_handle_key(c, event))
> + free(event);
>   }
>  
>   return (1);

Works for me!
ok solene@



Re: [PATCH] [www] faq/pf/pools.html - simplify loadbalancing section

2019-05-07 Thread Solene Rapenne
On Mon, May 06, 2019 at 10:47:39PM +0200, Thomas Huber wrote:
> Hi tech@,
> 
> after struggeling a while to setup a load-balancer, I´ve finaly managed it.
> At least not as I originally had in mind but it works.
> 
> During this kind of learning process I read the faq quite often and  over
> again.
> Now, after I dived into the rabit-hole of pf I think the  /faq/pf/pools.html
> site is little outdated and leads in the wrong directions when getting
> started.
> 
> My attached diff basically simplifies (from my point of view) the sections
> for
> loadbalancing outgoing traffic. I make havy use of interface modifiers -
> which
> are awesome btw - in the examples and removed some unnecessary rules in the
> pf.conf example at the bottom. For me it gets more clear to read an example
> with
> this modifiers than an random IP adress or named macros.
> Also I removed the special treatment of https connections. I´ld say that the
> majority of http connections are https and the there are less "broken"
> webapps
> out there that utilize the IP for a login-session. Actually I didn´t came
> across
> this problems in the wild. But I put a hint how to handle it a the bottom
> (stolen from the NAT section) but I would give this a priority anymore.
> 
> And and I added the 'least-state' method to introduction.
> 
> And it my first diff and my first contribution... hope its technicaly done
> right
> The diff is created wit git from the repo hosted on github.com:
> 
> diff --git faq/pf/pools.html faq/pf/pools.html
[...]
>  
> -lan_net = "192.168.0.0/24"
> -int_if  = "dc0"
> -ext_if1 = "fxp0"
> -ext_if2 = "fxp1"
> -ext_gw1 = "198.51.100.100"
> -ext_gw2 = "203.0.113.200"
> -
> -#  nat outgoing connections on each internet interface
> -match out on $ext_if1 from $lan_net nat-to ($ext_if1)
> -match out on $ext_if2 from $lan_net nat-to ($ext_if2)
> +match out on pppoe0 from em0:network nat-to (pppoe0:0)
> +match out on em2 from em0:network nat-to (em2:0)

Hi

I have no opinion about the technical changes, but you must keep the
macros instead of adding your interface names and addresses everywhere
in the examples instead of using the macros.



Re: httpd: avoid opening log files on "no log"

2019-05-02 Thread Solene Rapenne
On Thu, May 02, 2019 at 10:36:29PM +0200, Klemens Nanni wrote:
> httpd(8) still creates/opens log files with `no log' in httpd.conf(5): 
> 
>  [no] log [option]
>  Set the specified logging options.  Logging is enabled by default
>  using the standard access and error log files, but can be changed
>  per server or location.  Use the no log directive to disable
>  logging of any requests.  Multiple options may be specified
>  within curly braces.  Valid options are:
> 
> I want to quickly serve files with nothing but a config file:
> 
>   # cat /etc/httpd.conf
>   chroot "/foo"
>   server "default" {
>   listen on "*" port www
>   no log
>   root "/"
>   }
>   # httpd -d
>   doas (k...@eru.my.domain) password:
>   startup
>   failed to open /foo/logs/access.log: No such file or directory
>   parent: failed to open log file
>   logger exiting, pid 1150
>   server exiting, pid 42968
>   server exiting, pid 51707
> 
> Diff below fixes this.
> 
> Feedback? OK?

works for me on amd64
a big YES for this!!

it doesn't even require man page change.



Re: [PATCH] [www] cvsync.html - use class="cmdbox"

2019-04-18 Thread Solene Rapenne
On Thu, Apr 18, 2019 at 07:31:45AM +0200, Theo Buehler wrote:
> On Wed, Apr 17, 2019 at 11:41:18PM +0100, Raf Czlonka wrote:
> > On Wed, Apr 17, 2019 at 10:53:54PM BST, Theo Buehler wrote:
> > > On Wed, Apr 17, 2019 at 11:34:56PM +0200, Solene Rapenne wrote:
> > > > On Wed, Apr 17, 2019 at 09:55:26PM +0100, Raf Czlonka wrote:
> > > > > Hi all,
> > > > > 
> > > > > Similar to other pages[0][1], use class="cmdbox", add prompt character
> > > > > where appropriate, and remove superfluous indentation while there.
> > > > > 
> > > > > [0] https://www.openbsd.org/anoncvs.html
> > > > > [1] https://www.openbsd.org/ddb.html
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Raf
> > > > 
> > > > this looks much better with this
> > > > 
> > > > ok solene@
> > > > 
> > > 
> > > Please send a diff for www/build/mirrors/cvsync.html.* instead
> > 
> > After cvsync.html -> build/mirrors/cvsync.html.head change, the patch
> > applies just fine but, as requested, re-done for the
> > build/mirrors/cvsync.html.head below anyway.
> 
> Looks good.
> 
> ok tb
> 
> Solene, can you take care of committing this?
> 
> > 

done!



Re: [PATCH] [www] cvsync.html - use class="cmdbox"

2019-04-17 Thread Solene Rapenne
On Wed, Apr 17, 2019 at 09:55:26PM +0100, Raf Czlonka wrote:
> Hi all,
> 
> Similar to other pages[0][1], use class="cmdbox", add prompt character
> where appropriate, and remove superfluous indentation while there.
> 
> [0] https://www.openbsd.org/anoncvs.html
> [1] https://www.openbsd.org/ddb.html
> 
> Regards,
> 
> Raf

this looks much better with this

ok solene@



Re: dynamic RTS threshold in 11n mode

2019-02-27 Thread Solene Rapenne
On Tue, Feb 26, 2019 at 03:33:23PM +0100, Stefan Sperling wrote:
> On Tue, Feb 26, 2019 at 03:04:35PM +0100, Stefan Sperling wrote:
> > This diff makes the RTS threshold dynamic in 11n mode.
> > I am looking for tests with iwn(4), iwm(4), and athn(4) drivers.
> > 
> > When there's a lot of competition for air time, RTS can do more harm than
> > good because we end up causing more RTS/CTS frames on the air than actual
> > data frames. So a fixed RTS threshold really doesn't make a lot of sense.
> > 
> > This diff implements a heuristic for setting this threshold, based on 
> > section
> > 5.2 of the MiRa paper. It should improve Tx throughput on busy channels 
> > which
> > are especially common in the 2GHz band. In my testing it helps quite a bit.
> > 
> > This diff won't change the situation in 11a/b/g modes, and it might
> > not make a difference if there are 11a/b/g networks in range.
> 
> I realized the previous diff might take some time to raise throughput,
> so please try this one instead. The difference is just that the previous
> diff starts out with RTS threshold enabled, while this one starts out with
> RTS threshold disabled. This should make results look better for people
> doing quick tests rather than looking at long-term effects.  :-)
> 
> diff f727f040295e17987bfffe9c9952e45fd6ad7859 /usr/src
> blob - 7cf96bf074b3eef4d9fbb85c9253bac7e5550fd7
> file + sys/dev/ic/ar5008.c
> --- sys/dev/ic/ar5008.c
> +++ sys/dev/ic/ar5008.c
> @@ -1514,11 +1514,16 @@ ar5008_tx(struct athn_softc *sc, struct mbuf *m, struc
>   if (!IEEE80211_IS_MULTICAST(wh->i_addr1) &&
>   (wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK) ==
>   IEEE80211_FC0_TYPE_DATA) {
> + int rtsthres = ic->ic_rtsthreshold;
>   enum ieee80211_htprot htprot;
> - 
> +
> + if (ni->ni_flags & IEEE80211_NODE_HT)
> + rtsthres = ieee80211_mira_get_rts_threshold(>mn,
> + ic, ni, totlen);
>   htprot = (ic->ic_bss->ni_htop1 & IEEE80211_HTOP1_PROT_MASK);
> +
>   /* NB: Group frames are sent using CCK in 802.11b/g. */
> - if (totlen > ic->ic_rtsthreshold) {
> + if (totlen > rtsthres) {
>   ds->ds_ctl0 |= AR_TXC0_RTS_ENABLE;
>   } else if (((ic->ic_flags & IEEE80211_F_USEPROT) &&
>   athn_rates[ridx[0]].phy == IEEE80211_T_OFDM) ||
> blob - 7d7f0697a2b609f4a6e0fab09ede9a480baa7bd3
> file + sys/dev/pci/if_iwm.c
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -4216,7 +4216,7 @@ iwm_tx(struct iwm_softc *sc, struct mbuf *m, struct ie
>   bus_dma_segment_t *seg;
>   uint8_t tid, type;
>   int i, totlen, err, pad;
> - int hdrlen2;
> + int hdrlen2, rtsthres = ic->ic_rtsthreshold;
>  
>   wh = mtod(m, struct ieee80211_frame *);
>   hdrlen = ieee80211_get_hdrlen(wh);
> @@ -4292,9 +4292,13 @@ iwm_tx(struct iwm_softc *sc, struct mbuf *m, struct ie
>   flags |= IWM_TX_CMD_FLG_ACK;
>   }
>  
> + if (ni->ni_flags & IEEE80211_NODE_HT)
> + rtsthres = ieee80211_mira_get_rts_threshold(>in_mn, ic, ni,
> + totlen + IEEE80211_CRC_LEN);
> +
>   if (type == IEEE80211_FC0_TYPE_DATA &&
>   !IEEE80211_IS_MULTICAST(wh->i_addr1) &&
> - (totlen + IEEE80211_CRC_LEN > ic->ic_rtsthreshold ||
> + (totlen + IEEE80211_CRC_LEN > rtsthres ||
>   (ic->ic_flags & IEEE80211_F_USEPROT)))
>   flags |= IWM_TX_CMD_FLG_PROT_REQUIRE;
>  
> blob - 1dab60807c0709735799436e7a4a8e2d8d9f1ff9
> file + sys/dev/pci/if_iwn.c
> --- sys/dev/pci/if_iwn.c
> +++ sys/dev/pci/if_iwn.c
> @@ -3069,8 +3069,13 @@ iwn_tx(struct iwn_softc *sc, struct mbuf *m, struct ie
>  
>   /* Check if frame must be protected using RTS/CTS or CTS-to-self. */
>   if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) {
> + int rtsthres = ic->ic_rtsthreshold;
> + if (ni->ni_flags & IEEE80211_NODE_HT)
> + rtsthres = ieee80211_mira_get_rts_threshold(>mn,
> + ic, ni, totlen + IEEE80211_CRC_LEN);
> +
>   /* NB: Group frames are sent using CCK in 802.11b/g/n (2GHz). */
> - if (totlen + IEEE80211_CRC_LEN > ic->ic_rtsthreshold) {
> + if (totlen + IEEE80211_CRC_LEN > rtsthres) {
>   flags |= IWN_TX_NEED_RTS;
>   } else if ((ic->ic_flags & IEEE80211_F_USEPROT) &&
>   ridx >= IWN_RIDX_OFDM6) {
> blob - 4edd26a5fde82a9d9ddfd31e0bd075c0f59d2143
> file + sys/net80211/ieee80211_mira.c
> --- sys/net80211/ieee80211_mira.c
> +++ sys/net80211/ieee80211_mira.c
> @@ -85,6 +85,9 @@ int ieee80211_mira_valid_tx_mcs(struct ieee80211com *,
>  uint32_t ieee80211_mira_valid_rates(struct ieee80211com *,
>   struct ieee80211_node *);
>  uint32_t ieee80211_mira_mcs_below(struct ieee80211_mira_node *, int, int);
> +void ieee80211_mira_set_rts_threshold(struct ieee80211_mira_node *,
> +

Re: rework iwm(4) Tx rate selection

2019-02-20 Thread Solene Rapenne
On Wed, Feb 20, 2019 at 04:04:13PM +0100, Stefan Sperling wrote:
> iwm(4) has been using a firmware-based approach to retrying failed
> Tx attempts with successively lower data rates. This is suboptimal
> for our kernel's Tx rate selection algorithms, which are called
> MiRA (for 11n) and AMRR (for 11a/b/g).
> 
> I have observed a mismatch between the Tx rate reported by ifconfig iwm0
> and the Rx rate reported at the receiving end, and this diff fixes
> that issue for me.
> 
> Because iwm firmware retries on lower rates, our own rate selection
> is fooled into believing that high rates succeed when they in fact
> don't succeed. This causes more Tx retries than necessary, which
> results in lower throughput than we could achieve otherwise.
> 
> With the diff below we instead ask the firmware to always keep retrying
> at a constant Tx rate. This provides more accurate feedback to MiRa and
> AMRR, which are then able to select an initial Tx rate which is more
> likely to succeed.
> 
> However, there is another reason why we were using firmware-based retries.
> In 11n mode, net80211 only knows about rates which are based on OFDM.
> On 2GHz channels, the older CCK modulation provides a larger range and can
> thus make the difference between a bad network connection and no network
> connection at all. We were relying on the firmware to retry with CCK if
> OFDM frames failed so I had to implement a similar strategy in the driver.
> This is achived by falling back to CCK rates and running AMRR instead of
> MiRA if the lowest OFDM rate is failing, until AMRR decides to start using
> OFDM again, and then switch back to OFDM + MiRA. Getting the driver to switch
> back to OFDM once it is using CCK wasn't straightforward. I eventually found
> out that feeding only actual Tx failures to AMRR makes this work well.
> 
> I had to remove 11n support from AMRR which interfered with this fallback.
> This is overdue anyway since all drivers are using MiRa in 11n mode now.
> 
> When testing this, please compare throughput before and after this diff.
> I run tcpbench -s on a host behind the AP and start a tcpbench client on
> my iwm laptop. With this diff, and an 11ac AP on channel 149, tcpbench
> measures up to 26 Mpbs in my environment, with an average rate above 20 Mbps.
> 
> Also pay attention to changes in latency. To test this, on my iwm laptop
> I run ping and rain(6) through an SSH connection to a machine behind the AP.
> 
> Tested on a 7265 device only so far.
> 
> iwn(4) has the same problem and should also be fixed once this change
> has made it into the tree.
> 
> diff 3cfc9cae129c023be655a6d31902cddd094fdec4 /usr/src
> blob - 45e4446d79d2da0f847170e34b9a01e25b71ea62
> file + sys/dev/pci/if_iwm.c
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -217,6 +217,7 @@ const struct iwm_rate {
>  #define IWM_RIDX_MAX (nitems(iwm_rates)-1)
>  #define IWM_RIDX_IS_CCK(_i_) ((_i_) < IWM_RIDX_OFDM)
>  #define IWM_RIDX_IS_OFDM(_i_) ((_i_) >= IWM_RIDX_OFDM)
> +#define IWM_RVAL_IS_OFDM(_i_) ((_i_) >= 12 && (_i_) != 22)
>  
>  /* Convert an MCS index into an iwm_rates[] index. */
>  const int iwm_mcs2ridx[] = {
> @@ -368,6 +369,7 @@ void  iwm_rx_rx_phy_cmd(struct iwm_softc *, struct 
> iwm_
>  int  iwm_get_noise(const struct iwm_statistics_rx_non_phy *);
>  void iwm_rx_rx_mpdu(struct iwm_softc *, struct iwm_rx_packet *,
>   struct iwm_rx_data *);
> +void iwm_enable_ht_cck_fallback(struct iwm_softc *, struct iwm_node *);
>  void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *,
>   struct iwm_node *);
>  void iwm_rx_tx_cmd(struct iwm_softc *, struct iwm_rx_packet *,
> @@ -447,7 +449,6 @@ int   iwm_run(struct iwm_softc *);
>  int  iwm_run_stop(struct iwm_softc *);
>  struct ieee80211_node *iwm_node_alloc(struct ieee80211com *);
>  void iwm_calib_timeout(void *);
> -void iwm_setrates(struct iwm_node *);
>  int  iwm_media_change(struct ifnet *);
>  void iwm_newstate_task(void *);
>  int  iwm_newstate(struct ieee80211com *, enum ieee80211_state, int);
> @@ -3574,6 +3575,37 @@ iwm_rx_rx_mpdu(struct iwm_softc *sc, struct iwm_rx_pac
>  }
>  
>  void
> +iwm_enable_ht_cck_fallback(struct iwm_softc *sc, struct iwm_node *in)
> +{
> + struct ieee80211com *ic = >sc_ic;
> + struct ieee80211_node *ni = >in_ni;
> + struct ieee80211_rateset *rs = >ni_rates;
> + uint8_t rval = (rs->rs_rates[ni->ni_txrate] & IEEE80211_RATE_VAL);
> + uint8_t min_rval = ieee80211_min_basic_rate(ic);
> + int i;
> +
> + /* Are CCK frames forbidden in our BSS? */
> + if (IWM_RVAL_IS_OFDM(min_rval))
> + return;
> +
> + in->ht_force_cck = 1;
> +
> + ieee80211_mira_cancel_timeouts(>in_mn);
> + ieee80211_mira_node_init(>in_mn);
> + ieee80211_amrr_node_init(>sc_amrr, >in_amn);
> +
> + /* Choose initial CCK Tx rate. */
> + ni->ni_txrate = 0;
> + for (i = 0; i < rs->rs_nrates; i++) {
> + rval = (rs->rs_rates[i] & IEEE80211_RATE_VAL);
> + 

Re: CRYPTO CONTAINER

2019-02-11 Thread Solene Rapenne
On Mon, Feb 11, 2019 at 12:39:52PM +0100, Oleg Pahl wrote:
> Hi All,
> 
> Linux has one tool CRYPTSETUP.
> 
> With this tool I can prepare one container, then open it put
> some private data and close.
> 
> I know that our OpenBSD is also Crypto Paranoid OS.
> 
> Any idea how can I do the same procedure using OBSD default tools?
> 
> What is recommended work flow for it (to secure file/data) ?
> 
> P.S. I have full encrypted hard disk. But its not enough for me.
> 
> Many thx for strong support.
> 
> BR,
> 
> deface
> 
> 
Hi

You want to make a raw file using dd if=/dev/random of=container

then use vnconfig to make a disk device from that file, and then use
bioctl on it to create a CRYPTO raid. You will need to be root to
mount and umount it.



Re: undocumented nfs mount option "intr"

2018-12-21 Thread Solene Rapenne
Otto Moerbeek  wrote:
> On Thu, Dec 20, 2018 at 09:31:45AM +0100, Landry Breuil wrote:
> 
> > On Thu, Dec 20, 2018 at 09:26:33AM +0100, Solene Rapenne wrote:
> > > Hi
> > > 
> > > fstab(5) has an example for a nfs mountpoint using the "intr" option.
> > > 
> > > That option isn't documented in mount(8) or mount_nfs(8) and in fact, 
> > > I've not
> > > been able to find it anywhere. What is it doing?
> > 
> > I think it's the fstab shortcut for -i option in mount_nfs(8).
> > 
> 
> Looking at mntopt mopts[] in mount_nfs.c there are way more nfs specifc
> options that are only documented as getopt flags and not as -o flags. 
> 
>   -Otto

would it be accepted to add the "named options"  in mount_nfs(8), something
like this diff?

this is a quick draft

Index: mount_nfs.8
===
RCS file: /data/cvs/src/sbin/mount_nfs/mount_nfs.8,v
retrieving revision 1.39
diff -u -p -r1.39 mount_nfs.8
--- mount_nfs.8 6 Jun 2009 20:58:50 -   1.39
+++ mount_nfs.8 21 Dec 2018 17:24:53 -
@@ -163,6 +163,9 @@ Cache file attributes for at least
 .Ar num
 seconds.
 The default is 5 seconds.
+.It Cm intr
+This option is equivalent as using the flag
+.Fl i .
 .It Cm port Ns = Ns Ar portnumber
 Use the specified port number for NFS requests.
 The default is to query the portmapper for the NFS port.



undocumented nfs mount option "intr"

2018-12-20 Thread Solene Rapenne
Hi

fstab(5) has an example for a nfs mountpoint using the "intr" option.

That option isn't documented in mount(8) or mount_nfs(8) and in fact, I've not
been able to find it anywhere. What is it doing?



Re: make build as root fails when SUDO=doas

2018-12-11 Thread Solene Rapenne
Marc Espie  wrote:
> On Mon, Dec 10, 2018 at 01:33:49PM +0100, Solene Rapenne wrote:
> > hi
> > 
> > I have SUDO=doas in /etc/mk.conf for ports, this is preventing a `make 
> > build`
> > in /usr/src as root if /etc/doas.conf doesn't have a line "permit nopass 
> > root
> > as root". This fails when using "doas" in regress/usr/bin/ssh/
> > 
> > doas: Operation not permitted
> > *** Error 1 in regress/usr.bin/ssh (Makefile:212 'clean')
> > *** Error 1 in regress/usr.bin (:48 'cleandir')
> > *** Error 1 in regress (:48 'cleandir')
> > *** Error 1 in . (:48 'cleandir')
> > *** Error 1 in . (Makefile:86 'do-build')
> > *** Error 1 in /usr/src (Makefile:74 'build')
> > 
> > 
> > the issue comes from the 3rd line of that extract from Makefile:212
> > 
> > clean: ${CLEAN_SUBDIR}
> > rm -f ${CLEANFILES}
> > test -z "${SUDO}" || ${SUDO} rm -f ${SUDO_CLEAN}
> > rm -rf .putty
> > 
> > Not sure how to fix it. Maybe people shouldn't try to compile as root when
> > having SUDO=doas set and then, it's not an issue anymore?
> 
> There are several possibilities:
> - add a test similar to the one in src/Makefile, e.g., not run
> sudo if you're root already (relatively complicated for no obvious benefit)
> 
> - try to remove the files normally first
>  rm -f ${SUDO_CLEAN} || test -z "${SUDO}" || ${SUDO} rm -f 
> ${SUDO_CLEAN}
> 
> this should actually fix the issue.
> 
> Any other directory with that problem ?

that fix the issue and the build continues fine



make build as root fails when SUDO=doas

2018-12-10 Thread Solene Rapenne
hi

I have SUDO=doas in /etc/mk.conf for ports, this is preventing a `make build`
in /usr/src as root if /etc/doas.conf doesn't have a line "permit nopass root
as root". This fails when using "doas" in regress/usr/bin/ssh/

doas: Operation not permitted
*** Error 1 in regress/usr.bin/ssh (Makefile:212 'clean')
*** Error 1 in regress/usr.bin (:48 'cleandir')
*** Error 1 in regress (:48 'cleandir')
*** Error 1 in . (:48 'cleandir')
*** Error 1 in . (Makefile:86 'do-build')
*** Error 1 in /usr/src (Makefile:74 'build')


the issue comes from the 3rd line of that extract from Makefile:212

clean: ${CLEAN_SUBDIR}
rm -f ${CLEANFILES}
test -z "${SUDO}" || ${SUDO} rm -f ${SUDO_CLEAN}
rm -rf .putty

Not sure how to fix it. Maybe people shouldn't try to compile as root when
having SUDO=doas set and then, it's not an issue anymore?



[patch] sh.1 getopts inaccurate

2018-11-28 Thread Solene Rapenne
hi

I'm not familiar with getopts, first time I use it and the man page was
confusing. It says "a colon following an option indicates it may take an
argument".
I understand this as: if I use the string "s:" then I can use "-s" or "-s
something" as it **may** take an argument.

But if you use "s:", getopts reports an error "-s requires argument".

I propose to modify that sentence (not sure for the s in requires).

Index: sh.1
===
RCS file: /data/cvs/src/bin/ksh/sh.1,v
retrieving revision 1.149
diff -u -p -r1.149 sh.1
--- sh.128 Sep 2018 18:32:39 -  1.149
+++ sh.129 Nov 2018 06:44:50 -
@@ -495,7 +495,7 @@ to the index of the next variable to be 
 The string
 .Ar optstring
 contains a list of acceptable options;
-a colon following an option indicates it may take an argument.
+a colon following an option indicates it requires an argument.
 If an option not recognised by
 .Ar optstring
 is found,


Example to reproduce it:

#!/bin/sh
while getopts s:? args
do
case "$args" in
s) VALUE=${OPTARG} ;;
*) exit 0 ;;
esac
done
echo $VALUE


solene@t480 ~/notes/perso $ ./bug.sh -s
./bug.sh[9]: -`s' requires argument
solene@t480 ~/notes/perso $ ./bug.sh -s value
value



Re: faq16: clarify ownership management

2018-10-30 Thread Solene Rapenne
Klemens Nanni  wrote:
> "system" is ambigious, see `owner id` in vm.conf(5).
> 
> OK?
> 
> Index: faq16.html
> ===
> RCS file: /cvs/www/faq/faq16.html,v
> retrieving revision 1.2
> diff -u -p -r1.2 faq16.html
> --- faq16.html25 Oct 2018 15:43:31 -  1.2
> +++ faq16.html30 Oct 2018 09:59:28 -
> @@ -62,7 +62,7 @@ The following features are available:
>  
>serial console access to the virtual machines
>https://man.openbsd.org/tap;>tap(4) interfaces
> -  per-system user/group ownership
> +  per-VM user/group ownership
>privilege separation
>raw, qcow2 and qcow2-derived images
>dumping and restoring of guest system memory

seems fine to me. The original idea was to say it uses system user/group for VM
ownership, but in fact the current wording doesn't make sense.

ok solene@



/bin/df align inode output

2018-10-25 Thread Solene Rapenne
the following diff makes df printing aligned inode informations.

before patch

solene@t480 /usr/src/bin/df $ df -ik
Filesystem  1K-blocks  Used Avail Capacity iused   ifree  %iused  
Mounted on
/dev/sd2a 102887813786283957414%2227  153675 1%   /
/dev/sd2l   312080984  38691660 25778527613%  519480 19221190 3%   /home
/dev/sd2d 4125390  7718   3911404 0% 113  545549 0%   /tmp
/dev/sd2f 2061054786084   117191840%   14608  271214 5%   /usr
/dev/sd2g 102887819105278638420%9211  146691 6%   
/usr/X11R6
/dev/sd2h10318462   7347916   245462475%  171668 115351413%   
/usr/local
/dev/sd2k 6189758150842   5729430 3%2469  803033 0%   
/usr/obj
/dev/sd2j 2061054   111567884232457%  105820  18000237%   
/usr/src
/dev/sd2e20124398   1498948  17619232 8%   14606 2557808 1%   /var
/dev/sd2m   127381766  92115060  2889761876%  623330 15616668 4%   /data

with patch

solene@t480 /usr/src/bin/df $ ./df -ik
Filesystem  1K-blocks  Used Avail Capacity  iusedifree %iused  
Mounted on
/dev/sd2a 102887813786283957414% 2227   153675 1%   /
/dev/sd2l   312080984  38691660 25778527613%   519480 19221190 3%   
/home
/dev/sd2d 4125390  7718   3911404 0%  113   545549 0%   /tmp
/dev/sd2f 2061054786084   117191840%14608   271214 5%   /usr
/dev/sd2g 102887819105278638420% 9211   146691 6%   
/usr/X11R6
/dev/sd2h10318462   7347916   245462475%   171668  115351413%   
/usr/local
/dev/sd2k 6189758150842   5729430 3% 2469   803033 0%   
/usr/obj
/dev/sd2j 2061054   111567884232457%   105820   18000237%   
/usr/src
/dev/sd2e20124398   1498948  17619232 8%14606  2557808 1%   /var
/dev/sd2m   127381766  92115060  2889761876%   623330 15616668 4%   
/data


Index: df.c
===
RCS file: /cvs/src/bin/df/df.c,v
retrieving revision 1.59
diff -u -p -r1.59 df.c
--- df.c14 Aug 2016 21:07:40 -  1.59
+++ df.c25 Oct 2018 10:52:21 -
@@ -328,7 +328,7 @@ prtstat(struct statfs *sfsp, int maxwidt
if (iflag) {
inodes = sfsp->f_files;
used = inodes - sfsp->f_ffree;
-   (void)printf(" %7llu %7llu %5.0f%% ", used, sfsp->f_ffree,
+   (void)printf(" %8llu %8llu %5.0f%% ", used, sfsp->f_ffree,
   inodes == 0 ? 100.0 : (double)used / (double)inodes * 100.0);
} else
(void)printf("  ");
@@ -363,7 +363,7 @@ bsdprint(struct statfs *mntbuf, long mnt
 maxwidth, maxwidth, "Filesystem", header);
}
if (iflag)
-   (void)printf(" iused   ifree  %%iused");
+   (void)printf("  iusedifree %%iused");
(void)printf("  Mounted on\n");
 
 



Re: add explanations of vmctl send command in vmctl.8

2018-09-19 Thread Solene Rapenne
Solene Rapenne  wrote:
> This diff explains a little more about the send commands.
> send pauses the VM and send its memory + the start parameters.
> 

new diff with some changes, also thx bentley@ for telling me sentences should
start on a newline in mdoc.


Index: vmctl.8
===
RCS file: /cvs/src/usr.sbin/vmctl/vmctl.8,v
retrieving revision 1.47
diff -u -p -r1.47 vmctl.8
--- vmctl.8 11 Sep 2018 04:03:16 -  1.47
+++ vmctl.8 19 Sep 2018 10:20:06 -
@@ -90,6 +90,13 @@ Reset and terminate all VMs.
 Send a VM with the specified
 .Ar id
 to standard output and terminate it.
+The VM is paused while send is processing.
+Data sent to standard output contains the VM parameters and its memory,
+not the disk image.
+.Pp
+In order to move a VM from one host to another, disk files must be
+synced between the send and the receive processes and must be located
+under the same path.
 .It Cm show Op Ar id
 An alias for the
 .Cm status




add explanations of vmctl send command in vmctl.8

2018-09-19 Thread Solene Rapenne
This diff explains a little more about the send commands.
send pauses the VM and send its memory + the start parameters.

It's not obvious when you don't know vmctl.

Index: vmctl.8
===
RCS file: /cvs/src/usr.sbin/vmctl/vmctl.8,v
retrieving revision 1.47
diff -u -p -r1.47 vmctl.8
--- vmctl.8 11 Sep 2018 04:03:16 -  1.47
+++ vmctl.8 19 Sep 2018 08:14:11 -
@@ -89,7 +89,9 @@ Reset and terminate all VMs.
 .It Cm send Ar id
 Send a VM with the specified
 .Ar id
-to standard output and terminate it.
+to standard output and terminate it. The VM is paused while sending.
+Data sent to standard output contains the VM parameters and its memory,
+it does not contain the disk image.
 .It Cm show Op Ar id
 An alias for the
 .Cm status


This diff adds an explanation about moving a VM from one host to another.
Not sure if it should be in the man page.

Index: vmctl.8
===
RCS file: /cvs/src/usr.sbin/vmctl/vmctl.8,v
retrieving revision 1.47
diff -u -p -r1.47 vmctl.8
--- vmctl.8 11 Sep 2018 04:03:16 -  1.47
+++ vmctl.8 19 Sep 2018 08:17:16 -
@@ -89,7 +89,12 @@ Reset and terminate all VMs.
 .It Cm send Ar id
 Send a VM with the specified
 .Ar id
-to standard output and terminate it.
+to standard output and terminate it. The VM is paused while sending.
+Data sent to standard output contains the VM parameters and its memory,
+it does not contain the disk image.
+.Pp
+In order to move a VM from one host to another, disk files must be
+synced between the send and the receive processes and must have the same path.
 .It Cm show Op Ar id
 An alias for the
 .Cm status



Re: iostat: add "sp" column for CP_SPIN

2018-09-05 Thread Solene Rapenne
Solene Rapenne  wrote:
> Naoki Fukaumi  wrote:
> > hi tech@,
> > 
> > new cpu state, CP_SPIN, was added,
> >  https://marc.info/?l=openbsd-cvs=152630109526317=2
> > 
> > but there is no column for it in the header of iostat,
> > 
> > $ iostat
> >   tty  sd0 cpu
> >  tin tout  KB/t  t/s  MB/s  us ni sy in id
> >01 11.473  0.04   0  0  0  0  0100
> > 
> > this patch adds "sp" for CP_SPIN.
> > 
> > --
> > FUKAUMI Naoki
> > 
> > Index: usr.sbin/iostat/iostat.c
> > ===
> > RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> > retrieving revision 1.40
> > diff -u -p -u -p -r1.40 iostat.c
> > --- usr.sbin/iostat/iostat.c10 Feb 2018 19:49:50 -  1.40
> > +++ usr.sbin/iostat/iostat.c4 Sep 2018 04:19:14 -
> > @@ -229,7 +229,7 @@ header(void)
> > printf(" %16.16s ", cur.dk_name[i]);
> >  
> > if (ISSET(todo, SHOW_CPU))
> > -   printf("cpu");
> > +   printf("   cpu");
> > printf("\n");
> >  
> > /* Sub-Headers. */
> > @@ -254,7 +254,7 @@ header(void)
> > printf(" KB  xfr time ");
> >  
> > if (ISSET(todo, SHOW_CPU))
> > -   printf(" us ni sy in id");
> > +   printf(" us ni sy sp in id");
> > printf("\n");
> >  }
> >  
> 
> diff for iostat.8
> 
> not sure for the text though
> is spinning time, time spent in locks?
> 
> The text could be "CPU time waiting for locks" maybe
> 
> Index: iostat.8
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
> retrieving revision 1.26
> diff -u -p -r1.26 iostat.8
> --- iostat.817 Jan 2013 21:39:29 -  1.26
> +++ iostat.85 Sep 2018 08:29:36 -
> @@ -170,6 +170,8 @@ Seconds spent in disk activity
>  % of CPU time in user mode running niced processes
>  .It \
>  % of CPU time in system mode
> +.It \
> +% of CPU time spent spinning
>  .It \
>  % of CPU time processing interrupts
>  .It \

the right diff is this one

Index: iostat.8
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
retrieving revision 1.26
diff -u -p -r1.26 iostat.8
--- iostat.817 Jan 2013 21:39:29 -  1.26
+++ iostat.85 Sep 2018 08:29:36 -
@@ -170,6 +170,8 @@ Seconds spent in disk activity
 % of CPU time in user mode running niced processes
 .It \
 % of CPU time in system mode
+.It \
+% of CPU time spent spinning
 .It \
 % of CPU time processing interrupts
 .It \



Re: iostat: add "sp" column for CP_SPIN

2018-09-05 Thread Solene Rapenne
Naoki Fukaumi  wrote:
> hi tech@,
> 
> new cpu state, CP_SPIN, was added,
>  https://marc.info/?l=openbsd-cvs=152630109526317=2
> 
> but there is no column for it in the header of iostat,
> 
> $ iostat
>   tty  sd0 cpu
>  tin tout  KB/t  t/s  MB/s  us ni sy in id
>01 11.473  0.04   0  0  0  0  0100
> 
> this patch adds "sp" for CP_SPIN.
> 
> --
> FUKAUMI Naoki
> 
> Index: usr.sbin/iostat/iostat.c
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> retrieving revision 1.40
> diff -u -p -u -p -r1.40 iostat.c
> --- usr.sbin/iostat/iostat.c  10 Feb 2018 19:49:50 -  1.40
> +++ usr.sbin/iostat/iostat.c  4 Sep 2018 04:19:14 -
> @@ -229,7 +229,7 @@ header(void)
>   printf(" %16.16s ", cur.dk_name[i]);
>  
>   if (ISSET(todo, SHOW_CPU))
> - printf("cpu");
> + printf("   cpu");
>   printf("\n");
>  
>   /* Sub-Headers. */
> @@ -254,7 +254,7 @@ header(void)
>   printf(" KB  xfr time ");
>  
>   if (ISSET(todo, SHOW_CPU))
> - printf(" us ni sy in id");
> + printf(" us ni sy sp in id");
>   printf("\n");
>  }
>  

diff for iostat.8

not sure for the text though
is spinning time, time spent in locks?

The text could be "CPU time waiting for locks" maybe

Index: iostat.8
===
RCS file: /cvs/src/usr.sbin/iostat/iostat.8,v
retrieving revision 1.26
diff -u -p -r1.26 iostat.8
--- iostat.817 Jan 2013 21:39:29 -  1.26
+++ iostat.85 Sep 2018 08:29:36 -
@@ -170,6 +170,8 @@ Seconds spent in disk activity
 % of CPU time in user mode running niced processes
 .It \
 % of CPU time in system mode
+.It \
+% of CPU time spent spinning
 .It \
 % of CPU time processing interrupts
 .It \



Re: iostat: add "sp" column for CP_SPIN

2018-09-04 Thread Solene Rapenne
Stuart Henderson  wrote:
> On 2018/09/04 14:22, Solene Rapenne wrote:
> > About munin I'm trying to get a diff accepted upstream to fix cpu plugin and
> > talk about this with kirby@. The cpu plugin uses sysctl kern.cp_time. While
> > it's not related, I prefer to announce it here so people don't waste time
> > fixing it again by looking at the thread :)
> 
> Ah nice. When I worked on the initial munin port with mk I had intended
> to try to get upstream to take the openbsd plugins separately (rather
> than the current "copy similar OS and patch" approach), but I got fed up
> with rrdtool performance on OpenBSD and stopped using munin before I got
> round to it.. (and then I started using librenms and got fed up with
> rrdtool performance once again ;)

Using rrdcached the performances are really good. But that certainly depend on
the number of systems. It may not scale well with more than 50 systems, this is
also highly dependent on the number of plugins on each systems (as 1 value = 1
rrd file).



Re: iostat: add "sp" column for CP_SPIN

2018-09-04 Thread Solene Rapenne
Stuart Henderson  wrote:
> On 2018/09/04 12:07, Solene Rapenne wrote:
> > Naoki Fukaumi  wrote:
> > > hi tech@,
> > > 
> > > new cpu state, CP_SPIN, was added,
> > >  https://marc.info/?l=openbsd-cvs=152630109526317=2
> > > 
> > > but there is no column for it in the header of iostat,
> > > 
> > > $ iostat
> > >   tty  sd0 cpu
> > >  tin tout  KB/t  t/s  MB/s  us ni sy in id
> > >01 11.473  0.04   0  0  0  0  0100
> > > 
> > > this patch adds "sp" for CP_SPIN.
> > > 
> > > --
> > > FUKAUMI Naoki
> > > 
> > > Index: usr.sbin/iostat/iostat.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> > > retrieving revision 1.40
> > > diff -u -p -u -p -r1.40 iostat.c
> > > --- usr.sbin/iostat/iostat.c  10 Feb 2018 19:49:50 -  1.40
> > > +++ usr.sbin/iostat/iostat.c  4 Sep 2018 04:19:14 -
> > > @@ -229,7 +229,7 @@ header(void)
> > >   printf(" %16.16s ", cur.dk_name[i]);
> > >  
> > >   if (ISSET(todo, SHOW_CPU))
> > > - printf("cpu");
> > > + printf("   cpu");
> > >   printf("\n");
> > >  
> > >   /* Sub-Headers. */
> > > @@ -254,7 +254,7 @@ header(void)
> > >   printf(" KB  xfr time ");
> > >  
> > >   if (ISSET(todo, SHOW_CPU))
> > > - printf(" us ni sy in id");
> > > + printf(" us ni sy sp in id");
> > >   printf("\n");
> > >  }
> > >  
> > 
> > ok solene@ for this, but the man page should be updated too, it contains the
> > list of columns displayed.
> > 
> 
> Is iostat(8) something where people are likely to parse output?
> 
> (I first thought of sysutils/munin, iostat parsing is not enabled
> there, but there might be others).

About munin I'm trying to get a diff accepted upstream to fix cpu plugin and
talk about this with kirby@. The cpu plugin uses sysctl kern.cp_time. While
it's not related, I prefer to announce it here so people don't waste time
fixing it again by looking at the thread :)



Re: iostat: add "sp" column for CP_SPIN

2018-09-04 Thread Solene Rapenne
Naoki Fukaumi  wrote:
> hi tech@,
> 
> new cpu state, CP_SPIN, was added,
>  https://marc.info/?l=openbsd-cvs=152630109526317=2
> 
> but there is no column for it in the header of iostat,
> 
> $ iostat
>   tty  sd0 cpu
>  tin tout  KB/t  t/s  MB/s  us ni sy in id
>01 11.473  0.04   0  0  0  0  0100
> 
> this patch adds "sp" for CP_SPIN.
> 
> --
> FUKAUMI Naoki
> 
> Index: usr.sbin/iostat/iostat.c
> ===
> RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> retrieving revision 1.40
> diff -u -p -u -p -r1.40 iostat.c
> --- usr.sbin/iostat/iostat.c  10 Feb 2018 19:49:50 -  1.40
> +++ usr.sbin/iostat/iostat.c  4 Sep 2018 04:19:14 -
> @@ -229,7 +229,7 @@ header(void)
>   printf(" %16.16s ", cur.dk_name[i]);
>  
>   if (ISSET(todo, SHOW_CPU))
> - printf("cpu");
> + printf("   cpu");
>   printf("\n");
>  
>   /* Sub-Headers. */
> @@ -254,7 +254,7 @@ header(void)
>   printf(" KB  xfr time ");
>  
>   if (ISSET(todo, SHOW_CPU))
> - printf(" us ni sy in id");
> + printf(" us ni sy sp in id");
>   printf("\n");
>  }
>  

ok solene@ for this, but the man page should be updated too, it contains the
list of columns displayed.



Re: Status of openbsd/macppc port?

2018-08-17 Thread Solene Rapenne
Mark Cave-Ayland  wrote:
> On 17/08/18 13:55, Solene Rapenne wrote:
> 
> > I'm using the macppc port since 6.1 to -current and apart failing
> > harware I don't have any issue while playing Doom or rebuilind ports :)
> 
> Hmmm. 6.1 is the latest version that I can boot to userspace, even if it
> faults quickly after a few keypresses (QEMU is generally really strict
> on invalid memory accesses which is basically what I see, but once the
> access is tracked down it would be possible to fix it).
> 
> I'd be interested to know if you are able to at least boot a 6.3
> installation CDROM on the Mac Mini to the installer without hanging,
> which is probably the closest match to what I'm doing on real hardware.
> 
> 
> ATB,
> 
> Mark.

This is interesting as I never used a CDROM for installation, I don't
have a burner anymore and I'm not sure that the cdrom reader still work
but boot from PXE.



Re: Status of openbsd/macppc port?

2018-08-17 Thread Solene Rapenne
Mark Cave-Ayland  wrote:
> On 17/08/18 13:37, Solene Rapenne wrote:
> > Mark Cave-Ayland  wrote:
> >> Hi all,
> >>
> >> I was just wondering what is the current state of the openbsd/macppc
> >> port? As part of my recent work on qemu-system-ppc I now have a patch
> >> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu)
> >> machine but I'm seeing quite a bit of instability in OpenBSD compared to
> >> all my other test OSs.
> 
> > Hello
> > 
> > I can't help you much with your qemu issue but I can confirm you that
> > the OpenBSD macppc port works really well as I use 2 macppc devices (an
> > mac mini and a powerbook) often. The sad state is that less and less
> > ports are running on them.
> 
> Thanks for the response Solene. Can I ask which version of
> openbsd/macppc you are currently running?
> 
> 
> ATB,
> 
> Mark.

I'm using the macppc port since 6.1 to -current and apart failing
harware I don't have any issue while playing Doom or rebuilind ports :)



Re: Status of openbsd/macppc port?

2018-08-17 Thread Solene Rapenne
Mark Cave-Ayland  wrote:
> Hi all,
> 
> I was just wondering what is the current state of the openbsd/macppc
> port? As part of my recent work on qemu-system-ppc I now have a patch
> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu)
> machine but I'm seeing quite a bit of instability in OpenBSD compared to
> all my other test OSs.
> 
> For those that are interested I have included screenshots below:
> 
> OpenBSD 6.3
> - Hangs just after USB detection
> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.3.png
> 
> OpenBSD 6.2
> - Panics just after USB detection
> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.2.png
> 
> OpenBSD 6.1
> - Boots all the way to the installer but causes qemu-system-ppc to
> terminate fairly easily after pressing a few keys with "qemu: fatal:
> ERROR: instruction should not need address translation"
> - https://www.ilande.co.uk/tmp/qemu/openbsd-6.1.png
> 
> Note I also get a constant stream of messages on the console related to
> OpenPIC:
> 
> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f
> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f
> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f
> qemu-system-ppc: openpic_iack: bad raised IRQ 47 ctpr 8 ivpr 0x4047002f
> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c
> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c
> qemu-system-ppc: openpic_iack: bad raised IRQ 28 ctpr 8 ivpr 0x4045001c
> etc.
> 
> 
> Obviously I can't categorically state that QEMU's emulation is perfect,
> but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in
> my local tests which makes me suspect that OpenBSD is trying to do
> something different here.
> 
> 
> ATB,
> 
> Mark.

Hello

I can't help you much with your qemu issue but I can confirm you that
the OpenBSD macppc port works really well as I use 2 macppc devices (an
mac mini and a powerbook) often. The sad state is that less and less
ports are running on them.