Re: simple pledge for xeyes(1)

[Thomas Frohwein]

On Fri, Sep 08, 2023 at 08:55:10AM -0300, Lucas de Sena wrote:

[...]

> Quoting from `xenocara/app/xclock/xclock.c`:
> 
> > {
> > /* force reading of XErrorDB into memory to avoid adding "rpath" to 
> >pledge below */
> > char buf[1];
> >
> >(void)XGetErrorDatabaseText(XtDisplay(toplevel), "XProtoError", "0", "", 
> >  buf, 1);
> > }
> > if (pledge("stdio", NULL) == -1)
> >err(1, "pledge");

In xclock.c, this happens right before XtAppMainLoop, and it looks like
we could do the exact same thing for xeyes... Is this better?

Index: xeyes.c
===
RCS file: /cvs/xenocara/app/xeyes/xeyes.c,v
retrieving revision 1.5
diff -u -p -r1.5 xeyes.c
--- xeyes.c 29 Aug 2021 17:50:32 -  1.5
+++ xeyes.c 12 Sep 2023 01:34:03 -
@@ -32,6 +32,10 @@ from the X Consortium.
 # include "config.h"
 #endif
 
+#ifdef HAVE_PLEDGE
+# include 
+# include 
+#endif
 #include 
 #include 
 #include 
@@ -142,6 +146,19 @@ main(int argc, char **argv)
 XtRealizeWidget (toplevel);
 (void) XSetWMProtocols (XtDisplay(toplevel), XtWindow(toplevel),
 _delete_window, 1);
+
+#ifdef HAVE_PLEDGE
+{
+   /* force reading of XErrorDB into memory to avoid adding "rpath" to
+ * pledge below */
+char buf[1];
+
+(void)XGetErrorDatabaseText(XtDisplay(toplevel), "XProtoError", "0", 
"", buf, 1);
+}
+if (pledge("stdio", NULL) == -1)
+   err(1, "pledge");
+#endif
+
 XtAppMainLoop(app_context);
 
 return 0;

simple pledge for xeyes(1)

[Thomas Frohwein]

Very basic pledge(2) for the whole program. I didn't dive too much into
the details and maybe this can be refined some more. This is kind of a
product of me trying a tool I made `abstain` [1] for usefulness of
pledge(2) execpromises and it helped quickly find that xeyes(1) can run
with a very limited set of promises. I tested all permutations of
running xeyes(1) that are listed in the man page and none of them break
with this configuration.

ok to add?

[1] https://github.com/rfht/abstain

Index: xeyes.c
===
RCS file: /cvs/xenocara/app/xeyes/xeyes.c,v
retrieving revision 1.5
diff -u -p -r1.5 xeyes.c
--- xeyes.c 29 Aug 2021 17:50:32 -  1.5
+++ xeyes.c 8 Sep 2023 03:23:51 -
@@ -38,6 +38,8 @@ from the X Consortium.
 #include "Eyes.h"
 #include 
 #include 
+#include 
+#include 
 #include "eyes.bit"
 #include "eyesmask.bit"
 
@@ -111,6 +113,8 @@ main(int argc, char **argv)
 Arg arg[2];
 Cardinal i;
 
