Re: edgerouter poe panics when bringing network up at boot

[Miod Vallat]

> digging in the archives, i found
> https://marc.info/?l=openbsd-bugs=151063517020444=2 which seems to
> say that it'd be better to apparently skip that port (and that there's
> no hope for the two remaining ports ?)

Good work digging into the archives, I was not aware of that previous
report. I think both of visa@'s diffs should go in.

Re: edgerouter poe panics when bringing network up at boot

[Miod Vallat]

> hi,
> 
> playing with 7.5 on an edgerouter poe, it panics at boot:

Congratulations, you've reached a divide by zero in the kernel.

This is caused by cn30xxgmx_rgmii_speed() setting the local variable
`baudrate' to zero (with an XXX comment) prior to dividing by it.

The following diff sweeps the issue under the rug by following the
"consider unknown value as 1Gbps" logic used all over the file. It might
help your setup.

Index: dev/cn30xxgmx.c
===
RCS file: /OpenBSD/src/sys/arch/octeon/dev/cn30xxgmx.c,v
retrieving revision 1.54
diff -u -p -r1.54 cn30xxgmx.c
--- dev/cn30xxgmx.c 20 May 2024 23:13:33 -  1.54
+++ dev/cn30xxgmx.c 2 Jul 2024 19:49:45 -
@@ -991,7 +991,8 @@ cn30xxgmx_rgmii_speed(struct cn30xxgmx_p
baudrate = IF_Gbps(1);
break;
default:
-   baudrate = 0/* XXX */;
+   /* Assume 1Gbps for now*/
+   baudrate = IF_Gbps(1);  /* XXX */
break;
}
ifp->if_baudrate = baudrate;
@@ -1202,7 +1203,7 @@ cn30xxgmx_rgmii_speed_speed(struct cn30x
SET(prt_cfg, PRTN_CFG_SPEED);
break;
default:
-   /* NOT REACHED! */
+   /* THEORETICALLY NOT REACHED! */
/* Following configuration is default value of system.
*/
tx_clk = 1;

Re: powerpc64/pmap.c trouble report

[Miod Vallat]

> There's a corruption...
> 
> > ddb{7}> show panic
> >  cpu6: kernel diagnostic assertion "((flags & PGO_LOCKED) != 0 && 
> > rw_lock_held(
> > uobj->vmobjlock)) || (flags & PGO_LOCKED) == 0" failed: file 
> > "/sys/uvm/uvm_vnod
> > e.c", line 953
> > 
> > *cpu7: assertwaitok: non-zero mutex count: 1
> > ddb{7}> trace
> > panic+0x134
> > assertwaitok+0xf8
> > mi_switch+0x5c
> > sleep_finish+0x160
> > rw_enter+0x1cc
> > vm_map_lock_read_ln+0x38
> > uvmfault_lookup+0x114
> > uvm_fault_check+0x68
> > uvm_fault+0x12c
> > trap+0x7a4
> > trapagain+0x4
> > --- trap (type 0x300) ---
> > phtree_RBT_COMPARE+0x28
> > pool_do_put+0x94
> > pool_put+0x94
>
> ...inside this pool.  Which of the 3 is it?  Can someone with a ppc64
> figure out?

It's pmap_vp_pool.

Re: Kernel panic in malloc in acpi on boot

[Miod Vallat]

> >Synopsis:Kernel panic in malloc in acpi on boot
> >Category:amd64
> >Environment:
>   System  : OpenBSD 7.5
>   Details : OpenBSD 7.5 (GENERIC) #79: Wed Mar 20 15:33:49 MDT 2024
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> During boot the kernel panics:
> 
> panic: malloc: allocation too large, type = 33, size = 292057776136
> 
> This is during some ACPI stuff:

The size, in hex, is 0x440008, i.e. a merge 272 gigabytes.

The _OSC method in your dsdt disassembles as:

Method (_OSC, 5, NotSerialized)  // _OSC: Operating System 
Capabilities
{
Local0 = Arg3
Local1 = (Local0 * 0x04)
Name (BUF1, Buffer (Local1){})
BUF1 = Arg4
Local1 = Zero
Local2 = Zero
While (Local0)
{
Local2 = (Local1 * 0x04)
CreateDWordField (BUF1, Local2, CAPB)
If (Arg2)
{
If ((Local1 == Zero))
{
(CAPB & 0xFFFC)
}
}
Else
{
}

Local1++
Local0--
}

Return (BUF1) /* \_SB_.PCI0._OSC.BUF1 */
}

... which his horribly broken since it incorrectly declares 5 arguments
insteod of 4.

On the OpenBSD side, we can fix the AML interpreter to avoid invoking
methods when we do not pass enough arguments.

You might want to see if a BIOS update is available for your machine in
the meantime.

Re: fxp(4) crashes on ifconfig rdomain when up

[Miod Vallat]

Hello,

  thank you for your bug report. This appears to be a subtle bug
introduced in sys/dev/ic/fxp.c 1.49, a couple months short of being 20
years old.

The following diff ought to fix it. Can you give it a try on your
system?

Thanks,
Miod

Index: fxp.c
===
RCS file: /OpenBSD/src/sys/dev/ic/fxp.c,v
retrieving revision 1.133
diff -u -p -r1.133 fxp.c
--- fxp.c   10 Nov 2023 15:51:20 -  1.133
+++ fxp.c   26 Feb 2024 18:10:58 -
@@ -1382,11 +1382,12 @@ fxp_init(void *xsc)
else
bufs = FXP_NRFABUFS_MIN;
if (sc->rx_bufs > bufs) {
-   while (sc->rfa_headm != NULL && sc->rx_bufs-- > bufs) {
+   while (sc->rfa_headm != NULL && sc->rx_bufs > bufs) {
rxmap = *((bus_dmamap_t *)sc->rfa_headm->m_ext.ext_buf);
bus_dmamap_unload(sc->sc_dmat, rxmap);
FXP_RXMAP_PUT(sc, rxmap);
sc->rfa_headm = m_free(sc->rfa_headm);
+   sc->rx_bufs--;
}
} else if (sc->rx_bufs < bufs) {
int err, tmp_rx_bufs = sc->rx_bufs;

Re: Small bug in /usr/src/distrib/riscv64/ramdisk/Makefile?

[Miod Vallat]

> I noticed that there is a problem with libstubs in this process from a
> "vanilla" riscv64 build box.  It will error out.  The work around is to
> go into /usr/src/distrib/special/libstubs and manually make it there, where
> it gets ranlib'ed.   Then go back to the former path and continue making the
> ramdisk.

That's because you are not following the correct cinematics to build
installation media. You need (as a minimum) to build in distrib/, not in
distrib/arch/whatever.

Re: "kbd -l" -> wskbd_displayioctl_sc uvm_fault

[Miod Vallat]

> > Do you have machdep.forceukbd=1 somewhere in /etc/sysctl.conf?
> 
> Ah, yes! And there's no USB keyboard now, I added that when the
> disk was in a real machine before I moved it to a VM.

Ok, so this is what causes the keymap pointer to be reset to NULL. Phew!
Root cause found.

Anton, could you tweak your diff so that it becomes something like

count = 0;
if (sc->id->t_keymap.keydesc)
for (; sc->id->t_keymap.keydesc[count].name; count ++)
...

in order to only check for a NULL pointer once?

Re: "kbd -l" -> wskbd_displayioctl_sc uvm_fault

[Miod Vallat]

> Diff does fix the crash -
> 
> # kbd -l
> tables available for pc-xt/pc-at keyboard:
> encoding

Do you have machdep.forceukbd=1 somewhere in /etc/sysctl.conf?

Re: Sparc64 rthreads Instablilty

[Miod Vallat]

> Has been running for the last few hours without any issue.
> OK claudio@ on that diff.

But it's your diff! I only polished it a bit.

Re: Sparc64 rthreads Instablilty

[Miod Vallat]

> > A lot of this points towards a register window error in__tfork() which
> > affects only the parent process.
> 
> I think the issue is that cpu_fork() copies the u_pcb from parent to child
> and with that the special user register windows that got spilled because
> of some TL>0 fault. Since __tfork() uses a new stack it makes no sense
> to keep those windows around and possibly fault them back from the new
> thread (onto the old stack).

That makes sense.

> The following diff seems to fix the above repoducer for me. Please test.
> I will need to add some comments etc there (also not sure if the bzero()
> calls are needed or if clearing pcb_nsaved is enough.

Actually, rather than bzero'ing pcb_rwsp and pcb_rw, it would be better
to only bcopy offsetof(struct pcb, pcb_rw) rather than sizeof(struct
pcb) on line 139, i.e. something like this:

Index: vm_machdep.c
===
RCS file: /OpenBSD/src/sys/arch/sparc64/sparc64/vm_machdep.c,v
retrieving revision 1.42
diff -u -p -r1.42 vm_machdep.c
--- vm_machdep.c25 Oct 2022 06:05:57 -  1.42
+++ vm_machdep.c15 Feb 2024 15:29:37 -
@@ -100,6 +100,7 @@ cpu_fork(struct proc *p1, struct proc *p
struct pcb *npcb = >p_addr->u_pcb;
struct trapframe *tf2;
struct rwindow *rp;
+   size_t pcbsz;
extern struct proc proc0;
 
/*
@@ -136,7 +137,15 @@ cpu_fork(struct proc *p1, struct proc *p
 #else
opcb->lastcall = NULL;
 #endif
-   bcopy((caddr_t)opcb, (caddr_t)npcb, sizeof(struct pcb));
+   /*
+* If a new stack is provided, do not bother copying saved windows
+* in the new pcb. Also, we'll reset pcb_nsaved accordingly below.
+*/
+   if (stack != NULL)
+   pcbsz = offsetof(struct pcb, pcb_rw);
+   else
+   pcbsz = sizeof(struct pcb);
+   bcopy((caddr_t)opcb, (caddr_t)npcb, pcbsz);
if (p1->p_md.md_fpstate) {
fpusave_proc(p1, 1);
p2->p_md.md_fpstate = malloc(sizeof(struct fpstate),
@@ -162,6 +171,7 @@ cpu_fork(struct proc *p1, struct proc *p
 * with space reserved for the frame, and zero the frame pointer.
 */
if (stack != NULL) {
+   npcb->pcb_nsaved = 0;
tf2->tf_out[6] = (u_int64_t)(u_long)stack - (BIAS + CC64FSZ);
tf2->tf_in[6] = 0;
}

Re: "kbd -l" -> wskbd_displayioctl_sc uvm_fault

[Miod Vallat]

> Does this help?
> 
> diff --git sys/dev/wscons/wskbd.c sys/dev/wscons/wskbd.c
> index 7631cd5f701..dd65f61ce63 100644
> --- sys/dev/wscons/wskbd.c
> +++ sys/dev/wscons/wskbd.c
> @@ -1229,7 +1229,10 @@ getkeyrepeat:
>  
>   case WSKBDIO_GETENCODINGS:
>   uedp = (struct wskbd_encoding_data *)data;
> - for (count = 0; sc->id->t_keymap.keydesc[count].name; count++)
> + for (count = 0;
> +  sc->id->t_keymap.keydesc != NULL &&
> +  sc->id->t_keymap.keydesc[count].name;
> +  count++)
>   ;
>   if (uedp->nencodings > count)
>   uedp->nencodings = count;
> 

This ought to fix the panic Stuart is getting.

However I don't understand how t_keymap.keydesc can be a NULL pointer
(yet it obviousl was); it is initialized at wskbd attachment time with
valid data.

Stuart, did you issue specific wsconsctl or wsconscfg operations in this
VM prior to running 'kbd -l'? What are the contents of
/etc/wsconsctl.conf, if it exists?

Re: NFS server doesn't close connections (client freezes)

[Miod Vallat]

> The server detects that the connection is closed. It doesn't close the
> socket immediately and starts waiting for the client to reconnect (or
> another client, etc). As the socket is not closed, from client's point
> of view, the connection is still not fully closaed, so it keeps
> waiting before reconnecting with the same source port; a kind of
> deadlock.
> 
> The diff below fixes this by checking for EOF before sleeping.
> 
> OK?

Yes. Unfortunately NEEDQ and DISCONN may be both set, so we still need
to check for DISCONN here before NEEDQ.

Or the whole block could become

if (NEEDQ set and not DISCONN set)
nfsrv_rcv block
if (DISCONN set)
nfsrv_zapsock

but that's probably what the compiler will rewrite the logic into.

> Index: nfs_syscalls.c
> ===
> RCS file: /cvs/src/sys/nfs/nfs_syscalls.c,v
> diff -u -p -r1.119 nfs_syscalls.c
> --- nfs_syscalls.c3 Aug 2023 09:49:09 -   1.119
> +++ nfs_syscalls.c11 Jan 2024 15:15:12 -
> @@ -338,6 +338,15 @@ loop:
>   nfs_sndlock(>ns_solock, NULL);
>   nfsrv_rcv(slp->ns_so, (caddr_t)slp, M_WAIT);
>   nfs_sndunlock(>ns_solock);
> +
> + /*
> +  * The client may have closed the connection.
> +  * If so, zap the socket before sleeping,
> +  * allowing the client to reconnect with the
> +  * same source port.
> +  */
> + if (ISSET(slp->ns_flag, SLP_DISCONN))
> + nfsrv_zapsock(slp);
>   }
>  
>   error = nfsrv_dorec(slp, nfsd, );
> 

Re: ugold(4) TEMPerGold v3.5 tiny fix 2023q4

[Miod Vallat]

> Below patch makes ugold(4) work with TEMPerGold v3.5.

Thanks! Applied.

Re: pthread_main_np(3) randomly fails

[Miod Vallat]

> Should the tib_tid also be initialized?

I don't think so, it is initialized outside of the TIB_INIT macro. See
e.g. setup_static_tib().

Re: pthread_main_np(3) randomly fails

[Miod Vallat]

How about that diff.

Index: include/tib.h
===
RCS file: /OpenBSD/src/include/tib.h,v
retrieving revision 1.9
diff -u -p -r1.9 tib.h
--- include/tib.h   27 Dec 2022 07:44:56 -  1.9
+++ include/tib.h   8 Dec 2023 15:24:49 -
@@ -216,6 +216,7 @@ struct tib {
(tib)->tib_canceled = 0;\
(tib)->tib_dtv  = (dtv);\
(tib)->tib_errno= 0;\
+   (tib)->tib_thread_flags = 0;\
_TIB_PREP(tib); \
} while (0)
 

Re: ugold(4) TEMPerHUM_V3.9 tiny fix 2023q4

[Miod Vallat]

> Below patch made my TEMPerHUM_V3.9 work.

Applied, thanks!

Miod

Re: makefs: sporadic segfaults with FAT32

[Miod Vallat]

> It always chokes on fp->fsisig4.

Well, that's what you get from reading 512 bytes and casting the buffer
to a 1024 byte struct.

The following diff ought to solve this.

Index: msdos/msdosfs_vfsops.c
===
RCS file: /OpenBSD/src/usr.sbin/makefs/msdos/msdosfs_vfsops.c,v
retrieving revision 1.13
diff -u -p -r1.13 msdosfs_vfsops.c
--- msdos/msdosfs_vfsops.c  6 Oct 2021 00:40:41 -   1.13
+++ msdos/msdosfs_vfsops.c  1 Dec 2023 06:52:40 -
@@ -278,7 +278,8 @@ msdosfs_mount(struct mkfsvnode *devvp, i
DPRINTF(("%s(bread %lu)\n", __func__,
(unsigned long)de_bn2kb(pmp, pmp->pm_fsinfo)));
if ((error = bread(devvp, de_bn2kb(pmp, pmp->pm_fsinfo),
-   pmp->pm_BytesPerSec, 0, )) != 0)
+   roundup(sizeof(struct fsinfo), pmp->pm_BytesPerSec),
+   0, )) != 0)
goto error_exit;
fp = (struct fsinfo *)bp->b_data;
if (!memcmp(fp->fsisig1, "RRaA", 4)

Re: Integrity Issue: 'cd74.iso' (Loongson) Missing Checksums in SHA256 Files

[Miod Vallat]

> The 'cd74.iso' image for the Loongson architecture does not have a checksum
> entry in its respective SHA256 and SHA256.sig files.

Indeed, it was missing from the list of files to compute checksums for.
This is now fixed, thanks!

We'll update and resign the 7.4 SHA256 file once Theo is back from the
november hackathon.

Re: Sparc64 rthreads Instablilty

[Miod Vallat]

For what it's worth, I couldn't get your test to fail on a dual-cpu
sun4u. Either it's a sun4v-specific issue or it needs many more cpus to
trigger.

Re: lost ugold humidity sensor after upgrade

[Miod Vallat]

> After updating my RPi4 to a newer snap, it lost its humidity sensor.
> 
> dmesg from before and after the update both detect this:
> 
> uhidev1 at uhub1 port 2 configuration 1 interface 1 "RDing TEMPERHUM1V1.2" 
> rev 2.00/0.01 addr 3
> uhidev1: iclass 3/1
> ugold0 at uhidev1
> ugold0: 2 sensors type si7006 (temperature and humidity)
> 
> But the new install only has the temperature sensor available:
> 
> [weerd@raspberry] $ sysctl hw.sensors.ugold0
> hw.sensors.ugold0.temp0=22.32 degC (inner)

Sorry about that. Can you try the following diff and report if it brings
the humidity sensor back?

Miod

Index: ugold.c
===
RCS file: /OpenBSD/src/sys/dev/usb/ugold.c,v
retrieving revision 1.22
diff -u -p -r1.22 ugold.c
--- ugold.c 2 Apr 2023 17:03:14 -   1.22
+++ ugold.c 18 Apr 2023 15:51:13 -
@@ -432,7 +432,7 @@ ugold_si700x_intr(struct uhidev *addr, v
temp = ugold_si700x_temp(sc->sc_type, buf[2], buf[3]);
sc->sc_sensor[UGOLD_INNER].value = (temp * 1000) + 27315;
sc->sc_sensor[UGOLD_INNER].flags &= ~SENSOR_FINVALID;
-   if (sc->sc_type != UGOLD_TYPE_GOLD && buf[1] >= 6) {
+   if (sc->sc_type != UGOLD_TYPE_GOLD) {
rhum = ugold_si700x_rhum(sc->sc_type, buf[4], buf[5], 
temp);
sc->sc_sensor[UGOLD_HUM].value = rhum;
sc->sc_sensor[UGOLD_HUM].flags &= ~SENSOR_FINVALID;

Re: bse(4) media/link bug

[Miod Vallat]

> People have complained about this before.  I can't reproduce it and
> therefore I can't fix it.
> 
FWIW, with a "working" (Open)bse setup, I have seen the switch port to
which the RPi is connected keep blinking for days - eventually stopping
after more than 10 days of idleness.

I don't know what bse does wrong, but this might be a brgphy issue.

Re: Apparently 7.2 broke "fn" button on macbook air

[Miod Vallat]

> >Synopsis:fn key stopped working after upgrade
> >Category:kernel
> >Environment:
>   System  : OpenBSD 7.2
>   Details : OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 
> 2022
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   I've just upgraded my computer from 7.1. Prior to upgrade, I could use 
>   "fn" key with volume control and arrow keys (i.e. fn+F10 would toggle 
>   mute state, fn+F11 would decrease volume, fn+up arrow would generate
>   page up event. This stopped to work after 7.2 upgrade. Above key
>   combinations now generate the same events as only the primary key was 
>   pressed.

This is indeed a 7.2 regression, and got fixed in sys/dev/usb/ukbd.c
r1.88.

Miod

Re: /usr/bin/c++filt and c++filt(1) version mismatch

[Miod Vallat]

> >Description:
>   /usr/bin/c++filt is compiled from src/gnu/usr.bin/cxxfilt.
>   That directory also includes a man page, which is not
>   installed.  The installed c++filt(1) comes from
>   src/gnu/usr.bin/binutils-2.17/binutils/doc/cxxfilt.man.

You're right. The binutils cxxfilt codebase is more recent and
should be installed; the diff below takes care of this.

Note that, for platforms using clang as the system compiler, we should
eventually install llvm-cxxfilt as well, but that's a later task.

Thanks for reporting this!

Miod

Index: gnu/usr.bin/Makefile
===
RCS file: /OpenBSD/src/gnu/usr.bin/Makefile,v
retrieving revision 1.63
diff -u -p -r1.63 Makefile
--- gnu/usr.bin/Makefile3 May 2021 03:45:40 -   1.63
+++ gnu/usr.bin/Makefile19 Oct 2022 05:57:49 -
@@ -17,7 +17,7 @@ SUBDIR+=  clang
 .  endif
 .endif
 
-SUBDIR+=   cxxfilt cvs
+SUBDIR+=   cvs
 # binutils-2.17 needs to build gdb in binutils at the moment
 .if make(obj)
 SUBDIR+=   binutils
Index: gnu/usr.bin/binutils-2.17/binutils/Makefile.am
===
RCS file: /OpenBSD/src/gnu/usr.bin/binutils-2.17/binutils/Makefile.am,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile.am
--- gnu/usr.bin/binutils-2.17/binutils/Makefile.am  4 Jul 2011 23:58:26 
-   1.3
+++ gnu/usr.bin/binutils-2.17/binutils/Makefile.am  19 Oct 2022 05:57:49 
-
@@ -59,7 +59,7 @@ bin_PROGRAMS = $(OBJDUMP_PROG) $(AR_PROG
 
 ## We need a special rule to install the programs which are built with
 ## -new, and to rename cxxfilt to c++filt.
-noinst_PROGRAMS = $(STRIP_PROG)
+noinst_PROGRAMS = $(STRIP_PROG) $(DEMANGLER_PROG)
 
 EXTRA_PROGRAMS = $(NLMCONV_PROG) srconv sysdump coffdump $(DLLTOOL_PROG) 
$(WINDRES_PROG) $(DLLWRAP_PROG)
 
@@ -203,7 +203,7 @@ objdump_LDADD = $(OPCODES) $(BFDLIB) $(L
 objdump.o:objdump.c
$(COMPILE) -c $(OBJDUMP_DEFS) $(srcdir)/objdump.c
 
-#cxxfilt_SOURCES = cxxfilt.c $(BULIBS)
+cxxfilt_SOURCES = cxxfilt.c $(BULIBS)
 
 ar_SOURCES = arparse.y arlex.l ar.c not-ranlib.c arsup.c rename.c binemul.c \
emul_$(EMULATION).c $(BULIBS)
Index: gnu/usr.bin/binutils-2.17/binutils/Makefile.in
===
RCS file: /OpenBSD/src/gnu/usr.bin/binutils-2.17/binutils/Makefile.in,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile.in
--- gnu/usr.bin/binutils-2.17/binutils/Makefile.in  4 Jul 2011 23:58:26 
-   1.3
+++ gnu/usr.bin/binutils-2.17/binutils/Makefile.in  19 Oct 2022 05:57:49 
-
@@ -41,7 +41,7 @@ bin_PROGRAMS = $(am__EXEEXT_6) $(am__EXE
$(am__EXEEXT_8) $(am__EXEEXT_9) $(am__EXEEXT_10) \
@BUILD_NLMCONV@ @BUILD_SRCONV@ @BUILD_DLLTOOL@ @BUILD_WINDRES@ \
$(am__EXEEXT_11) $(am__EXEEXT_12) @BUILD_DLLWRAP@ @BUILD_MISC@
-noinst_PROGRAMS = $(am__EXEEXT_14)
+noinst_PROGRAMS = $(am__EXEEXT_14) $(am__EXEEXT_15)
 EXTRA_PROGRAMS = $(am__EXEEXT_1) srconv$(EXEEXT) sysdump$(EXEEXT) \
coffdump$(EXEEXT) $(am__EXEEXT_2) $(am__EXEEXT_3) \
$(am__EXEEXT_4)
@@ -210,7 +210,7 @@ YACCCOMPILE = $(YACC) $(YFLAGS) $(AM_YFL
 LTYACCCOMPILE = $(LIBTOOL) --mode=compile $(YACC) $(YFLAGS) \
$(AM_YFLAGS)
 SOURCES = $(addr2line_SOURCES) $(ar_SOURCES) $(coffdump_SOURCES) \
-   $(dlltool_SOURCES) $(dllwrap_SOURCES) \
+   $(cxxfilt_SOURCES) $(dlltool_SOURCES) $(dllwrap_SOURCES) \
$(nlmconv_SOURCES) $(nm_new_SOURCES) $(objcopy_SOURCES) \
$(objdump_SOURCES) $(ranlib_SOURCES) $(readelf_SOURCES) \
$(size_SOURCES) $(srconv_SOURCES) $(strings_SOURCES) \
@@ -253,7 +253,7 @@ CPPFLAGS = @CPPFLAGS@
 CYGPATH_W = @CYGPATH_W@
 DATADIRNAME = @DATADIRNAME@
 DEFS = @DEFS@
-#DEMANGLER_NAME = @DEMANGLER_NAME@
+DEMANGLER_NAME = @DEMANGLER_NAME@
 DEPDIR = @DEPDIR@
 DLLTOOL_DEFS = @DLLTOOL_DEFS@
 ECHO_C = @ECHO_C@
@@ -466,7 +466,7 @@ strip_new_SOURCES = objcopy.c is-strip.c
 nm_new_SOURCES = nm.c budemang.c $(BULIBS)
 objdump_SOURCES = objdump.c dwarf.c budemang.c prdbg.c $(DEBUG_SRCS) $(BULIBS)
 objdump_LDADD = $(OPCODES) $(BFDLIB) $(LIBIBERTY) $(INTLLIBS)
-#cxxfilt_SOURCES = cxxfilt.c $(BULIBS)
+cxxfilt_SOURCES = cxxfilt.c $(BULIBS)
 ar_SOURCES = arparse.y arlex.l ar.c not-ranlib.c arsup.c rename.c binemul.c \
emul_$(EMULATION).c $(BULIBS)
 
@@ -599,6 +599,9 @@ ar$(EXEEXT): $(ar_OBJECTS) $(ar_DEPENDEN
 coffdump$(EXEEXT): $(coffdump_OBJECTS) $(coffdump_DEPENDENCIES) 
@rm -f coffdump$(EXEEXT)
$(LINK) $(coffdump_LDFLAGS) $(coffdump_OBJECTS) $(coffdump_LDADD) 
$(LIBS)
+cxxfilt$(EXEEXT): $(cxxfilt_OBJECTS) $(cxxfilt_DEPENDENCIES) 
+   @rm -f cxxfilt$(EXEEXT)
+   $(LINK) $(cxxfilt_LDFLAGS) $(cxxfilt_OBJECTS) $(cxxfilt_LDADD) $(LIBS)
 dlltool$(EXEEXT): $(dlltool_OBJECTS) $(dlltool_DEPENDENCIES) 
@rm -f dlltool$(EXEEXT)
$(LINK) $(dlltool_LDFLAGS) $(dlltool_OBJECTS) $(dlltool_LDADD) $(LIBS)

time keeping on armv7

[Miod Vallat]

I recently installed OpenBSD to a PandaBoard (the original, not
PandaBoard ES) and noticed that the clock was very quickly getting
behind, with ntpd unable to cope.

The following extremely crude diff fixes it, but probably at the expense
of breaking other omap systems. Is there a better way to figure out what
is the real system clock frequency?

Index: sys/arch/armv7/omap/omapid.c
===
RCS file: /OpenBSD/src/sys/arch/armv7/omap/omapid.c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 omapid.c
--- sys/arch/armv7/omap/omapid.c24 Oct 2021 17:52:27 -  1.5
+++ sys/arch/armv7/omap/omapid.c20 Sep 2022 13:54:01 -
@@ -83,9 +83,12 @@ omapid_attach(struct device *parent, str
rev = bus_space_read_4(sc->sc_iot, sc->sc_ioh, O4_ID_CODE);
switch ((rev >> 12) & 0x) {
case 0xB852:
-   case 0xB95C:
board = "omap4430";
newclockrate = 400 * 1000 * 1000;
+   break;
+   case 0xB95C:
+   board = "omap4430";
+   newclockrate = 300 * 1000 * 1000;
break;
case 0xB94E:
board = "omap4460";



OpenBSD 7.2 (GENERIC) #11: Tue Sep 20 13:18:51 GMT 2022
m...@enfer.gentiane.org:/usr/src/sys/arch/armv7/compile/GENERIC
real mem  = 1021243392 (973MB)
avail mem = 992374784 (946MB)
random: boothowto does not indicate good seed
mainbus0 at root: TI OMAP4 PandaBoard
cpu0 at mainbus0 mpidr 0: ARM Cortex-A9 r1p2
cpu0: 32KB 32b/line 4-way L1 VIPT I-cache, 32KB 32b/line 4-way L1 D-cache
cortex0 at mainbus0
amptimer0 at cortex0: 396000 kHz
armliicc0 at cortex0: rtl 4 waymask: 0x000f
omap0 at mainbus0
omapid0 at omap0: omap4430
amptimer0: adjusting clock: new rate 30 kHz
prcm0 at omap0 rev 0.0
ampintc0 at mainbus0 nirq 160, ncpu 2: "interrupt-controller"
omwugen0 at mainbus0
simplebus0 at mainbus0: "ocp"
omsysc0 at simplebus0: "target-module"
omsysc1 at simplebus0: "target-module"
omsysc2 at simplebus0: "target-module"
omsysc3 at simplebus0: "target-module"
omsysc4 at simplebus0: "target-module"
omsysc5 at simplebus0: "target-module"
omsysc6 at simplebus0: "target-module"
simplebus1 at simplebus0: "l4"
simplebus2 at simplebus1: "cm1"
omcm0 at simplebus2: "mpuss_cm"
omclock0 at omcm0: "clk"
omcm1 at simplebus2: "tesla_cm"
omclock1 at omcm1: "clk"
omcm2 at simplebus2: "abe_cm"
omclock2 at omcm2: "clk"
simplebus3 at simplebus1: "cm2"
omcm3 at simplebus3: "l4_ao_cm"
omclock3 at omcm3: "clk"
omcm4 at simplebus3: "l3_1_cm"
omclock4 at omcm4: "clk"
omcm5 at simplebus3: "l3_2_cm"
omclock5 at omcm5: "clk"
omcm6 at simplebus3: "ducati_cm"
omclock6 at omcm6: "clk"
omcm7 at simplebus3: "l3_dma_cm"
omclock7 at omcm7: "clk"
omcm8 at simplebus3: "l3_emif_cm"
omclock8 at omcm8: "clk"
omcm9 at simplebus3: "d2d_cm"
omclock9 at omcm9: "clk"
omcm10 at simplebus3: "l4_cfg_cm"
omclock10 at omcm10: "clk"
omcm11 at simplebus3: "l3_instr_cm"
omclock11 at omcm11: "clk"
omcm12 at simplebus3: "ivahd_cm"
omclock12 at omcm12: "clk"
omcm13 at simplebus3: "iss_cm"
omclock13 at omcm13: "clk"
omcm14 at simplebus3: "l3_dss_cm"
omclock14 at omcm14: "clk"
omcm15 at simplebus3: "l3_gfx_cm"
omclock15 at omcm15: "clk"
omcm16 at simplebus3: "l3_init_cm"
omclock16 at omcm16: "clk"
omcm17 at simplebus3: "l4_per_cm"
omclock17 at omcm17: "clk"
simplebus4 at simplebus1: "scm"
syscon0 at simplebus4: "scm_conf"
simplebus5 at simplebus1: "scm"
syscon1 at simplebus5: "omap4_padconf_global"
pinctrl0 at simplebus5
simplebus6 at simplebus1: "l4"
"counter" at simplebus6 not configured
"prm" at simplebus6 not configured
"scrm" at simplebus6 not configured
"scm" at simplebus6 not configured
simplebus7 at simplebus6: "padconf"
pinctrl1 at simplebus7
"ocmcram" at simplebus0 not configured
"dma-controller" at simplebus0 not configured
omgpio0 at simplebus0: rev 0.1
gpio0 at omgpio0: 32 pins
omgpio1 at simplebus0: rev 0.1
gpio1 at omgpio1: 32 pins
omgpio2 at simplebus0: rev 0.1
gpio2 at omgpio2: 32 pins
omgpio3 at simplebus0: rev 0.1
gpio3 at omgpio3: 32 pins
omgpio4 at simplebus0: rev 0.1
gpio4 at omgpio4: 32 pins
omgpio5 at simplebus0: rev 0.1
gpio5 at omgpio5: 32 pins
"gpmc" at simplebus0 not configured
com0 at simplebus0: ti16750, 64 byte fifo
com0: probed fifo depth: 0 bytes
com1 at simplebus0: ti16750, 64 byte fifo
com1: probed fifo depth: 0 bytes
com2 at simplebus0: ti16750, 64 byte fifo
com2: console
com3 at simplebus0: ti16750, 64 byte fifo
com3: probed fifo depth: 0 bytes
omsysc7 at simplebus0: "target-module"
"smartreflex" at omsysc7 not configured
omsysc8 at simplebus0: "target-module"
"smartreflex" at omsysc8 not configured
omsysc9 at simplebus0: "target-module"
"smartreflex" at omsysc9 not configured
"spinlock" at simplebus0 not configured
tiiic0 at simplebus0 rev 0.10
iic0 at tiiic0
"ti,twl6030" at iic0 addr 0x48 not configured
"ti,twl6040" at iic0 

Re: macppc panic: vref used where vget required

[Miod Vallat]

> On Thu, Sep 01, 2022 at 02:57:27PM +0200, Martin Pieuchot wrote:
> > Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same
> > assert.  Here's an rebased diff for the bug discussed in this thread,
> > could you try again and let us know?  Thanks!
> 
> Wow!  With this diff I finished make release for the fist time on
> my macppc.  I am starting the next build right now.  Result for
> this test takes 1.13 days.

Same here, PowerMac11,2 has been able to bake a muild while running
GENERIC.MP for the first time ever, with this diff.

Re: uvm_fault on Framework 12th Gen Intel

[Miod Vallat]

The following diff ought to fix the problem, although there is no reason
it should have occurred in the first place.

Do the uvm_fault errors disappear if you `boot -c' and `disable ucc'? Or
if you `disable pckbd'?

Index: wskbdutil.c
===
RCS file: /OpenBSD/src/sys/dev/wscons/wskbdutil.c,v
retrieving revision 1.19
diff -u -p -r1.19 wskbdutil.c
--- wskbdutil.c 30 Dec 2021 06:55:11 -  1.19
+++ wskbdutil.c 2 Aug 2022 19:00:40 -
@@ -405,6 +405,8 @@ wskbd_load_keymap(const struct wskbd_map
for (cur = layout & ~KB_HANDLEDBYWSKBD, stack_ptr = 0;
 cur != 0; stack_ptr++) {
mp = mapdata->keydesc;
+   if (mp == NULL)
+   return(EFAULT); /* XXX */
while (mp->map_size > 0) {
if (cur == 0 || mp->name == cur) {
break;

Re: Boot(8) timeouts take excessively long on OnLogic Helix 500.

[Miod Vallat]

> >Synopsis: Boot(8) timeouts take excessively long on OnLogic Helix 500.
> >Category:  boot, amd64

The change in sys/stand/boot/cmd.c r1.44 has been reverted.

Miod

Re: pcidump -v panic in OpenBSD 7.0 on Samsung NC215S

[Miod Vallat]

> After printing information via "doas pcidump -v" on device PCI
> 0:0:27:0 "Intel 82801GB HD Audio", kernel panics. Sorry, I used OCR
> software to recognize the text from the photo of the screen, maybe
> there are some errors in hex numbers. Photo is attached.

The following diff, while not fixing the cause of the problem, ought to
prevent the kernel from panicing.

Does audio (azalia0) work correctly on your system?

Miod

Index: amd64/pci/pci_machdep.c
===
RCS file: /OpenBSD/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.77
diff -u -p -r1.77 pci_machdep.c
--- amd64/pci/pci_machdep.c 11 Mar 2021 11:16:55 -  1.77
+++ amd64/pci/pci_machdep.c 4 Feb 2022 19:31:36 -
@@ -213,15 +213,14 @@ pci_conf_size(pci_chipset_tag_t pc, pcit
return PCI_CONFIG_SPACE_SIZE;
 }
 
-void
+int
 pci_mcfg_map_bus(int bus)
 {
if (pci_mcfgh[bus])
-   return;
+   return 0;
 
-   if (bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
-   0, _mcfgh[bus]))
-   panic("pci_conf_read: cannot map mcfg space");
+   return bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
+   0, _mcfgh[bus]);
 }
 
 pcireg_t
@@ -235,7 +234,8 @@ pci_conf_read(pci_chipset_tag_t pc, pcit
if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
pci_decompose_tag(pc, tag, , NULL, NULL);
if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
-   pci_mcfg_map_bus(bus);
+   if (pci_mcfg_map_bus(bus) != 0)
+   return 0x;
data = bus_space_read_4(pci_mcfgt, pci_mcfgh[bus],
(tag & 0x000ff00) << 4 | reg);
return data;
@@ -261,7 +261,8 @@ pci_conf_write(pci_chipset_tag_t pc, pci
if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
pci_decompose_tag(pc, tag, , NULL, NULL);
if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
-   pci_mcfg_map_bus(bus);
+   if (pci_mcfg_map_bus(bus) != 0)
+   return;
bus_space_write_4(pci_mcfgt, pci_mcfgh[bus],
(tag & 0x000ff00) << 4 | reg, data);
return;
Index: i386/pci/pci_machdep.c
===
RCS file: /OpenBSD/src/sys/arch/i386/pci/pci_machdep.c,v
retrieving revision 1.87
diff -u -p -r1.87 pci_machdep.c
--- i386/pci/pci_machdep.c  11 Mar 2021 11:16:57 -  1.87
+++ i386/pci/pci_machdep.c  4 Feb 2022 19:31:36 -
@@ -127,7 +127,7 @@ bus_addr_t pci_mcfg_addr;
 int pci_mcfg_min_bus, pci_mcfg_max_bus;
 bus_space_tag_t pci_mcfgt = I386_BUS_SPACE_MEM;
 bus_space_handle_t pci_mcfgh[256];
-void pci_mcfg_map_bus(int);
+int pci_mcfg_map_bus(int);
 
 struct mutex pci_conf_lock = MUTEX_INITIALIZER(IPL_HIGH);
 
@@ -420,15 +420,14 @@ pci_conf_size(pci_chipset_tag_t pc, pcit
return PCI_CONFIG_SPACE_SIZE;
 }
 
-void
+int
 pci_mcfg_map_bus(int bus)
 {
if (pci_mcfgh[bus])
-   return;
+   return 0;
 
-   if (bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
-   0, _mcfgh[bus]))
-   panic("pci_conf_read: cannot map mcfg space");
+   return bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus << 20), 1 << 20,
+   0, _mcfgh[bus]);
 }
 
 pcireg_t
@@ -442,7 +441,8 @@ pci_conf_read(pci_chipset_tag_t pc, pcit
if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
pci_decompose_tag(pc, tag, , NULL, NULL);
if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
-   pci_mcfg_map_bus(bus);
+   if (pci_mcfg_map_bus(bus) != 0)
+   return 0x;
data = bus_space_read_4(pci_mcfgt, pci_mcfgh[bus],
(tag.mode1 & 0x000ff00) << 4 | reg);
return data;
@@ -480,7 +480,8 @@ pci_conf_write(pci_chipset_tag_t pc, pci
if (pci_mcfg_addr && reg >= PCI_CONFIG_SPACE_SIZE) {
pci_decompose_tag(pc, tag, , NULL, NULL);
if (bus >= pci_mcfg_min_bus && bus <= pci_mcfg_max_bus) {
-   pci_mcfg_map_bus(bus);
+   if (pci_mcfg_map_bus(bus) != 0)
+   return;
bus_space_write_4(pci_mcfgt, pci_mcfgh[bus],
(tag.mode1 & 0x000ff00) << 4 | reg, data);
return;

Re: sparc64 dlopen data access fault

[Miod Vallat]

> Hi,
> 
> On my sparc64 machine regress/lib/libpthread triggers a panic.  It
> happend with Feb 1 and Jan 31 snapshot.  Jan 29 snapshot paniced
> somewhere else.  Test and console output below.
> 
> *cpu1: pmap_enter: access_type exceeds prot
> 
> bluhm

Does the following diff help?

Index: uvm_fault.c
===
RCS file: /OpenBSD/src/sys/uvm/uvm_fault.c,v
retrieving revision 1.124
diff -u -p -r1.124 uvm_fault.c
--- uvm_fault.c 28 Dec 2021 13:16:28 -  1.124
+++ uvm_fault.c 2 Feb 2022 19:53:36 -
@@ -1023,8 +1023,10 @@ uvm_fault_upper(struct uvm_faultinfo *uf
counters_inc(uvmexp_counters, flt_anon);
oanon = anon;
pg = anon->an_page;
-   if (anon->an_ref > 1) /* disallow writes to ref > 1 anons */
-   flt->enter_prot = flt->enter_prot & ~PROT_WRITE;
+   if (anon->an_ref > 1) {   /* disallow writes to ref > 1 anons */
+   flt->enter_prot &= ~PROT_WRITE;
+   flt->access_type &= ~PROT_WRITE;
+   }
}
 
/*

Re: i386 :: install70.img :: SHA256.sig missing...

[Miod Vallat]

> I just rebuilt my mini laptop using the i386 image, but, when
> installing the filesets, I got a warning that the SHA256.sig file was
> missing, so that signify couldn't run, the error was:
> 
> 'Directory does not contain SHA256.sig'
> 
> (and the prompt allowed me to continue without verification or to
> redownload the sets)

Quoting https://www.openbsd.org/faq/faq4.html:

`` The install70.iso and install70.img images do not contain an
SHA256.sig file, so the installer will complain that it can't check the
signature of the included sets:

Directory does not contain SHA256.sig. Continue without verification? [no]

This is because it would make no sense for the installer to verify them.
If someone were to make a rogue installation image, they could certainly
change the installer to say the files were legitimate. If the image's
signature has been verified beforehand, it is safe to answer "yes" at
that prompt.''

Re: lib/csu/init_priority_test broken on macppc with clang

[Miod Vallat]

> Is this still an issue with the new linker?

No, the test passes in -CURRENT.

Re: A sparc oddity (hair-pulling bug)

[Miod Vallat]

> However, are there any other similar fallouts outside this initmsgbuf()
> situation?

There is only a risk on platforms where initmsgbuf() is invoked in (or
before) pmap_bootstrap(), and where curcpu() will not necessarily point
into the kernel data section for the boot processor.

That description only matches sparc*.

Re: A sparc oddity (hair-pulling bug)

[Miod Vallat]

>> Indeed. Wrappinge the mutex operations in msgbuf_putchar with if (!cold)
>> makes the kernel boot again.
>
> Here is a diff for that.

After a bit more thinking, it might be worth introduce a
msgbuf_putchar_unlocked() routine for the inner part only, and have
initmsgbuf() use it, since:
- it has made sure the magic value test will suceed.
- this is the only use of msgbuf_putchar() on sparc64 until the proper
  curcpu mappings are set up; all output from pmap_bootstrap() carefully
  uses the prom routines (and do not end up in the message buffer).

$.02

Re: A sparc oddity (hair-pulling bug)

[Miod Vallat]

> The per-CPU struct is mapped using a 64K locked TLB entry.  That TLB
> entry is installed by sun4u_bootstrap_cpu(), which gets called *after*
> initsmgbuf() is called.  So this issue was introduced when locking was
> added to msgbuf_putchar().
> 
> Now the real question is why this doesn't crash even on a cold boot?
> I suspect that is because on a cold boot the buffer is clean and the
> msgbuf_putchar() call in initmsgbuf() is skipped.
> 
> It may be possible to do some reordering in pmap_bootstrap(), but
> frankly I think the locking added to msgbuf_putchar() was a mistake.
> Or maybe the locking code should be bypassed when cold.

Indeed. Wrappinge the mutex operations in msgbuf_putchar with if (!cold)
makes the kernel boot again.

Re: A sparc oddity (hair-pulling bug)

[Miod Vallat]

> I think the window this occurs is something like:
> 
> bad
> OpenBSD 6.8-current (GENERIC) #510: Thu Oct 29 19:58:32 MDT 2020
> 
> good
> OpenBSD 6.8-current (GENERIC) #508: Thu Oct 29 06:05:29 MDT 2020

I was trying to find a narrow window, but since it does not always
happen, I ended up with a botched dichotomy. I thought I had narrowed
between 20201101 and 20201026, but could actually reproduce with a
20201026 kernel. And there are no sparc64 changes (except a minor
interrupt diff in vpci) between 20201026 and 20201101 anyway.

I'll reinstall 6.8 tomorrow and restart checking, more carefully.

(Unrelated to this, pmap_bootstrap() always uses 4 pages for the message
buffer regardless of MSGBUFSIZE, this might be worth fixing)

Re: Loongson new installboot doesn't copy the kernel on Gdium anymore

[Miod Vallat]

It would probably be a better solution to introduce an Octeon-like BOOT
kernel on loongson and use it as the bootloader on all loongson
platforms, if only because of the dire bugs in their ext2fs
implementation.

Doing this would make the Gdium-specific boot shenanigans much, much
simpler.

Re: PPPoE panic on Octeon

[Miod Vallat]

> > Indeed. And the kernel makes sure to use 16 byte alignment, so there
> > must be a bug creeping somewhere which causes a wrong offset to be
> > applied...
> >
> >
> Ah, so somewhere in the varargs it misses to take current alignment into
> consideration?

No, the stack at some point becomes misaligned. And then code assuming
it is aligned, misbehaves...

Re: PPPoE panic on Octeon

[Miod Vallat]

This should solve the problem.

Index: sys/arch/mips64/mips64/vm_machdep.c
===
RCS file: /OpenBSD/src/sys/arch/mips64/mips64/vm_machdep.c,v
retrieving revision 1.37
diff -u -p -r1.37 vm_machdep.c
--- sys/arch/mips64/mips64/vm_machdep.c 2 Sep 2017 15:56:29 -   1.37
+++ sys/arch/mips64/mips64/vm_machdep.c 20 Nov 2019 11:03:22 -
@@ -135,7 +135,7 @@ cpu_fork(struct proc *p1, struct proc *p
}
pcb->pcb_context.val[10] = (register_t)proc_trampoline;
pcb->pcb_context.val[8] = (register_t)pcb +
-   USPACE - sizeof(struct trapframe);
+   ((USPACE - sizeof(struct trapframe)) & ~_STACKALIGNBYTES);
pcb->pcb_context.val[1] = (register_t)arg;
pcb->pcb_context.val[0] = (register_t)func;
 }

Re: PPPoE panic on Octeon

[Miod Vallat]

> > For some reason, clang assumes the stack is aligned on a 16 byte
> > boundary, as for the first iteration v0 is computed as (v1 or 8),
> > while further iterations use (v1 plus 8).
> 
> 
> I guess it defaults to 16 for N64?
> https://reviews.llvm.org/D35874

Indeed. And the kernel makes sure to use 16 byte alignment, so there
must be a bug creeping somewhere which causes a wrong offset to be
applied...

> Wonder if it would be worth testing a run with clang -mstack-alignment=8
> just to confirm this?

This ought to sweep the issue under the rug.

Re: PPPoE panic on Octeon

[Miod Vallat]

The code generated by clang for sppp_auth_send() is incorrect.

Because the variadic part handling in sppp_auth_send() consumes
arguments in pairs, clang uses two registers to point to the pair, v1
pointing to the first argument (the size) and v0 to the second argument
(the pointer).

For some reason, clang assumes the stack is aligned on a 16 byte
boundary, as for the first iteration v0 is computed as (v1 or 8),
while further iterations use (v1 plus 8).

But as seen in your trace, the stack pointer is only aligned on a 8 byte
boundary, which causes a completely wrong pointer to be passed to
bcopy().

You might want to compile your kernel with CC=gcc for the time being,
until this code generation issue gets fixed.

Re: OpenBSD 6.4 doesn't boot on 486 class processor anymore

[Miod Vallat]

>> There are currently three places in sys/arch/i386/stand/libsa which make 
>> that check: cpuprobe.c, machdep.c, and random_i386.S. ucode_load() could 
>> copy the chunk from machdep.c...or someone could add a global and do the 
>> check once, early...
>
> Or we make cpuid a required feature?

Or drop the 32-bit x86 port, like everyone has.

Re: inteldrm freezes on Dell Inspiron 15 3000

[Miod Vallat]

> To have an idea of what is going on some other output is required.
> Do you have a hdmi display that could be plugged into the hdmi out?

I have tried with two not-so-old LCDs and an HD15<->HDMI converter, and
unfortunately there is no output on them either - they go into power
saving mode as if there was no signal.

inteldrm freezes on Dell Inspiron 15 3000

[Miod Vallat]

>Synopsis:  inteldrm freezes on Dell Inspiron 15 3000
>Category:  kernel
>Environment:
System  : OpenBSD 6.4
Details : OpenBSD 6.4 (GENERIC.MP) #355: Tue Oct  9 02:10:43 MDT 
2018
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
If inteldrm is not disabled in UKC, it will attach, print "inteldrm0:
msi", then proceed to switch video mode. At this point, the screen goes
blank and the system freezes (or maybe it's in ddb, but I doubt it as
the caps lock led does not get lit if pressed).
>How-To-Repeat:
boot the latest snapshot on a Dell Inspiron 15 3000 system.
>Fix:
unknown.

dmesg:
OpenBSD 6.4 (GENERIC.MP) #355: Tue Oct  9 02:10:43 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4185604096 (3991MB)
avail mem = 4049473536 (3861MB)
User Kernel Config
UKC> disable inteldrm
229 inteldrm* disabled
UKC> quit
Continuing...
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeceb0 (45 entries)
bios0: vendor Dell Inc. version "4.4.0" date 03/06/2018
bios0: Dell Inc. Inspiron 15-3552
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG BOOT SLIC SLIC HPET SSDT SSDT SSDT 
UEFI LPIT BGRT CSRT SSDT SSDT
acpi0: wakeup devices XHC1(S0) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) 
PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) LID0(S3)
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) Celeron(R) CPU N3060 @ 1.60GHz, 1600.36 MHz, 06-4c-04
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-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 79MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Celeron(R) CPU N3060 @ 1.60GHz, 1599.96 MHz, 06-4c-04
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 2, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
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)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x58), C1(1000@1 
mwait.1), PSS
acpipwrres0 at acpi0: USBC, resource for XHC1
acpitz0 at acpi0: critical temperature is 89 degC
acpipwrres1 at acpi0: FN00, resource for FAN0
acpitz1 at acpi0: critical temperature is 95 degC
acpicmos0 at acpi0
"DLL06AC" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "DELL GR43778" serial 13207 oem "SMP-LG2.8C"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
"DELLABCE" at acpi0 not configured
acpibtn2 at acpi0: SLPB
chvgpio0 at acpi0: GPO3 uid 4 addr 0xfed98000/0x8000 irq 91, 55 pins
"INT3400" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 1600 MHz: speeds: 1601, 1600, 1520, 1440, 1360, 1280, 
1200, 1120, 1040, 960, 880, 800, 720 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Braswell Host" rev 0x35
"Intel HD Graphics" rev 0x35 at pci0 dev 2 function 0 not configured
"Intel Braswell Power" rev 0x35 at pci0 dev 11 function 0 not configured
sdhc0 at pci0 dev 16 function 0 vendor "Intel", unknown product 0x2294 rev 
0x35: apic 1 int 16
sdhc0: SDHC 3.0, 200 MHz base clock
sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma
ahci0 at pci0 dev 19 function 0 "Intel Braswell AHCI" rev 0x35: msi, AHCI 1.3.1
ahci0: port 0: 6.0Gb/s
ahci0: port 1: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.5000c500b29b6537
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
cd0 at scsibus1 targ 1 lun 0:  ATAPI 5/cdrom 
removable
xhci0 at pci0 dev 20 function 0 "Intel Braswell xHCI" rev 0x35: msi, 

Re: tsciic(4) on alpha should be disabled, causes CS20 instability

[Miod Vallat]

>   A few releases ago, alipm got disabled on alpha because there were
>   reports of CS20 systems freezing.
>   Since then, another i2c controller has been added, tsciic.
>   On CS20 systems, the i2c bus at tsciic sports both the usual spdmem
>   information, and an lmenv(4) sensors chip.
>   Unfortunately, when the lmenv driver is enabled, the CS20 quickly
>   freezes hard, with both GENERIC and GENERIC.MP.
>   Until the cause for this is understood, I'd suggest disabling tsciic
>   (or lmenv, but this will cause a noisy lmenv probe signature to be
>output in dmesg) in order to make CS20 (and likely DS20L) usable again.

Per prodding from mlarkin@, I've been testing the current 6.2 snapshots
and the freezes are no longer seen, with either UP or MP kernels. Given
all the locking churning over the last few months, this might have been
a temporary bug which got fixed since.

Re: config(8) elf handling

[Miod Vallat]

> Anyone recall the issues that it was originally changed to fix?

It broke the passing of information between the boot blocks and the
kernel on x86, because locore would zero bss after the boot blocks
information variables had been written to.

Re: config(8) elf handling

[Miod Vallat]

> Forcing uextraloc into .data via
> int uextraloc __attribute__ ((section(".data"))) = 0;
> avoids the crashes.

Regardless of this bug, the in-tree gcc was modified to default to put
explicitly zero initialized data in .data rather than .bss, i.e. default
to -fno-zero-initialized-in-bss.

It might be wise to make the default configuration of clang follow this
behaviour as well.

tsciic(4) on alpha should be disabled, causes CS20 instability

[Miod Vallat]

>Synopsis:  tsciic(4) on alpha should be disabled, causes CS20 instability
>Category:  alpha
>Environment:
System  : OpenBSD 6.*
Architecture: OpenBSD.alpha
Machine : alpha
>Description:
A few releases ago, alipm got disabled on alpha because there were
reports of CS20 systems freezing.
Since then, another i2c controller has been added, tsciic.
On CS20 systems, the i2c bus at tsciic sports both the usual spdmem
information, and an lmenv(4) sensors chip.
Unfortunately, when the lmenv driver is enabled, the CS20 quickly
freezes hard, with both GENERIC and GENERIC.MP.
Until the cause for this is understood, I'd suggest disabling tsciic
(or lmenv, but this will cause a noisy lmenv probe signature to be
 output in dmesg) in order to make CS20 (and likely DS20L) usable again.
>How-To-Repeat:
Boot a recent enough OpenBSD kernel to have tsciic on a CS20 system.
>Fix:
Suggested workaround:
Index: sys/arch/alpha/conf/GENERIC
===
RCS file: /OpenBSD/src/sys/arch/alpha/conf/GENERIC,v
retrieving revision 1.259
diff -u -p -r1.259 GENERIC
--- sys/arch/alpha/conf/GENERIC 31 Aug 2016 12:46:45 -  1.259
+++ sys/arch/alpha/conf/GENERIC 29 Aug 2017 19:43:24 -
@@ -285,9 +285,9 @@ mlphy*  at mii? # Micro Linear 
6692 PH
 ukphy* at mii? # "unknown" PHYs
 
 # sensors
-alipm* at pci? disable
+alipm* at pci? disable # known to cause freezes on CS20/DS20L
 iic*   at alipm?
-tsciic*at tsc?
+tsciic*at tsc? disable # known to cause freezes on CS20/DS20L
 iic*   at tsciic?
 
 adc*   at iic? # Analog Devices AD7416/AD7417/7418

dmesg:
[ using 762464 bytes of bsd ELF symbol table ]
consinit: not using prom console
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.1-current (GENERIC.MP) #0: Thu Aug 10 09:24:05 GMT 2017
m...@voirat.gentiane.org:/usr/src/sys/arch/alpha/compile/GENERIC.MP
API CS20D 833 MHz
8192 byte page size, 2 processors.
real mem = 2147483648 (2048MB)
rsvd mem = 2981888 (2MB)
avail mem = 2099380224 (2002MB)
mainbus0 at root
cpu0 at mainbus0: ID 0 (primary), 21264B-3 (unknown minor type 3)
cpu0: architecture extensions: 307
cpu1 at mainbus0: ID 1, 21264B-3 (unknown minor type 3)
cpu1: architecture extensions: 307
tsc0 at mainbus0: 21272 Chipset, Cchip rev 0
tsc0: 4 Dchips, 1 memory bus of 32 bytes
tsc0: arrays present: 1024MB, 1024MB, 0MB, 0MB, Dchip 0 rev 1
tsp0 at tsc0 hose 0
pci0 at tsp0 bus 0
siop0 at pci0 dev 3 function 0 "Symbios Logic 53c1010-66" rev 0x01: dec 6600 
irq 16, using 8K of on-board RAM
scsibus0 at siop0: 16 targets, initiator 7
sd0 at scsibus0 targ 3 lun 0:  SCSI3 0/direct fixed 
naa.5005076206d78e86
sd0: 17501MB, 512 bytes/sector, 35843670 sectors
fxp0 at pci0 dev 4 function 0 "Intel 8255x" rev 0x08, i82559: dec 6600 irq 20, 
address 00:02:56:00:02:15
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
sio0 at pci0 dev 7 function 0 "Acer Labs M1533 ISA" rev 0xc3
pciide0 at pci0 dev 16 function 0 "Acer Labs M5229 UDMA IDE" rev 0xc2: DMA, 
channel 0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 ignored (disabled)
atapiscsi0 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom 
removable
cd0(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2
"Acer Labs M7101 Power" rev 0x00 at pci0 dev 17 function 0 not configured
isa0 at sio0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x3bc/4 irq 7
mcclock0 at isa0 port 0x70/2: mc146818 or compatible
tsp1 at tsc0 hose 1
pci1 at tsp1 bus 0
fxp1 at pci1 dev 3 function 0 "Intel 8255x" rev 0x08, i82559: dec 6600 irq 32, 
address 00:02:56:00:02:16
inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4
tsciic0 at tsc0
iic0 at tsciic0
lmenv0 at iic0 addr 0x2f: adm9240 rev 2
spdmem0 at iic0 addr 0x50: 256MB SDRAM registered ECC PC100CL3
spdmem1 at iic0 addr 0x51: 256MB SDRAM registered ECC PC100CL3
spdmem2 at iic0 addr 0x52: 256MB SDRAM registered ECC PC100CL3
spdmem3 at iic0 addr 0x53: 256MB SDRAM registered ECC PC100CL3
spdmem4 at iic0 addr 0x54: 256MB SDRAM registered ECC PC100CL3
spdmem5 at iic0 addr 0x55: 256MB SDRAM registered ECC PC100CL3
spdmem6 at iic0 addr 0x56: 256MB SDRAM registered ECC PC100CL3
spdmem7 at iic0 addr 0x57: 256MB SDRAM registered ECC PC100CL3
stray isa irq 15
stray isa irq 3
vscsi0 at root
scsibus2 at vscsi0: 

error extracting base is not detected

[Miod Vallat]

>Synopsis:  error extracting base is not detected
>Category:  installer
>Description:
During an install or an upgrade, if extraction of base fails, the
error is not handled correctly, because the specific handling of
etc-within-base is performed before checking $? (i.e. the result of the
extraction) for failure, as in:

Installing bsd  100% |**|  8626 KB00:08
Installing bsd.rd   100% |**|  2668 KB00:02
Installing base61.tgz99% |* | 97667 KB07:02
gzip: stdin: Input/output error
tar: End of archive volume 1 reached
Installing comp61.tgz   100% |**| 49443 KB04:24

>How-To-Repeat:
Try and install or upgrade and have I/O errors or whatever causes base
not to be extracted correctly.
>Fix:
This ought to work: (untested)

Index: install.sub
===
RCS file: /OpenBSD/src/distrib/miniroot/install.sub,v
retrieving revision 1.1032
diff -u -p -r1.1032 install.sub
--- install.sub 8 Aug 2017 07:14:05 -   1.1032
+++ install.sub 20 Aug 2017 21:38:12 -
@@ -1570,11 +1570,6 @@ install_files() {
case $_fsrc in
*.tgz)  $_unpriv ftp -D Installing -Vmo - "$_fsrc" |
tar -zxphf - -C /mnt
-   if [[ $_f == ?(x)base*.tgz && $MODE == install ]]; then
-   ftp -D Extracting -Vmo - \
-   file:///mnt/var/sysmerge/${_f%%base*}etc.tgz |
-   tar -zxphf - -C /mnt
-   fi
;;
*)  $_unpriv ftp -D Installing -Vmo - "$_fsrc" >"/mnt/$_f"
;;
@@ -1586,6 +1581,11 @@ install_files() {
return
fi
else
+   if [[ $_f == ?(x)base*.tgz && $MODE == install ]]; then
+   ftp -D Extracting -Vmo - \
+   file:///mnt/var/sysmerge/${_f%%base*}etc.tgz |
+   tar -zxphf - -C /mnt
+   fi
DEFAULTSETS=$(rmel $_f $DEFAULTSETS)
fi
[[ -d $_tmpsrc ]] && rm -f "$_tmpsrc/$_f"

Re: SGI Indy DHCP problems since 5.6 and still in 6.0-current

[Miod Vallat]

Thank you for researching this.

This behaviour is caused by a stupid mistake in the driver's code, where
the receiver is disabled unless either an address is set or the
interface is switched to promiscuous mode.

The following patch will fix the problem.

Index: if_sq.c
===
RCS file: /OpenBSD/src/sys/arch/sgi/hpc/if_sq.c,v
retrieving revision 1.28
diff -u -p -r1.28 if_sq.c
--- if_sq.c 22 Jan 2017 10:17:37 -  1.28
+++ if_sq.c 2 Mar 2017 07:13:48 -
@@ -580,7 +580,7 @@ sq_set_filter(struct sq_softc *sc)
/*
 * Unless otherwise specified, always accept broadcast frames.
 */
-   if ((sc->sc_rxcmd & ~RXCMD_REC_MASK) == RXCMD_REC_NONE)
+   if ((sc->sc_rxcmd & RXCMD_REC_MASK) == RXCMD_REC_NONE)
sc->sc_rxcmd |= RXCMD_REC_BROAD;
 }
 

Re: FW: smtpd dies on current

[Miod Vallat]

Sorry about these crashes, it seems I have been too greedy freeing
memory. Can you try the following diff, which should fix the issue?

Index: x509/x509_lu.c
===
RCS file: /cvs/src/lib/libcrypto/x509/x509_lu.c,v
retrieving revision 1.21
diff -u -p -r1.21 x509_lu.c
--- x509/x509_lu.c  8 Nov 2016 21:22:55 -   1.21
+++ x509/x509_lu.c  12 Nov 2016 09:37:12 -
@@ -376,8 +376,10 @@ X509_STORE_add_cert(X509_STORE *ctx, X50
 
CRYPTO_w_unlock(CRYPTO_LOCK_X509_STORE);
 
-   if (ret == 0)
+   if (ret == 0) {
+   obj->data.x509 = NULL; /* owned by the caller */
X509_OBJECT_free(obj);
+   }
 
return ret;
 }
@@ -419,8 +421,10 @@ X509_STORE_add_crl(X509_STORE *ctx, X509
 
CRYPTO_w_unlock(CRYPTO_LOCK_X509_STORE);
 
-   if (ret == 0)
+   if (ret == 0) {
+   obj->data.crl = NULL; /* owned by the caller */
X509_OBJECT_free(obj);
+   }
 
return ret;
 }

Re: Crash in softnet on SGI

[Miod Vallat]

> It crashed again last night so I rebuilt the kernel with your patch.
> Both hpc0 and hpc1 now report 25 mhz.  I've attached the full dmesg
> below for reference.

I was wondering if your system had a 33MHz GIO bus and was incorrectly
using the 25MHz settings. But since the diff now reports 25MHz, the
settings do not change and the diff doesn't change anything.

I am a bit surprised, because here my R5000 Indy has a 33MHz GIO bus
while all the R4000/R4400 Indys have 25MHz GIO buses, so I would naively
expect your R5000 Challenge S system to also use a 33MHz flavour; but
there might be good reasons for things to be this way (also, maybe SGI
used 25MHz buses for the R5000 model initially, and only switched to
33MHz months or years later).

Back to square one...

Re: Crash in softnet on SGI

[Miod Vallat]

> Theo suggested that a fix for ARP committed the other day might have
> some impact on this so I've been testing the latest snapshot.  So far
> I've been up for 19:47, so it's looking good so far.  Interestingly
> enough I was getting "sq1: receive FIFO overflow" periodically with
> the previous snapshot, so far on this boot that has not recurred.
> 
> If the box cores again I'll test your diff and see if that improves my
> situation.

If you still get `receive FIFO overflow' messages, even if the kernel
does not panic, please test this diff and tell me what speed gets
reported for hpc0 and hpc1 attachments.

