re: port-sparc/55573: sparc testbed logs many "coprocessor instruction" messages

[matthew green <mrg%eterna.com.au@localhost>]

The following reply was made to PR port-sparc/55573; it has been noted by GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: port-sparc-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost
Subject: re: port-sparc/55573: sparc testbed logs many "coprocessor instruction" messages
Date: Fri, 14 Aug 2020 19:08:17 +1000

 > The qemu-based TNF sparc testbed has started logging large numbers of
 > kernel messages saying "coprocessor instruction", like the following:
 > =
 
 >   Starting syslogd.
 >   [  15.0167285] coprocessor instruction
 >   [  15.0167285] coprocessor instruction
 >   [  15.0167285] coprocessor instruction
 >   [  15.0167285] coprocessor instruction
 >   Mounting all file systems...
 > =
 
 > This is from:
 > =
 
 >   http://releng.netbsd.org/b5reports/sparc/2020/2020.06.22.03.16.29/test=
 .log
 > =
 
 > There seem to be no ill effects other than cluttering the console
 > output and causing confusion.
 > =
 
 > The problem started during the period of build breakage between source
 > dates 2020.06.20.02.27.55 and 2020.06.22.03.16.29.  The only sparc
 > specific commits during the period in case were:
 > =
 
 >   2020.06.21.22.16.08 christos src/crypto/external/bsd/openssl/lib/libcr=
 ypto/arch/sparc/bn.inc 1.2
 >   2020.06.21.22.16.08 christos src/crypto/external/bsd/openssl/lib/libcr=
 ypto/arch/sparc/crypto.inc 1.13
 >   2020.06.21.22.16.08 christos src/crypto/external/bsd/openssl/lib/libcr=
 ypto/arch/sparc/modes.inc 1.4
 > =
 
 > Is openssl perhaps trying to use some kind of crypto coprocessor that
 > is not supported by qemu, and successfully falling back to another
 > method?  If that's the case, perhaps the message should simply be
 > disabled.
 
 this is odd.  i had a look, there doesnt seem to be
 any co-pro functions called here.  (i actually did
 not recall they existed, and had to read the manual.)
 
 i'll see about trying to reproduce it, expand the
 message to be more verbose about what proc/%pc etc.
 
 
 .mrg.