Re: Stop using direct syscall(2) from perl(1)

2023-07-19 Thread Marc Espie
On Sun, Jul 09, 2023 at 01:29:58PM -0700, Andrew Hewus Fresh wrote:
> Here is a patch to replace perl(1)'s use of syscall(2) with a dispatcher
> that will call the libc function instead.
> 
> I have to do some work on style before this is ready to commit, but it
> should be ready for some testing.
> 
> I don't currently plan on committing syscall_emulator.c because we need
> to regenerate it each time as I'm not sure how to tie it into sys/kern's
> `make syscalls` to only do it when things change.
> 
> Looking for tests from folks who use syscall from perl as well as style
> suggestions (like how do I correctly sort headers?) and maybe even
> ways to enable additional syscalls.

Nits in the perl part.

> Index: gnu/usr.bin/perl/gen_syscall_emulator.pl
> ===
> RCS file: gnu/usr.bin/perl/gen_syscall_emulator.pl
> diff -N gnu/usr.bin/perl/gen_syscall_emulator.pl
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ gnu/usr.bin/perl/gen_syscall_emulator.pl  9 Jul 2023 19:42:50 -
> @@ -0,0 +1,354 @@
> +#!/usr/bin/perl
> +#$OpenBSD$   #
> +use v5.36;
> +
> +# Copyright (c) 2023 Andrew Hewus Fresh 
> +#
> +# 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.
> +
> +my $includes = '/usr/include';
> +
> +# See also /usr/src/sys/kern/syscalls.master
> +my %syscalls = parse_syscalls(
> +"$includes/sys/syscall.h",
> +"$includes/sys/syscallargs.h",
> +);
> +delete $syscalls{MAXSYSCALL}; # not an actual function
> +
> +# The ordered list of all the headers we need
> +my @headers = qw<
> + sys/syscall.h
> + stdarg.h
> + errno.h
> +
> + sys/socket.h
> + sys/event.h
> + sys/futex.h
> + sys/ioctl.h
> + sys/ktrace.h
> + sys/mman.h
> + sys/mount.h
> + sys/msg.h
> + sys/poll.h
> + sys/ptrace.h
> + sys/resource.h
> + sys/select.h
> + sys/sem.h
> + sys/shm.h
> + sys/stat.h
> + sys/sysctl.h
> + sys/time.h
> + sys/uio.h
> + sys/wait.h
> +
> + dirent.h
> + fcntl.h
> + sched.h
> + signal.h
> + stdlib.h
> + stdio.h
> + syslog.h
> + tib.h
> + time.h
> + unistd.h
> +>;
> +
> +foreach my $header (@headers) {
> + my $file = "$includes/$header";
> + open my $fh, '<', $file or die "Unable to open $file: $!";
you could just autodie as you don't ever do anything fancy when open fails.
> + my $content = do { local $/; readline $fh };
> + close $fh;
> +
> + # Look for matching syscalls in this header
not sure that comment brings anything, or maybe you want a function, as
you tend to get fairly long winded.
> + foreach my $name (sort keys %syscalls) {
> + my $s = $syscalls{$name};
> + my $func_sig = find_func_sig($content, $name, $s);
> +
> + if (ref $func_sig) {
> + die "Multiple defs for $name <$header> <$s->{header}>"
> + if $s->{header};
> + $s->{func} = $func_sig;
> + $s->{header} = $header;
> + } elsif ($func_sig) {
> + $s->{mismatched_sig} = "$func_sig <$header>";
> + }
> + }
> +}
> +
> +say "/*\n * Generated from gen_syscall_emulator.pl\n */";
> +say "#include <$_>" for @headers;
> +print <<"EOL";
> +
> +long
> +syscall_emulator(int syscall, ...)
> +{
> + long ret = 0;
> + va_list args;
> + va_start(args, syscall);
> +
> + switch(syscall) {
> +EOL
> +
> +foreach my $name (
> + sort { $syscalls{$a}{id} <=> $syscalls{$b}{id} } keys %syscalls
> +) {
> + my %s = %{ $syscalls{$name} };
I never put spaces in this kind of construct, as I find it fairly readable
by itself
> +
> + # Some syscalls we can't emulate, so we comment those out.
> + $s{skip} //= "Indirect syscalls not supported"
> + if !$s{argtypes} && ($s{args}[-1] || '') eq '...';
> + $s{skip} //= "Mismatched func: $s{mismatched_sig}"
> + if $s{mismatched_sig} and not $s{func};
> + $s{skip} //= "No signature found in headers"
> + unless $s{header};
> +
> + my $ret = $s{ret} eq 'void' ? '' : 'ret = ';
> + $ret .= '(long)' if $s{ret} eq 'void *';
> +
> + my (@args, @defines);
> + my $argname = '';
> + if ($s{argtypes}) {
> +  

Re: Stop using direct syscall(2) from perl(1)

2023-07-19 Thread Theo de Raadt
-my $sb = "\0\0\0\0";
+my $sb = "\0" x 4096;

That's pretty terrible.  Does this language not have types?



Re: Stop using direct syscall(2) from perl(1)

2023-07-19 Thread George Koehler
On Sun, 9 Jul 2023 13:29:58 -0700
Andrew Hewus Fresh  wrote:

> +syscall_emulator.h   Emulator to dispatch syscalls to libc

This got installed as
/usr/libdata/perl5/powerpc64-openbsd/CORE/syscall_emulator.h

ExtUtils::MakeMaker is using cc -DHAS_SYSCALL_EMULATOR to build my XS
module; the define causes  to #include .

Can we hide this feature from XS?  I wish that only pp_sys.c and
syscall_emulator.c would #include , that
syscall_emulator.h would not be installed, and that
-DHAS_SYSCALL_EMULATOR would not appear in non-core modules.


Also, the new test has a heap overflow, because $sb is too small for
a struct stat,

$ cd /usr/src/gnu/usr.bin/perl/obj
$ MALLOC_OPTIONS=S perl t/op/syscall_emulator.t  
/usr/include/sys/syscall.h -> /usr/include/sys/syscall.ph
1..13
ok 1 - Opened test.txt for write/create
ok 2 - Wrote out to test.txt
ok 3 - closed test.txt
perl(15511) in malloc(): write after free 0xc36d1efcddc0
Abort trap (core dumped) 

I prevented the overflow by making $sb too big,

--- t/op/syscall_emulator.t.before  Thu Jul 13 00:39:10 2023
+++ t/op/syscall_emulator.t Wed Jul 19 15:32:40 2023
@@ -47,7 +47,7 @@
 my $out = "Hello World\n";
 my $in = "\0" x 32;
 my ($in_p, $in_v);
-my $sb = "\0\0\0\0";
+my $sb = "\0" x 4096;
 my $st_mode;
 
 my $perms = S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH;



Re: cron -n/-s/-q whitespace and /etc/crontab

2023-07-19 Thread Todd C . Miller
On Wed, 19 Jul 2023 16:44:23 +0100, Stuart Henderson wrote:

> When /etc/crontab is used, cron only skips over a single whitespace
> character between the username and -n/-s/-q flags; more than one and
> the flag is taken as part of the command:
>
> printf '*\t*\t*\t*\t*\tnobody\t-n true 1\n' | doas tee -a /etc/crontab
> printf '*\t*\t*\t*\t*\tnobody\t\t-n true 2\n' | doas tee -a /etc/crontab
>
> 2023-07-19T15:39:01.316Z symphytum cron[96294]: (nobody) CMD (  -n true 2)
> 2023-07-19T15:39:01.317Z symphytum cron[81012]: (nobody) CMD (true 1)
>
> Is this a "so don't do that then", or is it expected to work?
> (There's no problem with "per-user crontab" files).

It is a bug.  There is a missing call to Skip_Blanks() for the
/etc/crontab case.  Instead of adding yet another unget_char() after
Skip_Blanks(), we can get rid of a superfluous unget_char() +
get_char() pair.
 
 - todd

Index: usr.sbin/cron/entry.c
===
RCS file: /cvs/src/usr.sbin/cron/entry.c,v
retrieving revision 1.58
diff -u -p -u -r1.58 entry.c
--- usr.sbin/cron/entry.c   13 Jun 2023 15:36:21 -  1.58
+++ usr.sbin/cron/entry.c   19 Jul 2023 16:01:08 -
@@ -275,18 +275,17 @@ load_entry(FILE *file, void (*error_func
goto eof;
}
 
-   /* ch is the first character of a command, or a username */
-   unget_char(ch, file);
-
if (!pw) {
char*username = cmd;/* temp buffer */
 
+   unget_char(ch, file);
ch = get_string(username, MAX_COMMAND, file, " \t\n");
 
if (ch == EOF || ch == '\n' || ch == '*') {
ecode = e_cmd;
goto eof;
}
+   Skip_Blanks(ch, file)
 
pw = getpwnam(username);
if (pw == NULL) {
@@ -356,7 +355,6 @@ load_entry(FILE *file, void (*error_func
/* An optional series of '-'-prefixed flags in getopt style can
 * occur before the command.
 */
-   ch = get_char(file);
while (ch == '-') {
int flags = 0, loop = 1;
 



cron -n/-s/-q whitespace and /etc/crontab

2023-07-19 Thread Stuart Henderson
When /etc/crontab is used, cron only skips over a single whitespace
character between the username and -n/-s/-q flags; more than one and
the flag is taken as part of the command:

printf '*\t*\t*\t*\t*\tnobody\t-n true 1\n' | doas tee -a /etc/crontab
printf '*\t*\t*\t*\t*\tnobody\t\t-n true 2\n' | doas tee -a /etc/crontab

2023-07-19T15:39:01.316Z symphytum cron[96294]: (nobody) CMD (  -n true 2)
2023-07-19T15:39:01.317Z symphytum cron[81012]: (nobody) CMD (true 1)

Is this a "so don't do that then", or is it expected to work?
(There's no problem with "per-user crontab" files).



OpenBSD Errata: July 19, 2023 (ssh-agent)

2023-07-19 Thread Alexander Bluhm
Errata patches for ssh-agent have been released for
OpenBSD 7.2 and 7.3.

Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility.  Source code patches can be found on the
respective errata page:

  https://www.openbsd.org/errata72.html
  https://www.openbsd.org/errata73.html



Re: patch: partially fix interactive mode

2023-07-19 Thread Florian Obser
OK florian

On 2023-07-19 13:17 +02, Theo Buehler  wrote:
> The addition of unveil broke interactive mode since ask() assumes the
> default answer if it fails to open _PATH_TTY. Questions are only asked
> if neither force nor batch mode is activated, so condition on those.
>
> It seams cleaner to do unveil _PATH_TTY than to add a tty pledge since
> as far as I can see no ioctls on /dev/tty are emitted.
>
> Without this patch:
>
> $ cd usr.bin
> $ patch -Rs < /path/to/patch.below
> File to patch:
> No file found--skip this patch? [y]
> 1 out of 1 hunks ignored--saving rejects to Oops.rej
>
> With this patch:
>
> $ cd usr.bin
> $ patch -Rs < /path/to/patch.below
> File to patch: patch/patch.c
> Unreversed (or previously applied) patch detected!  Ignore -R? [y] y
>
> Obviously the unveil(".", rwc) places restrictions on the path that can
> be given, but that's expected.
>
> Index: patch.c
> ===
> RCS file: /cvs/src/usr.bin/patch/patch.c,v
> retrieving revision 1.73
> diff -u -p -4 -r1.73 patch.c
> --- patch.c   15 Jul 2023 10:42:54 -  1.73
> +++ patch.c   19 Jul 2023 11:09:37 -
> @@ -222,8 +222,13 @@ main(int argc, char *argv[])
>   if (unveil(filearg[1], "r") == -1) {
>   perror("unveil");
>   my_exit(2);
>   }
> + if (!force && !batch)
> + if (unveil(_PATH_TTY, "rw") == -1) {
> + perror("unveil");
> + my_exit(2);
> + }
>   if (unveil(".", "rwc") == -1) {
>   perror("unveil");
>   my_exit(2);
>   }
>

-- 
In my defence, I have been left unsupervised.



patch: partially fix interactive mode

2023-07-19 Thread Theo Buehler
The addition of unveil broke interactive mode since ask() assumes the
default answer if it fails to open _PATH_TTY. Questions are only asked
if neither force nor batch mode is activated, so condition on those.

It seams cleaner to do unveil _PATH_TTY than to add a tty pledge since
as far as I can see no ioctls on /dev/tty are emitted.

Without this patch:

$ cd usr.bin
$ patch -Rs < /path/to/patch.below
File to patch:
No file found--skip this patch? [y]
1 out of 1 hunks ignored--saving rejects to Oops.rej

With this patch:

$ cd usr.bin
$ patch -Rs < /path/to/patch.below
File to patch: patch/patch.c
Unreversed (or previously applied) patch detected!  Ignore -R? [y] y

Obviously the unveil(".", rwc) places restrictions on the path that can
be given, but that's expected.

Index: patch.c
===
RCS file: /cvs/src/usr.bin/patch/patch.c,v
retrieving revision 1.73
diff -u -p -4 -r1.73 patch.c
--- patch.c 15 Jul 2023 10:42:54 -  1.73
+++ patch.c 19 Jul 2023 11:09:37 -
@@ -222,8 +222,13 @@ main(int argc, char *argv[])
if (unveil(filearg[1], "r") == -1) {
perror("unveil");
my_exit(2);
}
+   if (!force && !batch)
+   if (unveil(_PATH_TTY, "rw") == -1) {
+   perror("unveil");
+   my_exit(2);
+   }
if (unveil(".", "rwc") == -1) {
perror("unveil");
my_exit(2);
}



Re: assign wsdisplay0 to the glass console

2023-07-19 Thread Mark Kettenis
> Date: Wed, 19 Jul 2023 16:12:59 +0900 (JST)
> From: YASUOKA Masahiko 
> 
> Hi,
> 
> I noticed that the keyboard doesn't work for RAMDISK kernel on HP DL20
> Gen10.  The kernel assigns wsdisplay0 for VGA and wsdisplay1 for
> efifb.  But actually the glass console is efieb but it doesn't have
> any keyboard assigned because the keyboard is assigned to wsdisplay0.
> 
> GENERIC kernel doesn't have the same problem because it was fixed at
> 
>   sys/arch/amd64/conf/GENERIC 1.347
>   sys/arch/i386/conf/GENERIC 1.753
>   (https://github.com/openbsd/src/commit/ea71d02a7c89)
> 
> So the diff does the same thing, make sure wsdisplay0 is always
> assigned for the console.
> 
> 
> ok?

ok kettenis@

> Assign wsdisplay0 to the glass console always.  The same change is
> done for GENERIC already.
> 
> Index: sys/arch/amd64/conf/RAMDISK
> ===
> RCS file: /var/cvs/openbsd/src/sys/arch/amd64/conf/RAMDISK,v
> retrieving revision 1.85
> diff -u -p -r1.85 RAMDISK
> --- sys/arch/amd64/conf/RAMDISK   26 Dec 2021 13:55:36 -  1.85
> +++ sys/arch/amd64/conf/RAMDISK   19 Jul 2023 07:08:36 -
> @@ -74,7 +74,7 @@ pckbd*  at pckbc?   # PC keyboard
>  wskbd*   at pckbd? mux 1
>  vga0 at isa?
>  vga* at pci?
> -wsdisplay*   at vga?
> +wsdisplay0   at vga? console 1
>  
>  com0 at isa? port 0x3f8 irq 4# standard PC serial ports
>  com1 at isa? port 0x2f8 irq 3
> Index: sys/arch/amd64/conf/RAMDISK_CD
> ===
> RCS file: /var/cvs/openbsd/src/sys/arch/amd64/conf/RAMDISK_CD,v
> retrieving revision 1.201
> diff -u -p -r1.201 RAMDISK_CD
> --- sys/arch/amd64/conf/RAMDISK_CD2 Apr 2023 03:40:54 -   1.201
> +++ sys/arch/amd64/conf/RAMDISK_CD19 Jul 2023 07:08:36 -
> @@ -149,7 +149,7 @@ pckbd*at pckbc?   # PC keyboard
>  wskbd*   at pckbd? mux 1
>  vga0 at isa?
>  vga* at pci?
> -wsdisplay*   at vga?
> +wsdisplay0   at vga? console 1
>  
>  efifb0   at mainbus? # EFI Framebuffer
>  wsdisplay0   at efifb? console 1
> Index: sys/arch/i386/conf/RAMDISK
> ===
> RCS file: /var/cvs/openbsd/src/sys/arch/i386/conf/RAMDISK,v
> retrieving revision 1.201
> diff -u -p -r1.201 RAMDISK
> --- sys/arch/i386/conf/RAMDISK16 Feb 2021 00:03:54 -  1.201
> +++ sys/arch/i386/conf/RAMDISK19 Jul 2023 07:08:36 -
> @@ -81,8 +81,8 @@ wskbd*  at pckbd? mux 1
>  vga0 at isa?
>  vga* at pci?
>  pcdisplay0   at isa? # CGA, MDA, EGA, HGA
> -wsdisplay*   at vga?
> -wsdisplay*   at pcdisplay?
> +wsdisplay0   at vga? console 1
> +wsdisplay0   at pcdisplay? console 1
>  
>  com0 at isa? port 0x3f8 irq 4# standard PC serial ports
>  com1 at isa? port 0x2f8 irq 3
> Index: sys/arch/i386/conf/RAMDISK_CD
> ===
> RCS file: /var/cvs/openbsd/src/sys/arch/i386/conf/RAMDISK_CD,v
> retrieving revision 1.252
> diff -u -p -r1.252 RAMDISK_CD
> --- sys/arch/i386/conf/RAMDISK_CD 26 Jun 2022 20:05:06 -  1.252
> +++ sys/arch/i386/conf/RAMDISK_CD 19 Jul 2023 07:08:36 -
> @@ -121,8 +121,8 @@ wskbd*at pckbd? mux 1
>  vga0 at isa?
>  vga* at pci?
>  pcdisplay0   at isa? # CGA, MDA, EGA, HGA
> -wsdisplay*   at vga?
> -wsdisplay*   at pcdisplay?
> +wsdisplay0   at vga? console 1
> +wsdisplay0   at pcdisplay? console 1
>  
>  com0 at isa? port 0x3f8 irq 4# standard PC serial ports
>  com1 at isa? port 0x2f8 irq 3
> 
> 



ixl(4): protect admin queue with mutex

2023-07-19 Thread Jan Klemkow
Hi,

there is an issue with the admin queue of ixl(4) which leads into the
following panic when the link state changes:

uvm_fault(0x818005f8, 0x18, 0, 2) -> e
kernel: page fault trap, code=0
Stopped at  ixl_intr0+0xca: movq%rdx,0x18(%rax)
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
 392823  13219  00x100040  02  ifstated
 444681  94950 90   0x1100010  06  ospf6d
 428704   9496 90   0x1100010  09  ospf6d
 106020  59273 85   0x1100010  01  ospfd
 420435  72114 85   0x1100010  05  ospfd
 295821  93368 73   0x1100010  03  syslogd
 367116  56598  0 0x14000  0x2007  zerothread
 275385  57815  0 0x14000  0x2004  softnet
ixl_intr0(84509000) at ixl_intr0+0xca
intr_handler(0,844b0b80) at intr_handler+0x5b
Xintr_ioapic_edge25_untramp() at Xintr_ioapic_edge25_untramp+0x18f
acpicpu_idle() at acpicpu_idle+0x1f6
sched_idle(0) at sched_idle+0x280
end trace frame: 0x0, count: 10
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
ddb{0}>

The queue is corrupted in a way, that slot->iaq_cookie is 0.  Which
causes the uvm fault when iatq is dereferenced.

The following diff uses a mutex to protect the admin queue and avoids
the issue above.

ok?

bye,
Jan

Index: dev/pci/if_ixl.c
===
RCS file: /cvs/src/sys/dev/pci/if_ixl.c,v
retrieving revision 1.87
diff -u -p -r1.87 if_ixl.c
--- dev/pci/if_ixl.c6 Feb 2023 20:27:45 -   1.87
+++ dev/pci/if_ixl.c19 Jul 2023 07:05:40 -
@@ -1274,6 +1274,7 @@ struct ixl_softc {
unsigned int sc_atq_prod;
unsigned int sc_atq_cons;
 
+   struct mutex sc_atq_mtx;
struct ixl_dmamemsc_arq;
struct task  sc_arq_task;
struct ixl_aq_bufs   sc_arq_idle;
@@ -1723,6 +1724,8 @@ ixl_attach(struct device *parent, struct
 
/* initialise the adminq */
 
+   mtx_init(&sc->sc_atq_mtx, IPL_NET);
+
if (ixl_dmamem_alloc(sc, &sc->sc_atq,
sizeof(struct ixl_aq_desc) * IXL_AQ_NUM, IXL_AQ_ALIGN) != 0) {
printf("\n" "%s: unable to allocate atq\n", DEVNAME(sc));
@@ -3599,6 +3602,8 @@ ixl_atq_post(struct ixl_softc *sc, struc
struct ixl_aq_desc *atq, *slot;
unsigned int prod;
 
+   mtx_enter(&sc->sc_atq_mtx);
+
/* assert locked */
 
atq = IXL_DMA_KVA(&sc->sc_atq);
@@ -3618,6 +3623,8 @@ ixl_atq_post(struct ixl_softc *sc, struc
prod &= IXL_AQ_MASK;
sc->sc_atq_prod = prod;
ixl_wr(sc, sc->sc_aq_regs->atq_tail, prod);
+
+   mtx_leave(&sc->sc_atq_mtx);
 }
 
 static void
@@ -3628,11 +3635,15 @@ ixl_atq_done(struct ixl_softc *sc)
unsigned int cons;
unsigned int prod;
 
+   mtx_enter(&sc->sc_atq_mtx);
+
prod = sc->sc_atq_prod;
cons = sc->sc_atq_cons;
 
-   if (prod == cons)
+   if (prod == cons) {
+   mtx_leave(&sc->sc_atq_mtx);
return;
+   }
 
atq = IXL_DMA_KVA(&sc->sc_atq);
 
@@ -3645,6 +3656,7 @@ ixl_atq_done(struct ixl_softc *sc)
if (!ISSET(slot->iaq_flags, htole16(IXL_AQ_DD)))
break;
 
+   KASSERT(slot->iaq_cookie != 0);
iatq = (struct ixl_atq *)slot->iaq_cookie;
iatq->iatq_desc = *slot;
 
@@ -3661,6 +3673,8 @@ ixl_atq_done(struct ixl_softc *sc)
BUS_DMASYNC_PREREAD|BUS_DMASYNC_PREWRITE);
 
sc->sc_atq_cons = cons;
+
+   mtx_leave(&sc->sc_atq_mtx);
 }
 
 static void
@@ -3691,6 +3705,8 @@ ixl_atq_poll(struct ixl_softc *sc, struc
unsigned int prod;
unsigned int t = 0;
 
+   mtx_enter(&sc->sc_atq_mtx);
+
atq = IXL_DMA_KVA(&sc->sc_atq);
prod = sc->sc_atq_prod;
slot = atq + prod;
@@ -3712,8 +3728,10 @@ ixl_atq_poll(struct ixl_softc *sc, struc
while (ixl_rd(sc, sc->sc_aq_regs->atq_head) != prod) {
delaymsec(1);
 
-   if (t++ > tm)
+   if (t++ > tm) {
+   mtx_leave(&sc->sc_atq_mtx);
return (ETIMEDOUT);
+   }
}
 
bus_dmamap_sync(sc->sc_dmat, IXL_DMA_MAP(&sc->sc_atq),
@@ -3724,6 +3742,7 @@ ixl_atq_poll(struct ixl_softc *sc, struc
 
sc->sc_atq_cons = prod;
 
+   mtx_leave(&sc->sc_atq_mtx);
return (0);
 }
 



assign wsdisplay0 to the glass console

2023-07-19 Thread YASUOKA Masahiko
Hi,

I noticed that the keyboard doesn't work for RAMDISK kernel on HP DL20
Gen10.  The kernel assigns wsdisplay0 for VGA and wsdisplay1 for
efifb.  But actually the glass console is efieb but it doesn't have
any keyboard assigned because the keyboard is assigned to wsdisplay0.

GENERIC kernel doesn't have the same problem because it was fixed at

  sys/arch/amd64/conf/GENERIC 1.347
  sys/arch/i386/conf/GENERIC 1.753
  (https://github.com/openbsd/src/commit/ea71d02a7c89)

So the diff does the same thing, make sure wsdisplay0 is always
assigned for the console.


ok?

Assign wsdisplay0 to the glass console always.  The same change is
done for GENERIC already.

Index: sys/arch/amd64/conf/RAMDISK
===
RCS file: /var/cvs/openbsd/src/sys/arch/amd64/conf/RAMDISK,v
retrieving revision 1.85
diff -u -p -r1.85 RAMDISK
--- sys/arch/amd64/conf/RAMDISK 26 Dec 2021 13:55:36 -  1.85
+++ sys/arch/amd64/conf/RAMDISK 19 Jul 2023 07:08:36 -
@@ -74,7 +74,7 @@ pckbd*at pckbc?   # PC keyboard
 wskbd* at pckbd? mux 1
 vga0   at isa?
 vga*   at pci?
-wsdisplay* at vga?
+wsdisplay0 at vga? console 1
 
 com0   at isa? port 0x3f8 irq 4# standard PC serial ports
 com1   at isa? port 0x2f8 irq 3
Index: sys/arch/amd64/conf/RAMDISK_CD
===
RCS file: /var/cvs/openbsd/src/sys/arch/amd64/conf/RAMDISK_CD,v
retrieving revision 1.201
diff -u -p -r1.201 RAMDISK_CD
--- sys/arch/amd64/conf/RAMDISK_CD  2 Apr 2023 03:40:54 -   1.201
+++ sys/arch/amd64/conf/RAMDISK_CD  19 Jul 2023 07:08:36 -
@@ -149,7 +149,7 @@ pckbd*  at pckbc?   # PC keyboard
 wskbd* at pckbd? mux 1
 vga0   at isa?
 vga*   at pci?
-wsdisplay* at vga?
+wsdisplay0 at vga? console 1
 
 efifb0 at mainbus? # EFI Framebuffer
 wsdisplay0 at efifb? console 1
Index: sys/arch/i386/conf/RAMDISK
===
RCS file: /var/cvs/openbsd/src/sys/arch/i386/conf/RAMDISK,v
retrieving revision 1.201
diff -u -p -r1.201 RAMDISK
--- sys/arch/i386/conf/RAMDISK  16 Feb 2021 00:03:54 -  1.201
+++ sys/arch/i386/conf/RAMDISK  19 Jul 2023 07:08:36 -
@@ -81,8 +81,8 @@ wskbd*at pckbd? mux 1
 vga0   at isa?
 vga*   at pci?
 pcdisplay0 at isa? # CGA, MDA, EGA, HGA
-wsdisplay* at vga?
-wsdisplay* at pcdisplay?
+wsdisplay0 at vga? console 1
+wsdisplay0 at pcdisplay? console 1
 
 com0   at isa? port 0x3f8 irq 4# standard PC serial ports
 com1   at isa? port 0x2f8 irq 3
Index: sys/arch/i386/conf/RAMDISK_CD
===
RCS file: /var/cvs/openbsd/src/sys/arch/i386/conf/RAMDISK_CD,v
retrieving revision 1.252
diff -u -p -r1.252 RAMDISK_CD
--- sys/arch/i386/conf/RAMDISK_CD   26 Jun 2022 20:05:06 -  1.252
+++ sys/arch/i386/conf/RAMDISK_CD   19 Jul 2023 07:08:36 -
@@ -121,8 +121,8 @@ wskbd*  at pckbd? mux 1
 vga0   at isa?
 vga*   at pci?
 pcdisplay0 at isa? # CGA, MDA, EGA, HGA
-wsdisplay* at vga?
-wsdisplay* at pcdisplay?
+wsdisplay0 at vga? console 1
+wsdisplay0 at pcdisplay? console 1
 
 com0   at isa? port 0x3f8 irq 4# standard PC serial ports
 com1   at isa? port 0x2f8 irq 3