+if(pledge("stdio rpath unix prot_exec", NULL) == -1)
+   err(1, "pledge");
 XtSetLanguageProc(NULL, (XtLanguageProc) NULL, NULL);
 
 toplevel = XtAppInitialize(_context, "XEyes",

Re: PATCH: a bit of introspection in make

[Thomas Frohwein]

On Tue, Aug 08, 2023 at 01:02:53PM +0200, Marc Espie wrote:
> Actually, as far as bsd.port.mk, it doesn't need to
> move too much stuff around thanks to make's lazyness.
> 
> Note that having a list of defined MASTER_SITES variables simplifies
> the check.
> 
> I've also added a check for the right MASTER_SITES to be defined,
> since currently we do not error out until actually using it, which
> means that fiddling around with MASTER_SITES before committing may
> often go unnoticed.
> 
> (That final part is meant to go in sooner rather than later)

this simplifies things overall a little (because var.c does more of the
heavy lifting now). checked this on limited scale with
`make show=_ALL_MASTER_SITES` working as expected. The DISTFILE
assignment to non-`:[0-9]` MASTER_SITESx needs a little more work, to
fully function, but this is a step in that direction.

ok thfr@ for this.

> Index: bsd.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1592
> diff -u -p -r1.1592 bsd.port.mk
> --- bsd.port.mk   13 Jun 2023 10:28:40 -  1.1592
> +++ bsd.port.mk   8 Aug 2023 10:59:38 -
> @@ -118,9 +118,8 @@ _ALL_VARIABLES_PER_ARCH =
>  # consumers of (dump-vars) include sqlports generation and dpb
>  # dpb doesn't need everything, those are speed optimizations
>  .if ${DPB:L:Mfetch} || ${DPB:L:Mall}
> -_ALL_VARIABLES += DISTFILES PATCHFILES SUPDISTFILES DIST_SUBDIR MASTER_SITES 
> \
> - MASTER_SITES0 MASTER_SITES1 MASTER_SITES2 MASTER_SITES3 MASTER_SITES4 \
> - MASTER_SITES5 MASTER_SITES6 MASTER_SITES7 MASTER_SITES8 MASTER_SITES9 \
> +_ALL_VARIABLES += DISTFILES PATCHFILES SUPDISTFILES DIST_SUBDIR \
> + ${_ALL_MASTER_SITES} \
>   CHECKSUM_FILE FETCH_MANUALLY MISSING_FILES PERMIT_DISTFILES
>  .endif
>  .if ${DPB:L:Mtest} || ${DPB:L:Mall}
> @@ -1280,19 +1280,15 @@ MASTER_SITES ?=
>  # sites for distfiles, add them to MASTER_SITE_BACKUP
>  
>  _warn_checksum = :
> -.if !empty(MASTER_SITES:M*[^/])
> -_warn_checksum += ;echo ">>> MASTER_SITES not ending in /: 
> ${MASTER_SITES:M*[^/]}"
> -.endif
>  
> -.for _I in 0 1 2 3 4 5 6 7 8 9
> -.  if defined(MASTER_SITES${_I})
> -.if !empty(MASTER_SITES${_I}:M*[^/])
> -_warn_checksum += ;echo ">>> MASTER_SITES${_I} not ending in /: 
> ${MASTER_SITES${_I}:M*[^/]}"
> -.endif
> +_ALL_MASTER_SITES = ${.VARIABLES:MMASTER_SITES*:NMASTER_SITES_*}
> +
> +.for _S in ${_ALL_MASTER_SITES}
> +.  if !empty(${_S}:M*[^/])
> +_warn_checksum += ;echo ">>> ${_S} not ending in /: ${${_S}:M*[^/]}"
>  .  endif
>  .endfor
>  
> -
>  EXTRACT_SUFX ?= .tar.gz
>  
>  .if !empty(GH_COMMIT)
> @@ -1322,6 +1318,9 @@ _FILES=
>  .  if !empty($v)
>  .for e in ${$v}
>  .  for f m u in ${e:C/:[0-9]$//:C/^(.*)\{.*\}(.*)$/\1\2/} 
> MASTER_SITES${e:M*\:[0-9]:C/^.*:([0-9])$/\1/} 
> ${e:C/:[0-9]$//:C/^.*\{(.*)\}(.*)$/\1\2/}
> +.if !defined($m)
> +ERRORS += "Fatal: $m is not defined but referenced by $e in $v"
> +.endif
>  .if empty(_FILES:M$f)
>  _FILES += $f
>  .  if empty(DIST_SUBDIR)

Re: PATCH: a bit of introspection in make

[Thomas Frohwein]

On Tue, Aug 08, 2023 at 12:51:43PM +0200, Marc Espie wrote:
> Here's a revised diff (reordered plus actual use of the boolean)
> plus concrete example  use for bsd.port.mk (disregarding the fact
> _ALL_VARIABLES would have to move *after* all MASTER_SITES have been defined.

I tested this on a small scale and it looks okay to me. ok thfr@ for
var.c part; see other email for the bsd.port.mk part.

> Index: var.c
> ===
> RCS file: /cvs/src/usr.bin/make/var.c,v
> retrieving revision 1.104
> diff -u -p -r1.104 var.c
> --- var.c 9 Jun 2022 13:13:14 -   1.104
> +++ var.c 8 Aug 2023 10:48:05 -
> @@ -104,6 +104,8 @@ static char   varNoError[] = "";
>  bool errorIsOkay;
>  static bool  checkEnvFirst;  /* true if environment should be searched for
>* variables before the global context */
> + /* do we need to recompute varname_list */
> +static bool  varname_list_changed = true;
>  
>  void
>  Var_setCheckEnvFirst(bool yes)
> @@ -222,6 +224,7 @@ typedef struct Var_ {
>  #define VAR_FROM_ENV 8   /* Special source: environment */
>  #define VAR_SEEN_ENV 16  /* No need to go look up environment again */
>  #define VAR_IS_SHELL 32  /* Magic behavior */
> +#define VAR_IS_NAMES 1024/* Very expensive, only defined when needed */
>  /* XXX there are also some flag values which are part of the visible API
>   * and thus defined inside var.h, don't forget to look there if you want
>   * to define some new flags !
> @@ -231,6 +234,8 @@ typedef struct Var_ {
>   char name[1];   /* the variable's name */
>  }  Var;
>  
> +/* for GNU make compatibility */
> +#define VARNAME_LIST ".VARIABLES"
>  
>  static struct ohash_info var_info = {
>   offsetof(Var, name),
> @@ -245,10 +250,11 @@ static void fill_from_env(Var *);
>  static Var *create_var(const char *, const char *);
>  static void var_set_initial_value(Var *, const char *);
>  static void var_set_value(Var *, const char *);
> -#define var_get_value(v) ((v)->flags & VAR_EXEC_LATER ? \
> - var_exec_cmd(v) : \
> - Buf_Retrieve(&((v)->val)))
> -static char *var_exec_cmd(Var *);
> +static char *var_get_value(Var *);
> +static void var_exec_cmd(Var *);
> +static void varname_list_retrieve(Var *);
> +
> +
>  static void var_append_value(Var *, const char *);
>  static void poison_check(Var *);
>  static void var_set_append(const char *, const char *, const char *, int, 
> bool);
> @@ -423,6 +429,7 @@ var_set_initial_value(Var *v, const char
>   len = strlen(val);
>   Buf_Init(&(v->val), len+1);
>   Buf_AddChars(&(v->val), len, val);
> + varname_list_changed = true;
>  }
>  
>  /* Normal version of var_set_value(), to be called after variable is fully
> @@ -440,6 +447,16 @@ var_set_value(Var *v, const char *val)
>   }
>  }
>  
> +static char *
> +var_get_value(Var *v)
> +{
> + if (v->flags & VAR_IS_NAMES)
> + varname_list_retrieve(v);
> + else if (v->flags & VAR_EXEC_LATER)
> + var_exec_cmd(v);
> + return Buf_Retrieve(&(v->val));
> +}
> +
>  /* Add to a variable, insert a separating space if the variable was already
>   * defined.
>   */
> @@ -628,6 +645,7 @@ Var_Deletei(const char *name, const char
>  
>   ohash_remove(_variables, slot);
>   delete_var(v);
> + varname_list_changed = true;
>  }
>  
>  /* Set or add a global variable, either to VAR_CMD or VAR_GLOBAL.
> @@ -687,7 +705,7 @@ Var_Appendi_with_ctxt(const char *name, 
>   var_set_append(name, ename, val, ctxt, true);
>  }
>  
> -static char *
> +static void
>  var_exec_cmd(Var *v)
>  {
>   char *arg = Buf_Retrieve(&(v->val));
> @@ -699,7 +717,30 @@ var_exec_cmd(Var *v)
>   var_set_value(v, res1);
>   free(res1);
>   v->flags &= ~VAR_EXEC_LATER;
> - return Buf_Retrieve(&(v->val));
> +}
> +
> +static void
> +varname_list_retrieve(Var *v)
> +{
> + unsigned int i;
> + void *e;
> + bool first = true;
> +
> + if (!varname_list_changed)
> + return;
> + for (e = ohash_first(_variables, ); e != NULL;
> + e = ohash_next(_variables, )) {
> + Var *v2 = e;
> + if (v2->flags & VAR_DUMMY)
> + continue;
> +
> + if (first)
> + var_set_value(v, v2->name);
> + else
> + var_append_value(v, v2->name);
> + first = false;
> + }
> + varname_list_changed = false;
>  }
>  
>  /* XXX different semantics for Var_Valuei() and Var_Definedi():
> @@ -1339,6 +1380,19 @@ set_magic_shell_variable()
>   v->flags = VAR_IS_SHELL | VAR_SEEN_ENV;
>  }
>  
> +static void
> +set_magic_name_list_variable()
> +{
> + const char *name = VARNAME_LIST;
> + const char *ename = NULL;
> + uint32_t k;
> + Var *v;
> +
> + k = ohash_interval(name, );
> + v = find_global_var_without_env(name, 

distexpand for autogenerated upstream distfile resources (was: standardize and simplify GitHub submodule handling in ports?)

[Thomas Frohwein]

On Mon, Aug 07, 2023 at 09:17:05PM +0100, Stuart Henderson wrote:

[...]

> I think maybe I'd prefer to have some variable that could be used
> *instead* of the existing GH_* variables rather than in conjunction with
> them (so they can be used for all GH archive ports, rather than have
> them a special case for multi-distfile ports). If that's the standard
> way to do things we can have a sweep of the tree converting other
> ports (or at least the ones that don't use go.port.mk ;)
> 
> It would be kind-of helpful if it could support more than just github
> too (gitlab.com, sr.ht, ..). While that could be done with different
> variables (GH_xx, GL_xx, SRHT_xx etc) they're all a similar enough
> layout to each other that making the site part of the variable itself
> rather than the name would be simpler and easier to add more sites
> (plus it covers the case where you have some port using one file from
> github and one from gitlab, etc).
> 
> Playing with syntax ideas, maybe something like this would be easy to
> use for pprts not needing a rename -
> 
> SOMEVAR+= github vim vim refs/tags/v9.0.1677
> SOMEVAR+= github vim colorschemes 22986fa2a3d2f7229efd4019fcbca411caa6afbb
> 
> or with some auto-renaming (and specifying more of the path to avoid the
> extra GH_WRKSRC which I think might not be enough in some cases anyway -
> a port may have several distfiles that need to go into different base
> dirs) -
> 
> SOMEVAR+= github fortran-lang fpm refs/tags/v0.7.0
> OTHERVAR+=github toml-f toml-f e49f5523e4ee67db6628618864504448fb8c8939 
> vendor/toml-f
> OTHERVAR+=github urbanjost M_CLI2 
> 90a1a146e19c8ad37b0469b8cbd04bc28eb67a50 vendor/M_CLI2
> 
> (no idea what to use as real names instead of SOMEVAR/OTHERVAR though!)
> 
> How does that sort of thing seem to you? (i.e. using the same basic idea as
> you have for submodules, but making it the standard for all gh distfiles)?

I ran with your suggestion and came up with a solution that I've named
distexpand. The idea is to use templates for commonly used,
automatically generated and therefore predictably named, stored, and
packaged dist files. 2 variables take different arguments/parts that
are 'expanded' with the template to working MASTER_SITESn and
DISTFILES.

The current configuration in the ports Makefile is done like this,
after putting distexpand.port.mk into /usr/ports/infrastructure/mk/:

MODULES += distexpand
DISTEXPAND += template account1 project1 id1(commithash/tag)
DISTEXPANDX += template account2 project2 id2(commithash/tag) targetdir

'template' is currently set up for github, gitlab, and sourcehut. You
can use multiple DISTEXPAND and DISTEXPANDX as needed. This will _not_
use up more MASTER_SITESn, as long as the template stays the same.

Regarding the naming, I'm definitely open to discuss other suggestions.
DISTEXPAND is what I've been able to think of that most clearly conveys
the use of the fragments that are expanded to a full address for
fetching the distfile. DISTEXPANDX - the last 'X' is meant to stand for
'extended' as this is the version that relocates the extracted files to
a target dir. I'm slightly partial to consider naming the variables
instead 'DISTEXPAND4' and 'DISTEXPAND5' which would remind the porter
of the number of components for each version.

For the templating, I used %account, %project, %id, %subdir as the
placeholders. Those are substituted later with :S. I'm open to
suggestions if there may be a more established pattern for placeholders
in strings in Makefile context.

This can replace GH_{ACCOUNT,PROJECT,TAGNAME,COMMIT}. Tags are detected
as such, and in that case a DISTNAME will be set to $project-$tag if
not otherwise set. In other scenarios, a DISTNAME or PKGNAME may need
to be set.

A couple of other things to note compared to before:
- GH_WRKSRC is gone without replacement. Its usefulness was
  questionable.
- It includes logic that finds the first MASTER_SITESn that isn't
  otherwise used, and throws an ERROR if it overruns past
  MASTER_SITES9.
- Using tags is now by just proving '0.1.0' or 'v0.11.2' or other
  non-commithash string (the heuristic checks for length to determine
  if this is a tag or a commit hash).
- It currently uses 2 longer for-loops that are almost identical, but
  one for DISTEXPAND, and the other one for DISTEXPANDX. Given the
  limitations in Makefiles, I couldn't think of a way to reuse more
  code there.

This doesn't need to be in a module, but this way it's easy to plug in
and experiment with.

I'm attaching the distexpand.port.mk, as well as the patch for using it
with neovim as an example. I've tested this with about 3 dozen ports
that use combinations of mostly github sites, but also a gitlab and a
sourcehut dist source [1].

[1] https://thfr.info/tmp/distexpand-ports.txt
Index: Makefile
===
RCS file: /cvs/ports/editors/neovim/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- 

Re: PATCH: a bit of introspection in make

[Thomas Frohwein]

On Mon, Aug 07, 2023 at 04:42:54PM +0200, Marc Espie wrote:
> I think it could be occasionally useful to know which variables have
> been defined in make.
> 
> Incidentally, this DOES exist in GNU make, so I've reused the same name
> for basically the same functionality.
> 
> I haven't checked whether NetBSD/FreeBSD introduced something similar.
> 
> This is a fairly straightforward patch, introduces .VARIABLES corresponding
> to the full list of global variables (from the command line and the Makefile)
> that have been defined.
> 
> (^ says the guy who had to remember a few details from his own(!) var.c 
> implementation from a few years ago)
> 
> I just took var_get_value offline from the old macro, for readability,
> even though it's likely the compiler may still decide to inline it.
> 
> For efficiency, that list is only computed as needed, since it is
> somewhat long.
> 
> For debugging purposes, this can come in fairly handy, and I see at 
> least another application in ports.
> 
> Comments and nits welcome.
> 
> Note that the list is completely unsorted. This could be sorted through
> since we already have the code for dumping purposes, but it would be even
> more expensive (the order will be "random", as per the hash)

I can't judge all the implications of this, but can speak to that I
compiled it and that I get a very long list of variables with:

$ make show=.VARIABLES

> Index: var.c
> ===
> RCS file: /cvs/src/usr.bin/make/var.c,v
> retrieving revision 1.104
> diff -u -p -r1.104 var.c
> --- var.c 9 Jun 2022 13:13:14 -   1.104
> +++ var.c 7 Aug 2023 14:33:42 -
> @@ -104,6 +104,8 @@ static char   varNoError[] = "";
>  bool errorIsOkay;
>  static bool  checkEnvFirst;  /* true if environment should be searched for
>* variables before the global context */
> + /* do we need to recompute varname_list */
> +static bool  varname_list_changed = true;

I assume the comment /* do we need to recompute varname_list */ is not
meant to be contiguous with the 2 comment lines above (/* true if...
* variables before...). I suggest using whitespace (newline?) to make
that clearer.

I looked through the file and it seems that varname_list_changed is
never set to anything but true. Is there a bit missing, like down lower
in varname_list_retrieve()?

>  
>  void
>  Var_setCheckEnvFirst(bool yes)
> @@ -228,9 +230,12 @@ typedef struct Var_ {
>   */
>  #define POISONS (POISON_NORMAL | POISON_EMPTY | POISON_NOT_DEFINED)
>   /* Defined in var.h */
> +#define VAR_IS_NAMES 1024/* Very expensive, only defined when needed */
>   char name[1];   /* the variable's name */
>  }  Var;
>  
> +/* for GNU make compatibility */
> +#define VARNAME_LIST ".VARIABLES"
>  
>  static struct ohash_info var_info = {
>   offsetof(Var, name),
> @@ -245,10 +250,11 @@ static void fill_from_env(Var *);
>  static Var *create_var(const char *, const char *);
>  static void var_set_initial_value(Var *, const char *);
>  static void var_set_value(Var *, const char *);
> -#define var_get_value(v) ((v)->flags & VAR_EXEC_LATER ? \
> - var_exec_cmd(v) : \
> - Buf_Retrieve(&((v)->val)))
> -static char *var_exec_cmd(Var *);
> +static char *var_get_value(Var *);
> +static void var_exec_cmd(Var *);
> +static void varname_list_retrieve(Var *);
> +
> +
>  static void var_append_value(Var *, const char *);
>  static void poison_check(Var *);
>  static void var_set_append(const char *, const char *, const char *, int, 
> bool);
> @@ -423,6 +429,7 @@ var_set_initial_value(Var *v, const char
>   len = strlen(val);
>   Buf_Init(&(v->val), len+1);
>   Buf_AddChars(&(v->val), len, val);
> + varname_list_changed = true;
>  }
>  
>  /* Normal version of var_set_value(), to be called after variable is fully
> @@ -440,6 +447,16 @@ var_set_value(Var *v, const char *val)
>   }
>  }
>  
> +static char *
> +var_get_value(Var *v)
> +{
> + if (v->flags & VAR_IS_NAMES)
> + varname_list_retrieve(v);
> + else if (v->flags & VAR_EXEC_LATER)
> + var_exec_cmd(v);
> + return Buf_Retrieve(&(v->val));
> +}
> +
>  /* Add to a variable, insert a separating space if the variable was already
>   * defined.
>   */
> @@ -628,6 +645,7 @@ Var_Deletei(const char *name, const char
>  
>   ohash_remove(_variables, slot);
>   delete_var(v);
> + varname_list_changed = true;
>  }
>  
>  /* Set or add a global variable, either to VAR_CMD or VAR_GLOBAL.
> @@ -687,7 +705,7 @@ Var_Appendi_with_ctxt(const char *name, 
>   var_set_append(name, ename, val, ctxt, true);
>  }
>  
> -static char *
> +static void
>  var_exec_cmd(Var *v)
>  {
>   char *arg = Buf_Retrieve(&(v->val));
> @@ -699,7 +717,27 @@ var_exec_cmd(Var *v)
>   var_set_value(v, res1);
>   free(res1);
>   v->flags &= ~VAR_EXEC_LATER;
> - 

Re: standardize and simplify GitHub submodule handling in ports?

[Thomas Frohwein]

On Mon, Aug 07, 2023 at 06:59:15PM +0100, Stuart Henderson wrote:
[...]

> I haven't looked at other ports, but asterisk, vim and vmm-firmware do
> not use git submodules.

With vim, it's the way colorschemes are pulled in that *could* be
reworked using GH_SUBMODULES syntax. The old way continues to work, so
for any of the ports listed, there is no need to change anything.

Re: standardize and simplify GitHub submodule handling in ports?

[Thomas Frohwein]

On Sun, Aug 06, 2023 at 07:00:49PM +0200, Marc Espie wrote:

[...]

> > > I'm also wondering if keeping the main GH_* stuff in bsd.port.mk makes a 
> > > lot
> > > of sense, instead of grouping everything in github.port.mk
> > 
> > I'm for it, maybe as a second step after the module for just the
> > submodule handling is done because there would be a lot of ports churn
> > with moving the main GH_* stuff out of bsd.port.mk.
> 
> Probably not. We have a few "big" modules that don't depend on explicitly
> adding to modules, but on some variable triggering it (historic imake stuff
> or configure), having github.port.mk brought in from one of the GH_* variables
> (probably don't need to test them all) would be acceptable.

I'm sharing a new version after some testing, this time as a diff
because it turns out the handling of GH_*-related DISTNAME juggling
needs to happen before setting up the DISTFILES in the module. So this
diff now effectively moves all the GH_* bits from bsd.port.mk into
github.port.mk. The module is hooked up by defining GH_ACCOUNT or
GH_SUBMODULES.

Some rework was needed while testing to handle the different situations
for the target directory of the submodule. This ended up with a test if
the directory exists, and depending on the result either rmdir'ing the
(presumed empty) directory, or mkdir'ing the parent directory.

I tested this with the about 30 ports I could identify that use GitHub
submodules, by adjusting the Makefile to use GH_SUBMODULES. Here a few
points from what I've observed:

1. It's well possible to mix and match with the old way of defining
MASTER_SITES0 etc and DISTFILES=filename.ext:0. An example is
devel/fpm, where I kept this line:
MASTER_SITES0 =
https://github.com/fortran-lang/fpm/releases/download/v${V}/
while replacing MASTER_SITES{1,2} with the new GH_SUBMODULES way.

2. Setting GH_WRKSRC allows keeping the diff from the current Makefile
small, for example in devel/fpm:
+GH_WRKSRC =${WRKSRC}/vendor
and in editors/neovim:
+GH_WRKSRC =${STATIC_DEPS_WRKSRC}

3. It's possible to either use the commit hash or a tagname, like here
for lang/jruby:
+GH_SUBMODULES+=jnr jffi refs/tags/jffi-1.3.10 jffi

4. When using EXTRACT_ONLY, the name to use is more complicated now,
but can be identified with `$ make show=CHECKSUMFILES`. Here is what I
had to change it to with print/lilypond:
-EXTRACT_ONLY=  ${DISTNAME}.tar.gz urw-base35-fonts-${URW_V}.tar.gz
+EXTRACT_ONLY=  ${DISTNAME}.tar.gz \
+   
gh-submodules/ArtifexSoftware-urw-base35-fonts-${URW_V}.tar.gz

The full table of what I tested and the result up to if the port still
packages is here: https://thfr.info/tmp/github-submodule-ports.txt

I also tested megaglest as a port that uses GH_ACCOUNT etc without using any
submodules. Tested also with dxx-rebirth as an example of a port not
using any GH_*.

This draft hijacks MASTER_SITES8 for the modules purposes - not
MASTER_SITES9, as I noticed that is used by some modules like cargo and
go. I grep'd through the ports tree and couldn't identify any explicit
use of MASTER_SITES8.

I think this is ready for more general testing:
$ cd /usr/ports/infrastructure/mk; patch < /path/to/github-submodules.diff
Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1595
diff -u -p -r1.1595 bsd.port.mk
--- bsd.port.mk 8 Jul 2023 10:20:16 -   1.1595
+++ bsd.port.mk 7 Aug 2023 16:42:28 -
@@ -136,8 +136,8 @@ _ALL_VARIABLES += BROKEN COMES_WITH \
CONFIGURE_STYLE USE_LIBTOOL SEPARATE_BUILD \
SHARED_LIBS TARGETS PSEUDO_FLAVOR \
AUTOCONF_VERSION AUTOMAKE_VERSION CONFIGURE_ARGS \
-   GH_ACCOUNT GH_COMMIT GH_PROJECT GH_TAGNAME MAKEFILE_LIST \
-   USE_LLD USE_NOEXECONLY USE_WXNEEDED USE_NOBTCFI \
+   GH_ACCOUNT GH_COMMIT GH_PROJECT GH_SUBMODULES GH_TAGNAME \
+   MAKEFILE_LIST USE_LLD USE_NOEXECONLY USE_WXNEEDED USE_NOBTCFI \
COMPILER COMPILER_LANGS COMPILER_LINKS \
SUBST_VARS UPDATE_PLIST_ARGS \
PKGPATHS DEBUG_PACKAGES DEBUG_CONFIGURE_ARGS \
@@ -313,6 +313,10 @@ MODULES += ${_i}
 .  endif
 .endfor
 
+.if defined(GH_ACCOUNT) || defined(GH_SUBMODULES)
+MODULES += github
+.endif
+
 MODULES ?=
 .if !empty(MODULES) || !empty(COMPILER)
 _MODULES_DONE =
@@ -611,18 +615,6 @@ BUILD_DEPENDS += textproc/groff>=1.21
 _PKG_ARGS += -DUSE_GROFF=1
 .endif
 
-# github related variables
-GH_TAGNAME ?=
-GH_COMMIT ?=
-GH_ACCOUNT ?=
-GH_PROJECT ?=
-
-.if !empty(GH_PROJECT) && !empty(GH_TAGNAME)
-_GH_TAG_DIST = ${GH_TAGNAME:C/^(v|V|ver|[Rr]el|[Rr]elease)[-._]?([0-9])/\2/}
-DISTNAME ?=   ${GH_PROJECT}-${_GH_TAG_DIST}
-GH_DISTFILE = ${GH_PROJECT}-${_GH_TAG_DIST}${EXTRACT_SUFX}
-.endif
-
 PKGNAME ?= ${DISTNAME}
 FULLPKGNAME ?= ${PKGNAME}${FLAVOR_EXT}
 _MASTER ?=
@@ -871,11 +863,7 @@ _WRKDIRS = ${WRKOBJDIR_${PKGPATH}}/${_WR
 _WRKDIRS += ${WRKOBJDIR}/${_WRKDIR_STEM}
 _WRKDIRS += 

Re: standardize and simplify GitHub submodule handling in ports?

[Thomas Frohwein]

On Sat, Aug 05, 2023 at 11:27:24PM +0200, Marc Espie wrote:
> Some comments already. I haven't looked very closely.

> On Sat, Aug 05, 2023 at 03:12:18PM -0400, Thomas Frohwein wrote:
> > The current draft hijacks post-extract target, but it would be easy to
> > add this to _post-extract-finalize in bsd.port.mk similar to how the
> > post-extract commands from modules are handled, if this is of interest.
> 
> Please do that.

Thanks, I updated the draft. Realized that including it with
MODULES=github is easiest and then this can just use
MODGITHUB_post-extract and doesn't need any custom code in bsd.port.mk.
I had a thinko in post-extract (needs to be '||', not '&&') which is
also corrected.

> > # where submodule distfiles will be stored
> > GHSM_DIST_SUBDIR ?= gh-submodules
> 
> Please keep to the GH_* subspace.
> 
> Already, modules usually use MOD* variable names, but in the GH case, that
> would be a bit long.

I renamed GHSM_* to GH_*. I wouldn't mind using MODGH_* if that's an
option, but MODGITHUB_* would be pretty unwieldy, especially if we were
to make the existing GH_{ACCOUNT,PROJECT,TAGNAME} etc. part of this.

[...]

> Please do a single loop.  That's slightly more readable for me.

yes, done.

[...]

> Also please draft a diff for port-modules(5)

I'm attaching a diff for port-modules.5, along with the updated
github.port.mk.

> I'm also wondering if keeping the main GH_* stuff in bsd.port.mk makes a lot
> of sense, instead of grouping everything in github.port.mk

I'm for it, maybe as a second step after the module for just the
submodule handling is done because there would be a lot of ports churn
with moving the main GH_* stuff out of bsd.port.mk.
# List of static dependencies. The format is:
# account project tag_or_commit target_dir # license
# Example:
# GH_SUBMODULES +=  moonlight-stream moonlight-common-c \
#   c9426a6a71c4162e65dde8c0c71a25f1dbca46ba \
#   third-party/moonlight-common-c # GPL-v3.0+
GH_SUBMODULES ?=

# Master site for github tarballs
GH_MASTER_SITES ?=  https://github.com/

# where submodule distfiles will be stored
GH_DIST_SUBDIR ?=   gh-submodules

# where submodules will be extracted to
GH_WRKSRC ?=${WRKSRC}

# Grab submodules by default with MASTER_SITES8. (Don't use 9 to avoid collision
# with language-specific mechanisms, like devel/cargo or lang/go.)
GH_MASTER_SITESN ?= 8
MASTER_SITES${GH_MASTER_SITESN} ?=  ${GH_MASTER_SITES}

# Default GitHub distfile suffix
GH_SUFX ?=  .tar.gz

.if defined(DISTNAME)
DISTFILES ?= ${DISTNAME}${EXTRACT_SUFX}
.elif !empty(GH_ACCOUNT) && !empty(GH_PROJECT)
DISTFILES ?= ${GH_DISTFILE}
.endif

# post-extract target for moving the submodules to GH_WRKSRC
MODGITHUB_post-extract = \
@${ECHO_MSG} "moving GitHub submodules to ${GH_WRKSRC}" ; \
mkdir -p ${GH_WRKSRC} ;

.for _ghaccount _ghproject _ghtagcommit _targetdir in ${GH_SUBMODULES}
DISTFILES +=
${GH_DIST_SUBDIR}/{}${_ghaccount}/${_ghproject}/archive/${_ghtagcommit}${GH_SUFX}:${GH_MASTER_SITESN}
MODGITHUB_post-extract += \
test -d ${GH_WRKSRC}/${_targetdir} && \
rm -rf ${GH_WRKSRC}/${_targetdir} ; \
mv ${WRKDIR}/${_ghproject}-${_ghtagcommit} ${GH_WRKSRC}/${_targetdir} ;
.endfor
Index: port-modules.5
===
RCS file: /cvs/src/share/man/man5/port-modules.5,v
retrieving revision 1.264
diff -u -p -r1.264 port-modules.5
--- port-modules.5  9 May 2023 19:44:06 -   1.264
+++ port-modules.5  6 Aug 2023 01:48:22 -
@@ -744,6 +744,15 @@ contains c++, this module provides
 .Ev MODGCC4_CPPLIBDEP
 and
 .Ev MODGCC4_CPPWANTLIB .
+.It github
+Set
+.Li GH_SUBMODULES += w x y z
+for each GitHub submodule to be used in the port, specifying GitHub account, 
project, commit hash, and the target directory relative to
+.Ev GH_WRKSRC
+.Po
+defaults to
+.Ev WRKSRC
+.Pc .
 .It gnu
 This module is documented in the main
 .Xr bsd.port.mk 5

standardize and simplify GitHub submodule handling in ports?

[Thomas Frohwein]

bRocket
 
 # c++11
 COMPILER = base-clang ports-gcc
@@ -59,14 +52,8 @@ CONFIGURE_ARGS = -DCMAKE_INSTALL_PREFIX=
 NO_TEST =  Yes
 
 # remove bundled SDL
-post-extract:
+pre-configure:
rm -rf  ${WRKSRC}/lib/libsdl
-   rmdir   ${WRKSRC}/cmake/external/rpavlik-cmake-modules
-   ln -s   ${WRKDIR}/cmake-modules-${RPAVLIK_CMAKE_MOD} \
-   ${WRKSRC}/cmake/external/rpavlik-cmake-modules
-   rmdir   ${WRKSRC}/lib/libRocket
-   ln -s   ${WRKDIR}/libRocket-${LIBROCKET} \
-   ${WRKSRC}/lib/libRocket
 
 do-gen:
${SUBST_CMD} ${WRKSRC}/CMakeLists.txt
@@ -74,4 +61,5 @@ do-gen:
 post-install:
${SUBST_CMD} -c -m 755 ${FILESDIR}/fs2open ${PREFIX}/bin/fs2open
 
+.include "/usr/ports/mystuff/github.port.mk"
 .include 
Index: distinfo
===
RCS file: /cvs/ports/games/fs2open/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo22 Feb 2023 06:51:24 -  1.7
+++ distinfo5 Aug 2023 19:05:53 -
@@ -1,6 +1,6 @@
-SHA256 (fs2open-23.0.0/7cef9577d6fc35057ea57f46b4986a8a28aeff50.tar.gz) = 
e2kS2gGlbuyljBP4u7B7YSCvjwRyIxZ0fcgTKo7GWso=
-SHA256 (fs2open-23.0.0/ecd648a43aff8a9f3daf064d75ca5725237d5b38.tar.gz) = 
JcjDM2xciQqxzt/90Z17tubwjVy+HASUyiAs+5h/Tfc=
-SHA256 (fs2open-23.0.0/fs2open-23.0.0.tar.gz) = 
AZok/u73pI+BcPAznFUwEisya9iPtz6ddRW/6eU4Gqg=
-SIZE (fs2open-23.0.0/7cef9577d6fc35057ea57f46b4986a8a28aeff50.tar.gz) = 267464
-SIZE (fs2open-23.0.0/ecd648a43aff8a9f3daf064d75ca5725237d5b38.tar.gz) = 2417905
-SIZE (fs2open-23.0.0/fs2open-23.0.0.tar.gz) = 12210430
+SHA256 (fs2open-23.0.0.tar.gz) = AZok/u73pI+BcPAznFUwEisya9iPtz6ddRW/6eU4Gqg=
+SHA256 
(gh-submodules/asarium/cmake-modules/archive/7cef9577d6fc35057ea57f46b4986a8a28aeff50.tar.gz)
 = e2kS2gGlbuyljBP4u7B7YSCvjwRyIxZ0fcgTKo7GWso=
+SHA256 
(gh-submodules/asarium/libRocket/archive/ecd648a43aff8a9f3daf064d75ca5725237d5b38.tar.gz)
 = JcjDM2xciQqxzt/90Z17tubwjVy+HASUyiAs+5h/Tfc=
+SIZE (fs2open-23.0.0.tar.gz) = 12210430
+SIZE 
(gh-submodules/asarium/cmake-modules/archive/7cef9577d6fc35057ea57f46b4986a8a28aeff50.tar.gz)
 = 267464
+SIZE 
(gh-submodules/asarium/libRocket/archive/ecd648a43aff8a9f3daf064d75ca5725237d5b38.tar.gz)
 = 2417905
Index: Makefile
===
RCS file: /cvs/ports/games/fna/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile15 Jul 2023 23:24:35 -  1.17
+++ Makefile5 Aug 2023 19:10:00 -
@@ -7,21 +7,16 @@ HOMEPAGE =https://fna-xna.github.io/
 MAINTAINER =   Thomas Frohwein 
 
 # MS-PL, includes lzxdecoder (dual MSPL/LGPL) and Mono.Xna (MIT)
-# zlib (Vorbisfile-CS)
 PERMIT_PACKAGE =   Yes
 
-NETSTUB =  ebff244074bb3c28aeeb8cf7b383b5a029d7e28d
-VORBISFILE =   521c8532f03b3608a141b36d7c1343e816b46cb1
+GH_SUBMODULES+=FNA-XNA FNA.NetStub \
+   ebff244074bb3c28aeeb8cf7b383b5a029d7e28d \
+   ../FNA.NetStub  # Ms-PL
+GH_SUBMODULES+=flibitijibibo Vorbisfile-CS \
+   521c8532f03b3608a141b36d7c1343e816b46cb1 \
+   Vorbisfile-CS   # zlib
 
 MASTER_SITES = https://github.com/FNA-XNA/FNA/releases/download/${V}/
-MASTER_SITES0 =https://github.com/FNA-XNA/FNA.NetStub/archive/
-MASTER_SITES1 =https://github.com/flibitijibibo/Vorbisfile-CS/archive/
-
-DISTFILES =${DISTNAME}${EXTRACT_SUFX} \
-   ${NETSTUB}.tar.gz:0 \
-   ${VORBISFILE}.tar.gz:1
-
-DIST_SUBDIR =  fna-${V}
 
 EXTRACT_SUFX = .zip
 MODULES =  lang/mono
@@ -31,14 +26,9 @@ RUN_DEPENDS =audio/faudio \
 WRKDIST =  ${WRKDIR}/FNA
 NO_TEST =  Yes
 ALL_TARGET =   release
-SUBST_VARS +=  VORBISFILE
-
-post-extract:
-   ln -sf ${WRKDIR}/FNA.NetStub-${NETSTUB} ${WRKDIR}/FNA.NetStub
 
 do-gen:
cp ${FILESDIR}/FNA.Settings.props ${WRKSRC}/
-   ${SUBST_CMD} ${WRKSRC}/FNA.Settings.props
 
 # need to rm bin,obj before FNA.sln to build with FNA.Settings.props
 do-build:
@@ -63,4 +53,5 @@ do-install:
${PREFIX}/share/FNA/
${INSTALL_DATA} ${FILESDIR}/FNA.dll.config ${PREFIX}/share/FNA/
 
+.include "/usr/ports/mystuff/github.port.mk"
 .include 
Index: distinfo
===
RCS file: /cvs/ports/games/fna/distinfo,v
retrieving revision 1.15
diff -u -p -r1.15 distinfo
--- distinfo15 Jul 2023 23:24:35 -  1.15
+++ distinfo5 Aug 2023 19:10:00 -
@@ -1,6 +1,6 @@
-SHA256 (fna-23.07/521c8532f03b3608a141b36d7c1343e816b46cb1.tar.gz) = 
Cj2HaaOFBDsXtb/LPiedFdKzTb59XU9nMU7fuR9C6gc=
-SHA256 (fna-23.07/ebff244074bb3c28aeeb8cf7b383b5a029d7e28d.tar.gz) = 
34qgjqOOFTODn6zSKEs6Gt9jbdaJi9MR/7rw12tlXIA=
-SHA256 (fna-23.07/fna-2307.zip) = 6ZmbKqwz0X+RKXGvQTgqsZtLDtPvdcNURGoROTZye0s=
-SIZE (fna-23.07/521c8532f03b3608a141b36d7c1343e816b46cb1.tar.gz) = 5607
-SIZE (fna-23.07/ebff244074bb3c28aeeb8cf7b383b5a029d7e28d.tar.gz) 

Re: Diff for evaluation (WACOM tablet driver)

[Thomas Frohwein]

On Mon, Jul 03, 2023 at 11:22:45AM +0200, Marc Espie wrote:
> I hope Vladimir will find the time to complete this answer.
> 
> As far as Vlad's work goes, he did a presentation last week-end:
> https://www.lre.epita.fr/news_content/SS_summer_week_pres/Vladimir_Driver_OpenBSD.pptx
> 
> (sorry for the medium, fortunately we have libreoffice)
> 
> In the mean time, here is an updated diff.
> 
> I removed the Gaomon stuff, which if anything should be a different patch.
> 
> And I cleaned up the 20+ minor style violations I could find...
> (tabs instead of +4 spaces for continued lines, a few non-style compliant
> function declarations and/or code blocks, oh well)
> 
> plus an extra malloc.h that snuck in and is not at all needed.
> 
> And some typos in comments.
> And a C++ style comment. Oh well
> 
> I would really for some version of this to get in soonish.
> I can vouch that my tablet "works" with it (well, as good as it can work
> within the limitations of wscons not allowing it to be easily differentiated
> from the normal mouse, which is really a pain for programs like gimp)

Thanks, I built a kernel with this and no issues observed. I have a
Wacom Bamboo (CTH-470, product id 0x00de) that doesn't attach yet, but
this can be left for future work. I don't see anything glaring. hid.c
could probably use some refactoring at some point in the future because
at least 3 functions now share 99% identical code (hid_is_collection,
hid_get_collection_data, hid_get_id_of_collection).

I recommend getting an ok from someone with more track record with
dev/hid and/or dev/usb, but from my side this is ok thfr@.

> 
> dmesg for the tablet with the diff
> | uhidev1 at uhub1 port 4 configuration 1 interface 0 "Wacom Co.,Ltd. Intuos 
> S" rev 2.00/1.07 addr 6
> | uhidev1: iclass 3/0, 228 report ids
> | uwacom0 at uhidev1: 9 buttons, Z and W dir, tip, barrel
> | wsmouse5 at uwacom0 mux 0
> | uwacom1 at uhidev1: 9 buttons, Z and W dir, tip, barrel
> | wsmouse6 at uwacom1 mux 0
> | uwacom2 at uhidev1: 9 buttons, Z and W dir, tip, barrel
> | wsmouse7 at uwacom2 mux 0
> 
> as far as I understand, it appears as several mice because the stylus
> acts as totally different devices depending on the mode/end used
> (stuff that wscons completely hides from us).
> 
> Without the patch, that tablet appears as 42 different uhid devices (!)
> 
> The idea is that the parser for collections was really primitive. The
> debug stuff can show the details of various collection. There is the actual
> tablet mechanisms (which becomes one device) including scale, stylus, etc,
> and some other wacky collections (!): a debug collection that the wacom guys
> told us "oh some of our hw team needs that, but don't ever touch" and
> some other stuff we can't support yet (like battery support for some
> advanced models of stylus)
> 
> Index: dev/hid/hid.c
> ===
> RCS file: /cvs/src/sys/dev/hid/hid.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 hid.c
> --- dev/hid/hid.c 20 May 2022 05:03:45 -  1.5
> +++ dev/hid/hid.c 3 Jul 2023 09:04:50 -
> @@ -657,3 +657,51 @@ hid_is_collection(const void *desc, int 
>   hid_end_parse(hd);
>   return (0);
>  }
> +
> +struct hid_data *
> +hid_get_collection_data(const void *desc, int size, int32_t usage,
> +uint32_t collection)
> +{
> + struct hid_data *hd;
> + struct hid_item hi;
> +
> + hd = hid_start_parse(desc, size, hid_all);
> +
> + DPRINTF("%s: usage=0x%x\n", __func__, usage);
> + while (hid_get_item(hd, )) {
> + DPRINTF("%s: kind=%d id=%d usage=0x%x(0x%x)\n", __func__,
> + hi.kind, hi.report_ID, hi.usage, usage);
> + if (hi.kind == hid_collection &&
> + hi.collection == collection && hi.usage == usage){
> + DPRINTF("%s: found\n", __func__);
> + return hd;
> + }
> + }
> + DPRINTF("%s: not found\n", __func__);
> + hid_end_parse(hd);
> + return NULL;
> +}
> +
> +int
> +hid_get_id_of_collection(const void *desc, int size, int32_t usage,
> +uint32_t collection)
> +{
> + struct hid_data *hd;
> + struct hid_item hi;
> +
> + hd = hid_start_parse(desc, size, hid_all);
> +
> + DPRINTF("%s: id=%d usage=0x%x\n", __func__, id, usage);
> + while (hid_get_item(hd, )) {
> + DPRINTF("%s: kind=%d id=%d usage=0x%x(0x%x)\n", __func__,
> + hi.kind, hi.report_ID, hi.usage, usage);
> + if (hi.kind == hid_collection &&
> + hi.collection == collection && hi.usage == usage){
> + DPRINTF("%s: found\n", __func__);
> + return hi.report_ID;
> + }
> + }
> + DPRINTF("%s: not found\n", __func__);
> + hid_end_parse(hd);
> + return 0;
> +}
> Index: dev/hid/hid.h
> ===
> RCS file: 

Re: Intel Arc / DG2

[Thomas Frohwein]

On Mon, Feb 13, 2023 at 08:40:22PM +1100, Jonathan Gray wrote:
> On Sun, Feb 12, 2023 at 02:25:47PM -0500, Thomas Frohwein wrote:
> > On Tue, Feb 07, 2023 at 08:51:40PM +1100, Jonathan Gray wrote:
> > 
> > [...] 
> > > > ...
> > > > i915_resize_lmem_bar: stub
> > > > panic: kernel diagnostic assertion "pdev->pci->sc_bridgetag == NULL" 
> > > > failed: file "/usr/src/sys/dev/pci/drm/drm_linux.c", line 1277
> > > > ...
> > > 
> > > The vga arbiter bits need to change.  There isn't an easy way to get
> > > a softc to avoid having state shared by multiple inteldrm instances.
> > > 
> > > perhaps they can be skipped for the moment?
> > 
> > Thanks, this leads to a uvm_fault now:
> > 
> > xehp_load_dss_mask: stub
> > xehp_load_dss_mask: stub
> > intel_slicemask_from_xehp_dssmask: stub
> > intel_slicemask_from_xehp_dssmask: stub
> > i915_resize_lmem_bar: stub
> > uvm_fault(0x825181f8, 0x10, 0, 1) -> e
> > 
> > screen photo at https://thfr.info/tmp/DG2-error-20230212.jpg
> 
> unfortunately, that isn't much help
> 
> If you boot -d and do:
>   w db_panic 0
>   c
> you should be able to get a backtrace.

There is no difference if I do this, and still no backtrace.

> 
> > 
> > > 
> > > Index: sys/dev/pci/drm/drm_linux.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> > > retrieving revision 1.95
> > > diff -u -p -r1.95 drm_linux.c
> > > --- sys/dev/pci/drm/drm_linux.c   1 Jan 2023 01:34:34 -   1.95
> > > +++ sys/dev/pci/drm/drm_linux.c   7 Feb 2023 09:31:55 -
> > > @@ -1274,7 +1274,8 @@ vga_disable_bridge(struct pci_attach_arg
> > >  void
> > >  vga_get_uninterruptible(struct pci_dev *pdev, int rsrc)
> > >  {
> > > - KASSERT(pdev->pci->sc_bridgetag == NULL);
> > > + if (pdev->pci->sc_bridgetag != NULL)
> > > + return;
> > >   pci_enumerate_bus(pdev->pci, vga_disable_bridge, NULL);
> > >  }
> > >  
> > > @@ -1282,6 +1283,9 @@ void
> > >  vga_put(struct pci_dev *pdev, int rsrc)
> > >  {
> > >   pcireg_t bc;
> > > +
> > > + if (pdev->pci->sc_bridgetag != NULL)
> > > + return;
> > >  
> > >   if (!vga_bridge_disabled)
> > >   return;
> > > Index: sys/dev/pci/drm/i915/i915_pci.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_pci.c,v
> > > retrieving revision 1.15
> > > diff -u -p -r1.15 i915_pci.c
> > > --- sys/dev/pci/drm/i915/i915_pci.c   25 Jan 2023 01:51:59 -  
> > > 1.15
> > > +++ sys/dev/pci/drm/i915/i915_pci.c   3 Feb 2023 01:43:02 -
> > > @@ -1078,7 +1078,6 @@ static const struct intel_device_info dg
> > >   XE_LPD_FEATURES,
> > >   .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
> > >  BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
> > > - .require_force_probe = 1,
> > >  };
> > >  
> > >  static const struct intel_device_info ats_m_info = {
> > > Index: sys/dev/pci/drm/i915/intel_memory_region.h
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_memory_region.h,v
> > > retrieving revision 1.3
> > > diff -u -p -r1.3 intel_memory_region.h
> > > --- sys/dev/pci/drm/i915/intel_memory_region.h1 Jan 2023 01:34:55 
> > > -   1.3
> > > +++ sys/dev/pci/drm/i915/intel_memory_region.h4 Feb 2023 00:59:23 
> > > -
> > > @@ -70,8 +70,13 @@ struct intel_memory_region {
> > >  
> > >   const struct intel_memory_region_ops *ops;
> > >  
> > > -#ifdef notyet
> > > +#ifdef __linux__
> > >   struct io_mapping iomap;
> > > +#else
> > > + struct vm_page *pgs;
> > > + struct agp_map *agph;
> > > + bus_space_handle_t bsh;
> > > + bus_space_tag_t bst;
> > >  #endif
> > >   struct resource region;
> > >  
> > > Index: sys/dev/pci/drm/i915/gem/i915_gem_lmem.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/drm/i915/gem/i915_gem_lmem.c,v
> > > retrieving revision 1.4
> > > diff -u -p -r1.4 i915_ge

Re: Intel Arc / DG2

[Thomas Frohwein]

On Tue, Feb 07, 2023 at 08:51:40PM +1100, Jonathan Gray wrote:

[...] 
> > ...
> > i915_resize_lmem_bar: stub
> > panic: kernel diagnostic assertion "pdev->pci->sc_bridgetag == NULL" 
> > failed: file "/usr/src/sys/dev/pci/drm/drm_linux.c", line 1277
> > ...
> 
> The vga arbiter bits need to change.  There isn't an easy way to get
> a softc to avoid having state shared by multiple inteldrm instances.
> 
> perhaps they can be skipped for the moment?

Thanks, this leads to a uvm_fault now:

xehp_load_dss_mask: stub
xehp_load_dss_mask: stub
intel_slicemask_from_xehp_dssmask: stub
intel_slicemask_from_xehp_dssmask: stub
i915_resize_lmem_bar: stub
uvm_fault(0x825181f8, 0x10, 0, 1) -> e

screen photo at https://thfr.info/tmp/DG2-error-20230212.jpg

> 
> Index: sys/dev/pci/drm/drm_linux.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> retrieving revision 1.95
> diff -u -p -r1.95 drm_linux.c
> --- sys/dev/pci/drm/drm_linux.c   1 Jan 2023 01:34:34 -   1.95
> +++ sys/dev/pci/drm/drm_linux.c   7 Feb 2023 09:31:55 -
> @@ -1274,7 +1274,8 @@ vga_disable_bridge(struct pci_attach_arg
>  void
>  vga_get_uninterruptible(struct pci_dev *pdev, int rsrc)
>  {
> - KASSERT(pdev->pci->sc_bridgetag == NULL);
> + if (pdev->pci->sc_bridgetag != NULL)
> + return;
>   pci_enumerate_bus(pdev->pci, vga_disable_bridge, NULL);
>  }
>  
> @@ -1282,6 +1283,9 @@ void
>  vga_put(struct pci_dev *pdev, int rsrc)
>  {
>   pcireg_t bc;
> +
> + if (pdev->pci->sc_bridgetag != NULL)
> + return;
>  
>   if (!vga_bridge_disabled)
>   return;
> Index: sys/dev/pci/drm/i915/i915_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_pci.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 i915_pci.c
> --- sys/dev/pci/drm/i915/i915_pci.c   25 Jan 2023 01:51:59 -  1.15
> +++ sys/dev/pci/drm/i915/i915_pci.c   3 Feb 2023 01:43:02 -
> @@ -1078,7 +1078,6 @@ static const struct intel_device_info dg
>   XE_LPD_FEATURES,
>   .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
>  BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
> - .require_force_probe = 1,
>  };
>  
>  static const struct intel_device_info ats_m_info = {
> Index: sys/dev/pci/drm/i915/intel_memory_region.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_memory_region.h,v
> retrieving revision 1.3
> diff -u -p -r1.3 intel_memory_region.h
> --- sys/dev/pci/drm/i915/intel_memory_region.h1 Jan 2023 01:34:55 
> -   1.3
> +++ sys/dev/pci/drm/i915/intel_memory_region.h4 Feb 2023 00:59:23 
> -
> @@ -70,8 +70,13 @@ struct intel_memory_region {
>  
>   const struct intel_memory_region_ops *ops;
>  
> -#ifdef notyet
> +#ifdef __linux__
>   struct io_mapping iomap;
> +#else
> + struct vm_page *pgs;
> + struct agp_map *agph;
> + bus_space_handle_t bsh;
> + bus_space_tag_t bst;
>  #endif
>   struct resource region;
>  
> Index: sys/dev/pci/drm/i915/gem/i915_gem_lmem.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/gem/i915_gem_lmem.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 i915_gem_lmem.c
> --- sys/dev/pci/drm/i915/gem/i915_gem_lmem.c  1 Jan 2023 01:34:56 -   
> 1.4
> +++ sys/dev/pci/drm/i915/gem/i915_gem_lmem.c  4 Feb 2023 00:58:16 -
> @@ -15,9 +15,6 @@ i915_gem_object_lmem_io_map(struct drm_i
>   unsigned long n,
>   unsigned long size)
>  {
> - STUB();
> - return NULL;
> -#ifdef notyet
>   resource_size_t offset;
>  
>   GEM_BUG_ON(!i915_gem_object_is_contiguous(obj));
> @@ -25,7 +22,11 @@ i915_gem_object_lmem_io_map(struct drm_i
>   offset = i915_gem_object_get_dma_address(obj, n);
>   offset -= obj->mm.region->region.start;
>  
> +#ifdef __linux__
>   return io_mapping_map_wc(>mm.region->iomap, offset, size);
> +#else
> + agp_map_atomic(obj->mm.region->agph, offset, >mm.region->bsh);
> + return bus_space_vaddr(obj->mm.region->bst, obj->mm.region->bsh);
>  #endif
>  }
>  
> Index: sys/dev/pci/drm/i915/gem/i915_gem_stolen.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/gem/i915_gem_stolen.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 i915_gem_stolen.c
> --- sys/dev/pci/drm/i915/gem/i915_gem_stolen.c4 Feb 2023 00:07:11 
> -   1.5
> +++ sys/dev/pci/drm/i915/gem/i915_gem_stolen.c4 Feb 2023 01:23:34 
> -
> @@ -774,18 +774,44 @@ static int init_stolen_lmem(struct intel
>   if (err)
>   return err;
>  
> - STUB();
> - return -ENOSYS;
> -#ifdef notyet
> +#ifdef __linux__
>   if (mem->io_size && 

Re: Intel Arc / DG2

[Thomas Frohwein]

On Sat, Feb 04, 2023 at 01:24:42PM +1100, Jonathan Gray wrote:

[...]

> 
> I've committed the i915_gem_stolen_lmem_setup() portion.
> 
> Another diff
> 
> likely some more iomap use will show up later
> 
> i915_gem_object_read_from_page_iomap()
> i915_gem_object_map_pfn()
> i915_gem_object_map()
> i915_ttm_io_mem_pfn()

I applied this; now the kernel panics when trying to switch the video
mode. Excerpt (handtyped; screenshot at [1]):

...
i915_resize_lmem_bar: stub
panic: kernel diagnostic assertion "pdev->pci->sc_bridgetag == NULL" failed: 
file "/usr/src/sys/dev/pci/drm/drm_linux.c", line 1277
...

[1] https://thfr.info/tmp/DG2-error-20230203.jpg

> 
> Index: sys/dev/pci/drm/i915/i915_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_pci.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 i915_pci.c
> --- sys/dev/pci/drm/i915/i915_pci.c   25 Jan 2023 01:51:59 -  1.15
> +++ sys/dev/pci/drm/i915/i915_pci.c   3 Feb 2023 01:43:02 -
> @@ -1078,7 +1078,6 @@ static const struct intel_device_info dg
>   XE_LPD_FEATURES,
>   .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
>  BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
> - .require_force_probe = 1,
>  };
>  
>  static const struct intel_device_info ats_m_info = {
> Index: sys/dev/pci/drm/i915/intel_memory_region.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_memory_region.h,v
> retrieving revision 1.3
> diff -u -p -r1.3 intel_memory_region.h
> --- sys/dev/pci/drm/i915/intel_memory_region.h1 Jan 2023 01:34:55 
> -   1.3
> +++ sys/dev/pci/drm/i915/intel_memory_region.h4 Feb 2023 00:59:23 
> -
> @@ -70,8 +70,13 @@ struct intel_memory_region {
>  
>   const struct intel_memory_region_ops *ops;
>  
> -#ifdef notyet
> +#ifdef __linux__
>   struct io_mapping iomap;
> +#else
> + struct vm_page *pgs;
> + struct agp_map *agph;
> + bus_space_handle_t bsh;
> + bus_space_tag_t bst;
>  #endif
>   struct resource region;
>  
> Index: sys/dev/pci/drm/i915/gem/i915_gem_lmem.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/gem/i915_gem_lmem.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 i915_gem_lmem.c
> --- sys/dev/pci/drm/i915/gem/i915_gem_lmem.c  1 Jan 2023 01:34:56 -   
> 1.4
> +++ sys/dev/pci/drm/i915/gem/i915_gem_lmem.c  4 Feb 2023 00:58:16 -
> @@ -15,9 +15,6 @@ i915_gem_object_lmem_io_map(struct drm_i
>   unsigned long n,
>   unsigned long size)
>  {
> - STUB();
> - return NULL;
> -#ifdef notyet
>   resource_size_t offset;
>  
>   GEM_BUG_ON(!i915_gem_object_is_contiguous(obj));
> @@ -25,7 +22,11 @@ i915_gem_object_lmem_io_map(struct drm_i
>   offset = i915_gem_object_get_dma_address(obj, n);
>   offset -= obj->mm.region->region.start;
>  
> +#ifdef __linux__
>   return io_mapping_map_wc(>mm.region->iomap, offset, size);
> +#else
> + agp_map_atomic(obj->mm.region->agph, offset, >mm.region->bsh);
> + return bus_space_vaddr(obj->mm.region->bst, obj->mm.region->bsh);
>  #endif
>  }
>  
> Index: sys/dev/pci/drm/i915/gem/i915_gem_stolen.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/gem/i915_gem_stolen.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 i915_gem_stolen.c
> --- sys/dev/pci/drm/i915/gem/i915_gem_stolen.c4 Feb 2023 00:07:11 
> -   1.5
> +++ sys/dev/pci/drm/i915/gem/i915_gem_stolen.c4 Feb 2023 01:23:34 
> -
> @@ -774,18 +774,44 @@ static int init_stolen_lmem(struct intel
>   if (err)
>   return err;
>  
> - STUB();
> - return -ENOSYS;
> -#ifdef notyet
> +#ifdef __linux__
>   if (mem->io_size && !io_mapping_init_wc(>iomap,
>   mem->io_start,
>   mem->io_size)) {
>   err = -EIO;
>   goto err_cleanup;
>   }
> +#else
> + if (mem->io_size) {
> + int i;
> +
> + uvm_page_physload(atop(mem->io_start),
> + atop(mem->io_start + mem->io_size),
> + atop(mem->io_start),
> + atop(mem->io_start + mem->io_size),
> + PHYSLOAD_DEVICE);
> + /* array of vm pages that physload introduced. */
> + mem->pgs = PHYS_TO_VM_PAGE(mem->io_start);
> + KASSERT(mem->pgs != NULL);
> + /*
> +  * XXX mark all pages write combining so user mmaps get the
> +  * right bits. We really need a proper MI api for doing this,
> +  * but for now this allows us to use PAT where available.
> +  */
> + for (i = 0; i < atop(mem->io_size); i++)
> + 

Re: Intel Arc / DG2

[Thomas Frohwein]

On Fri, Feb 03, 2023 at 12:54:52PM +1100, Jonathan Gray wrote:
[...]
> > +xehp_load_dss_mask: stub
> > +xehp_load_dss_mask: stub
> > +intel_slicemask_from_xehp_dssmask: stub
> > +intel_slicemask_from_xehp_dssmask: stub
> > +i915_gem_stolen_lmem_setup: stub
> > +drm:pid0:intel_memory_regions_hw_probe *ERROR* [drm] *ERROR* Failed to 
> > setup region(-78) type=3
> > +Device initialization failed (-78)
> 
> thanks
> 
> xehp_load_dss_mask() needs:
> bitmap_from_arr32()
> 
> intel_slicemask_from_xehp_dssmask() needs:
> bitmap_intersects()
> bitmap_shift_right()
> 
> updated diff which unstubs i915_gem_stolen_lmem_setup()

thanks, this moves forward into the next stub:

-i915_gem_stolen_lmem_setup: stub
+init_stolen_lmem: stub

attaching the complete diff of the dmesg before and after your most recent diff.

> 
> Index: sys/dev/pci/drm/i915/i915_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_pci.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 i915_pci.c
> --- sys/dev/pci/drm/i915/i915_pci.c   25 Jan 2023 01:51:59 -  1.15
> +++ sys/dev/pci/drm/i915/i915_pci.c   3 Feb 2023 01:43:02 -
> @@ -1078,7 +1078,6 @@ static const struct intel_device_info dg
>   XE_LPD_FEATURES,
>   .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
>  BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
> - .require_force_probe = 1,
>  };
>  
>  static const struct intel_device_info ats_m_info = {
> Index: sys/dev/pci/drm/i915/gem/i915_gem_stolen.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/gem/i915_gem_stolen.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 i915_gem_stolen.c
> --- sys/dev/pci/drm/i915/gem/i915_gem_stolen.c1 Jan 2023 01:34:56 
> -   1.4
> +++ sys/dev/pci/drm/i915/gem/i915_gem_stolen.c3 Feb 2023 01:50:07 
> -
> @@ -813,26 +813,40 @@ struct intel_memory_region *
>  i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type,
>  u16 instance)
>  {
> - STUB();
> - return ERR_PTR(-ENOSYS);
> -#ifdef notyet
>   struct intel_uncore *uncore = >uncore;
>   struct pci_dev *pdev = i915->drm.pdev;
>   resource_size_t dsm_size, dsm_base, lmem_size;
>   struct intel_memory_region *mem;
>   resource_size_t io_start, io_size;
>   resource_size_t min_page_size;
> + pcireg_t mtype;
> + bus_addr_t lmem_start;
> + bus_size_t lmem_len;
> + int ret;
>  
>   if (WARN_ON_ONCE(instance))
>   return ERR_PTR(-ENODEV);
>  
> +#ifdef __linux__
>   if (!i915_pci_resource_valid(pdev, GEN12_LMEM_BAR))
>   return ERR_PTR(-ENXIO);
> +#else
> + mtype = pci_mapreg_type(i915->pc, i915->tag,
> + 0x10 + (4 * GEN12_LMEM_BAR));
> + ret = pci_mapreg_info(i915->pc, i915->tag,
> + 0x10 + (4 * GEN12_LMEM_BAR), mtype, _start, _len, NULL);
> + if (ret != 0)
> + return ERR_PTR(-ENXIO);
> +#endif
>  
>   /* Use DSM base address instead for stolen memory */
>   dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
>   if (IS_DG1(uncore->i915)) {
> +#ifdef __linux__
>   lmem_size = pci_resource_len(pdev, GEN12_LMEM_BAR);
> +#else
> + lmem_size = lmem_len;
> +#endif
>   if (WARN_ON(lmem_size < dsm_base))
>   return ERR_PTR(-ENODEV);
>   } else {
> @@ -844,6 +858,7 @@ i915_gem_stolen_lmem_setup(struct drm_i9
>   }
>  
>   dsm_size = lmem_size - dsm_base;
> +#ifdef __linux__
>   if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
>   io_start = 0;
>   io_size = 0;
> @@ -851,6 +866,15 @@ i915_gem_stolen_lmem_setup(struct drm_i9
>   io_start = pci_resource_start(pdev, GEN12_LMEM_BAR) + dsm_base;
>   io_size = dsm_size;
>   }
> +#else
> + if (lmem_len < lmem_size) {
> + io_start = 0;
> + io_size = 0;
> + } else {
> + io_start = lmem_start + dsm_base;
> + io_size = dsm_size;
> + }
> +#endif
>  
>   min_page_size = HAS_64K_PAGES(i915) ? I915_GTT_PAGE_SIZE_64K :
>   I915_GTT_PAGE_SIZE_4K;
> @@ -878,7 +902,6 @@ i915_gem_stolen_lmem_setup(struct drm_i9
>   mem->private = true;
>  
>   return mem;
> -#endif
>  }
>  
>  struct intel_memory_region*
--- dmesg-20230202-postDG2patch.txt Thu Feb  2 15:49:28 2023
+++ dmesg-20230202-post-secondDG2diff.txt   Fri Feb  3 14:23:46 2023
@@ -1,7 +1,7 @@
-OpenBSD 7.2-current (GENERIC.MP) #0: Thu Feb  2 15:38:20 EST 2023
+OpenBSD 7.2-current (GENERIC.MP) #1: Fri Feb  3 14:18:10 EST 2023
 t...@thfr-hdd320g.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 34226315264 (32640MB)
-avail mem = 33169633280 (31633MB)
+avail mem = 33169629184 (31633MB)
 random: good seed from bootblocks
 mpath0 at 

Re: Intel Arc / DG2

[Thomas Frohwein]

On Mon, Jan 30, 2023 at 09:32:08PM +1100, Jonathan Gray wrote:
> The current generation of Intel Arc branded graphics cards are part of
> what drm and Mesa refers to as DG2.
> 
> https://ark.intel.com/content/www/us/en/ark/products/codename/226095/products-formerly-alchemist.html
> 
> In -current we now have Mesa 22.3 which has support for DG2.
> There is support in inteldrm but DG2 is not matched by default.
> 
> The following diff matches it by default, as do versions of linux
> after 6.1.
> d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> 
> I'm not sure if all the intel discrete gpu paths work.  I don't have
> hardware to test.

I have tested this with Intel Arc A750. It recognizes the device, but
fails to initialize it. diff of dmesg before vs. after your diff attached.

> 
> Index: sys/dev/pci/drm/i915/i915_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_pci.c,v
> retrieving revision 1.15
> diff -u -p -U5 -r1.15 i915_pci.c
> --- sys/dev/pci/drm/i915/i915_pci.c   25 Jan 2023 01:51:59 -  1.15
> +++ sys/dev/pci/drm/i915/i915_pci.c   29 Jan 2023 23:15:09 -
> @@ -1076,11 +1076,10 @@ static const struct intel_device_info xe
>  static const struct intel_device_info dg2_info = {
>   DG2_FEATURES,
>   XE_LPD_FEATURES,
>   .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
>  BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
> - .require_force_probe = 1,
>  };
>  
>  static const struct intel_device_info ats_m_info = {
>   DG2_FEATURES,
>   NO_DISPLAY,
> 
--- dmesg-20230202-preDG2patch.txt  Thu Feb  2 15:50:30 2023
+++ dmesg-20230202-postDG2patch.txt Thu Feb  2 15:50:46 2023
@@ -1,7 +1,7 @@
-OpenBSD 7.2-current (GENERIC.MP) #1015: Thu Feb  2 06:25:57 MST 2023
-dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
+OpenBSD 7.2-current (GENERIC.MP) #0: Thu Feb  2 15:38:20 EST 2023
+t...@thfr-hdd320g.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 34226315264 (32640MB)
-avail mem = 33169625088 (31633MB)
+avail mem = 33169633280 (31633MB)
 random: good seed from bootblocks
 mpath0 at root
 scsibus0 at mpath0: 256 targets
@@ -29,22 +29,22 @@
 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-10700 CPU @ 2.90GHz, 4589.31 MHz, 06-a5-05
+cpu1: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.32 MHz, 06-a5-05
 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,SMX,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,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
 cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
4-way L2 cache, 16MB 64b/line 16-way L3 cache
 cpu1: smt 0, core 1, package 0
 cpu2 at mainbus0: apid 4 (application processor)
-cpu2: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.31 MHz, 06-a5-05
+cpu2: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.33 MHz, 06-a5-05
 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,SMX,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,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
 cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
4-way L2 cache, 16MB 64b/line 16-way L3 cache
 cpu2: smt 0, core 2, package 0
 cpu3 at mainbus0: apid 6 (application processor)
-cpu3: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.31 MHz, 06-a5-05
+cpu3: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.32 MHz, 06-a5-05
 cpu3: 
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,SMX,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,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
 cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 
4-way L2 cache, 16MB 64b/line 16-way L3 cache
 cpu3: smt 0, core 3, package 0
 cpu4 at mainbus0: apid 8 

Re: Wireless Media Modes Identified in Man Page for ifmedia(4)

[Thomas Dunn]

Wireless Media Modes Identified in Man Page for ifmedia(4)

[Thomas Dunn]

Hello,

The man page for ifmedia(4) identifies the media modes defined for IEEE802.11 
Wireless LAN under the heading "MEDIA TYPES AND OPTIONS FOR IEEE802.11 WIRELESS 
LAN".

For better consistency, I suggest changing "TYPES" to "MODES" in this heading.

Also, back on Oct. 3, 2018, the Wi-Fi Alliance announced "Wi-Fi 4" and "Wi-Fi 
5" as alternative nomenclatures for IEEE802.11 ”11n” and ”11ac” respectively.  
This alternative generation-based naming convention subsequently gained 
relatively widespread use and popularity.  For better clarity, I suggest 
updating the descriptions of the corresponding media modes by replacing "[11n]" 
and "[11ac]" with "[11n (Wi-Fi 4)]" and "[11ac (Wi-Fi 5)]" respectively.

Thank you for your assistance.

Respectfully,

Thomas Dunn

Sent from my iPad

Re: reorder_kernel: suport ro /usr like library_aslr does

[Thomas de Grivel]

Hello,

I use read only /usr also,
I don't like a script changing mount options without a warning.
If it's read-only reorder_kernel should fail.
I just put a symlink from /usr/share/relink to /var/relink and everything
works fine...
With mount_mfs we could have a temporary directory but where has gone mfs ?

Le mar. 8 nov. 2022 à 12:11, Klemens Nanni  a écrit :

> More read-only filesystems mean less fsck during boot after crashes.
> Especially on crappy machines like the Pinebook Poop, I keep /usr
> read-only and run with this diff so I still get a relinked kernel.
>
> rc's reorder_libs() already does the same remount dance, but for
> multiple directories/filesystems.
>
> My diff works as expected with read-write and read-only /usr as well as
> interrupting /usr/libexec/reorder_kernel runs with ^C, i.e. a failed run
> will correctly mount /usr ro again if it was ro before the run.
>
> Feedback? OK?
>
> Index: reorder_kernel.sh
> ===
> RCS file: /cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
> retrieving revision 1.13
> diff -u -p -r1.13 reorder_kernel.sh
> --- reorder_kernel.sh   7 Nov 2022 15:55:56 -   1.13
> +++ reorder_kernel.sh   8 Nov 2022 11:02:42 -
> @@ -27,13 +27,32 @@ LOGFILE=$KERNEL_DIR/$KERNEL/relink.log
>  PROGNAME=${0##*/}
>  SHA256=/var/db/kernel.SHA256
>
> -# Silently skip if on a NFS mounted filesystem.
> -df -t nonfs $KERNEL_DIR >/dev/null 2>&1
> +# Silently skip if on NFS, otherwise remount the filesystem read-write.
> +DEV=$(df -t nonfs $KERNEL_DIR 2>/dev/null | awk 'NR == 2 { print $1 }')
> +MP=$(mount -t ffs | grep ^$DEV)
> +RO=false
> +if [[ $MP == *read-only* ]]; then
> +   MP=${MP%% *}
> +   mount -u -w $MP
> +   RO=true
> +fi
> +
> +restore_mount() {
> +   if $RO; then
> +   # Close the logfile to unbusy $MP by switching back to
> console.
> +   exec 1>/dev/console
> +   exec 2>&1
> +   mount -u -r $MP
> +   fi
> +}
>
>  # Install trap handlers to inform about success or failure via syslog.
>  ERRMSG='failed'
> -trap 'trap - EXIT; logger -st $PROGNAME "$ERRMSG" >/dev/console 2>&1' ERR
> -trap 'logger -t $PROGNAME "kernel relinking done"' EXIT
> +trap 'trap - EXIT
> +   logger -st $PROGNAME "$ERRMSG" 2>/dev/console
> +   restore_mount' ERR
> +trap 'logger -t $PROGNAME "kernel relinking done"
> +   restore_mount' EXIT
>
>  # Create kernel compile dir and redirect stdout/stderr to a logfile.
>  mkdir -m 700 -p $KERNEL_DIR/$KERNEL
>
>

-- 
 Thomas de Grivel
 https://www.kmx.io

Re: azalia module fix for 7.2-stable and some Intel 500 HDA Chips

[Thomas Frohwein]

On Fri, Nov 04, 2022 at 04:22:55PM +0100, Mark Kettenis wrote:
> > Date: Sat, 5 Nov 2022 02:06:11 +1100
> > From: Jonathan Gray 
> > 
> > On Fri, Nov 04, 2022 at 09:10:52AM -0500, John Browning wrote:
> > > Hi,
> > > I noticed I did not have sound on my new thinkpad which has a newer
> > > Intel 500 HDA chipset.
> > > 
> > > bsd$ doas pcidump -vvv 0:31:3
> > >  0:31:3: Intel 500 Series HD Audio
> > > 0x: Vendor ID: 8086, Product ID: 43c8
> > > 0x0004: Command: 0006, Status: 0010
> > > 0x0008:Class: 04 Multimedia, Subclass: 01 Audio,
> > > Interface: 00, Revision: 11
> > > 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
> > > Cache Line Size: 00
> > > 0x0010: BAR mem 64bit addr: 0x00603d1c/0x4000
> > > 0x0018: BAR empty ()
> > > 0x001c: BAR empty ()
> > > 0x0020: BAR mem 64bit addr: 0x00603d00/0x0010
> > > 0x0028: Cardbus CIS: 
> > > 0x002c: Subsystem Vendor ID: 17aa Product ID: 22e4
> > > 0x0030: Expansion ROM Base Address: 
> > > 0x0038: 
> > > 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
> > > 0x0050: Capability 0x01: Power Management
> > > State: D0
> > > 0x0080: Capability 0x09: Vendor Specific
> > > 0x0060: Capability 0x05: Message Signalled Interrupts (MSI)
> > > Enabled: yes
> > > 
> > > 
> > > Looking at src/sys/dev/pci/azalia.c I noticed making the change in the
> > > below diff corrects the issue with a new kernel build.  It seems the
> > > pci subsystem match inclusion may not be needed, but hopefully someone
> > > smarter than I can figure that out (or help me figure that out).
> > 
> > When the subclass is not hd-audio, we match with azalia_pci_devices[].
> > 
> > Which model thinkpad is this?
> 
> ok kettenis@

ok thfr@

(came up with the same diff based on a preceding discussion with John
Browning on #openbsd-gaming IRC on libera.chat; also with input from
brynet@)

> > Index: sys/dev/pci/azalia.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/azalia.c,v
> > retrieving revision 1.280
> > diff -u -p -r1.280 azalia.c
> > --- sys/dev/pci/azalia.c26 Oct 2022 20:19:08 -  1.280
> > +++ sys/dev/pci/azalia.c4 Nov 2022 14:10:59 -
> > @@ -488,6 +488,7 @@ const struct pci_matchid azalia_pci_devi
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_CAVS },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_LP_HDA },
> > +   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_HDA },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_LP_HDA },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_600SERIES_LP_HDA },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_HDA },
> > 
> > 
> 

Re: Consistency and cleanup in /share/misc/airport

[Thomas Wager]

On Sun, 2022-07-31 at 13:11 +0200, Thomas Wager wrote:
> On Sat, 2022-07-30 at 22:44 +0100, Stuart Henderson wrote:
> > Due to the rule for this file mentioned in the header, I think you'll
> > need to find a developer who has been to the added airports that have
> > replaced the metro areas, i.e. KCK MFW QDV QSF, either that or just
> > remove them.
> 
> You are right. I'll give it a try:
> Anyone been on one of those?
> 
> KCK:Kirensk, Russia
> MFW:Magaruque Island, Mozambique
> QDV:Comte. Rolim Adolfo Amaro, Jundiai, Brazil
> QSF:8 May 1945, Setif, Algeria
> 
> If no response I'll submit a revised patch with them removed next
> weekend.
> 

Since nobody was on the airports above, here is a revised patch to remove them:


Index: share/misc/airport
===
RCS file: /cvs/src/share/misc/airport,v
retrieving revision 1.84
diff -u -p -u -p -r1.84 airport
--- share/misc/airport  31 Jul 2022 06:12:20 -  1.84
+++ share/misc/airport  6 Aug 2022 20:36:58 -
@@ -470,7 +470,7 @@ DUD:Momona, Dunedin, New Zealand
 DUJ:Jefferson County, Du Bois, Pennsylvania, USA
 DUQ:Quamichan Lake, Duncan / Quam, British Columbia, Canada
 DUR:King Shaka International, Durban, South Africa
-DUS:Dusseldorf, Germany
+DUS:Duesseldorf, Germany
 DUT:Dutch Harbor, Alaska, USA
 DVO:Mati, Davao, Philippines
 DXB:Dubai, UAE
@@ -656,7 +656,7 @@ HAD:Halmstad, Halland, Sweden
 HAH:Moroni (Hahaya), Comoros
 HAJ:Langenhagen, Hanover, Germany
 HAK:Haikou, China
-HAM:Fuhlsbuettel Hamburg, Germany
+HAM:Hamburg, Germany
 HAN:Noibai, Hanoi, Vietnam
 HAU:Karmoy, Haugesund, Norway
 HAV:Jose Marti, Havana, Cuba
@@ -849,7 +849,6 @@ KBP:Kyiv Borispil International, Kyiv, U
 KBR:Sultan Ismail Petra, Kota Bharu, Malaysia
 KCG:Fisheries, Chignik, Alaska, USA
 KCH:Kuching, Sarawak, Malaysia
-KCK:All Airports around Kansas City, Kansas, USA
 KCL:Lagoon, Chignik, Alaska, USA
 KDG:Kardjali, Bulgaria
 KEF:Keflavik, Reykjavik, Iceland
@@ -940,7 +939,7 @@ LAW:Municipal, Lawton, Oklahoma, USA
 LAX:Los Angeles International, California, USA
 LBA:Leeds/Bradford, England, United Kingdom
 LBB:Lubbock, Texas, USA
-LBC:Lubeck, Germany
+LBC:Luebeck, Germany
 LBE:Westmoreland County, Latrobe, Pennsylvania, USA
 LBF:North Platte Lee Bird Field, Nebraska, USA
 LBL:Glenn L Martin Terminal, Liberal, Kansas, USA
@@ -1089,7 +1088,6 @@ MEY:Meghauli, Nepal
 MFE:Mc Allen/Mission, Texas, USA
 MFM:Macau
 MFN:Milford Sound, New Zealand
-MFW:All Airports around Miami, Ft. Lauderdale and West Palm Beach, Florida, USA
 MGA:Managua, Nicaragua
 MGM:Montgomery Municipal/Dannelly Field, Alabama, USA
 MGQ:Mogadishu, Somalia
@@ -1413,11 +1411,9 @@ PZE:Penzance, England, United Kingdom
 PZO:Puerto Ordaz, Venezuela
 PZU:Port Sudan, Sudan
 QBF:Vail/Eagle, Colorado, USA
-QDV:All Airports around Denver, Colorado, USA
 QKB:Breckenridge, Colorado, USA
 QLA:All Airports around Los Angeles, California, USA
 QRO:Queretaro, Mexico
-QSF:All Airports around San Francisco, California, USA
 QSY:Sydney, New South Wales, Australia
 RAB:Lakunai, Rabaul, Papua New Guinea
 RAJ:Rajkot, India
@@ -1673,7 +1669,6 @@ TGM:Tirgu Mures, Romania
 TGU:Toncontin, Tegucigalpa, Honduras
 TGZ:Llano San Juan, Tuxtla Gutierrez, Chiapas, Mexico
 THE:Teresina, Piaui, Brazil
-THF:Tempelhof, Berlin, Germany
 THN:Trollhattan, Sweden
 THR:Mehrabad, Tehran, Iran
 THU:Thule, Pituffik, Greenland
@@ -1852,7 +1847,7 @@ XBR:Brockville, Ontario, Canada
 XCM:Chatham, Ontario, Canada
 XDM:Drummondville, Quebec, Canada
 XFD:Stratford, Ontario, Canada
-XFW:Flugplatz Hamburg-Finkenwerder, Hamburg, Germany
+XFW:Hamburg-Finkenwerder, Hamburg, Germany
 XIY:Xianyang, Xi An, China
 XLV:Niagara Falls, Ontario, Canada
 XLZ:Truro, Nova Scotia, Canada

Re: Consistency and cleanup in /share/misc/airport

[Thomas Wager]

On Sat, 2022-07-30 at 22:44 +0100, Stuart Henderson wrote:
> Due to the rule for this file mentioned in the header, I think you'll
> need to find a developer who has been to the added airports that have
> replaced the metro areas, i.e. KCK MFW QDV QSF, either that or just
> remove them.

You are right. I'll give it a try:
Anyone been on one of those?

KCK:Kirensk, Russia
MFW:Magaruque Island, Mozambique
QDV:Comte. Rolim Adolfo Amaro, Jundiai, Brazil
QSF:8 May 1945, Setif, Algeria

If no response I'll submit a revised patch with them removed next
weekend.

Re: Consistency and cleanup in /share/misc/airport

[Thomas Wager]

On Fri, 2022-07-29 at 16:09 -0400, Daniel Dickman wrote:

> I think they’re called Metropolitan Area Airport Codes:
> 
> I found a list here:
> Metropolitan Area Airport Codes
> wikitravel.org
> 
> 
> Do you want to submit a revised patch with all the corrections?
> 

Thanks, I double checked with wikitravel.org as well. Here is a patch that
also addresses changes to the Metropolitan Area Airport Codes. Some of them
do not appear on wikitravel.org and not on iata.org but they are not reused
either, so I left them as they are (NRW, QLA). For QSF I found its homepage
here:
http://www.egsa-constantine.dz/index.php/aeroports/aeroport-de-setif-08-mai-1945
Its official name is "8 Mai 1945".
Here is a revised patch:


Index: airport
===
RCS file: /cvs/src/share/misc/airport,v
retrieving revision 1.83
diff -u -p -u -p -r1.83 airport
--- airport 26 Jun 2022 06:28:51 -  1.83
+++ airport 30 Jul 2022 20:23:57 -
@@ -470,7 +470,7 @@ DUD:Momona, Dunedin, New Zealand
 DUJ:Jefferson County, Du Bois, Pennsylvania, USA
 DUQ:Quamichan Lake, Duncan / Quam, British Columbia, Canada
 DUR:King Shaka International, Durban, South Africa
-DUS:Dusseldorf, Germany
+DUS:Duesseldorf, Germany
 DUT:Dutch Harbor, Alaska, USA
 DVO:Mati, Davao, Philippines
 DXB:Dubai, UAE
@@ -656,7 +656,7 @@ HAD:Halmstad, Halland, Sweden
 HAH:Moroni (Hahaya), Comoros
 HAJ:Langenhagen, Hanover, Germany
 HAK:Haikou, China
-HAM:Fuhlsbuettel Hamburg, Germany
+HAM:Hamburg, Germany
 HAN:Noibai, Hanoi, Vietnam
 HAU:Karmoy, Haugesund, Norway
 HAV:Jose Marti, Havana, Cuba
@@ -849,7 +849,7 @@ KBP:Kyiv Borispil International, Kyiv, U
 KBR:Sultan Ismail Petra, Kota Bharu, Malaysia
 KCG:Fisheries, Chignik, Alaska, USA
 KCH:Kuching, Sarawak, Malaysia
-KCK:All Airports around Kansas City, Kansas, USA
+KCK:Kirensk, Russia
 KCL:Lagoon, Chignik, Alaska, USA
 KDG:Kardjali, Bulgaria
 KEF:Keflavik, Reykjavik, Iceland
@@ -940,7 +940,7 @@ LAW:Municipal, Lawton, Oklahoma, USA
 LAX:Los Angeles International, California, USA
 LBA:Leeds/Bradford, England, United Kingdom
 LBB:Lubbock, Texas, USA
-LBC:Lubeck, Germany
+LBC:Luebeck, Germany
 LBE:Westmoreland County, Latrobe, Pennsylvania, USA
 LBF:North Platte Lee Bird Field, Nebraska, USA
 LBL:Glenn L Martin Terminal, Liberal, Kansas, USA
@@ -1088,7 +1088,7 @@ MEY:Meghauli, Nepal
 MFE:Mc Allen/Mission, Texas, USA
 MFM:Macau
 MFN:Milford Sound, New Zealand
-MFW:All Airports around Miami, Ft. Lauderdale and West Palm Beach, Florida, USA
+MFW:Magaruque Island, Mozambique
 MGA:Managua, Nicaragua
 MGM:Montgomery Municipal/Dannelly Field, Alabama, USA
 MGQ:Mogadishu, Somalia
@@ -1412,11 +1412,11 @@ PZE:Penzance, England, United Kingdom
 PZO:Puerto Ordaz, Venezuela
 PZU:Port Sudan, Sudan
 QBF:Vail/Eagle, Colorado, USA
-QDV:All Airports around Denver, Colorado, USA
+QDV:Comte. Rolim Adolfo Amaro, Jundiai, Brazil
 QKB:Breckenridge, Colorado, USA
 QLA:All Airports around Los Angeles, California, USA
 QRO:Queretaro, Mexico
-QSF:All Airports around San Francisco, California, USA
+QSF:8 May 1945, Setif, Algeria
 QSY:Sydney, New South Wales, Australia
 RAB:Lakunai, Rabaul, Papua New Guinea
 RAJ:Rajkot, India
@@ -1672,7 +1672,6 @@ TGM:Tirgu Mures, Romania
 TGU:Toncontin, Tegucigalpa, Honduras
 TGZ:Llano San Juan, Tuxtla Gutierrez, Chiapas, Mexico
 THE:Teresina, Piaui, Brazil
-THF:Tempelhof, Berlin, Germany
 THN:Trollhattan, Sweden
 THR:Mehrabad, Tehran, Iran
 THU:Thule, Pituffik, Greenland
@@ -1851,7 +1850,7 @@ XBR:Brockville, Ontario, Canada
 XCM:Chatham, Ontario, Canada
 XDM:Drummondville, Quebec, Canada
 XFD:Stratford, Ontario, Canada
-XFW:Flugplatz Hamburg-Finkenwerder, Hamburg, Germany
+XFW:Hamburg-Finkenwerder, Hamburg, Germany
 XIY:Xianyang, Xi An, China
 XLV:Niagara Falls, Ontario, Canada
 XLZ:Truro, Nova Scotia, Canada

Re: Consistency and cleanup in /share/misc/airport

[Thomas Wager]

On Thu, 2022-07-28 at 21:45 -0400, Daniel Dickman wrote:
> 

> No thanks. These are pretty standard ways to refer to groups of
> airports that are close by. We have a bunch of these in the file and
> I'd hate to lose these.
> 
> BHZ:All Airports around Belo Horizonte, MG, Brazil
> BUE:All Airports around Buenos Aires, Argentina
> BUH:All Airports around Bucharest, Romania
> CHI:All Airports around Chicago, Illinois, USA
> DTT:All Airports around Detroit, Michigan, USA
> JKT:All Airports around Jakarta, Indonesia
> KCK:All Airports around Kansas City, Kansas, USA
> LON:All Airports around London, United Kingdom
> MFW:All Airports around Miami, Ft. Lauderdale and West Palm Beach,
> Florida, USA
> MIL:All Airports around Milano, Italy
> MOW:All Airports around Moscow, Russia
> NRW:All Airports around Nordrhein-Westfalen, Germany
> NYC:All Airports around New York City, New York, USA
> OSA:All Airports around Osaka, Japan
> OSL:All Airports around Oslo, Norway
> PAR:All Airports around Paris, France
> QDV:All Airports around Denver, Colorado, USA
> QLA:All Airports around Los Angeles, California, USA
> QSF:All Airports around San Francisco, California, USA
> RIO:All Airports around Rio de Janeiro, RJ, Brazil
> ROM:All Airports around Roma, Italy
> SAO:All Airports around Sao Paulo, SP, Brazil
> STO:All Airports around Stockholm, Sweden
> TYO:All Airports around Tokyo, Japan
> WAS:All Airports around Washington, District of Columbia, USA
> YEA:All Airports around Edmonton, Alberta, Canada
> YMQ:All Airports around Montreal, Quebec, Canada
> YTO:All Airports around Toronto, Ontario, Canad NSB:North Seaplane

I have seen those, and I am a bit confused. If these are supposed to be
IATA codes there are several problems:

KCK:
according to
https://en.wikipedia.org/wiki/Kirensk_Airport
and  
https://www.iata.org/en/publications/directories/code-search/?airport.search=KCK
this is Kirensk, Russia

MFW:
according to
https://en.wikipedia.org/wiki/List_of_airports_by_IATA_airport_code%3A_M
and
https://www.iata.org/en/publications/directories/code-search/?airport.search=MFW
this is Magaruque Island, Mozambique
although http://www.gcmap.com/airport/MFW says it is closed.

NRW:
according to
https://www.iata.org/en/publications/directories/code-search/?airport.search=NRW
this does not exist. But according to
https://iata.codes/airline/polizeifliegerstaffel-nordrhein-westfalen-nrw-hummel-de
there is 3-letter ICAO (not IATA) code NRW for "Polizeifliegerstaffel
Nordrhein-Westfalen", aka a police helicopter squad.

QDV:
according to
https://en.wikipedia.org/wiki/Jundia%C3%AD_Airport
and
https://www.iata.org/en/publications/directories/code-search/?airport.search=QDV
this is Comte. Rolim Adolfo Amaro, Jundiai, Brazil

QSF:
according to
https://en.wikipedia.org/wiki/Ain_Arnat_Airport
and
https://www.iata.org/en/publications/directories/code-search/?airport.search=QSF
this is Ain Arnat (also "8 May 1945"), Setif, Algeria

But if those are not IATA codes, then I am probably completely wrong
here.

Consistency and cleanup in /share/misc/airport

[Thomas Wager]

Hi,

some changes to /share/misc/airport to treat german umlauts more
consistently, remove the "Flugplatz" (german for airport, which is kind
of redundant as it is all airports in the list), remove NRW which does
not exist as IATA code, remove THF which is gone since 2010.

-Thomas

Index: share/misc/airport
===
RCS file: /cvs/src/share/misc/airport,v
retrieving revision 1.83
diff -u -p -u -p -r1.83 airport
--- share/misc/airport  26 Jun 2022 06:28:51 -  1.83
+++ share/misc/airport  24 Jul 2022 23:20:14 -
@@ -470,7 +470,7 @@ DUD:Momona, Dunedin, New Zealand
 DUJ:Jefferson County, Du Bois, Pennsylvania, USA
 DUQ:Quamichan Lake, Duncan / Quam, British Columbia, Canada
 DUR:King Shaka International, Durban, South Africa
-DUS:Dusseldorf, Germany
+DUS:Duesseldorf, Germany
 DUT:Dutch Harbor, Alaska, USA
 DVO:Mati, Davao, Philippines
 DXB:Dubai, UAE
@@ -656,7 +656,7 @@ HAD:Halmstad, Halland, Sweden
 HAH:Moroni (Hahaya), Comoros
 HAJ:Langenhagen, Hanover, Germany
 HAK:Haikou, China
-HAM:Fuhlsbuettel Hamburg, Germany
+HAM:Fuhlsbuettel, Hamburg, Germany
 HAN:Noibai, Hanoi, Vietnam
 HAU:Karmoy, Haugesund, Norway
 HAV:Jose Marti, Havana, Cuba
@@ -940,7 +940,7 @@ LAW:Municipal, Lawton, Oklahoma, USA
 LAX:Los Angeles International, California, USA
 LBA:Leeds/Bradford, England, United Kingdom
 LBB:Lubbock, Texas, USA
-LBC:Lubeck, Germany
+LBC:Luebeck, Germany
 LBE:Westmoreland County, Latrobe, Pennsylvania, USA
 LBF:North Platte Lee Bird Field, Nebraska, USA
 LBL:Glenn L Martin Terminal, Liberal, Kansas, USA
@@ -1214,7 +1214,6 @@ NPL:New Plymouth, New Zealand
 NQY:Newquay Civil, England, United Kingdom
 NRK:Norrkoping, Sweden
 NRT:Narita, Tokyo, Japan
-NRW:All Airports around Nordrhein-Westfalen, Germany
 NSB:North Seaplane Base, Bimini, Bahamas
 NSI:Nsimalen, Yaounde, Cameroon
 NSN:Nelson, New Zealand
@@ -1672,7 +1671,6 @@ TGM:Tirgu Mures, Romania
 TGU:Toncontin, Tegucigalpa, Honduras
 TGZ:Llano San Juan, Tuxtla Gutierrez, Chiapas, Mexico
 THE:Teresina, Piaui, Brazil
-THF:Tempelhof, Berlin, Germany
 THN:Trollhattan, Sweden
 THR:Mehrabad, Tehran, Iran
 THU:Thule, Pituffik, Greenland
@@ -1851,7 +1849,7 @@ XBR:Brockville, Ontario, Canada
 XCM:Chatham, Ontario, Canada
 XDM:Drummondville, Quebec, Canada
 XFD:Stratford, Ontario, Canada
-XFW:Flugplatz Hamburg-Finkenwerder, Hamburg, Germany
+XFW:Hamburg-Finkenwerder, Hamburg, Germany
 XIY:Xianyang, Xi An, China
 XLV:Niagara Falls, Ontario, Canada
 XLZ:Truro, Nova Scotia, Canada

vmd writes corrupt qcow2 images

[Thomas L.]

ROR cluster 32769 refcount=0 reference=1

1 errors were found on the image.
Data may be corrupted, or further writes to the image may corrupt it.
39422/4915200 = 0.80% allocated, 3.31% fragmented, 0.00% compressed clusters
Image end offset: 2610888704

For bigger images the errors are at regular intervals (n*32768+1):

golem# qemu-img check www.qcow2
ERROR cluster 32769 refcount=0 reference=1
ERROR cluster 65537 refcount=0 reference=1
ERROR cluster 98305 refcount=0 reference=1
ERROR cluster 131073 refcount=0 reference=1
ERROR cluster 163841 refcount=0 reference=1
ERROR cluster 196609 refcount=0 reference=1
ERROR cluster 229377 refcount=0 reference=1
ERROR cluster 262145 refcount=0 reference=1
ERROR cluster 294913 refcount=0 reference=1
ERROR cluster 327681 refcount=0 reference=1
ERROR cluster 360449 refcount=0 reference=1
ERROR cluster 393217 refcount=0 reference=1
ERROR cluster 425985 refcount=0 reference=1
ERROR cluster 458753 refcount=0 reference=1
ERROR cluster 491521 refcount=0 reference=1
ERROR cluster 524289 refcount=0 reference=1
ERROR cluster 557057 refcount=0 reference=1
ERROR cluster 589825 refcount=0 reference=1
ERROR cluster 622593 refcount=0 reference=1
ERROR cluster 655361 refcount=0 reference=1
ERROR cluster 688129 refcount=0 reference=1
ERROR cluster 720897 refcount=0 reference=1
ERROR cluster 753665 refcount=0 reference=1
ERROR cluster 786433 refcount=0 reference=1
ERROR cluster 819201 refcount=0 reference=1
ERROR cluster 851969 refcount=0 reference=1
ERROR cluster 884737 refcount=0 reference=1
ERROR cluster 917505 refcount=0 reference=1
ERROR cluster 950273 refcount=0 reference=1
ERROR cluster 983041 refcount=0 reference=1
ERROR cluster 1015809 refcount=0 reference=1
ERROR cluster 1048577 refcount=0 reference=1

32 errors were found on the image.
Data may be corrupted, or further writes to the image may corrupt it.
1074802/4915200 = 21.87% allocated, 2.00% fragmented, 0.00% compressed clusters
Image end offset: 70456967168

Kind regards,

Thomas

Re: XBox One gamecontroller support

[Thomas Frohwein]

On Sat, Mar 19, 2022 at 09:15:23PM +0100, Stefan Sperling wrote:

[...]

> > +   /* XBox One controller initialization */
> 
> Shouldn't this initialization code be under #ifndef SMALL_KERNEL,
> like the rest of the code your patch is adding to this file?
> 
> > +   if (sc->sc_flags & UHIDEV_F_XB1) {
> > +   uint8_t init_data[] = { 0x05, 0x20, 0x00, 0x01, 0x00 };
> > +   int init_data_len = sizeof(init_data);
> 
> I would use 'size_t init_data_len' instead of 'int init_data_len'.
> Largely a matter of taste, but this way everything stays unsigned.
> usbd_setup_xfer() expects an unsigned int.

[...]

> Both of the above suggestions as a diff:

[...]

I updated the diff for the controller with your diff. Below is the
complete diff for all the files involved. I tested it again with my
controller and sdl-jstest (in ports); it continues to work as intended.

ok?

Index: uhid_rdesc.h
===
RCS file: /cvs/src/sys/dev/usb/uhid_rdesc.h,v
retrieving revision 1.1
diff -u -p -r1.1 uhid_rdesc.h
--- uhid_rdesc.h25 Oct 2013 03:09:59 -  1.1
+++ uhid_rdesc.h20 Mar 2022 22:41:04 -
@@ -273,3 +273,93 @@ static const uByte uhid_xb360gp_report_d
 0x81, 0x01,/*  INPUT (Constant)*/
 0xc0,  /* END COLLECTION   */
 };
+
+static const uByte uhid_xbonegp_report_descr[] = {
+0x05, 0x01,/* USAGE PAGE (Generic Desktop) 
*/
+0x09, 0x05,/* USAGE (Gamepad)  
*/
+0xa1, 0x01,/* COLLECTION (Application) 
*/
+/* Button packet */
+0xa1, 0x00,/*  COLLECTION (Physical)   
*/
+0x85, 0x20,/*   REPORT ID (0x20)   
*/
+/* Skip unknown field and counter */
+0x09, 0x00,/*   USAGE (Undefined)  
*/
+0x75, 0x08,/*   REPORT SIZE (8)
*/
+0x95, 0x02,/*   REPORT COUNT (2)   
*/
+0x81, 0x03,/*   INPUT (Constant, Variable, 
Absolute)   */
+/* Payload size */
+0x09, 0x3b,/*   USAGE (Byte Count) 
*/
+0x95, 0x01,/*   REPORT COUNT (1)   
*/
+0x81, 0x02,/*   INPUT (Data, Variable, Absolute)   
*/
+/* 16 Buttons: 1-2=Unknown, 3=Start, 4=Back, 5-8=ABXY,
+ *9-12=D-Pad(Up,Dn,Lt,Rt), 13=LB, 14=RB, 15=LS, 16=RS
+ */
+/* Skip the first 2 as they are not used */
+0x75, 0x01,/*   REPORT SIZE (1)
*/
+0x95, 0x02,/*   REPORT COUNT (2)   
*/
+0x81, 0x01,/*   INPUT (Constant)   
*/
+/* Assign buttons Start(7), Back(8), ABXY(1-4) */
+0x15, 0x00,/*   LOGICAL MINIMUM (0)
*/
+0x25, 0x01,/*   LOGICAL MAXIMUM (1)
*/
+0x95, 0x06,/*   REPORT COUNT (6)   
*/
+0x05, 0x09,/*   USAGE PAGE (Button)
*/
+0x09, 0x08,/*   USAGE (Button 8)   
*/
+0x09, 0x07,/*   USAGE (Button 7)   
*/
+0x09, 0x01,/*   USAGE (Button 1)   
*/
+0x09, 0x02,/*   USAGE (Button 2)   
*/
+0x09, 0x03,/*   USAGE (Button 3)   
*/
+0x09, 0x04,/*   USAGE (Button 4)   
*/
+0x81, 0x02,/*   INPUT (Data, Variable, Absolute)   
*/
+/* D-Pad */
+0x05, 0x01,/*   USAGE PAGE (Generic Desktop)   
*/
+0x09, 0x01,/*   USAGE (Pointer)
*/
+0xa1, 0x00,/*   COLLECTION (Physical)  
*/
+0x75, 0x01,/*REPORT SIZE (1)   
*/
+0x15, 0x00,/*LOGICAL MINIMUM (0)   
*/
+0x25, 0x01,/*LOGICAL MAXIMUM (1)   
*/
+0x95, 0x04,/*REPORT COUNT (4)  
*/
+0x05, 0x01,/*USAGE PAGE (Generic Desktop)  
*/
+0x09, 0x90,   

Re: XBox One gamecontroller support

[Thomas Frohwein]

On Thu, Mar 17, 2022 at 10:58:21PM +0100, Solene Rapenne wrote:

[...]

> > 
> 
> ping
> 
> this diff is still applying to the kernel and allows to use a popular
> and affordable game controller

The diff was written fairly conservatively based on pre-existing code
and NetBSD's solution. It would be nice if someone with more experience
with the USB fundamentals would comment, but maybe it could just go in
in its current form.

Re: Enthusiast Guy

[Thomas Vetere]

Hello,

Stefan S gave a presentation on this here:

https://youtu.be/W5qhWw07qpU

In addition I would get familiar with the coding style of the project:

https://man.openbsd.org/style.9




On Sat, Mar 5, 2022, 9:42 AM Shiran  wrote:

> Hi, as the title suggests, I'm a pretty enthusiast guy and wish to
> contribute on drivers for arm based devices.
> Where could I start?
>
>
> Regards,
>
> *Shiran*
>

Re: Suspend/Resume on modern Intel laptop platforms

[Thomas Frohwein]

On Thu, Sep 16, 2021 at 12:11:24AM +0200, Mark Kettenis wrote:
> > Date: Wed, 15 Sep 2021 17:29:39 +0200 (CEST)
> > From: Mark Kettenis 
> > 
> > The diff below is a preliminary diff to fix a suspend/resume issue on
> > recent Thinkpads.  This needs testing on a wider range of laptops to
> > make sure it doesn't break things.  The diff also puts some
> > information in dmesg that will help me improve things in the future.
> > 
> > So, if you have a laptop where pchgpio(4) attaches *and* supports S3
> > suspen/resume, please apply this diff, do a suspend/resume cycle and
> > send me a dmesg collected after that suspend/resume cycle.
> 
> This diff is now in snapshots, so instead of applying the diff and
> build your own kernel, you can just upgrade to the latest snapshot.

My ASUS Expertbook B9400 has pchgpio(4) attach, so here a dmesg after
a suspend and resume. I don't notice any changes - resuming after a few
minutes of sleep (zzz) or stand-by (apm -S) works, but if I leave the
laptop alone for longer, it doesn't wake anymore. None of opening lid,
pressing keys, or pressing power button brings it back then. That was
the same before and after the update to snapshot from 16 Sep.

(I have machdep.pwraction=0 in /etc/sysctl.conf, but doubt that would
be related...)

OpenBSD 7.0 (GENERIC.MP) #219: Thu Sep 16 00:17:22 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16825262080 (16045MB)
avail mem = 16299315200 (15544MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x5a4b2000 (95 entries)
bios0: vendor ASUSTeK COMPUTER INC. version "B9400CEA.304" date 06/02/2021
bios0: ASUSTeK COMPUTER INC. ASUS EXPERTBOOK B9400CEA_B9450CEA
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP MCFG SSDT FIDT ECDT MSDM SSDT SSDT SSDT SSDT HPET APIC 
SSDT NHLT LPIT SSDT DBGP DBG2 SSDT DMAR SSDT SSDT BGRT TPM2 PTDT WSMT FPDT
acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) GLAN(S4) 
XHCI(S3) XDCI(S4) HDAS(S4) CNVW(S4) TXHC(S3) TDM0(S4) TRP0(S3) PXSX(S4) 
TRP1(S3) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xc000, bus 0-255
acpiec0 at acpi0
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 4689.19 MHz, 06-8c-01
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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 256KB 64b/line disabled 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 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 4689.19 MHz, 06-8c-01
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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 256KB 64b/line disabled L2 cache
cpu1: disabling user TSC (skew=-911753242)
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 4090.57 MHz, 06-8c-01
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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 256KB 64b/line disabled L2 cache
cpu2: disabling user TSC (skew=-911753252)
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 

Re: ihidev: fix data request size

[Thomas Frohwein]

On Mon, Aug 23, 2021 at 08:57:59AM -0500, joshua stein wrote:
> On Sun, 22 Aug 2021 at 22:37:51 -0600, Thomas Frohwein wrote:
[...]
> > I thought I had the same problem on my new Asus Expertbook B9400CEA.
> > During boot, while reordering libraries and later it would print:
> > 
> > dwiic2: timed out reading remaining 16
> > 
> > This is accompanied by generalized slowness of the system - boot is
> > noticeably slow, xenodm takes about 20 seconds to get to the login
> > window, and glxgears(1) slows down visibly with any mouse movement.
> 
> That is because dwiic has to use polling while being invoked by 
> ihidev's interrupt handler or else it panics in tsleep.  It has to 
> wait longer than normal using delay(), so it blocks other kernel 
> processing.
> 
> As for why the timeouts are happening in the first place, it could 
> be a similar issue with the max report size being bogus.  Does this 
> diff change anything?

Thanks for taking a look. The only thing that seems to change is that
the message is now:

dwiic2: timed out reading remaining 4

... not 16 anymore.

dmesg from a kernel built with this patch attached.

> 
> 
> diff --git sys/dev/i2c/ihidev.c sys/dev/i2c/ihidev.c
> index 92778c679ad..0baba616329 100644
> --- sys/dev/i2c/ihidev.c
> +++ sys/dev/i2c/ihidev.c
> @@ -152,7 +152,7 @@ ihidev_attach(struct device *parent, struct device *self, 
> void *aux)
>   }
>  
>   /* find largest report size and allocate memory for input buffer */
> - sc->sc_isize = letoh16(sc->hid_desc.wMaxInputLength);
> + sc->sc_isize = 4;
>   for (repid = 0; repid < sc->sc_nrepid; repid++) {
>   repsz = hid_report_size(sc->sc_report, sc->sc_reportlen,
>   hid_input, repid);
> @@ -643,7 +643,7 @@ ihidev_intr(void *arg)
>  
>   iic_acquire_bus(sc->sc_tag, I2C_F_POLL);
>   res = iic_exec(sc->sc_tag, I2C_OP_READ_WITH_STOP, sc->sc_addr, NULL, 0,
> - sc->sc_ibuf, letoh16(sc->hid_desc.wMaxInputLength), I2C_F_POLL);
> + sc->sc_ibuf, sc->sc_isize, I2C_F_POLL);
>   iic_release_bus(sc->sc_tag, I2C_F_POLL);
>  
>   /*
> 
OpenBSD 7.0-beta (GENERIC.MP) #1: Mon Aug 23 08:20:12 MDT 2021
t...@thfr.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16825262080 (16045MB)
avail mem = 16299372544 (15544MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x5a4b2000 (95 entries)
bios0: vendor ASUSTeK COMPUTER INC. version "B9400CEA.304" date 06/02/2021
bios0: ASUSTeK COMPUTER INC. ASUS EXPERTBOOK B9400CEA_B9450CEA
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP MCFG SSDT FIDT ECDT MSDM SSDT SSDT SSDT SSDT HPET APIC 
SSDT NHLT LPIT SSDT DBGP DBG2 SSDT DMAR SSDT SSDT TPM2 BGRT PTDT WSMT FPDT
acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) GLAN(S4) 
XHCI(S3) XDCI(S4) HDAS(S4) CNVW(S4) TXHC(S3) TDM0(S4) TRP0(S3) PXSX(S4) 
TRP1(S3) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xc000, bus 0-255
acpiec0 at acpi0
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 68555.29 MHz, 06-8c-01
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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 256KB 64b/line disabled 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 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 4689.20 MHz, 06-8c-01
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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XG

Re: ihidev: fix data request size

[Thomas Frohwein]

On Sun, Aug 22, 2021 at 09:50:15PM -0500, joshua stein wrote:
> On a particular laptop with a touchpad behind ihidev, dwiic would 
> report a timeout every time it had to fetch touch data:
> 
> dwiic0: timed out reading remaining 2
> 
> On re-reading the i2c HID spec, the size supplied by wMaxInputLength 
> is already supposed to account for the size and report id bytes so 
> we shouldn't be adding them after the fact.  Otherwise ihidev would 
> ask for more data than can be available and, on this laptop anyway, 
> dwiic would have to wait for this transaction to timeout and fail.
> 
> This fix matches how the Linux i2c-hid driver operates.  I've tested 
> this on 3 laptops with touchpads and touchscreens and it doesn't 
> cause any regressions here while fixing the touchpad on one of them.  
> I'd appreciate tests on other laptops to make sure it doesn't break 
> anything and perhaps fixes your issue if you've also seen constant 
> dwiic timeouts.
> 

I thought I had the same problem on my new Asus Expertbook B9400CEA.
During boot, while reordering libraries and later it would print:

dwiic2: timed out reading remaining 16

This is accompanied by generalized slowness of the system - boot is
noticeably slow, xenodm takes about 20 seconds to get to the login
window, and glxgears(1) slows down visibly with any mouse movement.

Oddly enough these issues don't occur if I boot into bsd.rd before
booting regularly.

I built a kernel with your diff, but the problem persists. dmesg is
attached. If I disable the internal pointing device in the bios, the
apparent touchpad (via ihidev0 in the dmesg) is not present anymore,
but the problems still persist including the "timed out..." message.

No regression observed though.

> 
> 
> Index: sys/dev/i2c/ihidev.c
> ===
> RCS file: /cvs/src/sys/dev/i2c/ihidev.c,v
> retrieving revision 1.23
> diff -u -p -u -p -r1.23 ihidev.c
> --- sys/dev/i2c/ihidev.c  9 Jul 2020 21:01:55 -   1.23
> +++ sys/dev/i2c/ihidev.c  23 Aug 2021 02:38:21 -
> @@ -106,7 +106,6 @@ ihidev_attach(struct device *parent, str
>   struct device *dev;
>   int repid, repsz;
>   int repsizes[256];
> - int isize;
>  
>   sc->sc_tag = ia->ia_tag;
>   sc->sc_addr = ia->ia_addr;
> @@ -158,12 +157,8 @@ ihidev_attach(struct device *parent, str
>   repsz = hid_report_size(sc->sc_report, sc->sc_reportlen,
>   hid_input, repid);
>   repsizes[repid] = repsz;
> -
> - isize = repsz + 2; /* two bytes for the length */
> - isize += (sc->sc_nrepid != 1); /* one byte for the report ID */
> - if (isize > sc->sc_isize)
> - sc->sc_isize = isize;
> -
> + if (repsz > sc->sc_isize)
> + sc->sc_isize = repsz;
>   if (repsz != 0)
>   DPRINTF(("%s: repid %d size %d\n", sc->sc_dev.dv_xname,
>   repid, repsz));
> @@ -648,7 +643,7 @@ ihidev_intr(void *arg)
>  
>   iic_acquire_bus(sc->sc_tag, I2C_F_POLL);
>   res = iic_exec(sc->sc_tag, I2C_OP_READ_WITH_STOP, sc->sc_addr, NULL, 0,
> - sc->sc_ibuf, sc->sc_isize, I2C_F_POLL);
> + sc->sc_ibuf, letoh16(sc->hid_desc.wMaxInputLength), I2C_F_POLL);
>   iic_release_bus(sc->sc_tag, I2C_F_POLL);
>  
>   /*
> 
OpenBSD 7.0-beta (GENERIC.MP) #0: Sun Aug 22 21:55:30 MDT 2021
t...@thfr.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16825262080 (16045MB)
avail mem = 16299376640 (15544MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x5a4b2000 (95 entries)
bios0: vendor ASUSTeK COMPUTER INC. version "B9400CEA.304" date 06/02/2021
bios0: ASUSTeK COMPUTER INC. ASUS EXPERTBOOK B9400CEA_B9450CEA
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP MCFG SSDT FIDT ECDT MSDM SSDT SSDT SSDT SSDT HPET APIC 
SSDT NHLT LPIT SSDT DBGP DBG2 SSDT DMAR SSDT SSDT TPM2 BGRT PTDT WSMT FPDT
acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) GLAN(S4) 
XHCI(S3) XDCI(S4) HDAS(S4) CNVW(S4) TXHC(S3) TDM0(S4) TRP0(S3) PXSX(S4) 
TRP1(S3) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xc000, bus 0-255
acpiec0 at acpi0
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz, 68549.21 MHz, 06-8c-01
cpu0: 

Re: vmd: spurious VM restarts

[Thomas L.]

On Wed, 7 Apr 2021 17:00:00 -0700
Mike Larkin  wrote:
> Depends on the exact content that got swapped out (as we didn't handle
> TLB flushes correctly), so a crash was certainly a possibility.
> That's why I wanted to see the VMM_DEBUG output.
>
> In any case, Thomas should try -current and see if this problem is
> even reproducible.
>
> -ml

I've been running -current with VMM_DEBUG since Apr 14 and the problem
has not reproduced, instead I see spurious stops now. Output in
/var/log/messages on the occasion is:

Jun 19 03:31:16 golem vmd[95337]: vcpu_run_loop: vm 8 / vcpu 0 run ioctl 
failed: Invalid argument
Jun 19 03:31:16 golem /bsd: vcpu_run_vmx: can't read procbased ctls on exit
Jun 19 03:31:17 golem /bsd: vmm_free_vpid: freed VPID/ASID 8

There's also a lot of probably unrelated messages for all the VMs:

Jun 19 01:31:10 golem vmd[66318]: vionet_enq_rx: descriptor too small for 
packet data

I realize that this is an old version, so this might be an already
fixed bug. I can upgrade to a newer snapshot, but the bug shows about
once per month, so by the time it shows it will be an old version
again.

Kind regards,

Thomas

Re: vmd: spurious VM restarts

[Thomas L.]

> > Thomas: I looked at your host dmesg and your provided vm.conf. It
> > looks like 11 vm's with the default 512M memory and one (minecraft)
> > with 8G. Your host seems to have only 16GB of memory, some of which
> > is probably unavailable as it's used by the integrated gpu. I'm
> > wondering if you are effectively oversusbcribing your memory here.
> >
> > I know we currently don't support swapping guest memory out, but not
> > sure what happens if we don't have the physical memory to fault a
> > page in and wire it.
> >
>
> Something else gets swapped out.

Wire == Can't swap out?
top shows 15G real memory available. That should be enough (8G + 11 *
0.5G = 13.5G), or is this inherently risky with 6.8?
I can try -current as suggested in the other mail. Is this a likely
cause or should I run with VMM_DEBUG for further investigation? Is
"somewhat slower" from VMM_DEBUG still usable? I don't need full
performance, but ~month downtime until the problem shows again would be
too much.

> > Even without a custom kernel with VMM_DEBUG, if it's a uvm_fault
> > issue you should see a message in the kernel buffer. Something like:
> >
> >   vmx_fault_page: uvm_fault returns N, GPA=0x, rip=0x
> >
> > mlarkin: thoughts on my hypothesis? Am I wildly off course?
> >
> > -dv
> >
>
> Yeah I was trying to catch the big dump when a VM resets. That would
> tell us if the vm caused the reset or if vmd(8) crashed for some
> reason.

But if vmd crashed it wouldn't restart automatically or does it?
All VMs down from vmd crashing would have been noticed.
That kernel message would have shown in the dmesg too, wouldn't it?

Kind regards,

Thomas

Re: vmd: spurious VM restarts

[Thomas L.]

On Tue, 6 Apr 2021 14:28:09 -0700
Mike Larkin  wrote:

> On Tue, Apr 06, 2021 at 09:15:10PM +0200, Thomas L. wrote:
> > On Tue, 6 Apr 2021 11:11:01 -0700
> > Mike Larkin  wrote:
> > > Anything in the host's dmesg?
> >
>
> *host* dmesg. I think you misread what I was after...

The dmesg of the host was already attached to the first mail below the
vm.conf (I mistakenly called the host hypervisor, which I realize now is
not accurate). I figured since it was already attached, that
you must mean the VM, compounding the confusion ...

Kind regards,

Thomas

Re: vmd: spurious VM restarts

[Thomas L.]

On Tue, 6 Apr 2021 11:11:01 -0700
Mike Larkin  wrote:
> Anything in the host's dmesg?

Below is the dmesg and latest syslog from one of the VMs.

OpenBSD 6.8 (GENERIC) #1: Tue Nov  3 09:04:47 MST 2020
r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 520085504 (495MB)
avail mem = 489435136 (466MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf3f40 (10 entries)
bios0: vendor SeaBIOS version "1.11.0p3-OpenBSD-vmm" date 01/01/2011
bios0: OpenBSD VMM
acpi at bios0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3403.18 MHz, 06-3a-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,CX8,SEP,PGE,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
cpu0: using VERW MDS workaround
pvbus0 at mainbus0: OpenBSD
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "OpenBSD VMM Host" rev 0x00
virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00
viornd0 at virtio0
virtio0: irq 3
virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio1: address fe:e1:ba:d0:00:04
virtio1: irq 5
virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio2
scsibus1 at vioblk0: 1 targets
sd0 at scsibus1 targ 0 lun 0: 
sd0: 307200MB, 512 bytes/sector, 629145600 sectors
virtio2: irq 6
virtio3 at pci0 dev 4 function 0 "OpenBSD VMM Control" rev 0x00
vmmci0 at virtio3
virtio3: irq 7
isa0 at mainbus0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns8250, no fifo
com0: console
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (c14ce37920a910f7.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted

Apr  6 14:39:33 schleuder /bsd: OpenBSD 6.8 (GENERIC) #1: Tue Nov  3 09:04:47 
MST 2020
Apr  6 14:39:33 schleuder /bsd: 
r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
Apr  6 14:39:33 schleuder /bsd: real mem = 520085504 (495MB)
Apr  6 14:39:33 schleuder /bsd: avail mem = 489435136 (466MB)
Apr  6 14:39:33 schleuder /bsd: random: good seed from bootblocks
Apr  6 14:39:33 schleuder /bsd: mpath0 at root
Apr  6 14:39:33 schleuder /bsd: scsibus0 at mpath0: 256 targets
Apr  6 14:39:33 schleuder /bsd: mainbus0 at root
Apr  6 14:39:33 schleuder /bsd: bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf3f40 
(10 entries)
Apr  6 14:39:33 schleuder /bsd: bios0: vendor SeaBIOS version 
"1.11.0p3-OpenBSD-vmm" date 01/01/2011
Apr  6 14:39:33 schleuder /bsd: bios0: OpenBSD VMM
Apr  6 14:39:33 schleuder /bsd: acpi at bios0 not configured
Apr  6 14:39:33 schleuder /bsd: cpu0 at mainbus0: (uniprocessor)
Apr  6 14:39:33 schleuder /bsd: cpu0: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 
3403.18 MHz, 06-3a-09
Apr  6 14:39:33 schleuder /bsd: cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,CX8,SEP,PGE,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,MELTDOWN
Apr  6 14:39:33 schleuder /bsd: cpu0: 256KB 64b/line 8-way L2 cache
Apr  6 14:39:33 schleuder /bsd: cpu0: smt 0, core 0, package 0
Apr  6 14:39:33 schleuder /bsd: cpu0: using VERW MDS workaround
Apr  6 14:39:33 schleuder /bsd: pvbus0 at mainbus0: OpenBSD
Apr  6 14:39:33 schleuder /bsd: pvclock0 at pvbus0
Apr  6 14:39:33 schleuder /bsd: pci0 at mainbus0 bus 0
Apr  6 14:39:33 schleuder /bsd: pchb0 at pci0 dev 0 function 0 "OpenBSD VMM 
Host" rev 0x00
Apr  6 14:39:33 schleuder /bsd: virtio0 at pci0 dev 1 function 0 "Qumranet 
Virtio RNG" rev 0x00
Apr  6 14:39:33 schleuder /bsd: viornd0 at virtio0
Apr  6 14:39:33 schleuder /bsd: virtio0: irq 3
Apr  6 14:39:33 schleuder /bsd: virtio1 at pci0 dev 2 function 0 "Qumranet 
Virtio Network" rev 0x00
Apr  6 14:39:33 schleuder /bsd: vio0 at virtio1: address fe:e1:ba:d0:00:04
Apr  6 14:39:33 schleuder /bsd: virtio1: irq 5
Apr  6 14:39:33 schleuder /bsd: virtio2 at pci0 dev 3 function 0 "Qumranet 
Virtio Storage" rev 0x00
Apr  6 14:39:33 schleuder /bsd: vioblk0 at virtio2
Apr  6 14:39:33 schleuder /bsd: scsibus1 at vioblk0: 1 targets
Apr  6 14:39:33 schleuder /bsd: sd0 at scsibus1 targ 0 lun 0: 
Apr  6 14:39:33 schleuder /bsd: sd0: 307200MB, 512 bytes/sector, 629145600 
sectors
Apr  6 14:39:33 schleuder /bsd: virtio2: irq 6
Apr  6 14:39:33 schleuder /bsd: virtio3 at pci0 dev 4 function 0 "OpenBSD VMM 
Control" rev 0x00
Apr  6 14:39:33 schleuder /bsd: vmmci0 at virtio3
Apr  6 14:39:33 schleuder /bsd: virtio3: irq 7
Apr  6 14:39:33 schleuder /bsd: isa0 at mainbus0
Apr  6 14:39:33 schleuder /bsd: isadma0 at isa0
Apr  6 14:39:33 schleuder /bsd: com0 at isa0 port 0x3f8/8 irq 4: ns8250, no fifo
Apr  6 14:39:33 schleuder /bsd: com0: console
Apr  6 14:39:33 schleuder /bsd: vscsi0 at 

vmd: spurious VM restarts

[Thomas L.]

Hi,

I'm running OpenBSD 6.8 as hypervisor with multiple OpenBSD VMs.
Regularly, it happens that all VM are restarted, not at the same time
but clustered. The indication that this happend is reduced uptime on the
VMs, some services that fail to come up again and the following logs:

# grep vmd /var/log/daemon
Apr  1 18:10:35 golem vmd[31367]: wiki: started vm 12 successfully, tty 
/dev/ttyp0
Apr  6 13:24:52 golem vmd[31367]: matrix: started vm 13 successfully, tty 
/dev/ttypb
Apr  6 13:25:55 golem vmd[31367]: matrix: started vm 13 successfully, tty 
/dev/ttypb
Apr  6 13:26:45 golem vmd[18933]: vmd: LSR UART write 0x8203d260 unsupported
Apr  6 13:26:45 golem vmd[31367]: ticketfrei: started vm 5 successfully, tty 
/dev/ttyp5
Apr  6 14:22:34 golem vmd[31367]: www: started vm 4 successfully, tty /dev/ttyp4
Apr  6 14:33:54 golem vmd[31367]: kibicara: started vm 8 successfully, tty 
/dev/ttyp8
Apr  6 14:35:02 golem vmd[31367]: vpn: started vm 3 successfully, tty /dev/ttyp3
Apr  6 14:36:38 golem vmd[31367]: relay: started vm 1 successfully, tty 
/dev/ttyp1
Apr  6 14:37:51 golem vmd[31367]: schleuder: started vm 2 successfully, tty 
/dev/ttyp2
Apr  6 14:40:34 golem vmd[31367]: mumble: started vm 6 successfully, tty 
/dev/ttyp6
Apr  6 14:41:58 golem vmd[31367]: minecraft: started vm 9 successfully, tty 
/dev/ttyp9

The restarts seem to be non-graceful, since the matrix vm needed manual
fsck on /var. Going back over the logs this seems to happen about every
month (not all restarts are this phenomenon, but Mar 8/10 and Feb
17/20/22 seem like it):

# zgrep vmd /var/log/daemon.0.gz
Mar  8 19:43:07 golem vmd[31367]: wiki: started vm 12 successfully, tty 
/dev/ttyp0
Mar  8 19:43:37 golem vmd[31367]: ticketfrei: started vm 5 successfully, tty 
/dev/ttyp5
Mar 10 09:21:20 golem vmd[31367]: www: started vm 4 successfully, tty /dev/ttyp4
Mar 10 09:24:13 golem vmd[31367]: kibicara: started vm 8 successfully, tty 
/dev/ttyp8
Mar 10 09:26:13 golem vmd[31367]: vpn: started vm 3 successfully, tty /dev/ttyp3
Mar 10 09:28:40 golem vmd[31367]: gitea: started vm 7 successfully, tty 
/dev/ttyp7
Mar 10 09:29:01 golem vmd[31367]: relay: started vm 1 successfully, tty 
/dev/ttyp1
Mar 10 09:31:29 golem vmd[31367]: schleuder: started vm 2 successfully, tty 
/dev/ttyp2
Mar 10 09:34:02 golem vmd[31367]: mumble: started vm 6 successfully, tty 
/dev/ttyp6
Mar 10 09:35:44 golem vmd[31367]: minecraft: started vm 9 successfully, tty 
/dev/ttyp9
Mar 13 01:46:37 golem vmd[31367]: gitea: started vm 7 successfully, tty 
/dev/ttyp7
golem# zgrep vmd /var/log/daemon.1.gz
Feb 17 21:18:45 golem vmd[31367]: matrix: started vm 13 successfully, tty 
/dev/ttypc
Feb 20 08:32:28 golem vmd[31367]: wiki: started vm 12 successfully, tty 
/dev/ttyp0
Feb 20 08:33:14 golem vmd[31367]: ticketfrei: started vm 5 successfully, tty 
/dev/ttyp5
Feb 20 08:35:20 golem vmd[31367]: www: started vm 4 successfully, tty /dev/ttyp4
Feb 20 11:09:01 golem vmd[31367]: kibicara: started vm 8 successfully, tty 
/dev/ttyp8
Feb 20 11:10:18 golem vmd[31367]: vpn: started vm 3 successfully, tty /dev/ttyp3
Feb 20 11:11:52 golem vmd[31367]: gitea: started vm 7 successfully, tty 
/dev/ttyp7
Feb 22 00:51:03 golem vmd[31367]: relay: started vm 1 successfully, tty 
/dev/ttyp1
Feb 22 00:52:44 golem vmd[31367]: schleuder: started vm 2 successfully, tty 
/dev/ttyp2
Feb 22 00:53:59 golem vmd[31367]: mumble: started vm 6 successfully, tty 
/dev/ttyp6
Feb 22 00:54:45 golem vmd[31367]: minecraft: started vm 9 successfully, tty 
/dev/ttyp9
Feb 24 23:01:50 golem vmd[31367]: vmd_sighdlr: reload requested with SIGHUP
Feb 24 23:01:51 golem vmd[31367]: test: started vm 10 successfully, tty 
/dev/ttypa
Feb 24 23:01:51 golem vmd[52735]: test: unsupported refcount size
Feb 24 23:06:27 golem vmd[31367]: vmd_sighdlr: reload requested with SIGHUP
Feb 24 23:06:27 golem vmd[1230]: test: unsupported refcount size
Feb 24 23:06:27 golem vmd[31367]: matrix: started vm 13 successfully, tty 
/dev/ttypb
Feb 24 23:06:27 golem vmd[31367]: test: started vm 10 successfully, tty 
/dev/ttypc
Feb 24 23:10:20 golem vmd[31367]: matrix: started vm 13 successfully, tty 
/dev/ttypb

vm.conf and dmesg of the hypervisor are below. How would I go
about debugging this?

Kind regards,

Thomas


switch internal {
interface bridge0
locked lladdr
group internal
}


vm relay {
disk /data/vmd/relay.qcow2
interface {
switch internal
lladdr fe:e1:ba:d0:00:03
}
}

vm schleuder {
disk /data/vmd/schleuder.qcow2
interface {
switch internal
lladdr fe:e1:ba:d0:00:04
}
}

vm vpn {
disk /data/vmd/vpn.qcow2
interface {
switch internal
lladdr fe:e1:ba:d0:00:05
}
}

vm www {
disk /data/vmd/www.qcow2
interface {
switch internal
lladdr fe:e1:ba:d0:00:06
}
}

vm ticketfrei {
disk /data/vmd/ticketfrei.qcow2

Re: no IPv6 with umb0 on -current

[Thomas Windisch]

On Sat, Mar 13, 2021 at 11:34:29AM +, Stuart Henderson wrote:
> Nothing changed in umb(4) since 6.8-release. The change last year was
> between 6.7 and 6.8 ("IPv6 is no longer on by default. It must be
> enabled with "inet6 eui64").

It seems that the issue I had was not related to OpenBSD but due to 
bad configuration of the modem. What I failed to mention in my inital
email was that there were two modems (same model and firmware) on two
machines: one running -current, the other 6.8-release. I wrongfully
assumed that it had to do something with the OS. Apparently only one of
the modems had a setting set for inet4 AND/OR inet6 that is limiting 
or not overwritten by umb or via MBIM. Both should have had the same 
factory settings, colour me surprised. After issuing an appropriate 
AT-command I can now also get IPv6 on my -current machine.

no IPv6 with umb0 on -current

[Thomas Windisch]

I can get an IPv6 address with my LTE-Modem via umb with 6.8-release but
not with -current. I am aware that there was some discussion last year
on IPv6 support in umb but I'm not really sure what has changed. In
both cases I do get IPv4.

I use the following config:

$ cat /etc/hostname.umb0
rdomain 8
pin 1234
apn internet.telekom
inet6 autoconf
up

Is this a bug, expected beavior, or user error? If it's user error my 
question would be: How do I get IPv6 with umb in -current?

snapshot upgrade hangs with "iwm0: DAD detected duplicate"

[Thomas L.]

Hi,

current snapshot hangs during sysupgrade after rootfs mount with

iwm0: DAD detected duplicate IPv6 address fe80:1::164f:8aff:fe25:dbef: NS 
in/out=1/1, NA in=0
iwm0: DAD complete for fe80:1::164f:8aff:fe25:dbef - duplicate found
iwm0: manual intervention required

The problem persists over multiple trials including powercycle.
Full dmesg from bsd.upgrade below.

Kind regards,

Thomas

OpenBSD 6.9-beta (RAMDISK_CD) #356: Tue Mar  2 10:50:43 MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 8465113088 (8072MB)
avail mem = 8204537856 (7824MB)
random: good seed from bootblocks
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe5f50 (43 entries)
bios0: vendor FUJITSU // Insyde Software Corp. version "Version 2.02" date 
12/28/2017
bios0: FUJITSU LIFEBOOK A357
acpi0 at bios0: ACPI 5.0
acpi0: tables DSDT FACP UEFI UEFI SSDT SSDT TPM2 SSDT FOAT ASF! ASPT BOOT DBGP 
HPET APIC MCFG LPIT WSMT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT DMAR FPDT
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) i3-6006U CPU @ 2.00GHz, 1996.00 MHz, 06-4e-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,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,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus 2 (RP05)
acpiprt6 at acpi0: bus 3 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus 4 (RP09)
acpiprt10 at acpi0: bus -1 (RP10)
acpiprt11 at acpi0: bus -1 (RP11)
acpiprt12 at acpi0: bus -1 (RP12)
acpiprt13 at acpi0: bus -1 (RP13)
acpiprt14 at acpi0: bus -1 (RP14)
acpiprt15 at acpi0: bus -1 (RP15)
acpiprt16 at acpi0: bus -1 (RP16)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpiec0 at acpi0
"FUJ02E3" at acpi0 not configured
"FUJ0420" at acpi0 not configured
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
"PNP0C0C" at acpi0 not configured
"PNP0C0D" at acpi0 not configured
"ACPI0003" at acpi0 not configured
"PNP0C0A" at acpi0 not configured
"MSFT0101" at acpi0 not configured
acpicpu at acpi0 not configured
acpitz at acpi0 not configured
cpu0: using Skylake AVX MDS workaround
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 6G Host" rev 0x08
vga1 at pci0 dev 2 function 0 "Intel HD Graphics 520" rev 0x07
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
"Intel Core GMM" rev 0x00 at pci0 dev 8 function 0 not configured
xhci0 at pci0 dev 20 function 0 "Intel 100 Series xHCI" rev 0x21: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
addr 1
"Intel 100 Series MEI" rev 0x21 at pci0 dev 22 function 0 not configured
ahci0 at pci0 dev 23 function 0 "Intel 100 Series AHCI" rev 0x21: msi, AHCI 
1.3.1
ahci0: port 0: 6.0Gb/s
ahci0: PHY offline on port 1
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0:  naa.500a07511f000e2a
sd0: 244198MB, 512 bytes/sector, 500118192 sectors, thin
ppb0 at pci0 dev 28 function 0 "Intel 100 Series PCIE" rev 0xf1: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 4 "Intel 100 Series PCIE" rev 0xf1: msi
pci2 at ppb1 bus 2
iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x61, msi
ppb2 at pci0 dev 28 function 5 "Intel 100 Series PCIE" rev 0xf1: msi
pci3 at ppb2 bus 3
re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H (0x5400), 
msi, address a0:66:10:81:50:0a
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
ppb3 at pci0 dev 29 function 0 "Intel 100 Series PCIE" rev 0xf1: msi
pci4 at ppb3 bus 4
vendor "Realtek", unknown product 0x524a (class undefined unknown subclass 
0x00, rev 0x01) at pci4 dev 0 function 0 not configured
&qu

Re: XBox One gamecontroller support

[Thomas Frohwein]

On Fri, Jan 15, 2021 at 06:32:04AM -0700, Thomas Frohwein wrote:
> On Sat, Jan 09, 2021 at 10:50:35AM -0700, Thomas Frohwein wrote:
> > Hi,
> > 
> > This diff adds support for the XBox One gamecontroller in a similar way
> > to what we have for the (older) XBox 360 controller [1][2]. This diff
> > is based on the pertinent code in NetBSD's uhidev.c.
> > 
> > Similarities include that the device doesn't provide a report
> > descriptor, so this diff adds one to uhid_rdesc.h.
> > 
> > The biggest difference (that held this up for a while) is that the
> > controller needs an init byte sequence to "wake up."
> > 
> > The original report descriptor from NetBSD just maps the buttons and
> > axes in the order that they appear in the report. I modified the report
> > descriptor to assign the buttons/axes in the most logical order for
> > compatibility, which results in the same layout that we already have
> > for the XBox 360 controller.
> > 
> > The addition of the member sc_flags to struct uhidev_softc follows the
> > NetBSD example.
> > 
> > I have tested this with usbhidctl(1), sdl2-jstest (from sdl-jstest
> > package), and a couple of SDL2 games (Owlboy, Cryptark).
> > 
> > If you have an XBox One controller, the easiest way to test is with:
> > 
> > $ usbhidctl -f /dev/uhidX -l
> > 
> > Make sure to pick the right uhid device and that you have read
> > permissions for it.
> > 
> > Of course, this works only with the controller connected via USB, and
> > doesn't magically add wireless support.
> > 
> > If you test actual SDL2 applications, the button layout will likely
> > default to an odd configuration. I am simultaneously preparing a diff
> > for sdl2-2.0.14p0 that improves recognition and automatic mapping and
> > solves any issues with XBox One default button layout.
> 
> I have an update to this diff. 2 testers used a more recent XBox One
> controller model (model number 1708 in both cases) and ran into
> problems with the original diff. Below is a new diff that uses a longer
> 5-byte init sequence taken from Linux' xpad.c [1], compared to the
> 2-byte sequence from NetBSD's uhidev.c that I offered in the initial
> diff. This fixed the issue for the 2 testers.
> 
> My own XBox One controller is model number 1537 and still works with
> this diff.
> 
> [1] https://github.com/paroj/xpad/blob/master/xpad.c#L479

solene@ has tested this and is ok with it, but I was hoping to get an
opinion from someone with more mileage with the USB internals.

The items of note to direct anyone wanting to give a quick opinion
inlined below.

> 
> Index: uhid_rdesc.h
> ===
> RCS file: /cvs/src/sys/dev/usb/uhid_rdesc.h,v
> retrieving revision 1.1
> diff -u -p -r1.1 uhid_rdesc.h
> --- uhid_rdesc.h  25 Oct 2013 03:09:59 -  1.1
> +++ uhid_rdesc.h  9 Jan 2021 15:11:30 -
> @@ -272,4 +272,94 @@ static const uByte uhid_xb360gp_report_d
>  0x95, 0x01,  /*  REPORT COUNT (1)*/
>  0x81, 0x01,  /*  INPUT (Constant)*/
>  0xc0,/* END COLLECTION   */
> +};
> +
> +static const uByte uhid_xbonegp_report_descr[] = {
> +0x05, 0x01,  /* USAGE PAGE (Generic Desktop) 
> */
> +0x09, 0x05,  /* USAGE (Gamepad)  
> */
> +0xa1, 0x01,  /* COLLECTION (Application) 
> */
> +/* Button packet */
> +0xa1, 0x00,  /*  COLLECTION (Physical)   
> */
> +0x85, 0x20,  /*   REPORT ID (0x20)   
> */
> +/* Skip unknown field and counter */
> +0x09, 0x00,  /*   USAGE (Undefined)  
> */
> +0x75, 0x08,  /*   REPORT SIZE (8)
> */
> +0x95, 0x02,  /*   REPORT COUNT (2)   
> */
> +0x81, 0x03,  /*   INPUT (Constant, Variable, 
> Absolute)   */
> +/* Payload size */
> +0x09, 0x3b,  /*   USAGE (Byte Count) 
> */
> +0x95, 0x01,  /*   REPORT COUNT (1)   
> */
> +0x81, 0x02,  /*   INPUT (Data, Variable, Absolute)   
> */
> +/* 16 Buttons: 1-2=Unknown, 3=Start, 4=Back, 5-8=ABXY,
> + *  9-12=D-Pad(Up,Dn,Lt,Rt), 13=LB, 14=RB, 

Re: Use correct config descriptor in ugen_set_config

[Thomas Jeunet]

On Wed, Feb 03, 2021 at 08:30:42PM +0100, Marcus Glocker wrote:
> On Sun, Jan 31, 2021 at 07:05:29PM +0100, Thomas Jeunet wrote:
> 
> > Hello tech,
> > 
> > in ugen_set_config, the cached config descriptor (ugen.c:213) is
> > obsolete after the call to usbd_set_config_no (ugen.c:220). Use a
> > refreshed value so the next loop account for the correct number of
> > interfaces.
> > 
> > I also believe the dev->cdesc is leaked inside usbd_set_config_index but
> > I haven't yet fully audited how the variable is used.
> 
> Hmm, I don't think this is the right place to call
> usbd_get_config_descriptor() again.  We only enter the if branch (line
> 214) to usbd_set_config_no() when there was a problem with the first
> usbd_get_config_descriptor() call:
> 
>   cdesc = usbd_get_config_descriptor(dev);
>   if (cdesc == NULL || cdesc->bConfigurationValue != configno) {
> 
> If there was no problem we skip that, and cdesc is still valid.
> Therefore I think usbd_get_config_descriptor() should be only called
> right after usbd_set_config_no().
> 

Indeed, your diff looks better and also handle the case when
usbd_set_config_no fail. Thanks!
(And no memory leak, I missed a call to free...)


> Index: dev/usb/ugen.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ugen.c,v
> retrieving revision 1.114
> diff -u -p -u -p -r1.114 ugen.c
> --- dev/usb/ugen.c1 Feb 2021 09:21:51 -   1.114
> +++ dev/usb/ugen.c3 Feb 2021 19:27:37 -
> @@ -220,6 +220,10 @@ ugen_set_config(struct ugen_softc *sc, i
>   err = usbd_set_config_no(dev, configno, 1);
>   if (err)
>   return (err);
> + cdesc = usbd_get_config_descriptor(dev);
> + if (cdesc == NULL ||
> + cdesc->bConfigurationValue != configno)
> + return (USBD_INVAL);
>   }
>   }
>  

Use correct config descriptor in ugen_set_config

[Thomas Jeunet]

Hello tech,

in ugen_set_config, the cached config descriptor (ugen.c:213) is
obsolete after the call to usbd_set_config_no (ugen.c:220). Use a
refreshed value so the next loop account for the correct number of
interfaces.

I also believe the dev->cdesc is leaked inside usbd_set_config_index but
I haven't yet fully audited how the variable is used.

-- 
Thomas Jeunet


Index: ugen.c
===
RCS file: /var/cvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.113
diff -u -p -r1.113 ugen.c
--- ugen.c  28 Jan 2021 12:50:28 -  1.113
+++ ugen.c  31 Jan 2021 15:37:05 -
@@ -223,6 +223,7 @@ ugen_set_config(struct ugen_softc *sc, i
}
}
 
+   cdesc = usbd_get_config_descriptor(dev);
memset(sc->sc_endpoints, 0, sizeof sc->sc_endpoints);
for (ifaceno = 0; ifaceno < cdesc->bNumInterfaces; ifaceno++) {
DPRINTFN(1,("ugen_set_config: ifaceno %d\n", ifaceno));

Re: New ujoy(4) device for USB gamecontrollers

[Thomas Frohwein]

===
RCS file: /cvs/src/share/man/man4/uhidev.4,v
retrieving revision 1.12
diff -u -p -r1.12 uhidev.4
--- share/man/man4/uhidev.4 21 Aug 2020 19:02:46 -  1.12
+++ share/man/man4/uhidev.4 22 Jan 2021 20:05:06 -
@@ -40,6 +40,7 @@
 .Cd "ucycom*  at uhidev?"
 .Cd "ugold*   at uhidev?"
 .Cd "uhid*at uhidev?"
+.Cd "ujoy*at uhidev?"
 .Cd "ukbd*at uhidev?"
 .Cd "ums* at uhidev?"
 .Cd "umstc*   at uhidev?"
@@ -73,6 +74,7 @@ only dispatches data to them based on th
 .Xr ucycom 4 ,
 .Xr ugold 4 ,
 .Xr uhid 4 ,
+.Xr ujoy 4 ,
 .Xr ukbd 4 ,
 .Xr ums 4 ,
 .Xr umstc 4 ,
Index: share/man/man4/ujoy.4
===
RCS file: share/man/man4/ujoy.4
diff -N share/man/man4/ujoy.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/ujoy.4   22 Jan 2021 20:05:06 -
@@ -0,0 +1,53 @@
+.\" $OpenBSD: ujoy.4,v 1.4 2020/08/21 19:02:46 mglocker Exp $
+.\"
+.\" Copyright (c) 2020 Thomas Frohwein 
+.\" Copyright (c) 2020 Bryan Steele
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: December 27 2020 $
+.Dt UJOY 4
+.Os
+.Sh NAME
+.Nm ujoy
+.Nd USB joystick/gamecontroller
+.Sh SYNOPSIS
+.Cd "ujoy* at uhidev?"
+.Sh DESCRIPTION
+The
+.Nm
+driver provides support for USB joysticks and other gamecontrollers.
+They are Human Interface Devices (HID) which can be accessed via the
+.Pa /dev/ujoy/N
+interface.
+.Pp
+The driver is compatible with the
+.Xr read 2 ,
+and a subset of
+.Xr ioctl 2
+operations of the generic
+.Xr uhid 4
+device.
+.Sh FILES
+.Bl -tag -width /dev/ujoy/* -compact
+.It Pa /dev/ujoy/*
+.El
+.Sh SEE ALSO
+.Xr uhid 4 ,
+.Xr uhidev 4 ,
+.Xr usb 4
+.Sh HISTORY
+The
+.Nm
+driver first appeared in
+.Ox 6.9 .
Index: share/man/man4/usb.4
===
RCS file: /cvs/src/share/man/man4/usb.4,v
retrieving revision 1.203
diff -u -p -r1.203 usb.4
--- share/man/man4/usb.421 Aug 2020 20:38:56 -  1.203
+++ share/man/man4/usb.422 Jan 2021 20:05:06 -
@@ -255,6 +255,8 @@ TEMPer gold HID thermometer and hygromet
 Generic driver for Human Interface Devices
 .It Xr uhidev 4
 Base driver for all Human Interface Devices
+.It Xr ujoy 4
+USB joysticks/gamecontrollers
 .It Xr ukbd 4
 USB keyboards that follow the boot protocol
 .It Xr ums 4
Index: sys/arch/alpha/alpha/conf.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/conf.c,v
retrieving revision 1.88
diff -u -p -r1.88 conf.c
--- sys/arch/alpha/alpha/conf.c 6 Jul 2020 04:32:25 -   1.88
+++ sys/arch/alpha/alpha/conf.c 22 Jan 2021 20:05:06 -
@@ -113,6 +113,7 @@ cdev_decl(cy);
 #include "usb.h"
 #include "uhid.h"
 #include "fido.h"
+#include "ujoy.h"
 #include "ugen.h"
 #include "ulpt.h"
 #include "ucom.h"
@@ -207,6 +208,7 @@ struct cdevsw   cdevsw[] =
cdev_switch_init(NSWITCH,switch), /* 69: switch(4) control interface */
cdev_fido_init(NFIDO,fido), /* 70: FIDO/U2F security key */
cdev_pppx_init(NPPPX,pppac),/* 71: PPP Access Concentrator */
+   cdev_ujoy_init(NUJOY,ujoy), /* 72: USB joystick/gamecontroller */
 };
 intnchrdev = nitems(cdevsw);
 
