Re: -current tar(1) breakage

2021-03-29 Thread RVP

On Tue, 30 Mar 2021, Joerg Sonnenberger wrote:

This is a bug in the FUSE layer. It should really sanitize the input and 
not force it on any consumer.




Returning 0 for some of the fields, esp. f_iosize--which is what's
the cause of bug #56083--is not wrong, I think. According to statvfs(5):

struct statvfs {
...
unsigned long f_iosize;
...
};

Returning a -1 for that field is probably not right, even if that's what
libarchive seems to expect. And, POSIX doesn't say anythng about these
implementation-specific fields.

-RVP


daily CVS update output

2021-03-29 Thread NetBSD source update


Updating src tree:
P src/external/bsd/libarchive/dist/libarchive/archive_read_disk_posix.c
U src/external/cddl/osnet/dev/cyclic/mips/cyclic_machdep.c
U src/external/cddl/osnet/dev/dtrace/mips/dtrace_asm.S
U src/external/cddl/osnet/dev/dtrace/mips/dtrace_isa.c
U src/external/cddl/osnet/dev/dtrace/mips/dtrace_subr.c
U src/external/cddl/osnet/dev/dtrace/mips/regset.h
U src/external/cddl/osnet/dev/fbt/mips/fbt_isa.c
U src/external/cddl/osnet/dev/fbt/mips/fbt_isa.h
P src/external/cddl/osnet/lib/libdtrace/Makefile
P src/share/mk/bsd.kmodule.mk
P src/sys/arch/evbppc/conf/Makefile.virtex.inc
P src/sys/arch/evbppc/conf/Makefile.walnut.inc
P src/sys/arch/evbppc/conf/files.obs405
P src/sys/arch/evbppc/conf/files.walnut
P src/sys/arch/evbppc/evbppc/evbppc_machdep.c
P src/sys/arch/evbppc/explora/machdep.c
P src/sys/arch/evbppc/obs405/obs200_autoconf.c
P src/sys/arch/evbppc/obs405/obs200_machdep.c
P src/sys/arch/evbppc/obs405/obs266_autoconf.c
P src/sys/arch/evbppc/obs405/obs266_machdep.c
cvs update: `src/sys/arch/evbppc/obs405/obs405_autoconf.c' is no longer in the 
repository
cvs update: `src/sys/arch/evbppc/obs405/obs405_machdep.c' is no longer in the 
repository
P src/sys/arch/evbppc/obs405/obs600_autoconf.c
P src/sys/arch/evbppc/obs405/obs600_machdep.c
P src/sys/arch/evbppc/virtex/autoconf.c
P src/sys/arch/evbppc/virtex/consinit.c
P src/sys/arch/evbppc/virtex/design_gsrd2.c
P src/sys/arch/evbppc/virtex/machdep.c
P src/sys/arch/evbppc/virtex/dev/if_temac.c
P src/sys/arch/evbppc/virtex/dev/tft_ll.c
P src/sys/arch/evbppc/walnut/autoconf.c
P src/sys/arch/evbppc/walnut/consinit.c
P src/sys/arch/evbppc/walnut/machdep.c
cvs update: `src/sys/arch/evbppc/walnut/walnut_start.S' is no longer in the 
repository
cvs update: `src/sys/arch/evbppc/walnut/pci/pchb.c' is no longer in the 
repository
P src/sys/arch/mips/include/db_machdep.h
P src/sys/arch/mips/mips/mips_stacktrace.c
P src/sys/arch/mips/mips/trap.c
P src/sys/arch/powerpc/ibm4xx/cpu.c
P src/sys/arch/powerpc/ibm4xx/ibm4xx_autoconf.c
P src/sys/arch/powerpc/ibm4xx/ibm4xx_machdep.c
P src/sys/arch/powerpc/ibm4xx/dev/emacreg.h
P src/sys/arch/powerpc/ibm4xx/dev/if_emac.c
P src/sys/arch/powerpc/ibm4xx/openbios/locore.S
P src/sys/arch/powerpc/ibm4xx/openbios/openbios.c
P src/sys/arch/powerpc/include/ibm4xx/cpu.h
P src/sys/arch/powerpc/include/ibm4xx/openbios.h
P src/tests/usr.bin/xlint/lint1/d_c99_init.c
P src/tests/usr.bin/xlint/lint1/d_c99_init.exp
P src/tests/usr.bin/xlint/lint1/msg_181.c
U src/tests/usr.bin/xlint/lint1/msg_181.exp
U src/tests/usr.bin/xlint/lint1/msg_238.c
U src/tests/usr.bin/xlint/lint1/msg_238.exp
P src/usr.bin/xlint/lint1/cgram.y
P src/usr.bin/xlint/lint1/init.c