Thanks,
Miod

Re: Crash in softnet on SGI

[Miod Vallat]

> Machine seems to hang at (seemingly) random intervals.  This has
> occurred on several recent snapshots including 10-Jul. I have
> reproduced the issue on multiple systems, so it doesn't seem to be a
> hardware issue.  It may not be relevant but the machines are running
> an MTU of 1454 on sq1.

Are the other systems on which the issue has been reproduced also
Challenge S systems using the second Ethernet interface?

If so, the problem might be caused by bad timing settings for the second
interface.

Does the following diff help?

Index: hpc/hpc.c
===
RCS file: /OpenBSD/src/sys/arch/sgi/hpc/hpc.c,v
retrieving revision 1.18
diff -u -p -r1.18 hpc.c
--- hpc/hpc.c   18 Sep 2015 20:50:02 -  1.18
+++ hpc/hpc.c   15 Jul 2016 11:43:25 -
@@ -427,8 +427,8 @@ hpc_attach(struct device *parent, struct
uint32_t hpctype;
int isonboard;
int isioplus;
-   int giofast;
-   int needprobe;
+   int giofast = 0;
+   int needprobe = 0;
int sysmask = 0;
 
sc->sc_base = ga->ga_addr;
@@ -496,9 +496,34 @@ hpc_attach(struct device *parent, struct
isioplus = (sc->sc_base == HPC_BASE_ADDRESS_1 && hpctype == 3 &&
(sysmask & HPCDEV_IP24) != 0);
 
-   printf(": SGI HPC%d%s (%s)\n", (hpctype ==  3) ? 3 : 1,
-   (hpctype == 15) ? ".5" : "", (isonboard) ? "onboard" :
-   (isioplus) ? "IO+ mezzanine" : "GIO slot");
+   if (hpctype == 3) {
+   if (sys_config.system_subtype == IP22_INDIGO2) {
+   /* wild guess */
+   giofast = 1;
+   } else {
+   /*
+* According to IRIX hpc3.h, the fast GIO bit
+* is active high, but the register value has
+* been found to be 0xf8 on slow GIO systems
+* and 0xf1 on fast ones, which tends to prove
+* the opposite...
+*/
+   if ((bus_space_read_4(sc->sc_ct, sc->sc_ch,
+   IOC_BASE + IOC_GCREG) & IOC_GCREG_GIO_33MHZ) == 0)
+   giofast = 1;
+   }
+   }
+
+   if (hpctype == 3) {
+   printf(": SGI HPC3 (%s, %uMHz)\n",
+   (isonboard) ? "onboard" :
+   (isioplus) ? "IO+ mezzanine" : "GIO slot",
+   25 + 8 * giofast);
+   } else {
+   printf(": SGI HPC1%s (%s)\n",
+   (hpctype == 15) ? ".5" : "",
+   (isonboard) ? "onboard" : "GIO slot");
+   }
 
/*
 * Configure the IOC.
@@ -586,42 +611,16 @@ hpc_attach(struct device *parent, struct
 
if (hpctype == 3) {
hv = _values;
-   if (isonboard) {
+   if (isonboard)
hd = hpc3_onboard;
-   if (sys_config.system_subtype == IP22_INDIGO2) {
-   /* wild guess */
-   giofast = 1;
-   } else {
-   /*
-* According to IRIX hpc3.h, the fast GIO bit
-* is active high, but the register value has
-* been found to be 0xf8 on slow GIO systems
-* and 0xf1 on fast ones, which tends to prove
-* the opposite...
-*/
-   if (bus_space_read_4(sc->sc_ct, sc->sc_ch,
-   IOC_BASE + IOC_GCREG) & IOC_GCREG_GIO_33MHZ)
-   giofast = 0;
-   else
-   giofast = 1;
-   }
-   } else {
+   else
hd = hpc3_devices;
-   /*
-* XXX should IO+ Mezzanine use the same settings as
-* XXX the onboard HPC3?
-*/
-   giofast = 0;
-   }
-   needprobe = 0;
} else {
hv = _values;
hv->revision = hpctype;
-   giofast = 0;
-   if (isonboard) {
+   if (isonboard)
hd = hpc1_onboard;
-   needprobe = 0;
-   } else {
+   else {
hd = hpc1_devices;
/*
 * Until a reliable way of telling E++ and GIO32 SCSI

Re: openssl command can't be exited

[Miod Vallat]

> Accidentally ask for a password:
>
> #  openssl genrsa -aes256 -out /etc/ssl/private/server.key 2048
> Generating RSA private key, 2048 bit long modulus
> .+++
> ...+++
> e is 65537 (0x10001)
> Enter pass phrase for /etc/ssl/private/server.key:
> 822626074580:error:28069065:lib(40):UI_set_result:result too
> small:/home/tedu/src/lib/libcrypto/crypto/../../libssl/src/crypto/ui/ui_lib.c:834:You
> must type in 4 to 1023 characters
> Enter pass phrase for /etc/ssl/private/server.key:
> Enter pass phrase for /etc/ssl/private/server.key:
>
> And now you can't quit. ^C doesn't work. ^D doesn't work. pkill openssl in
> another terminal doesn't work. Nothing works.

Haha, this is a good one.

It is caused by this in openssl apps.c!password_callback()

if (ok >= 0)
do {
ok = UI_process(ui);
} while (ok < 0 &&
UI_ctrl(ui, UI_CTRL_IS_REDOABLE, 0, 0, 0));

which causes the loop to spin, because the redoable flag gets set on
the first error, but if never cleared by true failures such as ^C.

The following diff will fix the problem.

Index: ui/ui_lib.c
===
RCS file: /OpenBSD/src/lib/libssl/src/crypto/ui/ui_lib.c,v
retrieving revision 1.30
diff -u -p -r1.30 ui_lib.c
--- ui/ui_lib.c 10 Feb 2015 11:22:21 -  1.30
+++ ui/ui_lib.c 27 Mar 2016 10:10:59 -
@@ -491,6 +491,7 @@ UI_process(UI *ui)
switch (ui->meth->ui_read_string(ui,
sk_UI_STRING_value(ui->strings, i))) {
case -1:/* Interrupt/Cancel/something... */
+   ui->flags &= ~UI_FLAG_REDOABLE;
ok = -2;
goto err;
case 0: /* Errors */

Re: std::ifstream is broken on arm

[Miod Vallat]

Actually, I had forgotten to disable the stack protector, and guess
what? Disabling it produces a working libstdc++, at least for that
simple use case; I have not tried to build cmake.

Therefore I suggest the following diff until someone with enough love
for the utter crap known as `arm' comes with a real compiler fix:

Index: Makefile
===
RCS file: /OpenBSD/src/gnu/lib/libstdc++-v3/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile14 May 2015 02:56:01 -  1.8
+++ Makefile16 Feb 2016 20:04:20 -
@@ -17,6 +17,9 @@ CFLAGS+=  -frandom-seed=RepeatabilityCons
 CXXFLAGS+= -frandom-seed=RepeatabilityConsideredGood
 CXXFLAGS+= -fno-implicit-templates -ffunction-sections -fdata-sections \
-Wno-deprecated
+.if ${MACHINE_ARCH} == "arm"
+CXXFLAGS+= -fno-stack-protector
+.endif
 
 DPADD= ${LIBM}
 LDADD= -lm

Re: std::ifstream is broken on arm

[Miod Vallat]

>
> The first bug was already reported three years ago:
>
> http://marc.info/?l=openbsd-bugs=135732012310459
>
> std::ifstream has a bug when linked with libpthread:

This is a compiler bug. Compiling libstdc++ with -O0 yields a working
binary.

And of course, compiling libstdc++ with as few optimization as possible,
i.e. -O1 -fno-var-tracking -fno-defer-pop -fno-branch-probabilities
-fno-cprop-registers -fno-if-conversion -fno-if-conversion2
-fno-ipa-pure-const -fno-ipa-reference -fno-tree-ccp -fno-tree-dce
-fno-tree-dominator-opts -fno-tree-dse -fno-tree-ter -fno-tree-lrs
-fno-tree-sra -fno-tree-copyrename -fno-tree-fre -fno-tree-copy-prop
-fno-tree-sink -fno-tree-salias -fno-unit-at-a-time, triggers the
issue again.

Re: Recent checkin to bge broke my Broadcom ethernet

[Miod Vallat]

> >Fix:
>   Reverting src/sys/dev/pci/if_bge.c to rev 1.371 and if_bgereg.h to 
> 1.128 and
> rebuilding the kernel allows the interface to work correctly.

Does the following diff (on top of HEAD, thus if_bge 1.372 and
if_bgereg.h 1.129) help?

Index: if_bge.c
===
RCS file: /OpenBSD/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.372
diff -u -p -r1.372 if_bge.c
--- if_bge.c10 Nov 2015 20:23:50 -  1.372
+++ if_bge.c11 Nov 2015 19:45:38 -
@@ -3221,7 +3221,10 @@ bge_reset(struct bge_softc *sc)
 * When firmware finishes its initialization it will
 * write ~BGE_SRAM_FW_MB_MAGIC to the same location.
 */
-   write_op(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER);
+   if (write_op == bge_writereg_ind)
+   bge_writereg_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER);
+   else
+   bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER);
 
reset = BGE_MISCCFG_RESET_CORE_CLOCKS | BGE_32BITTIME_66MHZ;
 

Re: Extra keyboard keys not being recognized

[Miod Vallat]

> I'm trying to set the multimedia keys of my keyboard to de something. It
> have three simple keys with shutdown, internet and mail figures on it.
> It is a standard keyboard, a very simple one.
> First I tried to detect them using xev(1), but when I press the keys, nothing
> happens.
> Someone on irc, pointed me to try usbhidaction(1), and run usbhidctl
> to detect the keys. Running usbhidctl first made me note that sometimes
> the command fails, and gives:
> 
> usbhidctl: USB_GET_REPORT (probably not supported by device): Bad
> address

Can you show the output of `usbhidctl -f /dev/wskbd1 -r', `usbhidctl -f
/dev/uhid0 -r' and `usbhidctl -f /dev/uhid1 -r'? (needs root
permissions)

[...]

> Why wsconsctl is detecting it as two keys? With Caps_Lock +
> Num_Lock on I get ledstate=3, as all the keys was on.

I don't understand your question. Could you write clearly what you did,
what your expectations were, and what you observed?

Re: tmux uses too much cpu

[Miod Vallat]

 ktrace reveals that it's doing a wakeup every half second to stat and probe
 each terminal and process group. My opinion is that while the status bar
 updates are cool when I'm watching, if there's nobody attached this is wasted
 effort.

It's not your opinion, it's a fact. I've been running tmux with

set-option -g status off
set-window-option -g monitor-activity off

in my ~/.tmux.conf since about the time tmux got imported for this
reason, so that tmux does not cause a significant overhead when building
on power-challenged platforms.

Re: Segmentation fault in __powerpc_read_tcb on G3

[Miod Vallat]

 I had a look at that thread again, and it appears I'm not gonna grow
 hair anytime soon.

There is finally hope! The ld.so fix in libexec/ld.so/powerpc/ldasm.S
r1.22 seems to solve the issue here.

Re: vesa driver corrupts wsfontload loaded vga fonts.

[Miod Vallat]

 i found a few small flaws with this.

[...]

 so here are the corrected ones (for vga.c  vgavar.h, no change to the
 earlier wsdisplay.c patch)

I'm going to put this in. Thanks for working on this issue.

Re: Potential Bugs found by clang static analyzer

[Miod Vallat]

 Some examples?
 
 In crypto /x509v3 /v3_purp.c line 294 it is called:
 
 xptable_free(xstandard + i);
 
 xptable_free() makes an free() on this pointer, but xstandard was not
 allocated with malloc(). See line 92:
 
 static X509_PURPOSE xstandard[] = {
 {X509_PURPOSE_SSL_CLIENT, X509_TRUST_SSL_CLIENT, 0,
 check_purpose_ssl_client, SSL client, sslclient, NULL},
 ...
 };
 
 This is just an example...

I'd suggest you try and understand the code you are talking about before
pretending it has a bug.

Hint: have a look at the .flags field.

Alternatively, you can compile that code with coverage metrics and check
that xptable_free() will never call free() in that case.

Miod

Re: uvm_fault with bwi on i386 when scanning or bringing up.

[Miod Vallat]

Please try the following revert diff. It works for me on that particular
non-ioapic system with yds(4).

Index: arch/i386/i386/locore.s
===
RCS file: /cvs/src/sys/arch/i386/i386/locore.s,v
retrieving revision 1.150
diff -u -p -r1.150 locore.s
--- arch/i386/i386/locore.s 11 Feb 2015 00:16:07 -  1.150
+++ arch/i386/i386/locore.s 26 Feb 2015 20:37:20 -
@@ -104,7 +104,6 @@
  * These are used on interrupt or trap entry or exit.
  */
 #defineINTRENTRY \
-   cld ; \
pushl   %eax; \
pushl   %ecx; \
pushl   %edx; \
Index: lib/libkern/arch/i386/bcmp.S
===
RCS file: /cvs/src/sys/lib/libkern/arch/i386/bcmp.S,v
retrieving revision 1.3
diff -u -p -r1.3 bcmp.S
--- lib/libkern/arch/i386/bcmp.S29 Nov 2014 18:51:23 -  1.3
+++ lib/libkern/arch/i386/bcmp.S26 Feb 2015 20:37:21 -
@@ -13,6 +13,7 @@ ENTRY(bcmp)
movl12(%esp),%edi
movl16(%esp),%esi
xorl%eax,%eax   /* clear return value */
+   cld /* set compare direction forward */
 
movl20(%esp),%ecx   /* compare by words */
shrl$2,%ecx
Index: lib/libkern/arch/i386/bzero.S
===
RCS file: /cvs/src/sys/lib/libkern/arch/i386/bzero.S,v
retrieving revision 1.5
diff -u -p -r1.5 bzero.S
--- lib/libkern/arch/i386/bzero.S   29 Nov 2014 18:51:23 -  1.5
+++ lib/libkern/arch/i386/bzero.S   26 Feb 2015 20:37:21 -
@@ -13,6 +13,7 @@ ENTRY(bzero)
movl8(%esp),%edi
movl12(%esp),%edx
 
+   cld /* set fill direction forward */
xorl%eax,%eax   /* set fill data to 0 */
 
/*
Index: lib/libkern/arch/i386/memchr.S
===
RCS file: /cvs/src/sys/lib/libkern/arch/i386/memchr.S,v
retrieving revision 1.2
diff -u -p -r1.2 memchr.S
--- lib/libkern/arch/i386/memchr.S  29 Nov 2014 18:51:23 -  1.2
+++ lib/libkern/arch/i386/memchr.S  26 Feb 2015 20:37:21 -
@@ -14,6 +14,7 @@ ENTRY(memchr)
movl16(%esp),%ecx   /* set length of search */
testl   %ecx,%ecx   /* test for len == 0 */
jz  L1
+   cld /* set search forward */
repne   /* search! */
scasb
jne L1  /* scan failed, return null */
Index: lib/libkern/arch/i386/memcmp.S
===
RCS file: /cvs/src/sys/lib/libkern/arch/i386/memcmp.S,v
retrieving revision 1.2
diff -u -p -r1.2 memcmp.S
--- lib/libkern/arch/i386/memcmp.S  29 Nov 2014 18:51:23 -  1.2
+++ lib/libkern/arch/i386/memcmp.S  26 Feb 2015 20:37:21 -
@@ -12,6 +12,7 @@ ENTRY(memcmp)
pushl   %esi
movl12(%esp),%edi
movl16(%esp),%esi
+   cld /* set compare direction forward */
 
movl20(%esp),%ecx   /* compare by words */
shrl$2,%ecx
Index: lib/libkern/arch/i386/memmove.S
===
RCS file: /cvs/src/sys/lib/libkern/arch/i386/memmove.S,v
retrieving revision 1.7
diff -u -p -r1.7 memmove.S
--- lib/libkern/arch/i386/memmove.S 29 Nov 2014 18:51:23 -  1.7
+++ lib/libkern/arch/i386/memmove.S 26 Feb 2015 20:37:21 -
@@ -74,6 +74,7 @@ ENTRY(memcpy)
movl20(%esp),%ecx
 docopyf:
movl%edi,%eax   # setup return value for memcpy/memmove
+   cld # copy forward
shrl$2,%ecx # copy by 32-bit words
rep
movsl
Index: lib/libkern/arch/i386/memset.S
===
RCS file: /cvs/src/sys/lib/libkern/arch/i386/memset.S,v
retrieving revision 1.4
diff -u -p -r1.4 memset.S
--- lib/libkern/arch/i386/memset.S  29 Nov 2014 18:51:23 -  1.4
+++ lib/libkern/arch/i386/memset.S  26 Feb 2015 20:37:21 -
@@ -15,6 +15,8 @@ ENTRY(memset)
movl20(%esp),%ecx
pushl   %edi/* push address of buffer */
 
+   cld /* set fill direction forward */
+
/*
 * if the string is too short, it's really not worth the overhead
 * of aligning to word boundaries, etc.  So we jump to a plain
Index: lib/libkern/arch/i386/scanc.S
===
RCS file: /cvs/src/sys/lib/libkern/arch/i386/scanc.S,v
retrieving revision 1.3
diff -u -p -r1.3 scanc.S
--- lib/libkern/arch/i386/scanc.S   29 Nov 2014 18:51:23 -  1.3
+++ 

Re: uvm_fault with bwi on i386 when scanning or bringing up.

[Miod Vallat]

  Ok, so patched as requested, recompiled the kernel. Including the
  command itself, a new dmesg as it has some new information, the ps,
  trace and show registers outputs.
  Let me know if you need anything further.
 
 I have dusted a pre-ioapic system here...
 
 [...]
 cpu0: AMD-K6tm w/ multimedia extensions (AuthenticAMD 586-class) 234 MHz
 cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,MMX
 real mem  = 66646016 (63MB)
 avail mem = 8144 (52MB)
 mainbus0 at root
 bios0 at mainbus0: AT/286+ BIOS, date 02/26/98, BIOS32 rev. 0 @ 0xfb440
 apm0 at bios0: Power Management spec V1.2 (slowidle)
 pcibios0 at bios0: rev 2.1 @ 0xf/0xb8b8
 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdd30/128 (6 entries)
 pcibios0: PCI Exclusive IRQs: 5 9 10 11
 pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371SB ISA rev 0x00)
 pcibios0: PCI bus #0 is the last bus
 bios0: ROM list: 0xc/0x8000
 cpu0 at mainbus0: (uniprocessor)
 pci0 at mainbus0 bus 0: configuration mode 1 (bios)
 [...]
 
 ... in order to check if your issue is specific to bwi or not. The
 upgrade from bsd.rd ran smoothly, but GENERIC drops into ddb at the end
 of autoconf, before the kernel even gets a chance to start init.
 
 I'll try and investigate this regression further next weekend.
 

Actually, GENERIC runs if I boot -c and disable yds, which would
otherwise attach as:

yds0 at pci0 dev 13 function 0 Yamaha 724 rev 0x05: irq 9

so there is definitely something fishy regarding PCI interrupt
handling... but not necessarily all of them, since this device:

vr0 at pci0 dev 15 function 0 VIA Rhine/RhineII rev 0x06: irq 10, address 
00:50:ba:c8:1d:bb
amphy0 at vr0 phy 8: Am79C873 10/100 PHY, rev. 0

works (well, as far as a VIA Rhine can work).

Re: uvm_fault with bwi on i386 when scanning or bringing up.

[Miod Vallat]

 Ok, so patched as requested, recompiled the kernel. Including the
 command itself, a new dmesg as it has some new information, the ps,
 trace and show registers outputs.
 Let me know if you need anything further.

I have dusted a pre-ioapic system here...

[...]
cpu0: AMD-K6tm w/ multimedia extensions (AuthenticAMD 586-class) 234 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,MMX
real mem  = 66646016 (63MB)
avail mem = 8144 (52MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/26/98, BIOS32 rev. 0 @ 0xfb440
apm0 at bios0: Power Management spec V1.2 (slowidle)
pcibios0 at bios0: rev 2.1 @ 0xf/0xb8b8
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdd30/128 (6 entries)
pcibios0: PCI Exclusive IRQs: 5 9 10 11
pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371SB ISA rev 0x00)
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
[...]

... in order to check if your issue is specific to bwi or not. The
upgrade from bsd.rd ran smoothly, but GENERIC drops into ddb at the end
of autoconf, before the kernel even gets a chance to start init.

I'll try and investigate this regression further next weekend.

Re: uvm_fault with bwi on i386 when scanning or bringing up.

[Miod Vallat]

 On Sat, Feb 21, 2015 at 09:03:43AM +0100, Stefan Sperling wrote:
  On Fri, Feb 20, 2015 at 10:15:15PM -0330, Michael wrote:
   sudo ifconfig bwi0 up
   uvm_fault(0xd211a2d0, 0x0, 0, 1) - e
   fatal page fault (6) in supervisor mode
   trap type 6 code 0 eip 0 cs d0f60008 eflags 10202 cr2 0 cpl 60
   panic: trap type 6, code=0, pc=0
   Starting stack trace...
   panic(d09e1dca,f11adc10,d09e5a96,f11adc10,d0b3330c) at panic+0x85
   panic(d09e5a96,6,0,0,d0f60008) at panic+0x85
   trap() at trap+0x394
   --- trap (number 0) ---
   Bad frame pointer: 0xd0f69000
   0:
   End of stack trace.
   syncing disks... 4 4 4 done
  
  So it's running into a NULL pointer but it's still unclear where and why.
  Perhaps it's an unchecked allocation failure, perhaps some other problem.
  
  Are you comfortable with adding some debug printf to see which function in
  bwi is the last called one before the crash? Would you need help with that?
 
 FWIW, I have the same Broadcom BCM4306 device in a macppc box.
 I don't see your problem on this system -- the device works, apart
 from the usual poor level of performance.

I can't reproduce either with

bwi0 at pci1 dev 3 function 0 Broadcom BCM4306 rev 0x03: apic 1 int 19, 
address 00:0b:7d:19:27:01

on i386.

Re: uvm_fault with bwi on i386 when scanning or bringing up.

[Miod Vallat]

  FWIW, I have the same Broadcom BCM4306 device in a macppc box.
  I don't see your problem on this system -- the device works, apart
  from the usual poor level of performance.
 
 I can't reproduce either with
 
 bwi0 at pci1 dev 3 function 0 Broadcom BCM4306 rev 0x03: apic 1 int 19, 
 address 00:0b:7d:19:27:01
 
 on i386.

... which means this is likely a non-ioapic vs ioapic issue; as soon as
the device interrupts, it will cause the fault somehow on the non-ioapic
system.

Re: owtemp device no longer functioning under OpenBSD 5.6

[Miod Vallat]

 Synopsis: No owtemp device is recognized by onewire. 
 Category: kernel
 Environment:
  System  : OpenBSD 5.6
  Details : OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug  8 00:20:21 MDT 2014
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 
 
  Architecture: OpenBSD.amd64
  Machine : amd64
 Description:
  For the exact same hardware under OpenBSD 5.4, an attached Dallas 
 Semiconductor DS18B20 was recognized as an owtemp device, and showed up under 
 sysctl hw.sensors. Under 5.6, no owtemp is recognized; only the onewire 
 USB-FOB is recognized as uow, and onewire.
  How-To-Repeat:
  Attach a Dallas Semiconductor USB-FOB with an attached DSB1820 temperature 
 sensor.
  Note that dmesg does not show an owtemp device, and sysctl hw.sensor does 
 not show readings.
 Fix:
  No known workaround.

Can you share a 5.4 dmesg if you still have any?

Does `ps axk' show the `(onewire0)' kernel thread? Is it slepping on the
`owidle' wchan?

Can you recompile a kernel with `option ONEWIRE_DEBUG' and share the
messages it produces?

TIA,
Miod

Re: floppy doesn't work on sun4m

[Miod Vallat]

  Floppy doesn't work on sparc/5.6. I tested 5.5 and -currrent and same 
  behaviour.
 
 Actually, it does, on sun4c (slightly different controller). I can
 reproduce your symptoms on sun4m but I am not sure whether the floppy
 drive is still in working condition. As you have been able to confirm it
 works under Solaris, it's clearly a sun4m-specific issue.
 
On second hand, after going back in time until 3.2 without any floppy
success, I supected the drive was the culprit and swapped it with my
last spare; and it works like a charm on an SS5/110. I can boot off
floppy56.fs fine and access the floppy disk from OpenBSD.

What is your particular system configuration?

Re: floppy doesn't work on sun4m

[Miod Vallat]

 Floppy doesn't work on sparc/5.6. I tested 5.5 and -currrent and same 
 behaviour.

Actually, it does, on sun4c (slightly different controller). I can
reproduce your symptoms on sun4m but I am not sure whether the floppy
drive is still in working condition. As you have been able to confirm it
works under Solaris, it's clearly a sun4m-specific issue.

Re: [PATCH 0/5] libressl: Restore support for some OPENSSL_NO_xxx defines

[Miod Vallat]

 I am trying to build a smaller libressl(portable) and this is the
 src code I had change.
 
 The auto based build system also needs tweeking, I simply removed
 those lines for now but it would be nice with proper --enable/--disable
 knobs.

We did not unentangle the happy maze of openssl defines and options in
order to put it back later. There is no intent in supporting building
with OPENSSL_NO_whatever.

A diff back #ifdef OPENSSL_NO_FOO or shuffling the existing ones around
in order to get things to build will not get accepted. On the other
hand, diffs carefully removing the remaining defines will be much better
welcomed.

 I can currently build libressl with these defined, but I cannot
 tell if any of them sholed be removed from a security perspective?

If you're asking such a question, it looks to me that you have no idea
what you are doing. What are you trying to achieve? A library so
stripped down that it becomes useless?

Miod

Re: Segmentation fault in __powerpc_read_tcb on G3

[Miod Vallat]

  For what it's worth, this does not happen with:
 cpu0 at mainbus0: 750 (Revision 0x3311): 499 MHz: 256KB backside cache
  
  I'll try to put my BW G3 back in working condition ASAP to check if I
  can reproduce the problem. It features:
 cpu0 at mainbus0: 750 (Revision 0x202): 400 MHz: 1MB backside cache
  so if this is indeed an old-G3 specific issue, I should be affected.
  
  ... and I can reproduce this on the BW G3 here. I'll try to
  investigate, but this machine is actively trying to commit suicide (when
  it does not spontaneously powers off).
  
  Was this fixed?
 
 No. But I lost a lot of hair. And I could not find anything interesting
 in the various G3 errata documents.

That said, I wonder if mpi@'s recent rewrite of the idle path on ppc
will change that behaviour. Something for the week-end...

Re: OpenSSL / LibreSSL susceptible to cross-VM AES key compromise

[Miod Vallat]

Hello,

 http://eprint.iacr.org/2014/435.pdf
 
 Just wanted to make sure the LibreSSL team had seen this. Sorry about the
 lack of proper formatting - I figure sending the issue here is considerably
 more likely to get a response than OpenSSL's request tracker.
 
 Page 18, under Countermeasures - Cache Flushing, shows their recommended
 solution. It would probably make for additional good press to have LibreSSL
 have a countermeasure in place long before OpenSSL.

Thanks for pointing this.

There is not much we can do against this, but force the AES tables to be
warm in the cache at the end of the operation by reading them in whole,
and unfortunately this will have a performance impact.

Clearing the whole cache would as well, but there might be a way to do
the opposite and actually evict the AES tables from the cache. But this
will require adding platform-specific code and I'm not really fond of
adding more ifdefs to libcrypto at the moment.

Note that this kind of covert channel attacks are not new, and are the
reason why BN_mod_exp_mont_consttime() takes care having a constant
cache footprint.

It might be worth introducing ``consttime'' AES routines (and EVP
routines on top of them) to limit the suffering to their callers, but
since all the cloud/virtualization salesperson keep telling you that you
don't need to adjust your code for it to run in a virtualized
environment, this is probably a bad idea, because noone would use these
functions.

Re: Two OpenSSL cleanup fixes

[Miod Vallat]

Applied, thanks!

Miod

Re: volume keys not working on thinkpad x201

[Miod Vallat]

 Slamming outputs.master=255 would be way worse than the current
 situation. There are sounds, like the beep made when suspending and
 resuming, that do not go through sndiod. Maxing out the hardware volume
 is not a viable option.

suspend/resume and text console beeps usually run through pcppi(4),
which volume is not necessarily controlled by the audio device
(especially on systems without onboard audio devices).

There is no easy way to have the volume settings shown by mixerctl apply
to this. And, to the best of my knowledge, the kernel has no way to know
whether the pcppi wave generator goes through the audio device, or
directly reaches the speaker.

Re: Can't change keyboard layout on loongson/macppc installers

[Miod Vallat]

 Hello,
 
 My Yeeloong 8101B has a QWERTY keyboard, but I've set /etc/kbdtype to fr
 to have my usual French AZERTY layout.  It works fine, except in the
 installer.  (I don't mind using QWERTY, but if there's my usual layout I'd
 rather use it.)
 
 If I boot bsd.rd, I'm asked for a keyboard layout (whether I'm choosing
 to Install or Upgrade).  But it has no effect: if I type fr, I still
 have the default QWERTY layout.  Things work fine on my usual amd64/i386
 systems when I do this.
 
 If I go to the Shell
 # kbd fr
 has no effect
 
 and
 # kbd -l
 returns nothing.

Good catch! This is caused by missing /dev/wskbd* nodes on the bsd.rd
filesystem.

The following diff ought to fix this.

Index: MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.loongson/MAKEDEV.md,v
retrieving revision 1.16
diff -u -p -r1.16 MAKEDEV.md
--- MAKEDEV.md  5 Jan 2014 01:16:52 -   1.16
+++ MAKEDEV.md  1 Mar 2014 11:27:14 -
@@ -111,3 +111,4 @@ target(ramd, pty, 0)dnl
 target(ramd, bio)dnl
 target(ramd, diskmap)dnl
 target(ramd, random)dnl
+target(ramd, wskbd, 0, 1, 2)dnl

Re: Error in man page: acpi(4)

[Miod Vallat]

 Looking at acpi(4), in the SEE ALSO section it points to apm(4).? I believe
 this should be apm(8).
 
 apm(4) is the Alliance ProMotion video driver.

No, apm(4) is both the Alliance Promotion video driver for the X server,
and the Advanced Power Management driver for the kernel. It is
unfortunate that they share the same name.

Re: lspci broken and PCI USB hub not recognized on sparc64

[Miod Vallat]

   My system is a Sun Ultra 5, that I received with three open PCI slots.  
 I inserted a generic 5-port USB 2.0 PCI card 
 into one of the slots, but it was not detected in dmesg or usbdevs, 
 as you can see below.  I installed pciutils and 
 usbutils from packages, to see if the controller was at least 
 recognized by the kernel.  lsusb returns no output.  

The preferred way to enumerate pci devices is to use `pcidump' (and
`usbdevs' to list usb devices), rather than 3rd-party software.

That said, your card does not even appear as `not configured' in your
dmesg (the three PCI slots of the Ultra 5 are on pci2, which is empty on
your system).

It is possible that your card requires strict PCI 2.1 compliance; that
would explain why it isn't detected at all (Ultra 5 systems do not
support strict PCI 2.1 devices).

Miod

Re: Segmentation fault in __powerpc_read_tcb on G3

[Miod Vallat]

 The problem is still here on -current.  OpenBSD 5.1 (just before the
 switch to rthreads) works nicely, though.
 
 A very reproduceable way of seeing this crash is to launch fw_update
 on -current, now that Perl has threads enabled.  It always segfaults
 at startup.  Any BW G3 user to confirm this?  I guess it could be
 a processor errata; knowing that someone else has the same problem
 with the same processor might help...

For what it's worth, this does not happen with:
  cpu0 at mainbus0: 750 (Revision 0x3311): 499 MHz: 256KB backside cache

I'll try to put my BW G3 back in working condition ASAP to check if I
can reproduce the problem. It features:
  cpu0 at mainbus0: 750 (Revision 0x202): 400 MHz: 1MB backside cache
so if this is indeed an old-G3 specific issue, I should be affected.

Miod

Re: Segmentation fault in __powerpc_read_tcb on G3

[Miod Vallat]

 For what it's worth, this does not happen with:
   cpu0 at mainbus0: 750 (Revision 0x3311): 499 MHz: 256KB backside cache
 
 I'll try to put my BW G3 back in working condition ASAP to check if I
 can reproduce the problem. It features:
   cpu0 at mainbus0: 750 (Revision 0x202): 400 MHz: 1MB backside cache
 so if this is indeed an old-G3 specific issue, I should be affected.

... and I can reproduce this on the BW G3 here. I'll try to
investigate, but this machine is actively trying to commit suicide (when
it does not spontaneously powers off).

Re: My JIS-Keyboard does not work properly.(patch)

[Miod Vallat]

 So, I wonder this way is better way to report.

Yes, this is the right place to report such a problem.

The USB keymaps are generated from the PS/2 keymaps, and there was a bug
translating the JIS-specific keys. In addition to your diff, symbols
138 and 139 (Muhenkan and Henkan) need to be exchanged.

This is fixed in HEAD. Thanks for reporting this!

Miod

Re: avoid undefined behavior in signed overflow checks

[Miod Vallat]

 On Thu, 25 Jul 2013, Ted Unangst wrote:
 
 Thanks, these are bugs worth fixing in any case, but the native gcc on
 OpenBSD has these optimizations disabled. fyi. (it also has the ident
 string feature disabled, fwiw.)
 
 Indeed, good point for this particular case, though even gcc-4.2.1
 (used by OpenBSD) makes undefined behavior optimizations in other
 cases, such as pointer overflow (see below).
 
 As you mentioned, these bugs might be worth fixing anyway, in case
 OpenBSD decides to support a compiler other than gcc-4.2.1 (perhaps
 a recent version of Clang, which performs more aggressive
 optimizations).

We used to have -fwrapv the default, but it caused odd behaviours in
some third-party binaries, so this was replaced with a default
-fno-strict-overflow.

But apparently some form of -fwrapv is still required (your example case
will compile the test and the call to foo() if -fwrapv).

Miod

Re: Race condition in boot scripts when using DHCP (with wireless)

[Miod Vallat]

I can get the boot process to continue by pressing ctrl-c. Once it has
been booting up, the network has got ready by itself  and I can
manually mount the NFS-share. This is showing it is all about a race
condition where the NFS-mounting begins before the link is ready and
the DHCP-client had time to get an IP assigned.


You should mount your NFS filesystems with option bg, then.

Miod

Re: umount -tnfs -a does not unmount all NFS filesystems

[Miod Vallat]

 umount -tnfs -a does not unmount all NFS filesystems.

Likely related to the recent sysctl bug.

Re: PXE boot bsd.rd -- keyboard repeat rate (and delay) problem.

[Miod Vallat]

 I realise my first post was a bit vague (vacation, some gløgg, plus various 
 other
 excuses) so here's an update (transcript from screenshots) ...

[...]

 Welcome to the OpenBSD/i386 5.2 installation program.
 (I)nstall, (U)pgrade, or (S)hell? i
 
 ---
 
 So one keypress on 'i' spits out between 5 and 20 'i's depending
 on how quick I am at the keyboard.  Notice above that the boot
 prompt works just fine.  I hit enter and ...
 
 ---
 
 At any prompt except password prompts you can escape 
 [...]
 
 Choose your keyboard layout ('?' or 'L' for list [default] System hostname? 
 (short form, e.g. 'foo') System hostname? (short form, e.g. 'foo') System 
 hostname? (short form, e.g. 'foo') System hostname? (short form, e.g. 'foo') 
 System hostname? (short form, e.g. 'foo') System hostname? (short form, e.g. 
 'foo') System hostname? (short form, e.g. 'foo')

This smells like bad edge/level interrupt configuration for the kebyoard
controller. Are you using a PS/2 or USB keyboard? How is the keyboard
recognized by OpenBSD? If it's a USB keyboard recognized by the kernel
as PS/2, you might want to tinker with the `USB legacy keyboard
emulation' settings in your BIOS.

Miod

Re: gem device fails after a few minutes / ppc

[Miod Vallat]

 Description:
 I'm running OpenBSD 5.2 on an Apple PowerBook 12 1.5 GHz with two 
 network interfaces. gem0, the internal interface works fine for a few minutes 
 after the system booted. After that it stops working. I couldn't find a log 
 entry about the problem in /var/log/messages. The device stays in the list 
 yet I can't reach the network conntected to it. Same from the outside. I 
 can't ping the box. When I connect the network ot the USB interface it works 
 fine, so I'd rule out a problem with the network as such.

Are you using a fixed IP configuration or DHCP to get an address? Also,
which speed is your link?

I have a similar PowerBook6,8 system, and have noticed it takes a
significant while (i.e. 10 seconds or more) after the interface is
brought up, for a link to be obtained. I have not noticed loss of link,
though (at 100baseTX FD), but I have not used this system in a while...
maybe it's time for more investigation.

Miod

Re: hp300 kernel - userland breakage

[Miod Vallat]

 The latest snapshot kernel (OpenBSD 5.1 (GENERIC) #39: Thu Mar  1 03:11:52 
 EST 2012)
 works fine on my 345, but more recent kernels seem to break the
 userland. From the looks of it, it affects dynamically linked binaries
 mostly, not sure why I don't get a login prompt:

You need to rebuild and reinstall ld.so before booting recent kernels.

Re: inteldrm bug, more information

[Miod Vallat]

 Further to the bug report that I sent using sendbug(1) on the inteldrm driver,
 here is what I see if I install and boot 5.0 from the release CD on one of the
 affected Supermicro machines. This is a transcription that I am typing from
 the display, but I will try not to typo anything.
 
 intelagp at vga1 not configured
 inteldrm0 at vga1: apic 4 int 16
 drm0 at inteldrm0: couldn't find agp
 uvm_fault(0xd0a2, 0x0, 0, 1) - e
 kernel: page fault trap, code = 0
 Stopped at inteldrm_attach+0x42c: movl 0x28(%eax),%edx
 (now skipping some details, the call tree was:)
 inteldrm_attach
[...]

 Hope this helps,

It does. Can you give the following diff a try?

Miod

Index: drm_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_drv.c,v
retrieving revision 1.96
diff -u -p -r1.96 drm_drv.c
--- drm_drv.c   3 Jul 2011 18:34:14 -   1.96
+++ drm_drv.c   30 Dec 2011 19:03:47 -
@@ -99,6 +99,7 @@ drm_attach_pci(const struct drm_driver_i
 int is_agp, struct device *dev)
 {
struct drm_attach_args arg;
+   struct device *drm_dev;
 
arg.driver = driver;
arg.dmat = pa-pa_dmat;
@@ -115,7 +116,15 @@ drm_attach_pci(const struct drm_driver_i
snprintf(arg.busid, arg.busid_len, pci:%04x:%02x:%02x.%1x,
pa-pa_domain, pa-pa_bus, pa-pa_device, pa-pa_function);
 
-   return (config_found(dev, arg, drmprint));
+   drm_dev = config_found(dev, arg, drmprint);
+   /* force detachment if attachment did not complete successfully */
+   if (drm_dev != NULL 
+   ((struct drm_device *)drm_dev)-dev_private == NULL) {
+   config_detach(drm_dev, DETACH_FORCE);
+   drm_dev = NULL;
+   }
+
+   return drm_dev;
 }
 
 int

Re: FW: documentation of pkg_add -F

[Miod Vallat]

  I just noticed that the man page of pkg_add does not mention the -F flag,
  while it is still there.
  
  (I'm using current snapshots in both i386/amd64, the pkg_add binary
  knows of this flag in both platforms.)
 
 Yeah, that's intentional.
 
 The flag is still around for compatibility, but it's been renamed to -D.
 Old -F will vanish eventually, but I tend to do that very slowly, as it
 doesn't hurt.
 

Does this mean we can use -F update?

Re: old i386 P1 breakage post 5/28/2011

[Miod Vallat]

Please try this:

Index: pci/pci_machdep.c
===
RCS file: /cvs/src/sys/arch/i386/pci/pci_machdep.c,v
retrieving revision 1.66
diff -u -p -r1.66 pci_machdep.c
--- pci/pci_machdep.c   23 Oct 2011 21:18:14 -  1.66
+++ pci/pci_machdep.c   4 Dec 2011 17:16:22 -
@@ -298,17 +298,19 @@ pci_attach_hook(struct device *parent, s
break;
}
 
-   /*
-* Don't enable MSI on a HyperTransport bus.  In order to
-* determine that bus 0 is a HyperTransport bus, we look at
-* device 24 function 0, which is the HyperTransport
-* host/primary interface integrated on most 64-bit AMD CPUs.
-* If that device has a HyperTransport capability, bus 0 must
-* be a HyperTransport bus and we disable MSI.
-*/
-   tag = pci_make_tag(pc, 0, 24, 0);
-   if (pci_get_capability(pc, tag, PCI_CAP_HT, NULL, NULL))
-   pba-pba_flags = ~PCI_FLAGS_MSI_ENABLED;
+   if (pci_mode != 2) {
+   /*
+* Don't enable MSI on a HyperTransport bus.  In order to
+* determine that bus 0 is a HyperTransport bus, we look at
+* device 24 function 0, which is the HyperTransport
+* host/primary interface integrated on most 64-bit AMD CPUs.
+* If that device has a HyperTransport capability, bus 0 must
+* be a HyperTransport bus and we disable MSI.
+*/
+   tag = pci_make_tag(pc, 0, 24, 0);
+   if (pci_get_capability(pc, tag, PCI_CAP_HT, NULL, NULL))
+   pba-pba_flags = ~PCI_FLAGS_MSI_ENABLED;
+   }
 }
 
 int
@@ -318,7 +320,7 @@ pci_bus_maxdevs(pci_chipset_tag_t pc, in
/*
 * Bus number is irrelevant.  If Configuration Mechanism 2 is in
 * use, can only have devices 0-15 on any bus.  If Configuration
-* Mechanism 1 is in use, can have devices 0-32 (i.e. the `normal'
+* Mechanism 1 is in use, can have devices 0-31 (i.e. the `normal'
 * range).
 */
if (pci_mode == 2)

Re: kernel/6554: IPSEC + GRE + carp crash and lockup

[Miod Vallat]

The following reply was made to PR kernel/6554; it has been noted by GNATS.

From: Miod Vallat m...@online.fr
To: supp...@rayservers.com
Cc: gn...@openbsd.org
Subject: Re: kernel/6554: IPSEC + GRE + carp crash and lockup
Date: Tue, 22 Feb 2011 17:43:15 +

 Does the following diff help?
 
 Index: if_gre.c
 ===
 RCS file: /cvs/src/sys/net/if_gre.c,v
 retrieving revision 1.52
 diff -u -p -r1.52 if_gre.c
 --- if_gre.c   23 Sep 2010 11:34:50 -  1.52
 +++ if_gre.c   22 Feb 2011 17:41:54 -
 @@ -415,6 +415,15 @@ gre_output(struct ifnet *ifp, struct mbu
goto end;
}
  
 +  if (m-m_len  sizeof(struct greip)) {
 +  m = m_pullup(m, sizeof(struct ip));
 +  if (m == NULL) {
 +  IF_DROP(ifp-if_snd);
 +  error = ENOBUFS;
 +  goto end;
 +  }
 +  }
 +
gh = mtod(m, struct greip *);
if (sc-g_proto == IPPROTO_GRE) {
/* We don't support any GRE flags for now */

Re: sed: Segmentation fault on OpenBSD-4.8-stable

[Miod Vallat]

 # sed -e c\\
 Segmentation fault (core dumped)

This has been fixed, post release.

Re: bug on OpenBSD 4.8 Install with a SparcStation 5

[Miod Vallat]

 Problem :
 When netbooting host (where the system should be installed) freeze after
 getting root and swap via nfs

[...]

 *Created swap :*
 *
 *
 using these command :
 
 r...@freyr:/exports# dd if=/dev/zero of=swap bs=1M count=256
 256+0 records in
 256+0 records out
 268435456 bytes (268 MB) copied, 15.2499 s, 17.6 MB/s
 r...@freyr:/exports# mkswap swap
 Setting up swapspace version 1, size = 268431 kB
 no label, UUID=b510c091-3cf2-4cbb-9071-a67f0fc82887

That `mkswap' step is not necessary.

[...]

 Got the error when booting on sparc :
 Warning : /dev/console does not exist
 
 After Googling I tought it was beacause /exports/sparc/dev was not populated

This is correct.

 I couldn't use the original MAKEDEV from OpenBSD because I got these errors
 :
 
 r...@freyr:/exports/sparc/dev# ./MAKEDEV.bck
 ./MAKEDEV.bck: 171: RMlist[0]=rm -f: not found
 ./MAKEDEV.bck: 557: Bad substitution
 
 I instead use the MAKEDEV from ubuntu using command :
 
 r...@freyr:/exports/sparc/dev# ./MAKEDEV generic
 
 Seemed to work fine created a lot of dev !!!

But none of them are correct. You might want to run the OpenBSD MAKEDEV
with ksh (look for a `pdksh' package for your host system), as in:
# cd /exports/sparc/dev  /path/to/ksh ./MAKEDEV all

Miod

Re: amd64/6480: Activating bluetooth causes repeatable kernel panic on amd64 snapshots

[Miod Vallat]

 Since up works now I found out that btconfig ubt* down does not. Am I
 supposed to file a new PR or just send the usual info?

Define `does not'. What happens?

Miod

Re: amd64/6480: Activating bluetooth causes repeatable kernel panic on amd64 snapshots

[Miod Vallat]

 http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yesnumbers=6480
 
 Concerning PR 6480 I need to add: it's caused by the btconfig ubt* up
 commmand, at least on my machine. And it happens on i386, too.

Please try the following diff.

Miod

Index: uhci.c
===
RCS file: /cvs/src/sys/dev/usb/uhci.c,v
retrieving revision 1.84
diff -u -p -r1.84 uhci.c
--- uhci.c  23 Oct 2010 15:42:09 -  1.84
+++ uhci.c  18 Nov 2010 19:10:13 -
@@ -2757,7 +2757,9 @@ uhci_device_setintr(uhci_softc_t *sc, st
 
upipe-u.intr.npoll = npoll;
upipe-u.intr.qhs =
-   malloc(npoll * sizeof(uhci_soft_qh_t *), M_USBHC, M_WAITOK);
+   malloc(npoll * sizeof(uhci_soft_qh_t *), M_USBHC, M_NOWAIT);
+   if (upipe-u.intr.qhs == NULL)
+   return (USBD_NOMEM);
 
/*
 * Figure out which offset in the schedule that has most

Re: amd64/6480: Activating bluetooth causes repeatable kernel panic on amd64 snapshots

[Miod Vallat]

 I believe somebody passed that around on a list before, but there are
 other malloc bugs in bt code.

Oh, probably. Still, this uhci diff looks like the way to go to me (only
_u_hci needs to malloc() after open_pipe() has been called, and
open_pipe() is supposed to not sleep and allowed to report USBD_NOMEM).
This is a genuine usb stack bug.

Miod

Re: your mail

[Miod Vallat]

 Dear OpenBSD-Team,
 
 I have your 4.7 distribution installed. While I tried to install Eclipse from 
 your ports collection, I noticed a domain name resolving problem with the 
 xulrunner part of the installation. Deutsche Telekom resolvs the query
 for http://openbsddistfiles.org/martynas/mozilla/xulrunner/, which is listed 
 in the corresponding make file, to 69.43.160.175, which is a malware domain
 (reverse lookup). I used whois.domaintools.com to verify that.
   
 PCR
 

Thanks for pointing this to our attention. There isn't much we can do to
fix the domain hijacking, but you can use openbsddistfiles.com instead
of openbsddistfiles.org to fetch the proper files.

Sorry for the inconvenience.

Miod

Re: kernel/6465: panic: ifconfig tsec1 down during a special? case

[Miod Vallat]

The following reply was made to PR kernel/6465; it has been noted by GNATS.

From: Miod Vallat m...@online.fr
To: James Boyle james.bo...@canonic.net
Cc: gn...@openbsd.org
Subject: Re: kernel/6465: panic: ifconfig tsec1 down during a special? case
Date: Tue, 14 Sep 2010 22:40:23 +

 Does the following diff help?
 
 Index: if_tsec.c
 ===
 RCS file: /cvs/src/sys/arch/socppc/dev/if_tsec.c,v
 retrieving revision 1.28
 diff -u -p -r1.28 if_tsec.c
 --- if_tsec.c  21 Dec 2009 19:58:57 -  1.28
 +++ if_tsec.c  14 Sep 2010 22:39:52 -
 @@ -271,6 +271,8 @@ struct tsec_softc {
int sc_rx_cons;
  
struct timeout  sc_tick;
 +
 +  int sc_dma_stopped;
  };
  
  #define DEVNAME(_s)   ((_s)-sc_dev.dv_xname)
 @@ -1001,6 +1003,7 @@ tsec_up(struct tsec_softc *sc)
ecntrl = tsec_read(sc, TSEC_ECNTRL);
tsec_write(sc, TSEC_ECNTRL, ecntrl | TSEC_ECNTRL_R100M);
  
 +  sc-sc_dma_stopped = 0;
dmactrl = tsec_read(sc, TSEC_DMACTRL);
dmactrl |= TSEC_DMACTRL_TDSEN;
dmactrl |= TSEC_DMACTRL_TBDSEN;
 @@ -1201,28 +1204,33 @@ tsec_stop_dma(struct tsec_softc *sc)
uint32_t dmactrl, ievent;
int n;
  
 -  /* Stop DMA. */
 -  dmactrl = tsec_read(sc, TSEC_DMACTRL);
 -  dmactrl |= TSEC_DMACTRL_GTS;
 -  tsec_write(sc, TSEC_DMACTRL, dmactrl);
 +  if (sc-sc_dma_stopped == 0) {
 +  /* Stop DMA. */
 +  dmactrl = tsec_read(sc, TSEC_DMACTRL);
 +  dmactrl |= TSEC_DMACTRL_GTS;
 +  tsec_write(sc, TSEC_DMACTRL, dmactrl);
 +
 +  for (n = 0; n  100; n++) {
 +  ievent = tsec_read(sc, TSEC_IEVENT);
 +  if (ievent  TSEC_IEVENT_GTSC)
 +  break;
 +  }
 +  KASSERT(n != 100);
  
 -  for (n = 0; n  100; n++) {
 -  ievent = tsec_read(sc, TSEC_IEVENT);
 -  if (ievent  TSEC_IEVENT_GTSC)
 -  break;
 +  dmactrl = tsec_read(sc, TSEC_DMACTRL);
 +  dmactrl |= TSEC_DMACTRL_GRS;
 +  tsec_write(sc, TSEC_DMACTRL, dmactrl);
 +
 +  for (n = 0; n  100; n++) {
 +  ievent = tsec_read(sc, TSEC_IEVENT);
 +  if (ievent  TSEC_IEVENT_GRSC)
 +  break;
 +  }
 +  KASSERT(n != 100);
}
 -  KASSERT(n != 100);
  
 -  dmactrl = tsec_read(sc, TSEC_DMACTRL);
 -  dmactrl |= TSEC_DMACTRL_GRS;
 -  tsec_write(sc, TSEC_DMACTRL, dmactrl);
 -
 -  for (n = 0; n  100; n++) {
 -  ievent = tsec_read(sc, TSEC_IEVENT);
 -  if (ievent  TSEC_IEVENT_GRSC)
 -  break;
 -  }
 -  KASSERT(n != 100);
 +  sc-sc_dma_stopped = 1;
 +}
  }
  
  struct tsec_dmamem *