Index: sys/arch/alpha/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/alpha/conf/GENERIC,v
retrieving revision 1.266
diff -u -p -r1.266 GENERIC
--- sys/arch/alpha/conf/GENERIC 23 May 2020 06:28:29 -  1.266
+++ sys/arch/alpha/conf/GENERIC 22 Jan 2021 20:05:06 -
@@ -107,6 +107,7 @@ uslhcom* at uhidev? # Silicon Labs CP2
 ucom*  at uslhcom?
 uhid*  at uhidev?  # USB generic HID support
 fido*  at uhidev?  # FIDO/U2F security key support
+ujoy*  at uhidev?  # USB joystick/gamecontroller support
 upd*   at uhidev?  # USB Power Devices sensors
 aue*   at uhub?# ADMtek AN986 Pegasus Ethernet
 #atu*  at uhub?   

Re: XBox One gamecontroller support

[Thomas Frohwein]

On Sat, Jan 09, 2021 at 10:50:35AM -0700, Thomas Frohwein wrote:
> Hi,
> 
> This diff adds support for the XBox One gamecontroller in a similar way
> to what we have for the (older) XBox 360 controller [1][2]. This diff
> is based on the pertinent code in NetBSD's uhidev.c.
> 
> Similarities include that the device doesn't provide a report
> descriptor, so this diff adds one to uhid_rdesc.h.
> 
> The biggest difference (that held this up for a while) is that the
> controller needs an init byte sequence to "wake up."
> 
> The original report descriptor from NetBSD just maps the buttons and
> axes in the order that they appear in the report. I modified the report
> descriptor to assign the buttons/axes in the most logical order for
> compatibility, which results in the same layout that we already have
> for the XBox 360 controller.
> 
> The addition of the member sc_flags to struct uhidev_softc follows the
> NetBSD example.
> 
> I have tested this with usbhidctl(1), sdl2-jstest (from sdl-jstest
> package), and a couple of SDL2 games (Owlboy, Cryptark).
> 
> If you have an XBox One controller, the easiest way to test is with:
> 
> $ usbhidctl -f /dev/uhidX -l
> 
> Make sure to pick the right uhid device and that you have read
> permissions for it.
> 
> Of course, this works only with the controller connected via USB, and
> doesn't magically add wireless support.
> 
> If you test actual SDL2 applications, the button layout will likely
> default to an odd configuration. I am simultaneously preparing a diff
> for sdl2-2.0.14p0 that improves recognition and automatic mapping and
> solves any issues with XBox One default button layout.