Updating xsrc tree:


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  41323270 Mar 30 03:03 ls-lRA.gz


Re: -current tar(1) breakage

2021-03-29 Thread Joerg Sonnenberger
On Sun, Mar 28, 2021 at 06:49:33AM +, RVP wrote:
> This might, or might not, be related. There is another bug in
> tar. It hangs when reading files on FUSE-mounted filesystems:

This is a bug in the FUSE layer. It should really sanitize the input and
not force it on any consumer.

Joerg


pkgsrc-2021Q1 branch announcement

2021-03-29 Thread Thomas Klausner
The pkgsrc developers are proud to announce the 70th quarterly release
of pkgsrc, the cross-platform packaging system.  pkgsrc is available
with more than 26,000 packages, running on 23 separate platforms; more
information on pkgsrc itself is available at https://www.pkgsrc.org/

In total, 381 packages were added, 61 packages were removed, and 2,349
package updates (to 2,064 unique packages) were processed since the
pkgsrc-2020Q4 release.  Updates include 29 R packages, 499 Python, and
332 Ruby packages.

The default Go version in pkgsrc is now 1.16.

As always, many packages have been brought up to date relative to
upstream.  For the 2021Q1 release we welcome the following
notable packages additions and changes to the pkgsrc collection:

 - cmake 3.19.7
 - Firefox 78.9.0 (as an ESR), 86.0.1
 - gdal 3.2.2
 - Go 1.15.10, 1.16.2
 - LibreOffice 7.1.1.2
 - mosquitto 2.0.9
 - Nextcloud 21.0.0
 - Node.js 12.21.0, 14.16.0
 - ocaml 4.11.2
 - openblas 0.3.10
 - owncloud 10.6.0
 - PHP 7.3.27, 7.4.16, 8.0.3
 - PostGIS 3.1.1
 - PostgreSQL 9.5.25, 9.6.21, 10.16, 11.11, 12.6, 13.2
 - pulseaudio 14.2
 - Python 3.7.10, 3.8.8, 3.9.2
 - qemu 5.2.0
 - qgis 3.16.4
 - Ruby 3.0
 - Rust 1.49.0
 - spotify-qt 3.5
 - SQLite 3.35.2
 - Syncthing 1.14.0
 - Thunderbird 78.9.0
 - tor 0.4.5.7
 - Tor Browser 10.0.12
 - vlc-3.0.12
 - WebKitGTK 2.30.6

This branch we say notable goodbyes to:

 - php 7.2
 - nodejs 8
 - go 1.14

Changes to the pkgsrc infrastructure and notes:

- Note that Firefox, Thunderbird and likely other packages with
  difficult dependencies do not build on NetBSD 8 and other systems
  with non-recent compilers.  Users who wish to run these programs are
  advised to update to NetBSD 9 or newer versions of other operating
  systems.

Instructions on using the binary package manager can be found at
https://pkgin.net, and pkgsrc itself can be retrieved from via CVS or
tar file, and also from a mirror at https://github.com/NetBSD/pkgsrc.
See https://www.netbsd.org/docs/pkgsrc/getting.html for instructions.
The branch name for the 2021Q1 branch is "pkgsrc-2021Q1".



atomic_load_relaxed panic

2021-03-29 Thread Patrick Welche
On an otherwise idle amd64 box running

  NetBSD 9.99.81 (GENERIC) #3: Fri Mar 26 17:37:48 GMT 2021

I got tantalisingly close to managing to clone the NetBSD source:

# hg clone http://anonhg.netbsd.org/src
destination directory: src
applying clone bundle from 
https://cdn.NetBSD.org/_bundles/src/77d2a2ece3a06d837da45acd0fda80086ab4113c.zstd.hg
adding changesets
adding manifests
   
adding file changes 
   
added 931876 changesets with 2425841 changes to 439702 files (+417 heads)   
   
finished applying clone bundle
searching for changes
adding changesets
adding manifests
adding file changes
adding changesets
adding manifests
adding file changes
added 14681 changesets with 130115 changes to 91055 files (+5 heads)
new changesets 26c8f37631b6:87ca3e58cbb1 (241 drafts)
280333 local changesets published
updating to branch trunk
updating [=>   ]  71400/202610 17s

(any hints on making this go faster?)

When:

[ 257027.9185592] panic: kernel diagnostic assertion "atomic_load_relaxed(> 
[ 257027.9485598] cpu2: Begin traceback...  
[ 257027.9585600] vpanic() at netbsd:vpanic+0x156   
[ 257027.9685597] __x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax
[ 257027.9785609] pmap_clear_attrs() at netbsd:pmap_clear_attrs+0x124
[ 257027.9985632] uvm_pagemarkdirty() at netbsd:uvm_pagemarkdirty+0x37b
[ 257028.0085600] uao_get() at netbsd:uao_get+0x315
[ 257028.0185597] ubc_fault() at netbsd:ubc_fault+0x16a
[ 257028.0285614] uvm_fault_internal() at netbsd:uvm_fault_internal+0x57a
[ 257028.0485613] trap() at netbsd:trap+0x5b7
[ 257028.0485613] --- trap (number 6) ---
[ 257028.0585610] copyout() at netbsd:copyout+0x33
[ 257028.0685603] uiomove() at netbsd:uiomove+0x80
[ 257028.0785605] ubc_uiomove() at netbsd:ubc_uiomove+0x157
[ 257028.0885612] tmpfs_read() at netbsd:tmpfs_read+0xbe
[ 257028.0985609] VOP_READ() at netbsd:VOP_READ+0x40
[ 257028.1185598] vn_read() at netbsd:vn_read+0x97
[ 257028.1285595] dofileread() at netbsd:dofileread+0x79
[ 257028.1385631] sys_read() at netbsd:sys_read+0x49
[ 257028.1485614] syscall() at netbsd:syscall+0x23e
[ 257028.1585616] --- syscall (number 3) ---
[ 257028.1685608] netbsd:syscall+0x23e:
[ 257028.1685608] cpu2: End traceback...

[ 257028.1785615] dumping to dev 168,2 (offset=8, size=41938679):
[ 257028.1885651] dump 9684 9683 9682 9681 9680 9679 9678 9677 9676 9675 9674 9

tip in tmux doesn't appear to be wrapped... Hopefully the dump will succeed...


Cheers,

Patrick


Re: NVMM failure

2021-03-29 Thread Chavdar Ivanov
... and after a 'system_reset' it actually booted. There was a time
when I had to sysytem_reset this particular guest 2-3 times before
succeeding, but it hasn't been happening for quite some time.