I have an update to this diff. 2 testers used a more recent XBox One
controller model (model number 1708 in both cases) and ran into
problems with the original diff. Below is a new diff that uses a longer
5-byte init sequence taken from Linux' xpad.c [1], compared to the
2-byte sequence from NetBSD's uhidev.c that I offered in the initial
diff. This fixed the issue for the 2 testers.

My own XBox One controller is model number 1537 and still works with
this diff.

[1] https://github.com/paroj/xpad/blob/master/xpad.c#L479

Index: uhid_rdesc.h
===
RCS file: /cvs/src/sys/dev/usb/uhid_rdesc.h,v
retrieving revision 1.1
diff -u -p -r1.1 uhid_rdesc.h
--- uhid_rdesc.h25 Oct 2013 03:09:59 -  1.1
+++ uhid_rdesc.h9 Jan 2021 15:11:30 -
@@ -272,4 +272,94 @@ static const uByte uhid_xb360gp_report_d
 0x95, 0x01,/*  REPORT COUNT (1)*/
 0x81, 0x01,/*  INPUT (Constant)*/
 0xc0,  /* END COLLECTION   */
+};
+
+static const uByte uhid_xbonegp_report_descr[] = {
+0x05, 0x01,/* USAGE PAGE (Generic Desktop) 
*/
+0x09, 0x05,/* USAGE (Gamepad)  
*/
+0xa1, 0x01,/* COLLECTION (Application) 
*/
+/* Button packet */
+0xa1, 0x00,/*  COLLECTION (Physical)   
*/
+0x85, 0x20,/*   REPORT ID (0x20)   
*/
+/* Skip unknown field and counter */
+0x09, 0x00,/*   USAGE (Undefined)  
*/
+0x75, 0x08,/*   REPORT SIZE (8)
*/
+0x95, 0x02,/*   REPORT COUNT (2)   
*/
+0x81, 0x03,/*   INPUT (Constant, Variable, 
Absolute)   */
+/* Payload size */
+0x09, 0x3b,/*   USAGE (Byte Count) 
*/
+0x95, 0x01,/*   REPORT COUNT (1)   
*/
+0x81, 0x02,/*   INPUT (Data, Variable, Absolute)   
*/
+/* 16 Buttons: 1-2=Unknown, 3=Start, 4=Back, 5-8=ABXY,
+ *9-12=D-Pad(Up,Dn,Lt,Rt), 13=LB, 14=RB, 15=LS, 16=RS
+ */
+/* Skip the first 2 as they are not used */
+0x75, 0x01,/*   REPORT SIZE (1)
*/
+0x95, 0x02,/*   REPORT COUNT (2)   
*/
+0x81, 0x01,/*   INPUT (Constant)   
*/
+/* Assign buttons Start(7), Back(8), ABXY(1-4) */
+0x15, 0x00,/*   LOGICAL MINIMUM (0)
*/
+0x25, 0x01,/*   LOGICAL MAXIMUM (1)
*/
+0x95, 0x06,/*   REPORT COUNT (6)   
*/
+0x05, 0x09,

Re: New ujoy(4) device for USB gamecontrollers

[Thomas Frohwein]

On Sat, Jan 09, 2021 at 10:16:16AM +0100, Marcus Glocker wrote:
> On Thu, Jan 07, 2021 at 08:20:35PM +0100, Marcus Glocker wrote:
> 
> > > I have heard from others who tried the diff that the PS4 controller is
> > > causing problems with the way it attaches. I ordered one to trial-and-
> > > error this myself at home. Could you share output of lsusb -vv? Thanks
> > > for giving it a try!
> > 
> > Sure, here we go.
> > If I can find anything myself in the meantime I let you know.
> 
> So the problem doesn't seem to be in your new ujoy(4) code, but how the
> dev/hid/hid.c:hid_is_collection() function tries to cope with the PS4
> controller.

So with the hid_is_collection() problem not easy to mitigate [1],
should we table the ujoy(4) proposal for now pending a fix for the
problems with the PS4 controller? Or is this interesting enough for
some to work on moving forward despite this issue and finding a
solution for this specific (and in some ways unusual) device later?

3-4 have tested and reported to me so far. It seems so far that the
only new breakage is with the PS4 controller, and there is probably
another solution that can be found later that doesn't break other
drivers like [1]?

[1] https://marc.info/?l=openbsd-tech=161043081617336=mbox

> 
> I'm not much in to HID, but when I sync up the hid_is_collection()
> function with NetBSD, the PS4 controller attaches to ujoy(4) as
> expected, and also can be accessed by usbhidctl(1), while my other
> HID devices continue to work as before:
> 
> uaudio0 at uhub4 port 4 configuration 1 interface 1 "Sony Interactive
> Entertainment Wireless Controller" rev 2.00/1.00 addr 6
> uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 4 ctls
> audio1 at uaudio0
> uhidev6 at uhub4 port 4 configuration 1 interface 3 "Sony Interactive
> Entertainment Wireless Controller" rev 2.00/1.00 addr 6
> uhidev6: iclass 3/0, 180 report ids
> ujoy0 at uhidev6 reportid 1: input=63, output=0, feature=0 <--
> uhid6 at uhidev6 reportid 2: input=0, output=0, feature=36
> uhid7 at uhidev6 reportid 4: input=0, output=0, feature=36
> uhid8 at uhidev6 reportid 5: input=0, output=31, feature=0
> uhid9 at uhidev6 reportid 8: input=0, output=0, feature=3
> uhid10 at uhidev6 reportid 16: input=0, output=0, feature=4
> uhid11 at uhidev6 reportid 17: input=0, output=0, feature=2
> uhid12 at uhidev6 reportid 18: input=0, output=0, feature=15
> uhid13 at uhidev6 reportid 19: input=0, output=0, feature=22
> uhid14 at uhidev6 reportid 20: input=0, output=0, feature=16
> uhid15 at uhidev6 reportid 21: input=0, output=0, feature=44
> uhid16 at uhidev6 reportid 128: input=0, output=0, feature=6
> uhid17 at uhidev6 reportid 129: input=0, output=0, feature=6
> uhid18 at uhidev6 reportid 130: input=0, output=0, feature=5
> uhid19 at uhidev6 reportid 131: input=0, output=0, feature=1
> uhid20 at uhidev6 reportid 132: input=0, output=0, feature=4
> uhid21 at uhidev6 reportid 133: input=0, output=0, feature=6
> uhid22 at uhidev6 reportid 134: input=0, output=0, feature=6
> uhid23 at uhidev6 reportid 135: input=0, output=0, feature=35
> uhid24 at uhidev6 reportid 136: input=0, output=0, feature=34
> uhid25 at uhidev6 reportid 137: input=0, output=0, feature=2
> uhid26 at uhidev6 reportid 144: input=0, output=0, feature=5
> uhid27 at uhidev6 reportid 145: input=0, output=0, feature=3
> uhid28 at uhidev6 reportid 146: input=0, output=0, feature=3
> uhid29 at uhidev6 reportid 147: input=0, output=0, feature=12
> uhid30 at uhidev6 reportid 160: input=0, output=0, feature=6
> uhid31 at uhidev6 reportid 161: input=0, output=0, feature=1
> uhid32 at uhidev6 reportid 162: input=0, output=0, feature=1
> uhid33 at uhidev6 reportid 163: input=0, output=0, feature=48
> uhid34 at uhidev6 reportid 164: input=0, output=0, feature=13
> uhid35 at uhidev6 reportid 165: input=0, output=0, feature=21
> uhid36 at uhidev6 reportid 166: input=0, output=0, feature=21
> uhid37 at uhidev6 reportid 167: input=0, output=0, feature=1
> uhid38 at uhidev6 reportid 168: input=0, output=0, feature=1
> uhid39 at uhidev6 reportid 169: input=0, output=0, feature=8
> uhid40 at uhidev6 reportid 170: input=0, output=0, feature=1
> uhid41 at uhidev6 reportid 171: input=0, output=0, feature=57
> uhid42 at uhidev6 reportid 172: input=0, output=0, feature=57
> uhid43 at uhidev6 reportid 173: input=0, output=0, feature=11
> uhid44 at uhidev6 reportid 174: input=0, output=0, feature=1
> uhid45 at uhidev6 reportid 175: input=0, output=0, feature=2
> uhid46 at uhidev6 reportid 176: input=0, output=0, feature=63
> uhid47 at uhidev6 reportid 177: input=0, output=0, feature=2
> uhid48 at uhidev6 reportid 178: input=0, output=0, feature=2
> uhid49 at uhidev6 reportid 179: input=0, output=0, feature=63
> uhid50 at uhidev6 reportid 180: input=0, output=0, feature=63
> 
>   $ usbhidctl -f /dev/ujoy/0 -l
>   Game_Pad.X=126
>   Game_Pad.Y=126
>   Game_Pad.Z=125
>   Game_Pad.Rz=129
>   Game_Pad.Hat_Switch=8
>   Game_Pad.Button_1=0

Re: New ujoy(4) device for USB gamecontrollers

[Thomas Frohwein]

On Sat, Jan 09, 2021 at 10:16:16AM +0100, Marcus Glocker wrote:

[...]

> So the problem doesn't seem to be in your new ujoy(4) code, but how the
> dev/hid/hid.c:hid_is_collection() function tries to cope with the PS4
> controller.
> 
> I'm not much in to HID, but when I sync up the hid_is_collection()
> function with NetBSD, the PS4 controller attaches to ujoy(4) as
> expected, and also can be accessed by usbhidctl(1), while my other
> HID devices continue to work as before:

Nice find.

[...]

> Once this has been fixed I would continue to do some more ujoy(4)
> testing, and check about a possible import.  We also should agree on
> who/how to fix the ports part.

While I can't speak for all 11,000 packages, I am yet to encounter a
port that uses gamecontrollers/joysticks without going through sdl or
sdl2. And for those 2 ports it's literally a 1-line diff each.

I'm not sure if looking at all the ports with 'usbhid' in WANTLIB would
be helpful. I have a list of 55 of those from sqlports, excluding
anything with 'sdl' in its name.

XBox One gamecontroller support

[Thomas Frohwein]

Hi,

This diff adds support for the XBox One gamecontroller in a similar way
to what we have for the (older) XBox 360 controller [1][2]. This diff
is based on the pertinent code in NetBSD's uhidev.c.

Similarities include that the device doesn't provide a report
descriptor, so this diff adds one to uhid_rdesc.h.

The biggest difference (that held this up for a while) is that the
controller needs an init byte sequence to "wake up."

The original report descriptor from NetBSD just maps the buttons and
axes in the order that they appear in the report. I modified the report
descriptor to assign the buttons/axes in the most logical order for
compatibility, which results in the same layout that we already have
for the XBox 360 controller.

The addition of the member sc_flags to struct uhidev_softc follows the
NetBSD example.

I have tested this with usbhidctl(1), sdl2-jstest (from sdl-jstest
package), and a couple of SDL2 games (Owlboy, Cryptark).

If you have an XBox One controller, the easiest way to test is with:

$ usbhidctl -f /dev/uhidX -l

Make sure to pick the right uhid device and that you have read
permissions for it.

Of course, this works only with the controller connected via USB, and
doesn't magically add wireless support.

If you test actual SDL2 applications, the button layout will likely
default to an odd configuration. I am simultaneously preparing a diff
for sdl2-2.0.14p0 that improves recognition and automatic mapping and
solves any issues with XBox One default button layout.

comments? ok?

[1] https://marc.info/?l=openbsd-cvs=138267062532046=mbox
[2] https://marc.info/?l=openbsd-cvs=144956819605939=mbox

Index: uhid_rdesc.h
===
RCS file: /cvs/src/sys/dev/usb/uhid_rdesc.h,v
retrieving revision 1.1
diff -u -p -r1.1 uhid_rdesc.h
--- uhid_rdesc.h25 Oct 2013 03:09:59 -  1.1
+++ uhid_rdesc.h9 Jan 2021 15:11:30 -
@@ -272,4 +272,94 @@ static const uByte uhid_xb360gp_report_d
 0x95, 0x01,/*  REPORT COUNT (1)*/
 0x81, 0x01,/*  INPUT (Constant)*/
 0xc0,  /* END COLLECTION   */
+};
+
+static const uByte uhid_xbonegp_report_descr[] = {
+0x05, 0x01,/* USAGE PAGE (Generic Desktop) 
*/
+0x09, 0x05,/* USAGE (Gamepad)  
*/
+0xa1, 0x01,/* COLLECTION (Application) 
*/
+/* Button packet */
+0xa1, 0x00,/*  COLLECTION (Physical)   
*/
+0x85, 0x20,/*   REPORT ID (0x20)   
*/
+/* Skip unknown field and counter */
+0x09, 0x00,/*   USAGE (Undefined)  
*/
+0x75, 0x08,/*   REPORT SIZE (8)
*/
+0x95, 0x02,/*   REPORT COUNT (2)   
*/
+0x81, 0x03,/*   INPUT (Constant, Variable, 
Absolute)   */
+/* Payload size */
+0x09, 0x3b,/*   USAGE (Byte Count) 
*/
+0x95, 0x01,/*   REPORT COUNT (1)   
*/
+0x81, 0x02,/*   INPUT (Data, Variable, Absolute)   
*/
+/* 16 Buttons: 1-2=Unknown, 3=Start, 4=Back, 5-8=ABXY,
+ *9-12=D-Pad(Up,Dn,Lt,Rt), 13=LB, 14=RB, 15=LS, 16=RS
+ */
+/* Skip the first 2 as they are not used */
+0x75, 0x01,/*   REPORT SIZE (1)
*/
+0x95, 0x02,/*   REPORT COUNT (2)   
*/
+0x81, 0x01,/*   INPUT (Constant)   
*/
+/* Assign buttons Start(7), Back(8), ABXY(1-4) */
+0x15, 0x00,/*   LOGICAL MINIMUM (0)
*/
+0x25, 0x01,/*   LOGICAL MAXIMUM (1)
*/
+0x95, 0x06,/*   REPORT COUNT (6)   
*/
+0x05, 0x09,/*   USAGE PAGE (Button)
*/
+0x09, 0x08,/*   USAGE (Button 8)   
*/
+0x09, 0x07,/*   USAGE (Button 7)   
*/
+0x09, 0x01,/*   USAGE (Button 1)   
*/
+0x09, 0x02,/*   USAGE (Button 2)   
*/
+0x09, 0x03,/*   USAGE (Button 3)   
*/
+0x09, 0x04,/*   USAGE (Button 4)   
*/
+0x81, 0x02,/*   INPUT (Data, Variable, 

Re: slimblade support

[Thomas Frohwein]

On Sat, Nov 21, 2020 at 08:10:03AM +0200, Timo Myyrä wrote:
> Hi,
> 
> The last attempt at adding Kensington Slimblade trackball support seems
> to have stalled:
> https://marc.info/?l=openbsd-tech=147444999319756=2
> 
> I tested the diff and it still seems apply with little fuzz and works
> with my slimblade. It would be nice to have this included so I can paste
> with mouse.
> 
> Here's cleaned up patch for reference.
> 
> timo

I've been running with this diff through several snapshot upgrades
without issues. Would be interested to hear if there are concerns about
this diff or if I can get another ok? As far as quirks go, it's not
much code and relatively simple...

> 
> 
> Index: sys/dev/usb/ums.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ums.c,v
> retrieving revision 1.45
> diff -u -p -u -p -r1.45 ums.c
> --- sys/dev/usb/ums.c 23 Aug 2020 11:08:02 -  1.45
> +++ sys/dev/usb/ums.c 20 Nov 2020 20:22:11 -
> @@ -150,6 +150,8 @@ ums_attach(struct device *parent, struct
>   qflags |= HIDMS_MS_BAD_CLASS;
>   if (quirks & UQ_MS_LEADING_BYTE)
>   qflags |= HIDMS_LEADINGBYTE;
> + if (quirks & UQ_MS_VENDOR_BUTTONS)
> + qflags |= HIDMS_VENDOR_BUTTONS;
>  
>   if (hidms_setup(self, ms, qflags, uha->reportid, desc, size) != 0)
>   return;
> Index: sys/dev/usb/usb_quirks.c
> ===
> RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
> retrieving revision 1.76
> diff -u -p -u -p -r1.76 usb_quirks.c
> --- sys/dev/usb/usb_quirks.c  5 Jan 2020 00:54:13 -   1.76
> +++ sys/dev/usb/usb_quirks.c  20 Nov 2020 20:22:11 -
> @@ -150,6 +150,9 @@ const struct usbd_quirk_entry {
>   { USB_VENDOR_MICROSOFT, USB_PRODUCT_MICROSOFT_WLNOTEBOOK2,
>   ANY, { UQ_MS_BAD_CLASS | UQ_MS_LEADING_BYTE }},
>  
> + { USB_VENDOR_KENSINGTON, USB_PRODUCT_KENSINGTON_SLIMBLADE,
> + ANY, { UQ_MS_VENDOR_BUTTONS }},
> +
>   { 0, 0, 0, { 0 } }
>  };
>  
> Index: sys/dev/usb/usb_quirks.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usb_quirks.h,v
> retrieving revision 1.16
> diff -u -p -u -p -r1.16 usb_quirks.h
> --- sys/dev/usb/usb_quirks.h  19 Jul 2010 05:08:37 -  1.16
> +++ sys/dev/usb/usb_quirks.h  20 Nov 2020 20:22:11 -
> @@ -49,6 +49,8 @@ struct usbd_quirks {
>  #define UQ_MS_LEADING_BYTE   0x0001 /* mouse sends unknown leading byte 
> */
>  #define UQ_EHCI_NEEDTO_DISOWN0x0002 /* must hand device over to 
> USB 1.1
>   if attached to EHCI */
> +#define UQ_MS_VENDOR_BUTTONS 0x0004 /* mouse reports extra buttons in
> + vendor page */
>  };
>  
>  extern const struct usbd_quirks usbd_no_quirk;
> Index: sys/dev/usb/usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.728
> diff -u -p -u -p -r1.728 usbdevs
> --- sys/dev/usb/usbdevs   16 Nov 2020 09:49:10 -  1.728
> +++ sys/dev/usb/usbdevs   20 Nov 2020 20:22:11 -
> @@ -2491,6 +2491,7 @@ product KENSINGTON TURBOBALL0x1005  Turb
>  product KENSINGTON ORBIT_MAC 0x1009  Orbit trackball for Mac
>  product KENSINGTON BT_EDR0x105e  Bluetooth
>  product KENSINGTON VIDEOCAM_VGA  0x5002  VideoCAM VGA
> +product KENSINGTON SLIMBLADE 0x2041  Slimblade Trackball
>  
>  /* Keyspan products */
>  product KEYSPAN USA28_NF 0x0101  USA-28 serial
> Index: sys/dev/usb/usbdevs.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> retrieving revision 1.740
> diff -u -p -u -p -r1.740 usbdevs.h
> --- sys/dev/usb/usbdevs.h 16 Nov 2020 09:49:40 -  1.740
> +++ sys/dev/usb/usbdevs.h 20 Nov 2020 20:22:11 -
> @@ -2498,6 +2498,7 @@
>  #define  USB_PRODUCT_KENSINGTON_ORBIT_MAC0x1009  /* 
> Orbit trackball for Mac */
>  #define  USB_PRODUCT_KENSINGTON_BT_EDR   0x105e  /* Bluetooth */
>  #define  USB_PRODUCT_KENSINGTON_VIDEOCAM_VGA 0x5002  /* 
> VideoCAM VGA */
> +#define  USB_PRODUCT_KENSINGTON_SLIMBLADE0x2041  /* 
> Slimblade Trackball */
>  
>  /* Keyspan products */
>  #define  USB_PRODUCT_KEYSPAN_USA28_NF0x0101  /* USA-28 
> serial */
> Index: sys/dev/usb/usbdevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
> retrieving revision 1.734
> diff -u -p -u -p -r1.734 usbdevs_data.h
> --- sys/dev/usb/usbdevs_data.h16 Nov 2020 09:49:40 -  1.734
> +++ sys/dev/usb/usbdevs_data.h20 Nov 2020 20:22:11 -
> @@ -5402,6 +5402,10 @@ const struct usb_known_product usb_known
>   "VideoCAM VGA",
>   },
>   {
> + USB_VENDOR_KENSINGTON, 

Re: New ujoy(4) device for USB gamecontrollers

[Thomas Frohwein]

On Wed, Jan 06, 2021 at 10:48:58PM +0100, Marcus Glocker wrote:

[...]

> The implementation as such looks fine to me.
> But I quickly gave the diff a spin before on amd64 using my PS
> controller, and the result is not what I would expect.
> 
> With uhid, I can access the controller on /dev/uhid6.  The attach looks
> like this:
> 
> imac /bsd: uaudio0 at uhub4 port 4 configuration 1 interface 1 "Sony
> Interactive Entertainment Wireless Controller" rev 2.00/1.00 addr 6
> imac /bsd: uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec,
> 4 ctls
> imac /bsd: audio1 at uaudio0
> imac /bsd: uhidev6 at uhub4 port 4 configuration 1 interface 3 "Sony
> Interactive Entertainment Wireless Controller" rev 2.00/1.00 addr 6
> imac /bsd: uhidev6: iclass 3/0, 180 report ids
> imac /bsd: uhid6 at uhidev6 reportid 1: input=63, output=0, feature=0

[...]

> imac /bsd: uhid50 at uhidev6 reportid 179: input=0, output=0, feature=63
> imac /bsd: uhid51 at uhidev6 reportid 180: input=0, output=0, feature=63
> 
> ujoy instead attached to previous uhid51, and there it is of no use
> obviously.  I still can access the controller through uhid6.  The attach
> with ujoy looks like this:
> 
> imac /bsd: uaudio0 at uhub4 port 4 configuration 1 interface 1 "Sony
> Interactive Entertainment Wireless Controller" rev 2.00/1.00 addr 6
> imac /bsd: uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec,
> 4 ctls
> imac /bsd: audio1 at uaudio0
> imac /bsd: uhidev6 at uhub4 port 4 configuration 1 interface 3 "Sony
> Interactive Entertainment Wireless Controller" rev 2.00/1.00 addr 6
> imac /bsd: uhidev6: iclass 3/0, 180 report ids

[...]

> imac /bsd: uhid50 at uhidev6 reportid 179: input=0, output=0, feature=63
> imac /bsd: ujoy0 at uhidev6 reportid 180: input=0, output=0, feature=63
> 
> I haven't analyzed yet what happens in the code.
> I can provide an lsusb of the controller if it's more obvious to you.

I have heard from others who tried the diff that the PS4 controller is
causing problems with the way it attaches. I ordered one to trial-and-
error this myself at home. Could you share output of lsusb -vv? Thanks
for giving it a try!

New ujoy(4) device for USB gamecontrollers

[Thomas Frohwein]

=
RCS file: /cvs/src/etc/etc.powerpc64/MAKEDEV.md,v
retrieving revision 1.6
diff -u -p -r1.6 MAKEDEV.md
--- etc/etc.powerpc64/MAKEDEV.md24 Oct 2020 21:10:41 -  1.6
+++ etc/etc.powerpc64/MAKEDEV.md28 Dec 2020 03:25:05 -
@@ -52,6 +52,7 @@ _DEV(uall)
 _DEV(ugen, 49)
 _DEV(uhid, 50)
 _DEV(fido, 51)
+_DEV(ujoy, 94)
 _DEV(ulpt, 65)
 _DEV(usb, 48)
 _TITLE(spec)
Index: etc/etc.sgi/MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.sgi/MAKEDEV.md,v
retrieving revision 1.54
diff -u -p -r1.54 MAKEDEV.md
--- etc/etc.sgi/MAKEDEV.md  6 Jul 2020 06:11:27 -   1.54
+++ etc/etc.sgi/MAKEDEV.md  28 Dec 2020 03:25:05 -
@@ -69,6 +69,7 @@ _DEV(uall)
 _DEV(ugen, 63)
 _DEV(uhid, 62)
 _DEV(fido, 76)
+_DEV(ujoy, 78)
 _DEV(ulpt, 64)
 _DEV(usb, 61)
 _TITLE(spec)
Index: etc/etc.sparc64/MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.sparc64/MAKEDEV.md,v
retrieving revision 1.95
diff -u -p -r1.95 MAKEDEV.md
--- etc/etc.sparc64/MAKEDEV.md  22 Jul 2020 14:04:37 -  1.95
+++ etc/etc.sparc64/MAKEDEV.md  28 Dec 2020 03:25:05 -
@@ -104,6 +104,7 @@ _DEV(uall)
 _DEV(ugen, 92)
 _DEV(uhid, 91)
 _DEV(fido, 137)
+_DEV(ujoy, 139)
 _DEV(ulpt, 93)
 _DEV(usb, 90)
 _TITLE(spec)
Index: share/man/man4/Makefile
===
RCS file: /cvs/src/share/man/man4/Makefile,v
retrieving revision 1.790
diff -u -p -r1.790 Makefile
--- share/man/man4/Makefile 6 Dec 2020 20:48:12 -   1.790
+++ share/man/man4/Makefile 28 Dec 2020 03:25:31 -
@@ -84,7 +84,7 @@ MAN=  aac.4 abcrtc.4 abl.4 ac97.4 acphy.4
ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \
udav.4 udcf.4 udl.4 udp.4 udsbr.4 \
uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \
-   uk.4 ukbd.4 \
+   ujoy.4 uk.4 ukbd.4 \
ukphy.4 ulpt.4 umass.4 umb.4 umbg.4 umcs.4 umct.4 umidi.4 umodem.4 \
ums.4 umsm.4 umstc.4 umt.4 unix.4 uonerng.4 uow.4 uoaklux.4 uoakrh.4 \
uoakv.4 upd.4 upgt.4 upl.4 uplcom.4 ural.4 ure.4 url.4 urlphy.4 \
Index: share/man/man4/uhidev.4
===
RCS file: /cvs/src/share/man/man4/uhidev.4,v
retrieving revision 1.12
diff -u -p -r1.12 uhidev.4
--- share/man/man4/uhidev.4 21 Aug 2020 19:02:46 -  1.12
+++ share/man/man4/uhidev.4 28 Dec 2020 03:25:31 -
@@ -40,6 +40,7 @@
 .Cd "ucycom*  at uhidev?"
 .Cd "ugold*   at uhidev?"
 .Cd "uhid*at uhidev?"
+.Cd "ujoy*at uhidev?"
 .Cd "ukbd*at uhidev?"
 .Cd "ums* at uhidev?"
 .Cd "umstc*   at uhidev?"
@@ -73,6 +74,7 @@ only dispatches data to them based on th
 .Xr ucycom 4 ,
 .Xr ugold 4 ,
 .Xr uhid 4 ,
+.Xr ujoy 4 ,
 .Xr ukbd 4 ,
 .Xr ums 4 ,
 .Xr umstc 4 ,
Index: share/man/man4/ujoy.4
===
RCS file: share/man/man4/ujoy.4
diff -N share/man/man4/ujoy.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/ujoy.4   28 Dec 2020 03:25:31 -
@@ -0,0 +1,53 @@
+.\" $OpenBSD: ujoy.4,v 1.4 2020/08/21 19:02:46 mglocker Exp $
+.\"
+.\" Copyright (c) 2020 Thomas Frohwein 
+.\" Copyright (c) 2020 Bryan Steele
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: December 27 2020 $
+.Dt UJOY 4
+.Os
+.Sh NAME
+.Nm ujoy
+.Nd USB joystick/gamecontroller
+.Sh SYNOPSIS
+.Cd "ujoy* at uhidev?"
+.Sh DESCRIPTION
+The
+.Nm
+driver provides support for USB joysticks and other gamecontrollers.
+They are Human Interface Devices (HID) which can be accessed via the
+.Pa /dev/ujoy/N
+interface.
+.Pp
+The driver is compatible with the
+.Xr read 2 ,
+and a subset of
+.Xr ioctl 2
+operations of the generic
+.Xr uhid 4
+device.
+.Sh FILES
+.Bl -tag -width /dev/ujoy/* -compact
+.It Pa /dev/ujoy/*
+.El
+.Sh SEE ALSO
+.Xr uhid 4 ,
+.Xr uhidev 4 ,
+.Xr usb 4
+.Sh HISTORY
+The
+.Nm
+driver first appeared in
+.Ox 6.9 .
Index: share/man/man4/usb.4
===
RCS fi

Re: slimblade support

[Thomas Frohwein]

Hi timo

On Sat, Nov 21, 2020 at 08:10:03AM +0200, Timo Myyrä wrote:
> Hi,
> 
> The last attempt at adding Kensington Slimblade trackball support seems
> to have stalled:
> https://marc.info/?l=openbsd-tech=147444999319756=2

Thanks for digging this up. I got a Slimblade, but have been using
Emulate3Buttons to paste because I didn't know about this diff.

> 
> I tested the diff and it still seems apply with little fuzz and works
> with my slimblade. It would be nice to have this included so I can paste
> with mouse.
> 
> Here's cleaned up patch for reference.

I built a kernel with the patch. Kensington Slimblade works, now can paste
with the button in the upper left corner. xev(1) detects all buttons.
Scrolling by "twisting" the trackball still works as usual.

The code looks ok thfr@ to me, but better wait for an additional ok from
someone with a bit more familiarity with the usb and hid parts.

> 
> timo
> 
> 
> Index: sys/dev/usb/ums.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ums.c,v
> retrieving revision 1.45
> diff -u -p -u -p -r1.45 ums.c
> --- sys/dev/usb/ums.c 23 Aug 2020 11:08:02 -  1.45
> +++ sys/dev/usb/ums.c 20 Nov 2020 20:22:11 -
> @@ -150,6 +150,8 @@ ums_attach(struct device *parent, struct
>   qflags |= HIDMS_MS_BAD_CLASS;
>   if (quirks & UQ_MS_LEADING_BYTE)
>   qflags |= HIDMS_LEADINGBYTE;
> + if (quirks & UQ_MS_VENDOR_BUTTONS)
> + qflags |= HIDMS_VENDOR_BUTTONS;
>  
>   if (hidms_setup(self, ms, qflags, uha->reportid, desc, size) != 0)
>   return;
> Index: sys/dev/usb/usb_quirks.c
> ===
> RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
> retrieving revision 1.76
> diff -u -p -u -p -r1.76 usb_quirks.c
> --- sys/dev/usb/usb_quirks.c  5 Jan 2020 00:54:13 -   1.76
> +++ sys/dev/usb/usb_quirks.c  20 Nov 2020 20:22:11 -
> @@ -150,6 +150,9 @@ const struct usbd_quirk_entry {
>   { USB_VENDOR_MICROSOFT, USB_PRODUCT_MICROSOFT_WLNOTEBOOK2,
>   ANY, { UQ_MS_BAD_CLASS | UQ_MS_LEADING_BYTE }},
>  
> + { USB_VENDOR_KENSINGTON, USB_PRODUCT_KENSINGTON_SLIMBLADE,
> + ANY, { UQ_MS_VENDOR_BUTTONS }},
> +
>   { 0, 0, 0, { 0 } }
>  };
>  
> Index: sys/dev/usb/usb_quirks.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usb_quirks.h,v
> retrieving revision 1.16
> diff -u -p -u -p -r1.16 usb_quirks.h
> --- sys/dev/usb/usb_quirks.h  19 Jul 2010 05:08:37 -  1.16
> +++ sys/dev/usb/usb_quirks.h  20 Nov 2020 20:22:11 -
> @@ -49,6 +49,8 @@ struct usbd_quirks {
>  #define UQ_MS_LEADING_BYTE   0x0001 /* mouse sends unknown leading byte 
> */
>  #define UQ_EHCI_NEEDTO_DISOWN0x0002 /* must hand device over to 
> USB 1.1
>   if attached to EHCI */
> +#define UQ_MS_VENDOR_BUTTONS 0x0004 /* mouse reports extra buttons in
> + vendor page */
>  };
>  
>  extern const struct usbd_quirks usbd_no_quirk;
> Index: sys/dev/usb/usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.728
> diff -u -p -u -p -r1.728 usbdevs
> --- sys/dev/usb/usbdevs   16 Nov 2020 09:49:10 -  1.728
> +++ sys/dev/usb/usbdevs   20 Nov 2020 20:22:11 -
> @@ -2491,6 +2491,7 @@ product KENSINGTON TURBOBALL0x1005  Turb
>  product KENSINGTON ORBIT_MAC 0x1009  Orbit trackball for Mac
>  product KENSINGTON BT_EDR0x105e  Bluetooth
>  product KENSINGTON VIDEOCAM_VGA  0x5002  VideoCAM VGA
> +product KENSINGTON SLIMBLADE 0x2041  Slimblade Trackball
>  
>  /* Keyspan products */
>  product KEYSPAN USA28_NF 0x0101  USA-28 serial
> Index: sys/dev/usb/usbdevs.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> retrieving revision 1.740
> diff -u -p -u -p -r1.740 usbdevs.h
> --- sys/dev/usb/usbdevs.h 16 Nov 2020 09:49:40 -  1.740
> +++ sys/dev/usb/usbdevs.h 20 Nov 2020 20:22:11 -
> @@ -2498,6 +2498,7 @@
>  #define  USB_PRODUCT_KENSINGTON_ORBIT_MAC0x1009  /* 
> Orbit trackball for Mac */
>  #define  USB_PRODUCT_KENSINGTON_BT_EDR   0x105e  /* Bluetooth */
>  #define  USB_PRODUCT_KENSINGTON_VIDEOCAM_VGA 0x5002  /* 
> VideoCAM VGA */
> +#define  USB_PRODUCT_KENSINGTON_SLIMBLADE0x2041  /* 
> Slimblade Trackball */
>  
>  /* Keyspan products */
>  #define  USB_PRODUCT_KEYSPAN_USA28_NF0x0101  /* USA-28 
> serial */
> Index: sys/dev/usb/usbdevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
> retrieving revision 1.734
> diff -u -p -u -p -r1.734 usbdevs_data.h
> --- sys/dev/usb/usbdevs_data.h16 Nov 2020 09:49:40 -   