On Mon, 29 Mar 2021 at 12:03, Chavdar Ivanov  wrote:
>
> Hi,
>
> However... some of my guests refuse to play ball:
> .
> Loading Linux 4.9.0-12-amd64 ...
> Loading initial ramdisk ...
> [0.140619] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> [0.432176] Kernel panic - not syncing: IO-APIC + timer doesn't
> work!  Boot with apic=debug and send a report.  Then try booting with
> the 'noapic' option.
> [0.432176]
> [0.434698] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.9.0-12-amd64 #1 Debian 4.9.210-1+deb9u1
> [0.436125] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
> [0.437990]   99136f6e 
> b55ec0633e60
> [0.439282]  98f82f3c 0008 b55ec0633e70
> b55ec0633e08
> [0.440574]  524e301e9d3981be 0008 b55ec0633e90
> 
> [0.441862] Call Trace:
> [0.442278]  [] ? dump_stack+0x66/0x88
> [0.443179]  [] ? panic+0xe4/0x242
> [0.443994]  [] ? setup_IO_APIC+0x7ae/0x88f
> [0.444932]  [] ? clear_IO_APIC_pin+0x64/0x130
> [0.445910]  [] ? apic_bsp_setup+0xa2/0xaf
> [0.446834]  [] ? native_smp_prepare_cpus+0x26e/0x2ec
> [0.447910]  [] ? kernel_init_freeable+0xa4/0x1ec
> [0.448930]  [] ? rest_init+0x80/0x80
> [0.449783]  [] ? kernel_init+0xa/0x100
> [0.450667]  [] ? ret_from_fork+0x57/0x70
> [0.451702] ---[ end Kernel panic - not syncing: IO-APIC + timer
> doesn't work!  Boot with apic=debug and send a report.  Then try
> booting with the 'noapic' option.
> [0.451702]
>
>
> This is from a Debian machine, in use for a very long time... The
> FreeBSD 12 guest I tried is still working fine.
>
>
> Chavdar
>
> On Mon, 29 Mar 2021 at 10:57, Chavdar Ivanov  wrote:
> >
> > Hi,
> >
> > One of the patches needs patching... I thought nvmm was upstreamed and
> > we didn't need the patches for it?
> >
> > Index: patch-target_i386_nvmm_all.c
> > ===
> > RCS file: 
> > /cvsroot/pkgsrc/emulators/qemu/patches/patch-target_i386_nvmm_all.c,v
> > retrieving revision 1.1
> > diff -u -r1.1 patch-target_i386_nvmm_all.c
> > --- patch-target_i386_nvmm_all.c6 Mar 2021 11:19:34 -   1.1
> > +++ patch-target_i386_nvmm_all.c29 Mar 2021 09:55:19 -
> > @@ -1166,10 +1166,6 @@
> >  +error_report("NVMM: Unable to fetch capability, error=%d", errno);
> >  +return -err;
> >  +}
> > -+if (qemu_mach.cap.version != 1) {
> > -+error_report("NVMM: Unsupported version %u", 
> > qemu_mach.cap.version);
> > -+return -EPROGMISMATCH;
> > -+}
> >  +if (qemu_mach.cap.state_size != sizeof(struct nvmm_x64_state)) {
> >  +error_report("NVMM: Wrong state size %u", 
> > qemu_mach.cap.state_size);
> >  +return -EPROGMISMATCH;
> >
> > On Mon, 29 Mar 2021 at 01:32, Chavdar Ivanov  wrote:
> > >
> > > Hi,
> > >
> > > Have I missed something regarding nvmm? Since today's -current update,
> > > I am getting
> > >
> > > qemu-system-x86_64: -accel nvmm: NVMM: Unsupported version 2
> > > qemu-system-x86_64: -accel nvmm: failed to initialize nvmm: Program
> > > version wrong
> > >
> > > when I try to run any of my usual nvmm-accelerated guests (they work
> > > without nvmm).
> > >
> > > I updated qemu to the latest available version - qemu-5.2.0nb4 - and
> > > even ran the suggested atf tests:
> > >
> > > ➜  libnvmm atf-run | atf-report
> > > Tests root: /usr/tests/lib/libnvmm
> > >
> > > t_io_assist (1/2): 1 test cases
> > > io_assist: [0.013472s] Passed.
> > > [0.013606s]
> > >
> > > t_mem_assist (2/2): 1 test cases
> > > mem_assist: [0.012884s] Passed.
> > > [0.013004s]
> > >
> > > Summary for 2 test programs:
> > > 2 passed test cases.
> > > 0 failed test cases.
> > > 0 expected failed test cases.
> > > 0 skipped test cases.
> > >
> > > Chavdar
> > >
> > > --
> > > 
> >
> >
> >
> > --
> > 
>
>
>
> --
> 



-- 



Re: NVMM failure

2021-03-29 Thread Chavdar Ivanov
Hi,

However... some of my guests refuse to play ball:
.
Loading Linux 4.9.0-12-amd64 ...
Loading initial ramdisk ...
[0.140619] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[0.432176] Kernel panic - not syncing: IO-APIC + timer doesn't
work!  Boot with apic=debug and send a report.  Then try booting with
the 'noapic' option.
[0.432176]
[0.434698] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.9.0-12-amd64 #1 Debian 4.9.210-1+deb9u1
[0.436125] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[0.437990]   99136f6e 
b55ec0633e60
[0.439282]  98f82f3c 0008 b55ec0633e70
b55ec0633e08
[0.440574]  524e301e9d3981be 0008 b55ec0633e90

[0.441862] Call Trace:
[0.442278]  [] ? dump_stack+0x66/0x88
[0.443179]  [] ? panic+0xe4/0x242
[0.443994]  [] ? setup_IO_APIC+0x7ae/0x88f
[0.444932]  [] ? clear_IO_APIC_pin+0x64/0x130
[0.445910]  [] ? apic_bsp_setup+0xa2/0xaf
[0.446834]  [] ? native_smp_prepare_cpus+0x26e/0x2ec
[0.447910]  [] ? kernel_init_freeable+0xa4/0x1ec
[0.448930]  [] ? rest_init+0x80/0x80
[0.449783]  [] ? kernel_init+0xa/0x100
[0.450667]  [] ? ret_from_fork+0x57/0x70
[0.451702] ---[ end Kernel panic - not syncing: IO-APIC + timer
doesn't work!  Boot with apic=debug and send a report.  Then try
booting with the 'noapic' option.
[0.451702]


This is from a Debian machine, in use for a very long time... The
FreeBSD 12 guest I tried is still working fine.


Chavdar

On Mon, 29 Mar 2021 at 10:57, Chavdar Ivanov  wrote:
>
> Hi,
>
> One of the patches needs patching... I thought nvmm was upstreamed and
> we didn't need the patches for it?
>
> Index: patch-target_i386_nvmm_all.c
> ===
> RCS file: 
> /cvsroot/pkgsrc/emulators/qemu/patches/patch-target_i386_nvmm_all.c,v
> retrieving revision 1.1
> diff -u -r1.1 patch-target_i386_nvmm_all.c
> --- patch-target_i386_nvmm_all.c6 Mar 2021 11:19:34 -   1.1
> +++ patch-target_i386_nvmm_all.c29 Mar 2021 09:55:19 -
> @@ -1166,10 +1166,6 @@
>  +error_report("NVMM: Unable to fetch capability, error=%d", errno);
>  +return -err;
>  +}
> -+if (qemu_mach.cap.version != 1) {
> -+error_report("NVMM: Unsupported version %u", qemu_mach.cap.version);
> -+return -EPROGMISMATCH;
> -+}
>  +if (qemu_mach.cap.state_size != sizeof(struct nvmm_x64_state)) {
>  +error_report("NVMM: Wrong state size %u", qemu_mach.cap.state_size);
>  +return -EPROGMISMATCH;
>
> On Mon, 29 Mar 2021 at 01:32, Chavdar Ivanov  wrote:
> >
> > Hi,
> >
> > Have I missed something regarding nvmm? Since today's -current update,
> > I am getting
> >
> > qemu-system-x86_64: -accel nvmm: NVMM: Unsupported version 2
> > qemu-system-x86_64: -accel nvmm: failed to initialize nvmm: Program
> > version wrong
> >
> > when I try to run any of my usual nvmm-accelerated guests (they work
> > without nvmm).
> >
> > I updated qemu to the latest available version - qemu-5.2.0nb4 - and
> > even ran the suggested atf tests:
> >
> > ➜  libnvmm atf-run | atf-report
> > Tests root: /usr/tests/lib/libnvmm
> >
> > t_io_assist (1/2): 1 test cases
> > io_assist: [0.013472s] Passed.
> > [0.013606s]
> >
> > t_mem_assist (2/2): 1 test cases
> > mem_assist: [0.012884s] Passed.
> > [0.013004s]
> >
> > Summary for 2 test programs:
> > 2 passed test cases.
> > 0 failed test cases.
> > 0 expected failed test cases.
> > 0 skipped test cases.
> >
> > Chavdar
> >
> > --
> > 
>
>
>
> --
> 



-- 



Re: NVMM failure

2021-03-29 Thread Chavdar Ivanov
Hi,

One of the patches needs patching... I thought nvmm was upstreamed and
we didn't need the patches for it?

Index: patch-target_i386_nvmm_all.c
===
RCS file: /cvsroot/pkgsrc/emulators/qemu/patches/patch-target_i386_nvmm_all.c,v
retrieving revision 1.1
diff -u -r1.1 patch-target_i386_nvmm_all.c
--- patch-target_i386_nvmm_all.c6 Mar 2021 11:19:34 -   1.1
+++ patch-target_i386_nvmm_all.c29 Mar 2021 09:55:19 -
@@ -1166,10 +1166,6 @@
 +error_report("NVMM: Unable to fetch capability, error=%d", errno);
 +return -err;
 +}
-+if (qemu_mach.cap.version != 1) {
-+error_report("NVMM: Unsupported version %u", qemu_mach.cap.version);
-+return -EPROGMISMATCH;
-+}
 +if (qemu_mach.cap.state_size != sizeof(struct nvmm_x64_state)) {
 +error_report("NVMM: Wrong state size %u", qemu_mach.cap.state_size);
 +return -EPROGMISMATCH;

On Mon, 29 Mar 2021 at 01:32, Chavdar Ivanov  wrote:
>
> Hi,
>
> Have I missed something regarding nvmm? Since today's -current update,
> I am getting
>
> qemu-system-x86_64: -accel nvmm: NVMM: Unsupported version 2
> qemu-system-x86_64: -accel nvmm: failed to initialize nvmm: Program
> version wrong
>
> when I try to run any of my usual nvmm-accelerated guests (they work
> without nvmm).
>
> I updated qemu to the latest available version - qemu-5.2.0nb4 - and
> even ran the suggested atf tests:
>
> ➜  libnvmm atf-run | atf-report
> Tests root: /usr/tests/lib/libnvmm
>
> t_io_assist (1/2): 1 test cases
> io_assist: [0.013472s] Passed.
> [0.013606s]
>
> t_mem_assist (2/2): 1 test cases
> mem_assist: [0.012884s] Passed.
> [0.013004s]
>
> Summary for 2 test programs:
> 2 passed test cases.
> 0 failed test cases.
> 0 expected failed test cases.
> 0 skipped test cases.
>
> Chavdar
>
> --
> 



--