relax number of chunks for softraid level 1

[Thomas de Grivel]

Hello,

I couldn't but notice that the requirements on softraid level 1 in
base OpenBSD are actually lower than what the current user interface
returns.

The proposed patch does two things :
 - It relaxes the check for number of chunks for raid level 1 in the kernel
 - it allows building a level 1 array with only one disk.

This patch allows for the following workflow :
 - Install OpenBSD on one disk
 - format another disk as a single chunk RAID1
 - copy the OpenBSD installation on the RAID1 disk
 - check that you can boot on RAID1
 - boot on bsd.rd and copy the single chunk RAID1 disk to the OpenBSD disk
 - reassemble the RAID1 with two disks

It also allows reassembling a RAID1 array with a different number of
chunks, which is terribly useful I think.

-

Index: sbin/bioctl/bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.144
diff -u -p -r1.144 bioctl.c
--- sbin/bioctl/bioctl.c25 Apr 2020 14:37:43 -  1.144
+++ sbin/bioctl/bioctl.c21 Sep 2020 16:38:41 -
@@ -841,7 +841,7 @@ bio_createraid(u_int16_t level, char *de
min_disks = 2;
break;
case 1:
-   min_disks = 2;
+   min_disks = 1;
break;
case 5:
min_disks = 3;
Index: sys/dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.401
diff -u -p -r1.401 softraid.c
--- sys/dev/softraid.c  14 Apr 2020 07:38:21 -  1.401
+++ sys/dev/softraid.c  21 Sep 2020 16:38:42 -
@@ -3413,7 +3413,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
} else {

/* Ensure we are assembling the correct # of chunks. */
-   if (sd->sd_meta->ssdi.ssd_chunk_no != no_chunk) {
+   if (bc->bc_level != 1 &&
sd->sd_meta->ssdi.ssd_chunk_no != no_chunk) {
sr_error(sc, "volume chunk count does not
match metadata "
"chunk count");
goto unwind;
Index: sys/dev/softraid_raid1.c
===
RCS file: /cvs/src/sys/dev/softraid_raid1.c,v
retrieving revision 1.65
diff -u -p -r1.65 softraid_raid1.c
--- sys/dev/softraid_raid1.c12 Apr 2016 16:26:54 -  1.65
+++ sys/dev/softraid_raid1.c21 Sep 2020 16:38:42 -
@@ -76,8 +76,8 @@ int
 sr_raid1_create(struct sr_discipline *sd, struct bioc_createraid *bc,
 int no_chunk, int64_t coerced_size)
 {
-   if (no_chunk < 2) {
-   sr_error(sd->sd_sc, "%s requires two or more chunks",
+   if (no_chunk < 1) {
+   sr_error(sd->sd_sc, "%s requires one or more chunks",
        sd->sd_name);
return EINVAL;
}


-- 
 Thomas de Grivel
 kmx.io
Index: sbin/bioctl/bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.144
diff -u -p -r1.144 bioctl.c
--- sbin/bioctl/bioctl.c	25 Apr 2020 14:37:43 -	1.144
+++ sbin/bioctl/bioctl.c	21 Sep 2020 16:38:41 -
@@ -841,7 +841,7 @@ bio_createraid(u_int16_t level, char *de
 		min_disks = 2;
 		break;
 	case 1:
-		min_disks = 2;
+		min_disks = 1;
 		break;
 	case 5:
 		min_disks = 3;
Index: sys/dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.401
diff -u -p -r1.401 softraid.c
--- sys/dev/softraid.c	14 Apr 2020 07:38:21 -	1.401
+++ sys/dev/softraid.c	21 Sep 2020 16:38:42 -
@@ -3413,7 +3413,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
 	} else {
 
 		/* Ensure we are assembling the correct # of chunks. */
-		if (sd->sd_meta->ssdi.ssd_chunk_no != no_chunk) {
+		if (bc->bc_level != 1 && sd->sd_meta->ssdi.ssd_chunk_no != no_chunk) {
 			sr_error(sc, "volume chunk count does not match metadata "
 			"chunk count");
 			goto unwind;
Index: sys/dev/softraid_raid1.c
===
RCS file: /cvs/src/sys/dev/softraid_raid1.c,v
retrieving revision 1.65
diff -u -p -r1.65 softraid_raid1.c
--- sys/dev/softraid_raid1.c	12 Apr 2016 16:26:54 -	1.65
+++ sys/dev/softraid_raid1.c	21 Sep 2020 16:38:42 -
@@ -76,8 +76,8 @@ int
 sr_raid1_create(struct sr_discipline *sd, struct bioc_createraid *bc,
 int no_chunk, int64_t coerced_size)
 {
-	if (no_chunk < 2) {
-		sr_error(sd->sd_sc, "%s requires two or more chunks",
+	if (no_chunk < 1) {
+		sr_error(sd->sd_sc, "%s requires one or more chunks",
 		sd->sd_name);
 		return EINVAL;
 	}

Re: RFC: kern.video.record

[Thomas Frohwein]

On Sun, Sep 13, 2020 at 09:23:36AM +0100, Laurence Tratt wrote:
> 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

I support this suggestion. I think the idea behind it is based on the
same concerns that led to "kern.audio.record" (though admittedly I
wasn't privy to the conversations leading up to it).

> 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:
> 
>   * Is uvideo the only driver that can capture video? [I imagine not, but I
> don't really know.]
> 
>   * I've taken the same approach as kern.audio.record which is to keep on
> handing out data even when kern.video.record=0 *but* it's harder to work
> out what data we should hand out. At the moment we just pass on whatever
> happened to be in the buffer beforehand (which is clearly not a good
> idea in the long term, but proves the point for now). For uncompressed
> video, handing over (say) an entirely black image is probably easy; for
> compressed video we'd have to think about whether we also want to
> manipulate frame headers etc. It would probably be easier to simply
> intercept the "opening video" event but that would mean that if
> something is already streaming video, setting kern.video.record=0 would
> allow it to keep recording.

I built a kernel and sysctl with this and can confirm it works with my
Logitech C310. Of note, in its current form, running video(1) while
kern.video.record is 0 leads to a window showing mostly green and pink colors.

> 
> Comments welcome, including "this is a terrible idea full stop"!

Again, I'm in favor of this idea.

It might be worth considering combining kern.audio.record and
kern.video.record, as they serve the same purpose (just different
modalities). I doubt that granular controls with separate switches will
be very useful at this level; maybe rather leave this differentiation
to the application?

An added benefit would be that there would be less largely duplicated
code; and probably better maintainability.

> 
> 
> Laurie
> 
> 
> 
> Index: sbin/sysctl/sysctl.c
> ===
> RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
> retrieving revision 1.252
> diff -u -p -r1.252 sysctl.c
> --- sbin/sysctl/sysctl.c  15 Jul 2020 07:13:56 -  1.252
> +++ sbin/sysctl/sysctl.c  13 Sep 2020 08:08:57 -
> @@ -130,6 +130,7 @@ struct ctlname machdepname[] = CTL_MACHD
>  #endif
>  struct ctlname ddbname[] = CTL_DDB_NAMES;
>  struct ctlname audioname[] = CTL_KERN_AUDIO_NAMES;
> +struct ctlname videoname[] = CTL_KERN_VIDEO_NAMES;
>  struct ctlname witnessname[] = CTL_KERN_WITNESS_NAMES;
>  char names[BUFSIZ];
>  int lastused;
> @@ -219,6 +220,7 @@ void print_sensor(struct sensor *);
>  int sysctl_chipset(char *, char **, int *, int, int *);
>  #endif
>  int sysctl_audio(char *, char **, int *, int, int *);
> +int sysctl_video(char *, char **, int *, int, int *);
>  int sysctl_witness(char *, char **, int *, int, int *);
>  void vfsinit(void);
>  
> @@ -517,6 +519,11 @@ parse(char *string, int flags)
>   if (len < 0)
>   return;
>   break;
> + case KERN_VIDEO:
> + len = sysctl_video(string, , mib, flags, );
> + if (len < 0)
> + return;
> + break;
>   case KERN_WITNESS:
>   len = sysctl_witness(string, , mib, flags, );
>   if (len < 0)
> @@ -1766,6 +1773,7 @@ struct list shmlist = { shmname, KERN_SH
>  struct list watchdoglist = { watchdogname, KERN_WATCHDOG_MAXID };
>  struct list tclist = { tcname, KERN_TIMECOUNTER_MAXID };
>  struct list audiolist = { audioname, KERN_AUDIO_MAXID };
> +struct list videolist = { audioname, KERN_VIDEO_MAXID };
>  struct list witnesslist = { witnessname, KERN_WITNESS_MAXID };
>  
>  /*
> @@ -2813,6 +2821,25 @@ sysctl_audio(char *string, char **bufpp,
>   return (-1);
>   mib[2] = indx;
>   *typep = audiolist.list[indx].ctl_type;
> + return (3);
> +}
> +
> +/*
> + * Handle video support
> + */
> +int
> +sysctl_video(char *string, char **bufpp, int mib[], int flags, int *typep)
> +{
> + int indx;
> +
> + if (*bufpp == NULL) {
> + listall(string, );
> + return (-1);
> + }
> + if ((indx = findname(string, "third", bufpp, )) == -1)
> + return (-1);
> + mib[2] = indx;
> + *typep = videolist.list[indx].ctl_type;
>   return (3);
>  }
>  
> Index: sys/dev/usb/uvideo.c
> ===
> RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
> retrieving revision 1.209
> diff -u -p -r1.209 uvideo.c
> --- sys/dev/usb/uvideo.c  31 Jul 2020 

$pexp in re.subr(8)

[Thomas Levine]

The present patch changes the rc.subr(8) manual page to match
the implementation.

The current manual page for rc.subr(8) says that $pexp is "A regular
expression to be passed to pgrep(1) in order to find the desired process
or to be passed to pkill(1) to stop it."

The file /etc/rc.d/rc.subr currently uses $pexp only as a fixed
expression, with the -xf flags.

  > grep pexp /etc/rc.d/rc.subr
  pexp=${pexp}
  multicast nfs_server pexp pf pkg_scripts shlib_dirs spamd_black
pgrep -T "${daemon_rtable}" -q -xf "${pexp}"
pkill -HUP -T "${daemon_rtable}" -xf "${pexp}"
pkill -T "${daemon_rtable}" -xf "${pexp}"
  # make sure pexp matches the process (i.e. doesn't include the quotes)
  pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"

The -xf flags are explained in the pgrep(1) and pkill(1) man page.

-x  Require an exact match of the process name, or argument
list if -f is given.  The default is to match any substring.

The present patch replaces instances of "regular expression" with
"fixed expression".

I also think a better phrasing would be to explain in the rc.subr(8)
man page that $pexp is a substring of the process name with flags and
that it uses pgrep with -xf. I might eventually do that in a separate
patch.


Index: rc.subr.8
===
RCS file: /cvs/src/share/man/man8/rc.subr.8,v
retrieving revision 1.37
diff -u -p -r1.37 rc.subr.8
--- rc.subr.8   21 Feb 2020 00:47:21 -  1.37
+++ rc.subr.8   7 Aug 2020 00:46:34 -
@@ -184,7 +184,7 @@ call
 .It Ic rc_check
 Search for processes of the service with
 .Xr pgrep 1
-using the regular expression given in the
+using the fixed expression given in the
 .Va pexp
 variable.
 .It Ic rc_start
@@ -199,7 +199,7 @@ Send a
 .Dv SIGTERM
 signal using
 .Xr pkill 1
-on the regular expression given in the
+on the fixed expression given in the
 .Va pexp
 variable.
 .It Ic rc_reload
@@ -207,7 +207,7 @@ Send a
 .Dv SIGHUP
 signal using
 .Xr pkill 1
-on the regular expression given in the
+on the fixed expression given in the
 .Va pexp
 variable.
 One has to make sure that sending
@@ -267,7 +267,7 @@ functions.
 User to run the daemon as, using
 .Xr su 1 .
 .It Va pexp
-A regular expression to be passed to
+A fixed expression to be passed to
 .Xr pgrep 1
 in order to find the desired process or to be passed to
 .Xr pkill 1

Re: Compiler warning in ctype.h

[Thomas de Grivel]

Hello,

I was using base gcc but switching to base clang fixes the warnings on
-current at least.
Is base gcc not supported anymore ?

Sorry for the noise.

Cheers,

Le jeu. 5 mars 2020 à 16:59, Theo de Raadt  a écrit :
>
> Todd C. Miller  wrote:
>
> > On Thu, 05 Mar 2020 16:07:48 +0100, Thomas de Grivel wrote:
> >
> > > Actually I see the same problem on 6.6-stable :
> > > including readline/readline.h produces warnings.
> > >
> > > Any -Werror hope some day ?
> >
> > You still haven't bothered to include:
> >
> > 1) the compiler you are using
> > 2) the compiler flags to reproduce the problem
> > 3) a sample program to reproduce the problem
> >
> > The _l parameter in those inline functions already has the __unused__
> > attribute set which is supposed to suppress those warnings.
> >
> > I can't reproduce this using clang (base or ports) or gcc (base or
> > ports) using -Wall, -Wextra and -Wunused-parameter.  But since you
> > haven't provided any details, we just have to guess at what you are
> > doing.
>
> Or not guess, but simply delete the mail



-- 
 Thomas de Grivel
 kmx.io

Re: Compiler warning in ctype.h

[Thomas de Grivel]

Actually I see the same problem on 6.6-stable :
including readline/readline.h produces warnings.

Any -Werror hope some day ?

cheers

Le mer. 4 mars 2020 à 13:41, Thomas de Grivel  a écrit :
>
> With latest OpenBSD snapshot on amd64
>
> In file included from /usr/include/readline/chardefs.h:26,
>  from /usr/include/readline/keymaps.h:36,
>  from /usr/include/readline/readline.h:38,
>  from cli.c:21:
> /usr/include/ctype.h:216: warning: unused parameter '_l'
> /usr/include/ctype.h:222: warning: unused parameter '_l'
> /usr/include/ctype.h:228: warning: unused parameter '_l'
> /usr/include/ctype.h:234: warning: unused parameter '_l'
> /usr/include/ctype.h:240: warning: unused parameter '_l'
> /usr/include/ctype.h:246: warning: unused parameter '_l'
> /usr/include/ctype.h:252: warning: unused parameter '_l'
> /usr/include/ctype.h:258: warning: unused parameter '_l'
> /usr/include/ctype.h:264: warning: unused parameter '_l'
> /usr/include/ctype.h:270: warning: unused parameter '_l'
> /usr/include/ctype.h:276: warning: unused parameter '_l'
> /usr/include/ctype.h:282: warning: unused parameter '_l'
> /usr/include/ctype.h:288: warning: unused parameter '_l'
> /usr/include/ctype.h:294: warning: unused parameter '_l'
>
> --
>  Thomas de Grivel
>  kmx.io



-- 
 Thomas de Grivel
 kmx.io

Re: amdgpu (and possible radeondrm) fix

[Thomas de Grivel]

softraid0: 256 targets
root on sd0a (b800c95e55295e8f.a) swap on sd0b dump on sd0b
iwm0: hw rev 0x320, fw ver 34.3125811985.0, address 7c:b2:7d:1f:e4:ba
initializing kernel modesetting (RAVEN 0x1002:0x15D8 0x17AA:0x5125 0xD1).
amdgpu0: 1920x1080, 32bpp
wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhub0 detached
ugen0 detached
video0 detached
uvideo0 detached
video1 detached
uvideo1 detached
uhub2 detached
uhub1 detached
iwm0: acquiring device failed
uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev
3.00/1.00 addr 1
uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev
3.00/1.00 addr 1
ugen0 at uhub1 port 1 "Intel Bluetooth" rev 2.00/0.02 addr 2
uhub2 at uhub1 port 2 configuration 1 interface 0 "Genesys Logic
USB2.0 Hub" rev 2.00/60.52 addr 3
uvideo0 at uhub2 port 1 configuration 1 interface 0 "Chicony
Electronics Co.,Ltd. Integrated Camera" rev 2.01/67.23 addr 4
video0 at uvideo0
uvideo1 at uhub2 port 1 configuration 1 interface 2 "Chicony
Electronics Co.,Ltd. Integrated Camera" rev 2.01/67.23 addr 4
video1 at uvideo1

Le jeu. 23 janv. 2020 à 04:51, Thomas Frohwein
 a écrit :
>
> On Tue, Jan 21, 2020, at 7:10 PM, Mark Kettenis wrote:
> > The attached diff fixes amdgpu(4) and might very well fix radeondrm(4)
> > as well.
> [...]
>
> For the record, this fixes running piglit with radeon on my HD7570 since this
> was committed. It used to lock up on the test spec/arb_sync/sync_api, but
> now piglit completes. I haven't done further investigations how that may be
> related, but though it may be good to know that this means progress with
> the piglit testing suite.
> --
>
> tfrohw...@fastmail.com
>
> PGP Public Key: 
> https://pgp.mit.edu/pks/lookup?op=get=0xE1A22D58D20C6D22
>


-- 
 Thomas de Grivel
 kmx.io

Re: amdgpu (and possible radeondrm) fix

[Thomas Frohwein]

On Tue, Jan 21, 2020, at 7:10 PM, Mark Kettenis wrote:
> The attached diff fixes amdgpu(4) and might very well fix radeondrm(4) 
> as well.  
[...]

For the record, this fixes running piglit with radeon on my HD7570 since this
was committed. It used to lock up on the test spec/arb_sync/sync_api, but
now piglit completes. I haven't done further investigations how that may be
related, but though it may be good to know that this means progress with
the piglit testing suite.
-- 
  
tfrohw...@fastmail.com

PGP Public Key: https://pgp.mit.edu/pks/lookup?op=get=0xE1A22D58D20C6D22

Re: login_passwd: reject challenge service

[Thomas L.]

On Thu, 5 Dec 2019 13:35:40 +
"Lindner, Thomas 1. (Nokia - DE/Nuremberg)"
 wrote:
> The (untested) patch below makes login_passwd behave as described in
> the manpage.

I've now been able to test the patch and login/su/doas/ssh still work
as expected. All the other login_* styles in base are well behaved. Is
there a reason that this should not be done?

Kind regards,

Thomas

diff --git libexec/login_passwd/login.c libexec/login_passwd/login.c
index 09e683a7366..486d8bfcb8a 100644
--- libexec/login_passwd/login.c
+++ libexec/login_passwd/login.c
@@ -137,7 +137,7 @@ main(int argc, char **argv)
password = readpassphrase("Password:", pbuf,
sizeof(pbuf), RPP_ECHO_OFF); break;
case MODE_CHALLENGE:
-   fprintf(back, BI_AUTH "\n");
+   fprintf(back, BI_SILENT "\n");
exit(0);
break;
default:

login_passwd: reject challenge service

[Lindner, Thomas 1. (Nokia - DE/Nuremberg)]

Hi,

I read https://www.openwall.com/lists/oss-security/2019/12/04/5 and wondered
how the authentication bypass was possible, since the manpage says:
 If this style of authentication does not support challenge response, but
 does support the response service (described below) it should issue
 reject silent and then exit with a 0 status.

So I checked and indeed:
#  /usr/libexec/auth/login_passwd -schallenge foo 3>&1  
   
authorize

The (untested) patch below makes login_passwd behave as described in the 
manpage.

Kind regards,

Thomas

diff --git libexec/login_passwd/login.c libexec/login_passwd/login.c
index 09e683a7366..486d8bfcb8a 100644
--- libexec/login_passwd/login.c
+++ libexec/login_passwd/login.c
@@ -137,7 +137,7 @@ main(int argc, char **argv)
password = readpassphrase("Password:", pbuf, sizeof(pbuf), 
RPP_ECHO_OFF);
break;
case MODE_CHALLENGE:
-   fprintf(back, BI_AUTH "\n");
+   fprintf(back, BI_SILENT "\n");
exit(0);
break;
default:

Re: syscall call-from verification

[Thomas de Grivel]

My bad, SBCL uses the libc's wrappers indeed looking at the sources.

Le ven. 29 nov. 2019 à 22:41, Josh Elsasser  a écrit :
>
> On Fri, Nov 29, 2019 at 10:12:10AM +0100, Thomas de Grivel wrote:
> > Maybe Go is not the only problem, I see SBCL compiling syscalls too.
> >
> > Truth is libc is for C and not all programs are written in C nowadays.
>
> Where are you seeing SBCL compiling direct syscalls? In my testing,
> SBCL self-hosts just fine under a kernel modified to disallow syscalls
> from the text segment, whereas go is killed under such a kernel. Are
> you sure you're not seeing SBCL compile calls to the libc syscall
> wrappers?



-- 
 Thomas de Grivel
 kmx.io

Re: syscall call-from verification

[Thomas de Grivel]

Maybe Go is not the only problem, I see SBCL compiling syscalls too.

Truth is libc is for C and not all programs are written in C nowadays.

Le jeu. 28 nov. 2019 à 21:04, Theo de Raadt  a écrit :
>
> Miod Vallat  wrote:
>
> > > For dynamic binaries, valid regions are ld.so's text segment, the signal
> > > trampoline, and libc.so's text segment... AND the main program's text.
> > >
> > > Unfortunately our current go build model hasn't followed solaris/macos
> > > approach yet of calling libc stubs, and uses the inappropriate "embed
> > > system calls directly" method, so for now we'll need to authorize the main
> > > program text as well.  A comment in exec_elf.c explains this.
> > >
> > > If go is adapted to call library-based system call stubs on OpenBSD as
> > > well, this problem will go away.  There may be other environments creating
> > > raw system calls. I guess we'll need to find them as time goes by, and
> > > hope in time we can repair those also.
> >
> > Or you could use an ELF note to flag binaries allowed to issue syscalls
> > from their text section: only static binaries (including ld.so) and go
> > binaries would need them.
>
> Imagine a ld.so without the flag.  The kernel starts a userland process 
> running
> there.  So ld.so must be able to issue system calls
>
> Imagine a static binary without the flag.  It would fail.
>
> The kernel can alreayd identify these circumstances, and does not need a flag.
>
> The only special case is libc.so.  We discussed adding a linker option to add
> a note to libc.  And then build tooling to add the flag for libc.  And then 
> ld.so
> identification of this note.  But does it actually matter which way this is 
> done?
>
> I fear the option would be abused for other purposes.  In the future,
> why would we want programs doing system calls from other segments?  Are
> there any legitimate compelling reasons to avoid calling the libc stubs?
> I don't believe so.  Especially if those segments are in network facing
> programs and/or generated on the fly.  At worst a nasty JIT can generate code
> to call & of libc syscall(2) stub with SYS_* symbolic names.  That approach
> remains simple and workable for the developer, but somewhat more difficult for
> an attacker who not know the relevant locations.
>


-- 
 Thomas de Grivel
 kmx.io

Re: [PATCH] remove sysctl net.mpls.maxloop_inkernel

[thomas]

(adding claudio as the most recent contributor)

As per https://marc.info/?l=openbsd-misc=157191651123338=2 this is
no longer used and can be removed.

Before:
$ sysctl -a | grep mpls
net.mpls.ttl=255
net.mpls.maxloop_inkernel=16
net.mpls.mapttl_ip=1
net.mpls.mapttl_ip6=0

After:
$ sysctl -a | grep mpls
net.mpls.ttl=255
net.mpls.mapttl_ip=1
net.mpls.mapttl_ip6=0

--
typedef struct me_s {
  char name[]  = { "Thomas Habets" };
  char email[] = { "tho...@habets.se" };
  char kernel[]= { "Linux" };
  char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt; };
  char pgp[] = { "9907 8698 8A24 F52F 1C2E  87F6 39A4 9EEA 460A 0169" };
  char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;


diff --git netmpls/mpls.h netmpls/mpls.h
index 55c53a6d1d9..cbffd2a7baa 100644
--- netmpls/mpls.h
+++ netmpls/mpls.h
@@ -110,7 +110,6 @@ struct rt_mpls {
  */
 #define MPLSCTL_ENABLE 1
 #defineMPLSCTL_DEFTTL  2
-#defineMPLSCTL_MAXINKLOOP  4
 #define MPLSCTL_MAPTTL_IP  5
 #define MPLSCTL_MAPTTL_IP6 6
 #define MPLSCTL_MAXID  7
@@ -120,7 +119,7 @@ struct rt_mpls {
{ NULL, 0 }, \
{ "ttl", CTLTYPE_INT }, \
{ "ifq", CTLTYPE_NODE },\
-   { "maxloop_inkernel", CTLTYPE_INT }, \
+   { NULL, 0 }, \
{ "mapttl_ip", CTLTYPE_INT }, \
{ "mapttl_ip6", CTLTYPE_INT } \
 }
@@ -130,7 +129,7 @@ struct rt_mpls {
NULL, \
_defttl, \
NULL, \
-   _inkloop, \
+   NULL, \
_mapttl_ip, \
_mapttl_ip6 \
 }
@@ -161,7 +160,6 @@ extern  struct domain mplsdomain;
 extern int mpls_defttl;
 extern int mpls_mapttl_ip;
 extern int mpls_mapttl_ip6;
-extern int mpls_inkloop;


 struct mbuf*mpls_shim_pop(struct mbuf *);
diff --git netmpls/mpls_raw.c netmpls/mpls_raw.c
index 6d3a3fab105..67143d4f53a 100644
--- netmpls/mpls_raw.c
+++ netmpls/mpls_raw.c
@@ -46,7 +46,6 @@
 #include 

 int mpls_defttl = 255;
-int mpls_inkloop = MPLS_INKERNEL_LOOP_MAX;
 int mpls_push_expnull_ip = 0;
 int mpls_push_expnull_ip6 = 0;
 int mpls_mapttl_ip = 1;

[PATCH] remove sysctl net.mpls.maxloop_inkernel

[thomas]

As per https://marc.info/?l=openbsd-misc=157191651123338=2 this is
no longer used and can be removed.

Before:
$ sysctl -a | grep mpls
net.mpls.ttl=255
net.mpls.maxloop_inkernel=16
net.mpls.mapttl_ip=1
net.mpls.mapttl_ip6=0

After:
$ sysctl -a | grep mpls
net.mpls.ttl=255
net.mpls.mapttl_ip=1
net.mpls.mapttl_ip6=0

--
typedef struct me_s {
  char name[]  = { "Thomas Habets" };
  char email[] = { "tho...@habets.se" };
  char kernel[]= { "Linux" };
  char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt; };
  char pgp[] = { "9907 8698 8A24 F52F 1C2E  87F6 39A4 9EEA 460A 0169" };
  char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;


diff --git netmpls/mpls.h netmpls/mpls.h
index 55c53a6d1d9..cbffd2a7baa 100644
--- netmpls/mpls.h
+++ netmpls/mpls.h
@@ -110,7 +110,6 @@ struct rt_mpls {
  */
 #define MPLSCTL_ENABLE 1
 #defineMPLSCTL_DEFTTL  2
-#defineMPLSCTL_MAXINKLOOP  4
 #define MPLSCTL_MAPTTL_IP  5
 #define MPLSCTL_MAPTTL_IP6 6
 #define MPLSCTL_MAXID  7   
@@ -120,7 +119,7 @@ struct rt_mpls {
{ NULL, 0 }, \
{ "ttl", CTLTYPE_INT }, \
{ "ifq", CTLTYPE_NODE },\
-   { "maxloop_inkernel", CTLTYPE_INT }, \
+   { NULL, 0 }, \
{ "mapttl_ip", CTLTYPE_INT }, \
{ "mapttl_ip6", CTLTYPE_INT } \
 }
@@ -130,7 +129,7 @@ struct rt_mpls {
NULL, \
_defttl, \
NULL, \
-   _inkloop, \
+   NULL, \
_mapttl_ip, \
_mapttl_ip6 \
 }
@@ -161,7 +160,6 @@ extern  struct domain mplsdomain;
 extern int mpls_defttl;
 extern int mpls_mapttl_ip;
 extern int mpls_mapttl_ip6;
-extern int mpls_inkloop;


 struct mbuf*mpls_shim_pop(struct mbuf *);
diff --git netmpls/mpls_raw.c netmpls/mpls_raw.c
index 6d3a3fab105..67143d4f53a 100644
--- netmpls/mpls_raw.c
+++ netmpls/mpls_raw.c
@@ -46,7 +46,6 @@
 #include 

 int mpls_defttl = 255;
-int mpls_inkloop = MPLS_INKERNEL_LOOP_MAX;
 int mpls_push_expnull_ip = 0;
 int mpls_push_expnull_ip6 = 0;
 int mpls_mapttl_ip = 1;

Re: [PATCH] ksh: Fail gracefully if sethistsize() fails

[thomas]

On Sat, 19 Oct 2019 16:32:56 +0100, Jeremie Courreges-Anglas
 said:
> > Before:
> > $ HISTSIZE=10 /bin/sh
> > /bin/sh: internal error: unable to allocate memory
> >   <--- no ksh
> Could you provide more details please?  A fatal error and a crash are
> very different problems.

Yes, it's a fatal error resulting in a termination since nothing
"catches" the internal_errorf() from the allocation failure.

> Does "no ksh" imply that the *current* shell
> exited or crashed, leaving you with no shell at all?

It does not crash the current shell. But if the current shell is not
ksh, then the experience is:

bash$ /bin/sh
ksh: internal error: unable to allocate memory
bash$

Which is not hugely informative. My actual experience was that running
"some commands" failed with this error, because they ran shell scripts
either directly or indirectly. So I was not directly running ksh or
/bin/sh when I first got these errors.

I don't have a specific use case where this would lock you out of
troubleshooting, but seems plausible.

> Note that setting HISTSIZE like this affects your *current* shell and
> prevents it to run /bin/sh.  Use env to only affect the child shell:

My current shell is usually bash, which handles large HISTSIZE (I
don't know if by mmaping the file, a capped effective size, or some
other way).

> Your diff doesn't apply as is.

Sorry about that. I used github.com/openbsd/src HEAD, and am looking
forward to got (https://gameoftrees.org/). Maybe I still screwed up somehow.

> After applying it, the child ksh will
> indeed keep running even if setting HISTSIZE fails.  But it reliably
> crashes on exit if HISTSIZE was set in its startup environment:
>
> --8<--
> ritchie /usr/src/bin/ksh$ env ENV=/dev/null HISTFILE=ksh_history 
> HISTSIZE=1000 obj/ksh
> ritchie$ ^D
> Unable to set the history size to 0
> Trace/BPT trap (core dumped)
> -->8--

Confirmed that I made it crash on exit if and only if the HISTSIZE is
*low*. I was missing a quitenv(NULL) as the last line in
sethistsize(). After adding that it works as it should for both normal
and oversized HISTSIZE.

I'm not familiar with the "environment" concept in the code, and could
not find it documented, thus missed that.

> I think we can do ourselves a favor and not involve unwinding/setjmps
> for this simple error case.
> Using alloc.c to allocate histbase is not useful,

That would be ideal, yes, if there's no reason to use alloc.c here.

> so just switch to reallocarray.  Allocation failure at startup
> is still fatal because the code can't cope with a NULL history array.
>
> ok?

Yeah, that looks better, and I can confirm that it works as expected
for me now, both for small and large HISTSIZE.

I don't know what the general philosophy of footguns are for you, but
a cap on HISTSIZE could prevent someone having ksh consume 764MB RAM
(as seen by top with HISTSIZE=1).

Thanks!

>
>
> Index: history.c
> ===
> RCS file: /cvs/src/bin/ksh/history.c,v
> retrieving revision 1.82
> diff -u -p -r1.82 history.c
> --- history.c 28 Jun 2019 13:34:59 -  1.82
> +++ history.c 19 Oct 2019 15:29:04 -
> @@ -554,6 +554,7 @@ void
>  sethistsize(int n)
>  {
>   if (n > 0 && (uint32_t)n != histsize) {
> + char **tmp;

why not void* ?

>   int offset = histptr - history;
>
>   /* save most recent history */
> @@ -566,10 +567,15 @@ sethistsize(int n)
>   memmove(history, histptr - offset, n * sizeof(char *));
>   }
>
> - histsize = n;
> - histbase = areallocarray(histbase, n + 1, sizeof(char *), 
> APERM);
> - history = histbase + 1;
> - histptr = history + offset;
> + tmp = reallocarray(histbase, n + 1, sizeof(char *));
> + if (tmp != NULL) {
> + histbase = tmp;
> + histsize = n;
> + history = histbase + 1;
> + histptr = history + offset;
> + } else
> + warningf(false, "resizing history storage: %s",
> + strerror(errno));
>   }
>  }
>
> @@ -613,8 +619,10 @@ init_histvec(void)
>* allocate one extra element so that histptr always
>* lies within array bounds
>*/
> - histbase = areallocarray(NULL, histsize + 1, sizeof(char *),
> - APERM);
> + histbase = reallocarray(NULL, histsize + 1, sizeof(char *));
> + if (histbase == NULL)
> + internal_errorf("allocating history st

[PATCH] ksh: Fail gracefully if sethistsize() fails

[thomas]

This can be hard to debug, and could indeed prevent debugging, since
it can take out the ability to run /bin/sh, depending on how you've
set up your environment.

Before:
$ HISTSIZE=10 /bin/sh
/bin/sh: internal error: unable to allocate memory
  <--- no ksh

With this pa
$ HISTSIZE=10 ./ksh
./ksh: internal error: unable to allocate 16+88 bytes of memory
Unable to set the history size to 10
hostname$ ^D   <--- ksh running

diff --git a/bin/ksh/alloc.c b/bin/ksh/alloc.c
index 204e835890c..6e29e2eb3fe 100644
--- a/bin/ksh/alloc.c
+++ b/bin/ksh/alloc.c
@@ -97,7 +97,7 @@ aresize(void *ptr, size_t size, Area *ap)

l2 = realloc(l, sizeof(struct link) + size);
if (l2 == NULL)
-   internal_errorf("unable to allocate memory");
+   internal_errorf("unable to allocate %lu+%lu bytes of memory",
sizeof(struct link), size);
if (lprev)
lprev->next = l2;
else
diff --git a/bin/ksh/history.c b/bin/ksh/history.c
index a3a8b60cc76..3bd6444d7a9 100644
--- a/bin/ksh/history.c
+++ b/bin/ksh/history.c
@@ -549,10 +549,17 @@ sethistcontrol(const char *str)
 /*
  * set history
  * this means reallocating the dataspace
+ * if memory allocation fails then history size will remain unchanged
  */
 void
 sethistsize(int n)
 {
+   newenv(E_FUNC);
+   if (sigsetjmp(genv->jbuf, 0)) {
+   fprintf(stderr, "Unable to set the history size to %d\n", n);
+   quitenv(NULL);
+   return;
+   }
if (n > 0 && (uint32_t)n != histsize) {
int offset = histptr - history;

@@ -566,8 +573,8 @@ sethistsize(int n)
memmove(history, histptr - offset, n * sizeof(char *));
}

-   histsize = n;
histbase = areallocarray(histbase, n + 1, sizeof(char *), 
APERM);
+   histsize = n;
history = histbase + 1;
histptr = history + offset;
}

Re: 64-bit dma for drm(4) on amd64

[Thomas Frohwein]

On Thu, Jun 06, 2019 at 11:41:07PM +0200, Mark Kettenis wrote:
[...]
> It seems to work fine on my Intel Broadwell laptop.  I haven't tested
> this on radeon(4) yet.  So further testing, especially on systems with
> 4GB of memory or more is necessary.
> 
> Please test.

Tested on a desktop with 8GB RAM and amdgpu enabled (GPU is a Vega 64,
but that may not be relevant). I'm attaching dmesg below. Tested for
about 2 hours with some Chrome, some Firefox, mono... No regression
noticed. The situations where the display freezes were encountered as
before building the kernel with this patch, that is with Chrome after a
while with Google Maps (one of the most reliable triggers). Also with
`piglit run all results/all` after 39 tests (dmafence on wait channel
again).

If there's more that would help testing or reporting, I'm happy to.

> 
> 
> Index: arch/amd64/amd64/bus_dma.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/bus_dma.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 bus_dma.c
> --- arch/amd64/amd64/bus_dma.c14 Oct 2017 04:44:43 -  1.50
> +++ arch/amd64/amd64/bus_dma.c6 Jun 2019 21:19:21 -
> @@ -319,7 +319,8 @@ _bus_dmamap_load_raw(bus_dma_tag_t t, bu
>   if (plen < sgsize)
>   sgsize = plen;
>  
> - if (paddr > dma_constraint.ucr_high)
> + if (paddr > dma_constraint.ucr_high &&
> + (map->_dm_flags & BUS_DMA_64BIT) == 0)
>   panic("Non dma-reachable buffer at paddr 
> %#lx(raw)",
>   paddr);
>  
> @@ -583,7 +584,8 @@ _bus_dmamap_load_buffer(bus_dma_tag_t t,
>*/
>   pmap_extract(pmap, vaddr, (paddr_t *));
>  
> - if (curaddr > dma_constraint.ucr_high)
> + if (curaddr > dma_constraint.ucr_high &&
> + (map->_dm_flags & BUS_DMA_64BIT) == 0)
>   panic("Non dma-reachable buffer at curaddr %#lx(raw)",
>   curaddr);
>  
> Index: dev/pci/drm/drm_linux.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 drm_linux.c
> --- dev/pci/drm/drm_linux.c   4 Jun 2019 12:08:22 -   1.37
> +++ dev/pci/drm/drm_linux.c   6 Jun 2019 21:19:21 -
> @@ -293,16 +293,19 @@ struct vm_page *
>  alloc_pages(unsigned int gfp_mask, unsigned int order)
>  {
>   int flags = (gfp_mask & M_NOWAIT) ? UVM_PLA_NOWAIT : UVM_PLA_WAITOK;
> + struct uvm_constraint_range *constraint = _constraint;
>   struct pglist mlist;
>  
>   if (gfp_mask & M_CANFAIL)
>   flags |= UVM_PLA_FAILOK;
>   if (gfp_mask & M_ZERO)
>   flags |= UVM_PLA_ZERO;
> + if (gfp_mask & __GFP_DMA32)
> + constraint = _constraint;
>  
>   TAILQ_INIT();
> - if (uvm_pglistalloc(PAGE_SIZE << order, dma_constraint.ucr_low,
> - dma_constraint.ucr_high, PAGE_SIZE, 0, , 1, flags))
> + if (uvm_pglistalloc(PAGE_SIZE << order, constraint->ucr_low,
> + constraint->ucr_high, PAGE_SIZE, 0, , 1, flags))
>   return NULL;
>   return TAILQ_FIRST();
>  }
> Index: dev/pci/drm/include/linux/gfp.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/include/linux/gfp.h,v
> retrieving revision 1.1
> diff -u -p -r1.1 gfp.h
> --- dev/pci/drm/include/linux/gfp.h   14 Apr 2019 10:14:53 -  1.1
> +++ dev/pci/drm/include/linux/gfp.h   6 Jun 2019 21:19:21 -
> @@ -7,24 +7,25 @@
>  #include 
>  #include 
>  
> -#define GFP_ATOMIC   M_NOWAIT
> -#define GFP_NOWAIT   M_NOWAIT
> -#define GFP_KERNEL   (M_WAITOK | M_CANFAIL)
> -#define GFP_USER (M_WAITOK | M_CANFAIL)
> -#define GFP_TEMPORARY(M_WAITOK | M_CANFAIL)
> -#define GFP_HIGHUSER 0
> -#define GFP_DMA320
> -#define __GFP_NOWARN 0
> -#define __GFP_NORETRY0
> -#define __GFP_ZERO   M_ZERO
> +#define __GFP_ZERO   M_ZERO
> +#define __GFP_DMA32  0x8000
> +#define __GFP_NOWARN 0
> +#define __GFP_NORETRY0
>  #define __GFP_RETRY_MAYFAIL  0
>  #define __GFP_MOVABLE0
>  #define __GFP_COMP   0
> -#define GFP_TRANSHUGE_LIGHT  0
>  #define __GFP_KSWAPD_RECLAIM 0
>  #define __GFP_HIGHMEM0
>  #define __GFP_RECLAIMABLE0
> -#define __GFP_DMA32  0
> +
> +#define GFP_ATOMIC   M_NOWAIT
> +#define GFP_NOWAIT   M_NOWAIT
> +#define GFP_KERNEL   (M_WAITOK | M_CANFAIL)
> +#define GFP_USER (M_WAITOK | M_CANFAIL)
> +#define GFP_TEMPORARY(M_WAITOK | M_CANFAIL)
> +#define GFP_HIGHUSER 0
> +#define GFP_DMA32__GFP_DMA32
> +#define GFP_TRANSHUGE_LIGHT  0
>  
>  static inline bool
>  gfpflags_allow_blocking(const unsigned int flags)
> Index: 

acme-client: renewal fails

[Lindner, Thomas 1. (Nokia - DE/Nuremberg)]

etsencrypt.org: cached
acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value": "l=
ists.dl6tom.de" }, "status": "pending", "expires": "2019-01-29T18:21:10Z", =
"challenges": [ { "type": "tls-sni-01", "status": "pending", "uri": "https:=
//acme-v01.api.letsencrypt.org/acme/challenge/x1Rh_VhMUuYxk_v22zHe32fL2zh7s=
RNh2LSKFNwkqxA/11749932856", "token": "pedbWPKfQ3SS_6EB1nZUz8vMOjLXyVsq_W7a=
ALRaVbE" }, { "type": "http-01", "status": "pending", "uri": "https://acme-=
v01.api.letsencrypt.org/acme/challenge/x1Rh_VhMUuYxk_v22zHe32fL2zh7sRNh2LSK=
FNwkqxA/11749932858", "token": "FF1lMKPyjmEeEURPWUyLwBe8ZRj3ozkdUGkyfOmGT5s=
" }, { "type": "dns-01", "status": "pending", "uri": "https://acme-v01.api.=
letsencrypt.org/acme/challenge/x1Rh_VhMUuYxk_v22zHe32fL2zh7sRNh2LSKFNwkqxA/=
11749932860", "token": "Fc-aeqzccqH82AKNN2vJ3KY6u_jBV0yzXEpVd3yFuCo" }, { "=
type": "tls-alpn-01", "status": "pending", "uri": "https://acme-v01.api.let=
sencrypt.org/acme/challenge/x1Rh_VhMUuYxk_v22zHe32fL2zh7sRNh2LSKFNwkqxA/117=
49932862", "token": "NuPrsMpxl05_qBBWjog2_ogK1w-VptNsECjwSatGfAE" } ], "com=
binations": [ [ 2 ], [ 1 ], [ 0 ], [ 3 ] ] }] (1271 bytes) =
  =20
acme-client: /var/www/acme/FF1lMKPyjmEeEURPWUyLwBe8ZRj3ozkdUGkyfOmGT5s: cre=
ated
acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/x1Rh_VhMUu=
Yxk_v22zHe32fL2zh7sRNh2LSKFNwkqxA/11749932858: challenge   =
   =
  =20
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: transfer buffer: [{ "type": "http-01", "status": "pending", "u=
ri": "https://acme-v01.api.letsencrypt.org/acme/challenge/x1Rh_VhMUuYxk_v22=
zHe32fL2zh7sRNh2LSKFNwkqxA/11749932858", "token": "FF1lMKPyjmEeEURPWUyLwBe8=
ZRj3ozkdUGkyfOmGT5s", "keyAuthorization": "FF1lMKPyjmEeEURPWUyLwBe8ZRj3ozkd=
UGkyfOmGT5s.YJLLEKdoM4e4WocQ9C9xvXqa6dAO4zUn6hdCgEgIfBs" }] (337 bytes)=
   =
  =20
acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/x1Rh_VhMUu=
Yxk_v22zHe32fL2zh7sRNh2LSKFNwkqxA/11749932858: status  =
   =
  =20
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: certificat=
e
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: acme-v01.api.letsencrypt.org: cached
acme-client: https://acme-v01.api.letsencrypt.org/acme/new-cert: bad HTTP: =
403
acme-client: transfer buffer: [{ "type": "urn:acme:error:unauthorized", "de=
tail": "Error creating new cert :: authorizations for these names not found=
 or expired: lists.dl6tom.de", "status": 403 }] (171 bytes)=
  =20
acme-client: bad exit: netproc(64946): 1

The token in /var/www/acme seems fine as far as I am able to judge:
# cat /var/www/acme/FF1lMKPyjmEeEURPWUyLwBe8ZRj3ozkdUGkyfOmGT5s
FF1lMKPyjmEeEURPWUyLwBe8ZRj3ozkdUGkyfOmGT5s.YJLLEKdoM4e4WocQ9C9xvXqa6dAO4zU=
n6hdCgEgIfBs

Kind regards

Thomas Lindner

Re: vmd console freeze and locked (?) qcow2 image

[Thomas L.]

On Sat, 5 Jan 2019 17:56:01 -0800
Mike Larkin  wrote:
> Did you kill all the old vmd processes?
> 
> -ml
> 

I tested again and it works now. There were restarts in between.
I will try killing vmd processes if this happens again, thanks.

Kind regards,

Thomas

vmd console freeze and locked (?) qcow2 image

[Thomas L.]

Hi,

I am running -current and installed Arch Linux on vmd.
Unfortunatly, after a while the vmd console freezes.
I tried stoping the vm with vmctl stop, but it keept hanging (maybe related to 
the console hanging?).
So I terminated the vm with vmctl stop -f.
Now, the vm won't start up complaining that it can't open the disk (log snippet 
below).
Is the qcow2 image somehow locked and can I unlock it?
Or is it corrupted? If so, is it recommanded using qcow2 images or are raw 
images more robust?

Kind regards,

Thomas


Jan  4 16:00:52 hilbert vmd[76370]: startup
Jan  4 16:00:52 hilbert vmd[76370]: archlinux: started vm 1 successfully, tty 
/dev/ttyp5
Jan  4 16:01:03 hilbert vmd[40912]: vcpu_process_com_data: guest reading com1 
when not ready
Jan  4 16:01:03 hilbert last message repeated 2 times
Jan  4 16:01:04 hilbert vmd[40912]: vioblk_notifyq: unsupported command 0x8
Jan  4 16:01:04 hilbert vmd[40912]: vioblk_notifyq: unsupported command 0x8
Jan  4 16:04:53 hilbert vmd[40912]: vioblk_notifyq: unsupported command 0x8
Jan  4 16:04:53 hilbert vmd[40912]: vioblk_notifyq: unsupported command 0x8
Jan  4 16:04:55 hilbert vmd[40912]: vcpu_process_com_data: guest reading com1 
when not ready
Jan  4 16:04:55 hilbert last message repeated 2 times
Jan  4 16:45:44 hilbert vmd[76370]: parent terminating
Jan  4 16:45:44 hilbert vmd[55480]: vmm exiting, pid 55480
Jan  4 16:45:44 hilbert vmd[76051]: control exiting, pid 76051
Jan  4 16:45:44 hilbert vmd[31650]: priv exiting, pid 31650
Jan  4 16:45:44 hilbert vmd[72119]: startup
Jan  4 16:45:44 hilbert vmd[72119]: can't open disk /var/vmd/archlinux.qcow2: 
Resource temporarily unavailable
Jan  4 16:45:44 hilbert vmd[72119]: failed to start vm archlinux
Jan  4 16:45:44 hilbert vmd[72119]: parent: configuration failed
Jan  4 16:45:44 hilbert vmd[12825]: vmm exiting, pid 12825
Jan  4 16:45:44 hilbert vmd[55512]: control exiting, pid 55512
Jan  4 16:45:44 hilbert vmd[1619]: priv exiting, pid 1619

Add C++ support for cscope in mg

[thomas duplessis]

Since cscope supports C++, would the team accept a patch that updates
the fnmatch
in do_cscope to recognize .cc, .cpp and .hpp files?

Re: Add $daemon_nice to rc.subr

[Thomas de Grivel]

plus it's really 6 new lines in rc.subr, no big deal.
Le mar. 4 sept. 2018 à 10:53, Thomas de Grivel  a écrit :
>
> why ? well all interactive process get a quarter range nice priority
> advance compared to all daemon tasks, at least for a laptop
> environment it really makes sense. sndiod and ntpd are unaffected by
> this change.
>
> you're right to criticize in that I did not document my code, the
> point of this new variable is that an amendment to daemon priority is
> no more than putting one line in /etc/rc.conf.local eg.
> sshd_nice=1
>
> or in the rc.d/ file
> daemon_nice=whatever
>
> why, because it is a whole lot more readable and usable than
> inheriting a whole new login class just to change one parameter, but
> if you don't like it nobody foces you huh ?
>
> Le mar. 4 sept. 2018 à 07:57, Alexandre Ratchov  a écrit :
> >
> > On Tue, Sep 04, 2018 at 04:58:53AM +0200, Thomas de Grivel wrote:
> > >
> > > And I still feel the default nice priority of 10 is rather a good
> > > idea.
> >
> > why?
>
>
>
> --
>  Thomas de Grivel
>  http://b.lowh.net/billitch/



-- 
 Thomas de Grivel
 http://b.lowh.net/billitch/

Re: Add $daemon_nice to rc.subr

[Thomas de Grivel]

> why ?

why ? well all interactive process get a quarter range nice priority
advance compared to all daemon tasks, at least for a laptop
environment it really makes sense. sndiod and ntpd are unaffected by
this change.

you're right to criticize in that I did not document my code, the
point of this new variable is that an amendment to daemon priority is
no more than putting one line in /etc/rc.conf.local eg.
sshd_nice=1

or in the rc.d/ file
daemon_nice=whatever

why, because it is a whole lot more readable and usable than
inheriting a whole new login class just to change one parameter, but
if you don't like it nobody foces you huh ?

-- 
Thomas de Grivel
http://kmx.io

Le mar. 4 sept. 2018 à 07:57, Alexandre Ratchov  a écrit :
>
> On Tue, Sep 04, 2018 at 04:58:53AM +0200, Thomas de Grivel wrote:
> >
> > And I still feel the default nice priority of 10 is rather a good
> > idea.
>
> why?



-- 
 Thomas de Grivel
 http://b.lowh.net/billitch/

Re: Add $daemon_nice to rc.subr

[Thomas de Grivel]

Thanks, good to know.

But if I actually wanted per daemon priorities with settable
configuration in rc.conf.local how would I get that ? And I still feel
the default nice priority of 10 is rather a good idea.
Le lun. 3 sept. 2018 à 23:10, Antoine Jacoutot  a écrit :
>
> On Mon, Sep 03, 2018 at 10:34:51PM +0200, Thomas de Grivel wrote:
> > Hello,
>
> Hi.
>
> > Following patch allows sysadmins to configure nice values for RC daemons.
> > Default nice value is set to 10 as I wish to prioritize interactive
> > applications over system daemons and I think most probably do too.
> > It is based on OpenBSD 6.3 but might apply easily to later releases.
> > Please let me know if it is of any interest to you.
>
> We already support that.
>
> Extract from rc.d(8):
>
>  daemon_class is a special read-only variable.  It is set to “daemon”
>  unless there is a login class configured in login.conf(5) with the same
>  name as the rc.d script itself, in which case it will be set to that
>  login class.  This allows setting many initial process properties, for
>  example environment variables, scheduling priority, and process limits
>  such as maximum memory use and number of files.
>
> Extract from login.conf(5):
>
>  priority   number   Initial priority (nice)
>      level.
>
> Cheers!
>
>
> > commit 1f4121df3ae31121d435571ffdbd93a20c1e8a07
> > Author: Thomas de Grivel 
> > Date:   Mon Sep 3 21:52:37 2018 +0200
> >
> > Add a $daemon_nice parameter.
> > If not overriden by the launched daemon the default nice value is 10.
> > See nice(1) for more details.
> >
> > diff --git rc.d/rc.subr.orig rc.d/rc.subr
> > index 6c2f694..5f4fbe5 100644
> > --- rc.d/rc.subr.orig
> > +++ rc.d/rc.subr
> > @@ -49,6 +49,7 @@ _rc_write_runfile() {
> >   cat >${_RC_RUNFILE} < >  daemon_class=${daemon_class}
> >  daemon_flags=${daemon_flags}
> > +daemon_nice=${daemon_nice}
> >  daemon_rtable=${daemon_rtable}
> >  daemon_timeout=${daemon_timeout}
> >  daemon_user=${daemon_user}
> > @@ -170,7 +171,7 @@ _rc_parse_conf() {
> >  [ -n "${FUNCS_ONLY}" ] && return
> >
> >  rc_start() {
> > - ${rcexec} "${daemon} ${daemon_flags}"
> > + ${rcexec} "nice -n ${daemon_nice} ${daemon} ${daemon_flags}"
> >  }
> >
> >  rc_check() {
> > @@ -288,6 +289,7 @@ _RC_RUNFILE=${_RC_RUNDIR}/${_name}
> >  _rc_do _rc_parse_conf
> >
> >  eval _rcflags=\${${_name}_flags}
> > +eval _rcnice=\${${_name}_nice}
> >  eval _rcrtable=\${${_name}_rtable}
> >  eval _rcuser=\${${_name}_user}
> >  eval _rctimeout=\${${_name}_timeout}
> > @@ -295,6 +297,7 @@ eval _rctimeout=\${${_name}_timeout}
> >  # set default values; duplicated in rcctl(8)
> >  getcap -f /etc/login.conf ${_name} 1>/dev/null 2>&1 && 
> > daemon_class=${_name} ||
> >   daemon_class=daemon
> > +[ -z "${daemon_nice}" ] && daemon_nice=10
> >  [ -z "${daemon_rtable}" ] && daemon_rtable=0
> >  [ -z "${daemon_user}" ] && daemon_user=root
> >  [ -z "${daemon_timeout}" ] && daemon_timeout=30
> > @@ -304,6 +307,7 @@ getcap -f /etc/login.conf ${_name} 1>/dev/null
> > 2>&1 && daemon_class=${_name} ||
> >   unset _rcflags
> >
> >  [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
> > +[ -n "${_rcnice}" ] && daemon_nice=${_rcnice}
> >  [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
> >  [ -n "${_rcuser}" ] && daemon_user=${_rcuser}
> >  [ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
> > @@ -315,7 +319,7 @@ if [ -n "${_RC_DEBUG}" ]; then
> >  fi
> >
> >  readonly daemon_class
> > -unset _rcflags _rcrtable _rcuser _rctimeout
> > +unset _rcflags _rcnice _rcrtable _rcuser _rctimeout
> >  pexp="${daemon}${daemon_flags:+ ${daemon_flags}}"
> >  rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
> >  [ "${daemon_rtable}" -eq 0 ] ||
> >
> >
> > --
> >  Thomas de Grivel
> >
>
> --
> Antoine



-- 
 Thomas de Grivel
 http://b.lowh.net/billitch/

Re: Linux DRM

[Thomas de Grivel]

Le lun. 3 sept. 2018 à 23:33, Philip Guenther  a écrit :
>
> On Mon, Sep 3, 2018 at 11:46 AM Thomas de Grivel  wrote:
>>
>> I was browsing the DRM code ported from Linux and it's a terrible
>> mess, is there any ongoing project to clean up that codebase or
>> rewrite it entirely ?
>
>
> No.  OpenBSD doesn't have the resources to reimplement the DRM subsystem or 
> maintain a non-trivial fork of the Linux version.  We don't want to get stuck 
> with a code base that doesn't support close-to-current hardware, so the 
> porting work has concentrated on minimizing the changes necessary to make the 
> upstream code base work in OpenBSD.
>
> It's clear that the hardware support in the upstream has large contributions 
> from developers with inside access at the hardware vendors; without such 
> access it's doubtful that all the hardware bugs^Wlimitations can be worked 
> around with non-infinite resource.
>
> Improvements in the DRM code itself should be done in the upstream, not just 
> to minimize OpenBSD costs in this area, but so that all OSes that draw from 
> that base can benefit.

You probably do not care and actually neither do I but that current
state of graphic hardware support code is crazy in my opinion.
Computer graphic cards have to be the single most successful hardware
in the history of computer hardware or even hardware in general and
yet their drivers are a complete mess. It makes no sense to me. It all
appears like a hideous obscurity-based false sense of security where
you really cannot ensure the minimality of any driver and their
features.

I would not be least surprised to see a few backdoors in that code,
preventing OpenBSD for use for private intellectual property work,
however different the advertisement can be. I sure hope I'm wrong.

--
 Thomas de Grivel
 http://kmx.io/

Linux DRM

[Thomas de Grivel]

I was browsing the DRM code ported from Linux and it's a terrible
mess, is there any ongoing project to clean up that codebase or
rewrite it entirely ?

-- 
 Thomas de Grivel

Add $daemon_nice to rc.subr

[Thomas de Grivel]

Hello,

Following patch allows sysadmins to configure nice values for RC daemons.
Default nice value is set to 10 as I wish to prioritize interactive
applications over system daemons and I think most probably do too.
It is based on OpenBSD 6.3 but might apply easily to later releases.
Please let me know if it is of any interest to you.

commit 1f4121df3ae31121d435571ffdbd93a20c1e8a07
Author: Thomas de Grivel 
Date:   Mon Sep 3 21:52:37 2018 +0200

Add a $daemon_nice parameter.
If not overriden by the launched daemon the default nice value is 10.
See nice(1) for more details.

diff --git rc.d/rc.subr.orig rc.d/rc.subr
index 6c2f694..5f4fbe5 100644
--- rc.d/rc.subr.orig
+++ rc.d/rc.subr
@@ -49,6 +49,7 @@ _rc_write_runfile() {
  cat >${_RC_RUNFILE} </dev/null 2>&1 && daemon_class=${_name} ||
  daemon_class=daemon
+[ -z "${daemon_nice}" ] && daemon_nice=10
 [ -z "${daemon_rtable}" ] && daemon_rtable=0
 [ -z "${daemon_user}" ] && daemon_user=root
 [ -z "${daemon_timeout}" ] && daemon_timeout=30
@@ -304,6 +307,7 @@ getcap -f /etc/login.conf ${_name} 1>/dev/null
2>&1 && daemon_class=${_name} ||
  unset _rcflags

 [ -n "${_rcflags}" ] && daemon_flags=${_rcflags}
+[ -n "${_rcnice}" ] && daemon_nice=${_rcnice}
 [ -n "${_rcrtable}" ] && daemon_rtable=${_rcrtable}
 [ -n "${_rcuser}" ] && daemon_user=${_rcuser}
 [ -n "${_rctimeout}" ] && daemon_timeout=${_rctimeout}
@@ -315,7 +319,7 @@ if [ -n "${_RC_DEBUG}" ]; then
 fi

 readonly daemon_class
-unset _rcflags _rcrtable _rcuser _rctimeout
+unset _rcflags _rcnice _rcrtable _rcuser _rctimeout
 pexp="${daemon}${daemon_flags:+ ${daemon_flags}}"
 rcexec="su -l -c ${daemon_class} -s /bin/sh ${daemon_user} -c"
 [ "${daemon_rtable}" -eq 0 ] ||


-- 
 Thomas de Grivel

disable seemingly unsupported MSI for AMD 17h/Raven Ridge HD Audio in azalia.c

[Thomas Frohwein]

Hi,

It appears that HD Audio from AMD's generation Ryzen can't handle MSI.
This leads to the bug that I reported here:

https://marc.info/?l=openbsd-bugs=151648196215922=2

Disabling MSI resolves the problem on my current system which is a Raven
Ridge APU. I don't have the Summit Ridge hardware anymore to test that
it is also resolved there, but the line is included in the diff
(PCI_PRODUCT_AMD_AMD64_17_HDA). It seems likely that this diff will also
fix HD Audio on Summit Ridge. However, testing would be welcome by
anyone who has a first-gen Ryzen.

I was slightly confused by the fact that so far it seems I've been the
only one who reported this. Even searching online for such an issue in
other OS didn't yield anything. However, the issue was there between 2
different Ryzen CPUs, 3 different motherboards, and at least 2 separate
OpenBSD -current installations. And it was never there on any
Intel-based setup, with otherwise same hardware and OpenBSD install.
While there have been several reports of people using Ryzen with
OpenBSD, they may not have used audio (that's my explanation for this
at the moment).

This diff was collaborative work with brynet@.

ok?

Index: azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.244
diff -u -p -r1.244 azalia.c
--- azalia.c22 Apr 2018 10:02:13 -  1.244
+++ azalia.c7 Jul 2018 18:26:20 -
@@ -517,6 +517,15 @@ azalia_pci_attach(struct device *parent,
azalia_pci_write(sc->pc, sc->tag, ICH_PCI_MMC, reg);
}
 
+   /* disable MSI for AMD Summit Ridge/Raven Ridge HD Audio */
+   if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
+   switch (PCI_PRODUCT(sc->pciid)) {
+   case PCI_PRODUCT_AMD_AMD64_17_HDA:
+   case PCI_PRODUCT_AMD_RAVENRIDGE_HDA:
+   pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
+   }
+   }
+
/* interrupt */
if (pci_intr_map_msi(pa, ) && pci_intr_map(pa, )) {
printf(": can't map interrupt\n");

pcidevs for AMD 17h and Raven Ridge APUs (Ryzen)

[Thomas Frohwein]

Hi,

This is a diff to add a bunch of AMD Summit Ridge (17h) and Raven Ridge
PCI devices. It's in preparation of an upcoming diff for these that I've
worked on in collaboration with brynet@.

The link to http://www.pcidatabase.com/ in the comments for pcidevs
isn't retrievable anymore. I have found device ids here instead:

https://pci-ids.ucw.cz/read/PC/1022

This includes all that I could find in my dmesg on Raven Ridge Ryzen 3
2200G, as well as dmesg of the Summit Ridge Ryzen 5 1400 that I owned
previously (see
https://marc.info/?l=openbsd-bugs=151648196215922=2).

ok?

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1853
diff -u -p -r1.1853 pcidevs
--- pcidevs 6 Jul 2018 01:37:00 -   1.1853
+++ pcidevs 7 Jul 2018 18:28:47 -
@@ -730,7 +730,22 @@ product AMD AMD64_15_3X_PCIE_1 0x1424  AM
 product AMD AMD64_15_3X_PCIE_2 0x1425  AMD64 15h PCIE
 product AMD AMD64_15_3X_PCIE_3 0x1426  AMD64 15h PCIE
 product AMD AMD64_16_PCIE  0x1439  AMD64 16h PCIE
+product AMD AMD64_17_RC0x1450  AMD64 17h Root Complex
+product AMD AMD64_17_IOMMU 0x1451  AMD64 17h IOMMU
+product AMD AMD64_17_PCIE_10x1452  AMD64 17h PCIE
+product AMD AMD64_17_PCIE_20x1453  AMD64 17h PCIE
+product AMD AMD64_17_PCIE_30x1454  AMD64 17h PCIE
 product AMD CCPV5A 0x1456  Cryptographic Co-processor v5a
+product AMD AMD64_17_HDA   0x1457  AMD64 17h HD Audio
+product AMD AMD64_17_XHCI  0x145c  AMD64 17h USB xHCI
+product AMD AMD64_17_DF_1  0x1460  AMD64 17h Data Fabric
+product AMD AMD64_17_DF_2  0x1461  AMD64 17h Data Fabric
+product AMD AMD64_17_DF_3  0x1462  AMD64 17h Data Fabric
+product AMD AMD64_17_DF_4  0x1463  AMD64 17h Data Fabric
+product AMD AMD64_17_DF_5  0x1464  AMD64 17h Data Fabric
+product AMD AMD64_17_DF_6  0x1465  AMD64 17h Data Fabric
+product AMD AMD64_17_DF_7  0x1466  AMD64 17h Data Fabric
+product AMD AMD64_17_DF_8  0x1467  AMD64 17h Data Fabric
 product AMD CCPV5B 0x1468  Cryptographic Co-processor v5b
 product AMD AMD64_14_HB0x1510  AMD64 14h Host
 product AMD AMD64_14_PCIE_10x1512  AMD64 14h PCIE
@@ -766,6 +781,7 @@ product AMD AMD64_16_3X_DRAM0x1582  AMD6
 product AMD AMD64_16_3X_MISC   0x1583  AMD64 16h Misc Cfg
 product AMD AMD64_16_3X_CPU_PM 0x1584  AMD64 16h CPU Power
 product AMD AMD64_16_3X_MISC_2 0x1585  AMD64 16h Misc Cfg
+product AMD RAVENRIDGE_HDA 0x15e3  Raven Ridge HD Audio
 product AMD AMD64_15_0x_LINK   0x1600  AMD64 15/0xh Link Cfg
 product AMD AMD64_15_0x_ADDR   0x1601  AMD64 15/0xh Address Map
 product AMD AMD64_15_0x_DRAM   0x1602  AMD64 15/0xh DRAM Cfg
@@ -809,6 +825,9 @@ product AMD HUDSON2_PCIE_1  0x43a0  Hudson
 product AMD HUDSON2_PCIE_2 0x43a1  Hudson-2 PCIE
 product AMD HUDSON2_PCIE_3 0x43a2  Hudson-2 PCIE
 product AMD HUDSON2_PCIE_4 0x43a3  Hudson-2 PCIE
+product AMD 300SERIES_PCIE 0x43b4  300 Series PCIe Port
+product AMD 300SERIES_SATA 0x43b7  300 Series SATA
+product AMD 300SERIES_XHCI 0x43bb  300 Series xHCI
 /* http://www.amd.com/products/cpg/athlon/techdocs/pdf/21910.pdf */
 product AMD SC751_SC   0x7006  751 System
 product AMD SC751_PPB  0x7007  751

Behaviour of fsync() in case of write-back errors

[Thomas Munro]

Hello,

I work on PostgreSQL.  I don't use OpenBSD, but recently I've been
investigating how fsync() reports write-back errors on all operating
systems that people like to run PostgreSQL on:

https://wiki.postgresql.org/wiki/Fsync_Errors

It seems to me that on OpenBSD, asynchronous write-back errors might
not be reported to userspace in a subsequent call to fsync(), and
synchronous write-back errors that are reported to userspace might not
be reported in a follow-up call to fsync() (that is, retrying will
appear to be successful but in fact your data is gone).

Am I wrong?  Perhaps some other code elsewhere will record the error
at device, filesystem or inode level?  I didn't try to test this: I
simply compared the brelse() error handling code with that of FreeBSD
and NetBSD whose behaviours are known to be correct and incorrect
respectively, according to our assessment of what fsync() *should* do.
(Or at least the behaviour that PostgreSQL relies on, when it reports
that your data exists on disk as part of its checkpoint protocol).
OpenBSD certainly appears to be like NetBSD in this respect, so I
thought it was worth pinging your list and asking for an expert
opinion.

Do you think that my suspicion is correct?  Would you consider that to
be a bug?

Thanks!

Thomas Munro

[patch] 62.html

[Thomas Alexander Frederiksen]

Same as the rejected patch for the temporary 63.html, but this time for a 
relevant page.

--- 62.html.orig2018-03-16 14:17:49.0 +0100
+++ 62.html 2018-03-16 14:18:07.0 +0100
@@ -180,9 +180,9 @@
 
 MiRA 802.11n TX rate scaling now supports devices with unequal numbers
 of Tx and Rx streams. Fixes 11n mode for some
-https://man.openbsd.org/athn.8;>athn(8) devices.
-The https://man.openbsd.org/iwn.8;>iwn(8) and
-https://man.openbsd.org/iwm.8;>iwm(8) drivers will now 
start
+https://man.openbsd.org/athn.4;>athn(4) devices.
+The https://man.openbsd.org/iwn.4;>iwn(4) and
+https://man.openbsd.org/iwm.4;>iwm(4) drivers will now 
start
 scanning for a new access point if they no longer receive beacons from
 the current AP.
 Prefer the 5GHz band over the 2GHz band during access point selection.

-- 
We’re sysadmins, to us, data is protocol overhead.

> Den 16. mar. 2018 kl. 14.16 skrev Theo de Raadt :
> 
> No, the 63 page is full of lies from 6.2
> 

[patch] 63.html

[Thomas Alexander Frederiksen]

Typo fix for 802.11 driver man page links

--- 63.html.orig2018-03-16 12:41:10.0 +0100
+++ 63.html 2018-03-16 12:42:36.0 +0100
@@ -181,9 +181,9 @@
 
 MiRA 802.11n TX rate scaling now supports devices with unequal numbers
 of Tx and Rx streams. Fixes 11n mode for some
-https://man.openbsd.org/athn.8;>athn(8) devices.
-The https://man.openbsd.org/iwn.8;>iwn(8) and
-https://man.openbsd.org/iwm.8;>iwm(8) drivers will now 
start
+https://man.openbsd.org/athn.4;>athn(4) devices.
+The https://man.openbsd.org/iwn.4;>iwn(4) and
+https://man.openbsd.org/iwm.4;>iwm(4) drivers will now 
start
 scanning for a new access point if they no longer receive beacons from
 the current AP.
 Prefer the 5GHz band over the 2GHz band during access point selection.

--  
We’re sysadmins, to us, data is protocol overhead.

mono: partial progress and possible issue with TLS/pthread_getspecific(3)

[Thomas Frohwein]

In December, I found the mono port in a state where it only built with the
(deprecated) mcs compiler, and it would catch a SIGABRT predominantly when
exiting applications (including any call to the newer csc/roslyn compiler).

I've since made what seems like partial progress with mono's functionality and
reliability, but hit a dead end. It appears to be related to the thread local
storage. Here's a brief summary, hoping for some additional input from those
with more knowledge about these matters:

- I found that the SIGABRT was consistently associated with a SIGTTIN signal
  that mono sets in mono-threads-posix-signals.c as the abort signal for
  threads. Setting it to SIGUSR1 resolved this and allows for applications
  to exit without aborting. (I found some reference that Linux uses SIGUSR1/2,
  and on platforms with SIGRTMIN, the first one available from there is chosen)

- After this, trying to build with csc/roslyn still fails - it deadlocks when
  building the first dll (mscorlib). Attaching it to gdb shows ~16-20 parallel
  threads with no clear pattern (to me) that would lead anywhere.

- However, setting build option '--with-cooperative-gc=yes' allows the build
  process to run further. This is also what upstream is planning to make the
  default (https://github.com/mono/mono/issues/6921).
  Now it builds several dozen if not more dll's with csc/roslyn, but eventually
  segfaults. This occurs at different times and with different dll's each time.
  I've tried to troubleshoot it, but this seems to be beyond my capabilities.
  Every time, the backtrace of the core file looks like this:

[...]
Core was generated by `mono-sgen'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  mono_get_lmf () at mini-runtime.c:741
741 return jit_tls->lmf;
(gdb) where
#0  mono_get_lmf () at mini-runtime.c:741
#1  0x1f5d55296988 in mono_thread_state_init (ctx=0x1f5f82f08070) at 
mini-exceptions.c:3127
#2  0x1f5d554d9b19 in 
mono_threads_enter_gc_safe_region_unbalanced_with_info (info=0x1f5f82f08000, 
stackdata=) at mono-threads-coop.c:245
#3  0x1f5d554d69b3 in mono_thread_info_suspend_lock_with_info 
(info=0x1f5f82f08000) at mono-threads.c:1093
#4  0x1f5d55479a79 in acquire_gc_locks () at sgen-stw.c:87
#5  sgen_client_stop_world (generation=0) at sgen-stw.c:111
#6  0x1f5d5548869e in sgen_stop_world (generation=0) at sgen-gc.c:3790
#7  0x1f5d5545d5a5 in mono_gc_clear_domain (domain=0x1f5fc211d400) at 
sgen-mono.c:865
#8  0x1f5d55362a88 in mono_domain_free (domain=0x1f5fc211d400, 
force=) at domain.c:1088
#9  0x1f5d55209556 in mini_cleanup (domain=0x1f5fc211d400) at 
mini-runtime.c:4445
#10 0x1f5d5525c5eb in mono_main (argc=26, argv=) at 
driver.c:2374
#11 0x1f5d552016f0 in mono_main_with_options (argc=2, argv=0x7f7d4e78) 
at ./main.c:47
#12 main (argc=26, argv=) at ./main.c:344
(gdb) info locals
jit_tls = 0x1f5f8df48000
(gdb) p *jit_tls
Cannot access memory at address 0x1f5f8df48000
(gdb)

I've checked with a printf and mono_get_lmf gets called countless times with no
apparent errors/bugs before the segfault. I tried running the build command
that failed in gdb, but that lead to very inconsistent results. Sometimes
the program would complete normally, sometimes catch SIGSEGV (in a different
place), sometimes catch SIGABRT elsewhere.

In mini-runtime.c, jit_tls is obtained via mono_tls_get_jit_tls which in the
end calls pthread_getspecific(3) (in mono-tls.h). It is unclear to me why it
would call an unaccessible memory address. The key is created by
pthread_key_create(3), also in mono-tls.h.

It appears that finding out why mono_get_lmf segfaults might be a way to
restore mono to working condition. It otherwise has been running mostly stable
with these changes (with SIGUSR1 and cooperative gc via MONO_ENABLE_GC env var),
including hour-long application test sessions and building C# projects with
xbuild. Not sure if this behavior is indicative of a race condition, or an edge
case that is regularly triggered.

Any advice on how to get to the bottom of this?

Use kernel-space address with FUSE_DEBUG

[Thomas Jeunet]

The following patch use the proper address space when using a kernel
with FUSE_DEBUG (kernel instead of user, see the copyin above). While
here, add some sanity check to the debug function fuse_dump_buff.

-- 
Thomas Jeunet

Index: sys/miscfs/fuse/fuse_device.c
===
RCS file: /var/cvs/src/sys/miscfs/fuse/fuse_device.c,v
retrieving revision 1.23
diff -u -p -r1.23 fuse_device.c
--- sys/miscfs/fuse/fuse_device.c   10 Aug 2017 14:36:34 -  1.23
+++ sys/miscfs/fuse/fuse_device.c   25 Oct 2017 12:18:55 -
@@ -92,6 +92,15 @@ fuse_dump_buff(char *buff, int len)
char text[17];
int i;
 
+   if (len < 0) {
+   DPRINTF("invalid len: %d", len);
+   return;
+   }
+   if (buff == NULL) {
+   DPRINTF("invalid buff");
+   return;
+   }
+
bzero(text, 17);
for (i = 0; i < len; i++) {
if (i != 0 && (i % 16) == 0) {
@@ -338,7 +347,7 @@ fuseioctl(dev_t dev, u_long cmd, caddr_t
}
 
 #ifdef FUSE_DEBUG
-   fuse_dump_buff(ioexch->fbxch_data, ioexch->fbxch_len);
+   fuse_dump_buff(fbuf->fb_dat, fbuf->fb_len);
 #endif
 
/* Adding fbuf in fd_fbufs_wait */

[PATCH] iked: Incorrect definition of critical bit (IKEV2_CRITICAL_PAYLOAD)

[Thomas Klute]

Hi tech@,

I noticed that the definition of IKEV2_CRITICAL_PAYLOAD in ikev2.h is
incorrect. According to RFC 7296, Section 3.2 the critical bit is the
first/high bit of the second octet of the IKE payload header. An octet
with only its first bit set results in a hex value of 0x80, not 0x01.

IKEV2_CRITICAL_PAYLOAD is only used to create a log message in
ikev2_pld_payloads (ikev2_pld.c), so the impact of this bug is small,
but correctly logging whether a payload is critical seems useful.

Best regards,
Thomas

--- a/ikev2.h
+++ b/ikev2.h
@@ -78,7 +78,7 @@ struct ikev2_payload {
uint16_t pld_length;/* Payload length with header */
 } __packed;

-#define IKEV2_CRITICAL_PAYLOAD 0x01/* First bit in the reserved field */
+#define IKEV2_CRITICAL_PAYLOAD 0x80/* First bit in the reserved field */

 /* IKEv2 payload types */
 #define IKEV2_PAYLOAD_NONE 0   /* No payload */

Re: [PATCH] iked: Bugfixes for IKE rekeying

[Thomas Klute]

Am 09.11.2016 um 20:36 schrieb Vincent Gross:
> On Wed, 9 Nov 2016 13:16:46 +
> Thomas Klute <thomas.kl...@achelos.de> wrote:
> 
>> Hi tech@,
>>
>> this patch contains fixes for two bugs that break IKE rekeying
>> initiated by iked. Please review, and apply or let me know what has to
>> be changed! Both bugs are fixed by initializing the respective
>> structures of the new IKE SA (struct iked_sa *nsa in the
>> ikev2_ike_sa_rekey function):
> 
> Thanks, we are looking into it.

Hi, is there any progress on this?

>> For [1]: Copying the address information is required to send any
>> request messages over the new IKE SA after rekeying, otherwise errors
>> like the following happen because the IP addresses and ports remain
>> initialized to zero:
>>
>> ikev2_msg_send: INFORMATIONAL request from any to any msgid 1, 80
>> bytes ikev2_msg_send: sendtofrom: Invalid argument
>>
>> For [2]: Setting the DH group based on the currently used one is
>> necessary because iked proposes only the currently used transforms
>> during IKE rekeying, so trying to use any other group for the DH
>> exchange will fail even if it is preferred by local policy (see
>> comment in the patch for details).
>>
>> This patch includes and supersedes the one for only the first bug I
>> sent yesterday.
>>
>> Best regards,
>> Thomas
>>
>> [1] https://marc.info/?l=openbsd-bugs=147739504516767=2
>> [2] https://marc.info/?l=openbsd-bugs=147747405806461=2
>>
>> Index: src/sbin/iked/ikev2.c
>> ===
>> RCS file: /cvs/src/sbin/iked/ikev2.c,v
>> retrieving revision 1.131
>> diff -u -p -u -r1.131 ikev2.c
>> --- src/sbin/iked/ikev2.c2 Jun 2016 07:14:26 -
>> 1.131 +++ src/sbin/iked/ikev2.c  9 Nov 2016 13:12:32 -
>> @@ -2658,6 +2658,18 @@ ikev2_ike_sa_rekey(struct iked *env, voi
>>  goto done;
>>  }
>>  
>> +/* Select the DH group ID based on the currently used
>> + * one. Otherwise the call to ikev2_sa_initiator below would
>> + * set it to the first DH transform in the policy, while the
>> + * SA payload contains only one proposal matching the
>> + * currently used transforms. If a different DH transform has
>> + * been negotiated this means KE payload and negotiated DH
>> + * transform cannot match, causing rekeying to fail. */
>> +if ((nsa->sa_dhgroup = group_get(sa->sa_dhgroup->id)) ==
>> NULL) {
>> +log_debug("%s: failed to initialize DH group",
>> __func__);
>> +goto done;
>> +}
>> +
>>  if (ikev2_sa_initiator(env, nsa, sa, NULL)) {
>>  log_debug("%s: failed to setup DH", __func__);
>>  goto done;
>> @@ -2665,6 +2677,13 @@ ikev2_ike_sa_rekey(struct iked *env, voi
>>  sa_state(env, nsa, IKEV2_STATE_AUTH_SUCCESS);
>>  nonce = nsa->sa_inonce;
>>  
>> +/* Copy local and peer address from the old SA */
>> +if (sa_address(nsa, >sa_peer, >sa_peer.addr) == -1
>> ||
>> +sa_address(nsa, >sa_local, >sa_local.addr) ==
>> -1) {
>> +log_debug("%s: failed copy address data", __func__);
>> +goto done;
>> +}
>> +
>>  if ((e = ibuf_static()) == NULL)
>>  goto done;
>>  
>>
> 

[PATCH] iked: Bugfixes for IKE rekeying

[Thomas Klute]

Hi tech@,

this patch contains fixes for two bugs that break IKE rekeying
initiated by iked. Please review, and apply or let me know what has to
be changed! Both bugs are fixed by initializing the respective
structures of the new IKE SA (struct iked_sa *nsa in the
ikev2_ike_sa_rekey function):

For [1]: Copying the address information is required to send any
request messages over the new IKE SA after rekeying, otherwise errors
like the following happen because the IP addresses and ports remain
initialized to zero:

ikev2_msg_send: INFORMATIONAL request from any to any msgid 1, 80 bytes
ikev2_msg_send: sendtofrom: Invalid argument

For [2]: Setting the DH group based on the currently used one is
necessary because iked proposes only the currently used transforms
during IKE rekeying, so trying to use any other group for the DH
exchange will fail even if it is preferred by local policy (see
comment in the patch for details).

This patch includes and supersedes the one for only the first bug I
sent yesterday.

Best regards,
Thomas

[1] https://marc.info/?l=openbsd-bugs=147739504516767=2
[2] https://marc.info/?l=openbsd-bugs=147747405806461=2

Index: src/sbin/iked/ikev2.c
===
RCS file: /cvs/src/sbin/iked/ikev2.c,v
retrieving revision 1.131
diff -u -p -u -r1.131 ikev2.c
--- src/sbin/iked/ikev2.c   2 Jun 2016 07:14:26 -   1.131
+++ src/sbin/iked/ikev2.c   9 Nov 2016 13:12:32 -
@@ -2658,6 +2658,18 @@ ikev2_ike_sa_rekey(struct iked *env, voi
goto done;
}
 
+   /* Select the DH group ID based on the currently used
+* one. Otherwise the call to ikev2_sa_initiator below would
+* set it to the first DH transform in the policy, while the
+* SA payload contains only one proposal matching the
+* currently used transforms. If a different DH transform has
+* been negotiated this means KE payload and negotiated DH
+* transform cannot match, causing rekeying to fail. */
+   if ((nsa->sa_dhgroup = group_get(sa->sa_dhgroup->id)) == NULL) {
+   log_debug("%s: failed to initialize DH group", __func__);
+   goto done;
+   }
+
if (ikev2_sa_initiator(env, nsa, sa, NULL)) {
log_debug("%s: failed to setup DH", __func__);
goto done;
@@ -2665,6 +2677,13 @@ ikev2_ike_sa_rekey(struct iked *env, voi
sa_state(env, nsa, IKEV2_STATE_AUTH_SUCCESS);
nonce = nsa->sa_inonce;
 
+   /* Copy local and peer address from the old SA */
+   if (sa_address(nsa, >sa_peer, >sa_peer.addr) == -1 ||
+   sa_address(nsa, >sa_local, >sa_local.addr) == -1) {
+   log_debug("%s: failed copy address data", __func__);
+   goto done;
+   }
+
if ((e = ibuf_static()) == NULL)
goto done;
 

[PATCH] iked: Preserve address information during rekeying

[Thomas Klute]

Hi tech@,

a week ago I reported to bugs@ that iked "forgets" the local and peer addresses 
associated with an IKE SA while rekeying it if iked has initiated the rekeying, 
breaking any IKE requests iked tries to send after rekeying [1]. The patch 
below fixes the bug by copying the addresses from the current IKE SA when 
initiating the rekeying. Please review and apply if OK.

[1] https://marc.info/?l=openbsd-bugs=147739504516767=2

Index: ikev2.c
===
RCS file: /cvs/src/sbin/iked/ikev2.c,v
retrieving revision 1.131
diff -u -p -u -r1.131 ikev2.c
--- ikev2.c 2 Jun 2016 07:14:26 -   1.131
+++ ikev2.c 8 Nov 2016 14:06:12 -
@@ -2665,6 +2665,13 @@ ikev2_ike_sa_rekey(struct iked *env, voi
sa_state(env, nsa, IKEV2_STATE_AUTH_SUCCESS);
nonce = nsa->sa_inonce;
 
+   /* Copy local and peer address from the old SA */
+   if (sa_address(nsa, >sa_peer, >sa_peer.addr) == -1 ||
+   sa_address(nsa, >sa_local, >sa_local.addr) == -1) {
+   log_debug("%s: failed copy address data", __func__);
+   goto done;
+   }
+
if ((e = ibuf_static()) == NULL)
goto done;
 

X Server failing about libfreetype.so.24.0 with latest snapshot

[Thomas Schmidt]

Hi,
I just updated from a 5.7-current snapshot (15th June) to a recent one
(29th June).
Now, when I try to 'startx' I get the following error:

$ startx
xauth: (stdin):1:  bad display name turin.local:0 in add command

/usr/X11R6/bin/X: can't load library 'libfreetype.so.24.0'
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
xauth: (argv):1:  bad display name turin.local:0 in remove command

$ cat .xinitrc
cwm

Is anyone else seeing this? I'll try the next snapshot as soon as it's
available.

$ dmesg
OpenBSD 5.7-current (GENERIC.MP) #1063: Mon Jun 15 00:54:48 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4062691328 (3874MB)
avail mem = 3935686656 (3753MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
bios0: vendor LENOVO version 6IET83WW (1.43 ) date 04/12/2012
bios0: LENOVO 2537G98
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA DMAR 
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP1(S4) EXP2(S4) 
EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.24 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 1197.00 MHz
cpu3: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 5 (EXP4)
acpiprt6 at acpi0: bus 13 (EXP5)
acpicpu0 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpicpu1 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpicpu2 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpicpu3 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 42T4912 serial 11240 type LION oem LGC
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0
cpu0: Enhanced SpeedStep 1197 MHz: speeds: 2400, 2399, 2266, 2133, 1999, 1866, 
1733, 1599, 1466, 1333, 1199 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02
vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1280x800
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 Intel 82577LM rev 0x06: msi, address 
f0:de:f1:2c:df:5e

dmesg(8) incomplete?

[Thomas Schmidt]

Hi,
I am a pretty new user so please forgive any uninformed statements.

I just spent a few hours trying to figure out why my dmesg displays an
old kernel (May 5th), when I just compiled a new one (for recent -stable
patches). I've looked pretty much everywhere and retraced every step
until finally giving up and starting to compose a mail to get help.
Then, when pasting my dmesg output into the mail I realized that there
were multiple system messages from multiple startups in the dmesg output,
and that everything was fine with my system.
Now, except for a few threads from 200[367], even now that I know what
I'm looking for I don't see this behaviour documented anywhere. Since
there is no other record of this behaviour my knowldge is probably
incomplete but attached is a patch - I borrowed some wordings from a mail
from Theo[1] - that adds this information to the dmesg manpage.

Best Regards,
Thomas

[1] http://marc.info/?l=openbsd-miscm=115272548814461w=2


Index: src/sbin/dmesg/dmesg.8
===
RCS file: /cvs/src/sbin/dmesg/dmesg.8,v
retrieving revision 1.15
diff -u -p -u -r1.15 dmesg.8
--- src/sbin/dmesg/dmesg.8  13 Jan 2015 10:07:58 -  1.15
+++ src/sbin/dmesg/dmesg.8  13 Mar 2015 03:14:45 -
@@ -45,6 +45,11 @@
 .Nm
 displays the contents of the system message buffer.
 It is most commonly used to review system startup messages.
+If the kernel finds that the
+.Nm
+buffer in the kernel address space is still intact after reboot, it does
+not clear it, but appends to it, resulting in the output of messages from
+multiple startups. This is so that crash-related data will be retained.
 .Pp
 The options are as follows:
 .Bl -tag -width Ds

Re: qsort.3 big O notation

[Thomas Schmidt]

In the most recent algorithms lecture I heard we used log for base 2, ln for 
base e, and lg for base 10. But asymptotically the base doesn't matter and the 
notation coventions differ. So I'd also go for consistency with other 
documentation. 

On March 3, 2015 5:48:20 PM CET, frantisek holop min...@obiit.org wrote:
Joerg Sonnenberger, 03 Mar 2015 17:28:
 On Tue, Mar 03, 2015 at 05:02:39PM +0100, frantisek holop wrote:
  i leave the battle about lg vs log to others,
  but i prefer 'log' as there is a man page for that
  and there is none for 'lg'...
 
 If anything, it should be log because that is the name of the
 mathematical function. libm is completely irrelevant in this context.

'lg' is also a valid name
(altough i admit i didn't know, i was used to log2)
https://en.wikipedia.org/wiki/Logarithm#Particular_bases

as Tedu pointed out lg = log2 and lg != log

but i think my point is still kind of valid,
as there is log2(3) and no lg(3).

i find it relevant that libm should also use
the most common, easiest names where possible...
it is kind of nice to be able to do 'man log2'
after reading 'man qsort', a kind of indirect
cross reference.

-f
-- 
illiterate?  write for a free brochure!

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

libssl patch: Add brainpool curves to the tls default curves

[Thomas Jakobi]

hi,

when playing around with the brainpool curves we realised that trying to 
establish a tls connection between s_server and s_client using brainpool 
curves always ended with a handshake error. it seems 3 lines were missed 
when merging a change from openssl[1].

attached patch removes one tab charachter at the end of an existing line 
and adds the 3 missing array entries in t1_lib.c in the array of the 
default curves. this fixes usage of the brainpool curves in tls connections.

this patch is equivalent to the pull request #14 on github, yet i was told 
that submitting the patch here is more promising.

thanks for all your hard work, you guys are great ;)

fake

P.S.: in case of any discussion, please CC me, as i am currently not 
  subscribed to this list.

[1] https://github.com/openssl/openssl/commit/469bcb0c



brainpool-tls-in-default-curves.patch
Description: Binary data

Re: libssl/src/apps don't cast {m,re}alloc

[Thomas Pfaff]

 This doesn't fix the problems, only removes markers alerting us
 to audit it.
 
 Memory management in these files is still missing integer overflow
 checks, NULL return checks, and is full of crazy abominations [...]

Yes, I saw that but I thought I'd take care of one thing first
then send patches to fix other things, but I get your point.

 X509_NAME *
 parse_name(char *subject, long chtype, int multirdn)
 {
   size_t buflen = strlen(subject) + 1;/* ...
   char *buf = malloc(buflen);
   size_t max_ne = buflen / 2 + 1; /* maximum number of name elements */
   char **ne_types = malloc(max_ne * sizeof(char *));
   char **ne_values = malloc(max_ne * sizeof(char *));
   int *mval = malloc(max_ne * sizeof(int));

Beautiful.

libssl/src/apps don't cast {m,re}alloc

[Thomas Pfaff]

Don't cast {m,re}alloc.  No point and it's inconsistent already.

Index: apps.c
===
RCS file: /cvs/src/lib/libssl/src/apps/apps.c,v
retrieving revision 1.42
diff -u -p -r1.42 apps.c
--- apps.c  22 Apr 2014 14:54:13 -  1.42
+++ apps.c  23 Apr 2014 07:20:29 -
@@ -216,7 +216,7 @@ chopup_args(ARGS * arg, char *buf, int *
i = 0;
if (arg-count == 0) {
arg-count = 20;
-   arg-data = (char **)malloc(sizeof(char *) * arg-count);
+   arg-data = malloc(sizeof(char *) * arg-count);
}
for (i = 0; i  arg-count; i++)
arg-data[i] = NULL;
@@ -236,8 +236,7 @@ chopup_args(ARGS * arg, char *buf, int *
if (num = arg-count) {
char **tmp_p;
int tlen = arg-count + 20;
-   tmp_p = (char **) realloc(arg-data,
-   sizeof(char *) * tlen);
+   tmp_p = realloc(arg-data, sizeof(char *) * tlen);
if (tmp_p == NULL)
return 0;
arg-data = tmp_p;
@@ -417,7 +416,7 @@ password_callback(char *buf, int bufsiz,
ok = UI_add_input_string(ui, prompt, ui_flags, buf,
PW_MIN_LENGTH, bufsiz - 1);
if (ok = 0  verify) {
-   buff = (char *) malloc(bufsiz);
+   buff = malloc(bufsiz);
ok = UI_add_verify_string(ui, prompt, ui_flags, buff,
PW_MIN_LENGTH, bufsiz - 1, buf);
}
Index: ca.c
===
RCS file: /cvs/src/lib/libssl/src/apps/ca.c,v
retrieving revision 1.46
diff -u -p -r1.46 ca.c
--- ca.c22 Apr 2014 13:32:17 -  1.46
+++ ca.c23 Apr 2014 07:20:29 -
@@ -1981,17 +1981,17 @@ again2:
goto err;
 
/* We now just add it to the database */
-   row[DB_type] = (char *) malloc(2);
+   row[DB_type] = malloc(2);
 
tm = X509_get_notAfter(ret);
-   row[DB_exp_date] = (char *) malloc(tm-length + 1);
+   row[DB_exp_date] = malloc(tm-length + 1);
memcpy(row[DB_exp_date], tm-data, tm-length);
row[DB_exp_date][tm-length] = '\0';
 
row[DB_rev_date] = NULL;
 
/* row[DB_serial] done already */
-   row[DB_file] = (char *) malloc(8);
+   row[DB_file] = malloc(8);
row[DB_name] = X509_NAME_oneline(X509_get_subject_name(ret), NULL, 0);
 
if ((row[DB_type] == NULL) || (row[DB_exp_date] == NULL) ||
@@ -2003,8 +2003,7 @@ again2:
row[DB_type][0] = 'V';
row[DB_type][1] = '\0';
 
-   if ((irow = (char **)malloc(sizeof(char *) * (DB_NUMBER + 1))) ==
-   NULL) {
+   if ((irow = malloc(sizeof(char *) * (DB_NUMBER + 1))) == NULL) {
BIO_printf(bio_err, Memory allocation failure\n);
goto err;
}
@@ -2245,17 +2244,17 @@ do_revoke(X509 * x509, CA_DB * db, int t
row[DB_serial], row[DB_name]);
 
/* We now just add it to the database */
-   row[DB_type] = (char *) malloc(2);
+   row[DB_type] = malloc(2);
 
tm = X509_get_notAfter(x509);
-   row[DB_exp_date] = (char *) malloc(tm-length + 1);
+   row[DB_exp_date] = malloc(tm-length + 1);
memcpy(row[DB_exp_date], tm-data, tm-length);
row[DB_exp_date][tm-length] = '\0';
 
row[DB_rev_date] = NULL;
 
/* row[DB_serial] done already */
-   row[DB_file] = (char *) malloc(8);
+   row[DB_file] = malloc(8);
 
/* row[DB_name] done already */
 
@@ -2268,7 +2267,7 @@ do_revoke(X509 * x509, CA_DB * db, int t
row[DB_type][0] = 'V';
row[DB_type][1] = '\0';
 
-   if ((irow = (char **)malloc(sizeof(char *) *
+   if ((irow = malloc(sizeof(char *) *
(DB_NUMBER + 1))) == NULL) {
BIO_printf(bio_err, Memory allocation failure\n);
goto err;
@@ -2405,7 +2404,7 @@ do_updatedb(CA_DB * db)
 
/* get actual time and make a string */
a_tm = X509_gmtime_adj(a_tm, 0);
-   a_tm_s = (char *) malloc(a_tm-length + 1);
+   a_tm_s = malloc(a_tm-length + 1);
if (a_tm_s == NULL) {
cnt = -1;
goto err;
Index: dgst.c
===
RCS file: /cvs/src/lib/libssl/src/apps/dgst.c,v
retrieving revision 1.27
diff -u -p -r1.27 dgst.c
--- dgst.c  18 Apr 2014 19:54:57 -  1.27
+++ dgst.c  23 Apr 2014 07:20:30 -
@@ -132,7 +132,7 @@ dgst_main(int argc, char **argv)
 
apps_startup();
 
-   if ((buf = (unsigned char *) malloc(BUFSIZE)) == 

Re: GSoC proposal: Quirinus C library (qc)

[Thomas Adam]

On 25 February 2014 11:39, Dmitry Selyutin ghostman...@gmail.com wrote:
 It's a pity that for language like C we generally don't have something
 universal like Boost, so we have to implement some common functions from
 scratch or introduce new dependencies. We have Glib, which is used mainly
 by Gnome developers (though it is a standalone library) and LGPL-ed, which
 is not as liberal as Boost's license. We also have APR, which seems to be a
 bit more comprehensive and convenient, yet it is not so well-known as Glib.
 I'm in process of implementing a something like Boost for ANSI C (though I
 don't pretend this library to share Boost's comprehensiveness). Several
 ideas I find useful are:

Well, what you'll find here in OpenBSD is that a lot of projects---and
by that I mean those Open* ones affiliated with OpenBSD, or those
maintained as part of src/ (core) to have some convention like xfoo()
where foo() is some standard library which has been wrapped to provide
additional checking/functionality.  A good example of this is
xmalloc() which tends to check the return value from malloc() as not
NULL and acting accordingly.

Are you saying your Quirinus library should help reduce this
duplication?  In terms of things like data structures, we have TAILQ,
CIRCLEQ, and RB_TREES all of which are surprisingly not portable
without the header files outside of BSD.  Additionally, OpenBSD has
things like strtonum(), strlcpy(), etc., all of which provide
solutions to specific problems.  How does your proposed library help
unify these, seeing as they already exist?

 1. Strict and universal interface. Each function begins with qc_ prefix,

That's more a naming convention than an interface.

 followed by type if function is type-related. Most of types (except
 enum-typedef'ed ones) have three common functions (replace _type_ with the
 necessary type name, e.g. _bytes_):
   a. Constructor: void * qc_type_construct(void). Allocate object instance
 and initialize it to default value.
   b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory
 allocated for object and its members.
   c. Replicator: void * qc_type_replicate(void const * pointer). Replicate
 object, copying its data to new allocated object, i.e. clone.

Hmm.  I am not sure I like this---but my immediate question is why is
this better than what we have now, and where might you consider its
replacement within OpenBSD to be beneficial?  Do you have an example?

 2. Common and universal error type, qc_error. Such errors can be generated
 from errno values as well as from Windows API errors.

Welcome to strerrno()

[...]

-- Thomas Adam

Add EMC Barcode Scanner to usbdevs

[Thomas Pfaff]

Add IDs for Elan Microelectronics barcode scanner (from usb.ids).

uhidev1 at uhub3 port 4 configuration 1 interface 0 vendor 0x04f3 product 
0x0001 rev 1.10/1.00 addr 3

uhidev1 at uhub3 port 4 configuration 1 interface 0 Elan Microelectronics 
Corp. Barcode Scanner rev 1.10/1.00 addr 3

Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.617
diff -u -p -r1.617 usbdevs
--- usbdevs 13 Dec 2013 17:38:38 -  1.617
+++ usbdevs 16 Dec 2013 10:30:55 -
@@ -148,6 +148,7 @@ vendor SAMSUNG2 0x04e8  Samsung Electron
 vendor ANNABOOKS   0x04ed  Annabooks
 vendor JVC 0x04f1  JVC
 vendor CHICONY 0x04f2  Chicony Electronics
+vendor ELAN0x04f3  Elan Microelectronics Corp.
 vendor BROTHER 0x04f9  Brother Industries
 vendor DALLAS  0x04fa  Dallas Semiconductor
 vendor ACER0x0502  Acer
@@ -1569,6 +1570,9 @@ product EICON DIVA852 0x4905  Diva 852 I
 /* EIZO products */
 product EIZO HUB   0x  hub
 product EIZO MONITOR   0x0001  monitor
+
+/* Elan Microelectronics products */
+product ELAN BARCODE   0x0001  Barcode Scanner
 
 /* ELCON Systemtechnik products */
 product ELCON PLAN 0x0002  Goldpfeil P-LAN

Add ATI Radeon HD 7850 and 7850 HD Audio to pcidevs

[Thomas Pfaff]

Add ATI Radeon HD 7850 and 7850 HD Audio to pcidevs.

Verified with the Windows driver information (I was
unable to find these ids anywhere else).

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1664
diff -u -p -r1.1664 pcidevs
--- pcidevs 2 Jan 2013 05:45:41 -   1.1664
+++ pcidevs 13 Jan 2013 10:09:07 -
@@ -1263,6 +1263,7 @@ product ATI RADEON_X700_PCIE_S0x5e6d  Ra
 product ATI RADEON_X700_SE 0x5e4f  Radeon X700 SE
 product ATI RADEON_X700_SE_S   0x5e6f  Radeon X700 SE Sec
 product ATI RADEON_HD6670  0x6758  Radeon HD 6670
+product ATI RADEON_HD7850  0x6819  Radeon HD 7850
 product ATI RADEON_HD5800  0x6899  Radeon HD 5800
 product ATI RADEON_HD5700  0x68b8  Radeon HD 5700
 product ATI RADEON_HD5670  0x68d8  Radeon HD 5670
@@ -1512,6 +1513,7 @@ product ATI RADEON_HD5600_HDA 0xaa60  Rad
 product ATI RADEON_HD5470_HDA  0xaa68  Radeon HD 5470 Audio
 product ATI RADEON_HD6670_HDA  0xaa90  Radeon HD 6670 Audio
 product ATI RADEON_HD6400_HDA  0xaa98  Radeon HD 6400 Audio
+product ATI RADEON_HD7850_HDA  0xaab0  Radeon HD 7850 HD Audio
 product ATI RS100_AGP  0xcab0  RS100 AGP
 product ATI RS200_AGP  0xcab2  RS200 AGP
 product ATI RS250_AGP  0xcab3  RS250 AGP

Re: Add ATI Radeon HD 7850 and 7850 HD Audio to pcidevs

[Thomas Pfaff]

On Sun, 13 Jan 2013 12:18:50 + (UTC)
Alexey E. Suslikov alexey.susli...@gmail.com wrote:

 Thomas Pfaff tpfaff at tp76.info writes:
 
   product ATI RADEON_HD6400_HDA  0xaa98  Radeon HD 6400 Audio
  +product ATI RADEON_HD7850_HDA  0xaab0  Radeon HD 7850 HD Audio
 
 I think 7850 audio entry shouldn't say HD twice (see 6400).


product ATI RADEON_HD6310_HDA  0x1314  Radeon HD 6310 HD Audio

I'm not sure what's correct.

Re: Add ATI Radeon HD 7850 to pcidevs

[Thomas Pfaff]

On Mon, 19 Nov 2012 18:44:23 +0100
Thomas Pfaff tpf...@tp76.info wrote:

 Add ATI Radeon HD 7850 to pcidevs.

Sorted by PCI ID this time (dmesg also included).

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1661
diff -u -p -r1.1661 pcidevs
--- pcidevs 17 Nov 2012 15:42:29 -  1.1661
+++ pcidevs 20 Nov 2012 13:00:59 -
@@ -1262,6 +1262,7 @@ product ATI RADEON_X700_PCIE_S0x5e6d  Ra
 product ATI RADEON_X700_SE 0x5e4f  Radeon X700 SE
 product ATI RADEON_X700_SE_S   0x5e6f  Radeon X700 SE Sec
 product ATI RADEON_HD6670  0x6758  Radeon HD 6670
+product ATI RADEON_HD7850  0x6819  Radeon HD 7850
 product ATI RADEON_HD5800  0x6899  Radeon HD 5800
 product ATI RADEON_HD5700  0x68b8  Radeon HD 5700
 product ATI RADEON_HD5670  0x68d8  Radeon HD 5670


OpenBSD 5.2-current (GENERIC.MP) #21: Tue Nov 20 14:04:21 CET 2012
tpf...@ws.tp76.info:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8535011328 (8139MB)
avail mem = 8285323264 (7901MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb520 (104 entries)
bios0: vendor American Megatrends Inc. version 1406 date 07/19/2012
bios0: ASUSTeK COMPUTER INC. P8Z77-V
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT DMAR
acpi0: wakeup devices PS2M(S4) UAR1(S4) PS2K(S4) P0P1(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) 
PEG3(S4) PXSX(S4) RP05(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(S4) PWRB(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) i5-3550 CPU @ 3.30GHz, 3310.15 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 100MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 3309.72 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 3309.72 MHz
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz, 3309.72 MHz
cpu3: 
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 3 (RP04)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus 6 (RP07)
acpiprt8 at acpi0: bus 7 (RP08)
acpiprt9 at acpi0: bus 1 (PEG0)
acpiprt10 at acpi0: bus -1 (PEG1)
acpiprt11 at acpi0: bus -1 (PEG2)
acpiprt12 at acpi0: bus -1 (PEG3)
acpiprt13 at acpi0: bus 4 (RP05)
acpiprt14 at acpi0: bus 5 (PXSX)
acpiec0 at acpi0
acpiec at acpi0 not configured
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00
acpipwrres1 at acpi0: FN01
acpipwrres2 at acpi0: FN02
acpipwrres3 at acpi0: FN03
acpipwrres4 at acpi0: FN04
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: Enhanced SpeedStep 3310 MHz: speeds: 3301, 3300, 3200, 3100, 2900, 2800, 
2700, 2600, 2400, 2300, 2200, 2100