Re: config(1) warning for amd64 release
On Sat, 25 Jan 2020, Paul Goyette wrote: With sources updated as of updated Sat Jan 25 16:18:15 UTC 2020 $SRC/sys/dev/files.audio:3: warning: The use of `defopt' is deprecated I just saw jmcneill's commit to fix this - thanks! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
config(1) warning for amd64 release
++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ -- Forwarded message -- Date: Sat, 25 Jan 2020 10:53:45 -0800 (PST) From: Paul Goyette To: p...@whooppee.com Subject: ../BUILD -Z3 -TurdJ1 -N2 -S src -e VPS1 -e TEST With sources updated as of updated Sat Jan 25 16:18:15 UTC 2020 $SRC/sys/dev/files.audio:3: warning: The use of `defopt' is deprecated
Failure with ``build.sh -V USE_PIGZGZIP=yes install-image''
On Mon, 6 Jan 2020, Paul Goyette wrote: Failure to build install-image - sources current as of 2020-01-06 at 13:03:23 UTC Creating rootfs... chmod +r work/var/spool/ftp/hidden /build/netbsd-local/tools/x86_64/amd64/bin/nbmakefs -M 1519386624 -m 1519386624 -B 1234 -F work.spec -N work/etc -o bsize=16384,fsize=2048,density=8192 work.rootfs work nbmakefs: `work' size of 1994735616 is larger than the maxsize of 1519386624. *** Failed target: imgroot.fs This seems to be a repeatable failure. Running without specifying USE_PIGZGZIP works correctly. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
[no subject]
Failure to build install-image - sources current as of 2020-01-06 at 13:03:23 UTC Creating rootfs... chmod +r work/var/spool/ftp/hidden /build/netbsd-local/tools/x86_64/amd64/bin/nbmakefs -M 1519386624 -m 1519386624 -B 1234 -F work.spec -N work/etc -o bsize=16384,fsize=2048,density=8192 work.rootfs work nbmakefs: `work' size of 1994735616 is larger than the maxsize of 1519386624. *** Failed target: imgroot.fs ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: How to make XZ_SETS compress using multiple threads?
On Sun, 5 Jan 2020, Martin Husemann wrote: On Sun, Jan 05, 2020 at 05:34:51AM -0800, Paul Goyette wrote: I see that we have an XZ_ARGS variable which we can force to define with ``-V XZ_ARGS=-T6'' and that appears that it will add the "-T6" argument when invoking xz to build sets. ... which won't help as the tools xz version is not threaded. Ah, I see. Thanks. Per discussion on IRC I will investigate using pigz ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
How to make XZ_SETS compress using multiple threads?
I see that we have an XZ_ARGS variable which we can force to define with ``-V XZ_ARGS=-T6'' and that appears that it will add the "-T6" argument when invoking xz to build sets. However, this would break the evbmips Makefile, which already uses XZ_ARGS to conditionally set several other flags. Is there something equivalent to XZ_ARGS which can be set by a user without interfering with the existing build mechanisms? ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: 9.99.32 panic
Hmmm, I'm running X on amd64-9.99.32 built from sources that were updated just a couple hours ago, without any problem. I've got a nouveau graphics card (CTX 1050Ti) if it matters. I'm not using xfce, just plain xdm and fvwm On Wed, 1 Jan 2020, Chavdar Ivanov wrote: Hi, I get: ... #0 0x80224245 in cpu_reboot () #1 0x807b9723 in db_reboot_cmd () #2 0x807b9f3b in db_command () #3 0x807ba2a6 in db_command_loop () #4 0x807bdc2a in db_trap () #5 0x80220b15 in kdb_trap () #6 0x80225c86 in trap () #7 0x8021ed63 in alltraps () #8 0x8021f57d in breakpoint () #9 0x80a33270 in vpanic () #10 0x80e79e33 in kern_assert () #11 0x809ae062 in uvm_pageactivate () #12 0x809947a2 in amap_cow_now () #13 0x809a8d1e in uvmspace_fork () #14 0x8099eea9 in uvm_proc_fork () #15 0x809d9e8b in fork1 () #16 0x809daa12 in sys_fork () #17 0x80254d49 in syscall () #18 0x802096bd in handle_syscall () on uname -a NetBSD marge.lorien.lan 9.99.32 NetBSD 9.99.32 (GENERIC) #13: Wed Jan 1 12:31:34 GMT 2020 sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 when I try to startxfce4. Normal startx works, as well as xrandr to get me to the right resolution under VirtualBox (with client additions 6.1); gdm also starts OK and subsequently the mate session works. Chavdar -- !DSPAM:5e0cdbd0269651875828750! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 build failure
.c,v 1.539 2019.12.31.12.27.50 jmcneill src/sys/dev/acpi/acpi.c,v 1.282 2019.12.31.12.27.50 jmcneill src/sys/dev/acpi/acpi_resource.c,v 1.39 2019.12.31.12.27.50 jmcneill src/sys/dev/acpi/acpivar.h,v 1.79 2019.12.31.12.40.27 ad src/sys/arch/hppa/hppa/pmap.c,v 1.102 2019.12.31.12.40.27 ad src/sys/arch/x86/x86/pmap.c,v 1.349 2019.12.31.12.40.27 ad src/sys/miscfs/genfs/genfs_io.c,v 1.82 2019.12.31.12.40.27 ad src/sys/rump/librump/rumpkern/vm.c,v 1.178 2019.12.31.12.40.27 ad src/sys/uvm/uvm_page.c,v 1.218 2019.12.31.12.40.27 ad src/sys/uvm/uvm_page.h,v 1.91 2019.12.31.12.40.27 ad src/sys/uvm/uvm_pdaemon.c,v 1.120 2019.12.31.12.40.27 ad src/sys/uvm/uvm_pdpolicy_clock.c,v 1.26 2019.12.31.12.40.27 ad src/sys/uvm/uvm_pdpolicy_clockpro.c,v 1.21 2019.12.31.13.07.09 ad src/external/cddl/osnet/dist/uts/common/fs/zfs/arc.c,v 1.18 2019.12.31.13.07.09 ad src/sys/arch/alpha/alpha/machdep.c,v 1.357 2019.12.31.13.07.09 ad src/sys/arch/atari/atari/machdep.c,v 1.182 2019.12.31.13.07.10 ad src/sys/arch/cesfic/cesfic/machdep.c,v 1.70 2019.12.31.13.07.10 ad src/sys/arch/emips/emips/machdep.c,v 1.15 2019.12.31.13.07.10 ad src/sys/arch/evbppc/explora/machdep.c,v 1.39 2019.12.31.13.07.10 ad src/sys/arch/evbppc/virtex/machdep.c,v 1.24 2019.12.31.13.07.10 ad src/sys/arch/evbppc/walnut/machdep.c,v 1.58 2019.12.31.13.07.10 ad src/sys/arch/ews4800mips/ews4800mips/machdep.c,v 1.30 2019.12.31.13.07.10 ad src/sys/arch/hp300/hp300/machdep.c,v 1.232 2019.12.31.13.07.10 ad src/sys/arch/hppa/hppa/machdep.c,v 1.12 2019.12.31.13.07.10 ad src/sys/arch/luna68k/luna68k/machdep.c,v 1.105 2019.12.31.13.07.11 ad src/sys/arch/mac68k/mac68k/machdep.c,v 1.357 2019.12.31.13.07.11 ad src/sys/arch/mips/mips/cpu_subr.c,v 1.44 2019.12.31.13.07.11 ad src/sys/arch/mvme68k/mvme68k/machdep.c,v 1.157 2019.12.31.13.07.11 ad src/sys/arch/news68k/news68k/machdep.c,v 1.106 2019.12.31.13.07.11 ad src/sys/arch/next68k/next68k/machdep.c,v 1.114 2019.12.31.13.07.11 ad src/sys/arch/powerpc/booke/booke_machdep.c,v 1.29 2019.12.31.13.07.11 ad src/sys/arch/powerpc/ibm4xx/ibm4xx_machdep.c,v 1.28 2019.12.31.13.07.11 ad src/sys/arch/powerpc/oea/oea_machdep.c,v 1.78 2019.12.31.13.07.12 ad src/sys/arch/riscv/riscv/riscv_machdep.c,v 1.8 2019.12.31.13.07.12 ad src/sys/arch/sgimips/sgimips/machdep.c,v 1.149 2019.12.31.13.07.12 ad src/sys/arch/sh3/sh3/sh3_machdep.c,v 1.109 2019.12.31.13.07.12 ad src/sys/arch/sparc/sparc/machdep.c,v 1.333 2019.12.31.13.07.12 ad src/sys/arch/sparc64/sparc64/machdep.c,v 1.297 2019.12.31.13.07.12 ad src/sys/arch/sun2/sun2/machdep.c,v 1.80 2019.12.31.13.07.12 ad src/sys/arch/sun3/sun3/machdep.c,v 1.211 2019.12.31.13.07.12 ad src/sys/arch/sun3/sun3x/machdep.c,v 1.138 2019.12.31.13.07.12 ad src/sys/arch/vax/vax/machdep.c,v 1.195 2019.12.31.13.07.13 ad src/sys/arch/x68k/x68k/machdep.c,v 1.202 2019.12.31.13.07.13 ad src/sys/compat/linux/common/linux_misc.c,v 1.247 2019.12.31.13.07.13 ad src/sys/compat/linux32/common/linux32_sysinfo.c,v 1.10 2019.12.31.13.07.13 ad src/sys/dev/ccd.c,v 1.183 2019.12.31.13.07.13 ad src/sys/fs/tmpfs/tmpfs_mem.c,v 1.12 2019.12.31.13.07.13 ad src/sys/kern/init_main.c,v 1.514 2019.12.31.13.07.13 ad src/sys/kern/kern_module.c,v 1.143 2019.12.31.13.07.13 ad src/sys/kern/kern_proc.c,v 1.239 2019.12.31.13.07.13 ad src/sys/kern/vfs_bio.c,v 1.286 2019.12.31.13.07.13 ad src/sys/miscfs/procfs/procfs_linux.c,v 1.79 2019.12.31.13.07.13 ad src/sys/rump/librump/rumpkern/vm.c,v 1.179 2019.12.31.13.07.13 ad src/sys/ufs/chfs/chfs_subr.c,v 1.11 2019.12.31.13.07.14 ad src/sys/ufs/lfs/lfs_bio.c,v 1.144 2019.12.31.13.07.14 ad src/sys/uvm/uvm_extern.h,v 1.217 2019.12.31.13.07.14 ad src/sys/uvm/uvm_glue.c,v 1.174 2019.12.31.13.07.14 ad src/sys/uvm/uvm_meter.c,v 1.73 2019.12.31.13.07.14 ad src/sys/uvm/uvm_page.c,v 1.219 2019.12.31.13.07.14 ad src/sys/uvm/uvm_pdaemon.c,v 1.121 2019.12.31.13.07.14 ad src/sys/uvm/uvm_pdpolicy_clock.c,v 1.27 2019.12.31.13.07.14 ad src/sys/uvm/uvm_pglist.c,v 1.79 2019.12.31.13.07.14 ad src/sys/uvm/uvm_stat.c,v 1.43 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.12.html#2019.12.31.13.07.14 !DSPAM:5e0b6508209901749451217! +--------+--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: amd64 -current build failure
On Tue, 17 Dec 2019, Chavdar Ivanov wrote: I am still getting the same errors, my CVS log is empty... You might have to run a full build. I was trying an update build which failed, but a full build seems to work. On Tue, 17 Dec 2019 at 15:12, Paul Goyette wrote: Christos just fixed the lzma stuff... On Tue, 17 Dec 2019, Chavdar Ivanov wrote: Looks like it; the lzma/bz2 undefined references still there though, 10 minutes ago. On Tue, 17 Dec 2019 at 13:18, Andrew Doran wrote: Hi, On Tue, Dec 17, 2019 at 09:49:58AM +, Chavdar Ivanov wrote: Last two days I haven't been able to build amd64 -current: ... /home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld: /home/sysbuild/amd64/destdir/usr/lib/librump.so: undefined reference to `rumpns_cpuctl_ioctl' collect2: error: ld returned 1 exit status I think I fixed that one late last night - your followup message seems to confirm. Andrew -- ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ -- !DSPAM:5df8fd1c112731575111740! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: amd64 -current build failure
Christos just fixed the lzma stuff... On Tue, 17 Dec 2019, Chavdar Ivanov wrote: Looks like it; the lzma/bz2 undefined references still there though, 10 minutes ago. On Tue, 17 Dec 2019 at 13:18, Andrew Doran wrote: Hi, On Tue, Dec 17, 2019 at 09:49:58AM +, Chavdar Ivanov wrote: Last two days I haven't been able to build amd64 -current: ... /home/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld: /home/sysbuild/amd64/destdir/usr/lib/librump.so: undefined reference to `rumpns_cpuctl_ioctl' collect2: error: ld returned 1 exit status I think I fixed that one late last night - your followup message seems to confirm. Andrew -- !DSPAM:5df8dacf79529213120201! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: New ATF test failures
OK, looks like this is fixed. With the fix I just committed, these tests now pass: # cd /usr/tests/dev/sysmon # atf-run t_swsensor | atf-report Tests root: /usr/tests/dev/sysmon t_swsensor (1/1): 5 test cases alarm_sensor: [57.065200s] Passed. entropy_interrupt_sensor: [36.167103s] Passed. entropy_polled_sensor: [68.102301s] Passed. limit_sensor: [56.831116s] Passed. simple_sensor: [35.712674s] Passed. [253.936348s] Summary for 1 test programs: 5 passed test cases. 0 failed test cases. 0 expected failed test cases. 0 skipped test cases. # atf-run t_vlan | atf-report Tests root: /usr/tests/net/if_vlan t_vlan (1/1): 14 test cases vlan_auto_follow_mtu: [16.895262s] Passed. vlan_auto_follow_mtu6: [9.539698s] Passed. vlan_basic: [31.873899s] Passed. vlan_basic6: [31.160412s] Passed. vlan_bridge: [5.104153s] Passed. vlan_bridge6: [5.430393s] Passed. vlan_configs: [4.959282s] Passed. vlan_configs6: [5.565353s] Passed. vlan_create_destroy: [5.446405s] Passed. vlan_create_destroy6: [5.899840s] Passed. vlan_multicast: [12.461551s] Passed. vlan_multicast6: [8.807345s] Passed. vlan_vlanid: [14.141529s] Passed. vlan_vlanid6: [14.487024s] Passed. [171.900011s] Summary for 1 test programs: 14 passed test cases. 0 failed test cases. 0 expected failed test cases. 0 skipped test cases. # On Sun, 15 Dec 2019, Andreas Gustafsson wrote: The following test cases are now failing on multiple testbeds: dev/sysmon/t_swsensor/alarm_sensor dev/sysmon/t_swsensor/entropy_interrupt_sensor dev/sysmon/t_swsensor/entropy_polled_sensor dev/sysmon/t_swsensor/limit_sensor dev/sysmon/t_swsensor/simple_sensor net/if_vlan/t_vlan/vlan_auto_follow_mtu net/if_vlan/t_vlan/vlan_auto_follow_mtu6 net/if_vlan/t_vlan/vlan_basic net/if_vlan/t_vlan/vlan_basic6 net/if_vlan/t_vlan/vlan_bridge net/if_vlan/t_vlan/vlan_bridge6 net/if_vlan/t_vlan/vlan_configs net/if_vlan/t_vlan/vlan_configs6 net/if_vlan/t_vlan/vlan_create_destroy net/if_vlan/t_vlan/vlan_create_destroy6 net/if_vlan/t_vlan/vlan_multicast net/if_vlan/t_vlan/vlan_multicast6 net/if_vlan/t_vlan/vlan_vlanid net/if_vlan/t_vlan/vlan_vlanid6 since these commits: 2019.12.12.22.55.20 pgoyette src/sys/kern/files.kern 1.39 2019.12.12.22.55.20 pgoyette src/sys/kern/init_main.c 1.509 2019.12.12.22.55.20 pgoyette src/sys/kern/kern_module.c 1.141 2019.12.12.22.55.20 pgoyette src/sys/kern/kern_module_hook.c 1.1 2019.12.12.22.55.20 pgoyette src/sys/rump/librump/rumpkern/Makefile.rumpkern 1.178 2019.12.12.22.55.20 pgoyette src/sys/sys/module_hook.h 1.6 2019.12.12.22.55.20 pgoyette src/sys/sys/param.h 1.624 For logs, see: http://www.gson.org/netbsd/bugs/build/amd64-baremetal/commits-2019.12.html#2019.12.12.22.55.20 -- Andreas Gustafsson, g...@gson.org !DSPAM:5df6011f137371101510858! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: New ATF test failures
Working on it. As far as I can tell, it just needs to initialize the newly-created module_hook synchronization variables. I'll commit the fix as soon as I can test it. Index: rump.c === RCS file: /cvsroot/src/sys/rump/librump/rumpkern/rump.c,v retrieving revision 1.337 diff -u -p -r1.337 rump.c --- rump.c 7 Dec 2019 14:55:58 - 1.337 +++ rump.c 15 Dec 2019 13:43:06 - @@ -52,6 +52,7 @@ __KERNEL_RCSID(0, "$NetBSD: rump.c,v 1.3 #include #include #include +#include #include #include #include @@ -412,6 +413,7 @@ rump_init(void) iostat_init(); fd_sys_init(); module_init(); + module_hook_init(); devsw_init(); pipe_init(); resource_init(); On Sun, 15 Dec 2019, Andreas Gustafsson wrote: The following test cases are now failing on multiple testbeds: dev/sysmon/t_swsensor/alarm_sensor dev/sysmon/t_swsensor/entropy_interrupt_sensor dev/sysmon/t_swsensor/entropy_polled_sensor dev/sysmon/t_swsensor/limit_sensor dev/sysmon/t_swsensor/simple_sensor net/if_vlan/t_vlan/vlan_auto_follow_mtu net/if_vlan/t_vlan/vlan_auto_follow_mtu6 net/if_vlan/t_vlan/vlan_basic net/if_vlan/t_vlan/vlan_basic6 net/if_vlan/t_vlan/vlan_bridge net/if_vlan/t_vlan/vlan_bridge6 net/if_vlan/t_vlan/vlan_configs net/if_vlan/t_vlan/vlan_configs6 net/if_vlan/t_vlan/vlan_create_destroy net/if_vlan/t_vlan/vlan_create_destroy6 net/if_vlan/t_vlan/vlan_multicast net/if_vlan/t_vlan/vlan_multicast6 net/if_vlan/t_vlan/vlan_vlanid net/if_vlan/t_vlan/vlan_vlanid6 since these commits: 2019.12.12.22.55.20 pgoyette src/sys/kern/files.kern 1.39 2019.12.12.22.55.20 pgoyette src/sys/kern/init_main.c 1.509 2019.12.12.22.55.20 pgoyette src/sys/kern/kern_module.c 1.141 2019.12.12.22.55.20 pgoyette src/sys/kern/kern_module_hook.c 1.1 2019.12.12.22.55.20 pgoyette src/sys/rump/librump/rumpkern/Makefile.rumpkern 1.178 2019.12.12.22.55.20 pgoyette src/sys/sys/module_hook.h 1.6 2019.12.12.22.55.20 pgoyette src/sys/sys/param.h 1.624 For logs, see: http://www.gson.org/netbsd/bugs/build/amd64-baremetal/commits-2019.12.html#2019.12.12.22.55.20 -- Andreas Gustafsson, g...@gson.org !DSPAM:5df6011f137371101510858! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build breakage
Working on it - expect a commit soon, as soon as my build comlpetes. On Thu, 12 Dec 2019, Andreas Gustafsson wrote: Hi all, As of source date 2019.12.12.05.00.33, the evbarm-earmv7hf build is failing with: --- kern_module.o --- /tmp/bracket/build/2019.12.12.11.47.30-evbarm-earmv7hf/src/lib/librump/../../sys/rump/../kern/kern_module.c: In function 'module_init': /tmp/bracket/build/2019.12.12.11.47.30-evbarm-earmv7hf/src/lib/librump/../../sys/rump/../kern/kern_module.c:456:20: error: implicit declaration of function 'pserialize_create'; did you mean 'sysctl_create'? [-Werror=implicit-function-declaration] module_hook_psz = pserialize_create(); ^ sysctl_create cc1: all warnings being treated as errors *** [kern_module.o] Error code 1 and the sparc build is also failing with a similar error. -- Andreas Gustafsson, g...@gson.org !DSPAM:5df265f354781187315487! ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
heads up - amd64 booting is broken
It seems that amd64 booting is broken, likely as a result of the recent addition of support for multiboot2. See [1] and [2] [1] http://mail-index.netbsd.org/source-changes-d/2019/12/10/msg011875.html [2] http://mail-index.netbsd.org/source-changes/2019/12/10/msg111777.html ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build failure
With up-to-date sources, I'm getting checkflist ===> distrib/sets === 2 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/tests/usr.bin/make/unit-tests/varmod-edge.exp ./usr/tests/usr.bin/make/unit-tests/varmod-edge.mk = end of 2 extra files === Looks like the sets lists need to be updated. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Crash with HEAD on amd64 - in setrunnable()
On Sun, 24 Nov 2019, Paul Goyette wrote: With a very current kernel, I just got this: # crash -M /var/crash/netbsd.21.core -N /netbsd.gdb Crash version 9.99.18, image version 9.99.18. System panicked: kernel diagnostic assertion "lwp_locked(l, l->l_cpu->ci_schedstate.spc_lwplock)" failed: file "/build/netbsd-local/src_ro/sys/kern/kern_synch.c", line 910 Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NVGA_RASTERCONSOLE() at 0 ?() at de890ce0af54 vpanic() at vpanic+0x181 kern_assert() at kern_assert+0x48 setrunnable() at setrunnable+0x179 lwp_start() at lwp_start+0xba do_lwp_create() at do_lwp_create+0xa1 sys__lwp_create() at sys__lwp_create+0xc1 syscall() at syscall+0x28a --- syscall (number 309) --- 45ae46: crash> (Obviously, I have a core dump, so I'll be happy to investigate further if anyone has suggestions.) Perhaps this is the "potential panic" that ad@ references in this commit log message? :) Module Name:src Committed By: ad Date: Sun Nov 24 13:23:57 UTC 2019 Modified Files: src/sys/kern: kern_lwp.c Log Message: lwp_start(): don't try to change the target CPU. Fixes potential panic in setrunnable(). Oops, experimental change that escaped. To generate a diff of this commit: cvs rdiff -u -r1.213 -r1.214 src/sys/kern/kern_lwp.c ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Crash with HEAD on amd64 - in setrunnable()
With a very current kernel, I just got this: # crash -M /var/crash/netbsd.21.core -N /netbsd.gdb Crash version 9.99.18, image version 9.99.18. System panicked: kernel diagnostic assertion "lwp_locked(l, l->l_cpu->ci_schedstate.spc_lwplock)" failed: file "/build/netbsd-local/src_ro/sys/kern/kern_synch.c", line 910 Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NVGA_RASTERCONSOLE() at 0 ?() at de890ce0af54 vpanic() at vpanic+0x181 kern_assert() at kern_assert+0x48 setrunnable() at setrunnable+0x179 lwp_start() at lwp_start+0xba do_lwp_create() at do_lwp_create+0xa1 sys__lwp_create() at sys__lwp_create+0xc1 syscall() at syscall+0x28a --- syscall (number 309) --- 45ae46: crash> (Obviously, I have a core dump, so I'll be happy to investigate further if anyone has suggestions.) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
I've confirmed that these failures occur with builds from before my most recent changes. So, as Kamil indicated (and Joerg on IRC), it ain't my fault! On Tue, 12 Nov 2019, Paul Goyette wrote: Hmmm, this might be my fault. Checking/bisecting now... On Tue, 12 Nov 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait4:thread_concurrent_signals lib/libc/sys/t_ptrace_wait4:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait6:thread_concurrent_signals lib/libc/sys/t_ptrace_wait6:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait:thread_concurrent_signals lib/libc/sys/t_ptrace_wait:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitid:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitpid:thread_concurrent_signals lib/libc/sys/t_ptrace_waitpid:trace_thread_lwpcreate_and_exit The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. Between the last successful test and the failed test, a total of 10064 revisions were committed, by the following developers: christos chs gutteridge hannken jdolecek jmcneill joerg kamil maxv mlelstv mrg msaitoh nisimura pgoyette roy sevan tnn yamaguchi Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.11.html#2019.11.11.02.40.48 !DSPAM:5dca6d0b256033292947347! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
On Tue, 12 Nov 2019, Kamil Rytarowski wrote: The problem is in ATF tests with assumptions that are no longer valid. We are working on this. The right fix is to improve the tests. Oh, good - not my fault after all! Thanks! On 12.11.2019 13:53, Paul Goyette wrote: Hmmm, this might be my fault.?? Checking/bisecting now... On Tue, 12 Nov 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait4:thread_concurrent_signals lib/libc/sys/t_ptrace_wait4:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait6:thread_concurrent_signals lib/libc/sys/t_ptrace_wait6:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait:thread_concurrent_signals lib/libc/sys/t_ptrace_wait:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitid:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitpid:thread_concurrent_signals lib/libc/sys/t_ptrace_waitpid:trace_thread_lwpcreate_and_exit The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. Between the last successful test and the failed test, a total of 10064 revisions were committed, by the following developers: christos chs gutteridge hannken jdolecek jmcneill joerg kamil maxv mlelstv mrg msaitoh nisimura pgoyette roy sevan tnn yamaguchi Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.11.html#2019.11.11.02.40.48 !DSPAM:5dca6d0b256033292947347! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)?? | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
Hmmm, this might be my fault. Checking/bisecting now... On Tue, 12 Nov 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: lib/libc/sys/t_ptrace_wait3:thread_concurrent_signals lib/libc/sys/t_ptrace_wait3:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait4:thread_concurrent_signals lib/libc/sys/t_ptrace_wait4:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait6:thread_concurrent_signals lib/libc/sys/t_ptrace_wait6:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_wait:thread_concurrent_signals lib/libc/sys/t_ptrace_wait:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitid:trace_thread_lwpcreate_and_exit lib/libc/sys/t_ptrace_waitpid:thread_concurrent_signals lib/libc/sys/t_ptrace_waitpid:trace_thread_lwpcreate_and_exit The above tests failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. Between the last successful test and the failed test, a total of 10064 revisions were committed, by the following developers: christos chs gutteridge hannken jdolecek jmcneill joerg kamil maxv mlelstv mrg msaitoh nisimura pgoyette roy sevan tnn yamaguchi Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.11.html#2019.11.11.02.40.48 !DSPAM:5dca6d0b256033292947347! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
nvmmctl debug file
With the new nvmmctl utility, when building a release with MKDEBUG=yes I get an unexpected file in $DESTDIR/amd64/usr/libdata/debug/usr/sbin/nvmmctl.debug Do you maybe need to add something to $SRC/distrib/sets/lists/debug/* ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Tar extract behaviour changed
On Wed, 23 Oct 2019, Christos Zoulas wrote: I am not advocating for either, perhaps we should just add -P to the extraction and get over it :-) This one gets my vote! :) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: built-in vs loadable modules and userconf
On Sat, 19 Oct 2019, Rhialto wrote: On Sat 19 Oct 2019 at 08:16:02 -0700, Paul Goyette wrote: If the module is built-in, it will never be loaded from the *.kmod file. But as I pointed out above, disabling in userconf does NOT disable the module, and does not prevent the module's initialization code from executing. Side-thought: maybe userconf can benefit from a way to disable modules? Yeah, that might be nice to have... :) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: built-in vs loadable modules and userconf
On Sat, 19 Oct 2019, John D. Baker wrote: On Sat, 19 Oct 2019, Paul Goyette wrote: I want to be sure that a disabled built-in module won't cause a loadable module to be loaded and defeat the disabling of the built-in "raid" device. Disabling the raid device in userconf doesn't disable the raidframe module. If the raidframe module is in your kernel, it can only be disabled after booting, using modunload(8). All raidframe support is built-in on my kernel (includes GENERIC and elides unnecessary/unwanted items). If I disable all the raid* stuff, won't that disable raidframe as well? From the module(9) perspective, no, the module is not disabled as a result of userconf activity. Using userconf to disable the device will prevent all accesses to the device. BUT, the module will still be active, and the module's initialization code will be called. Any code in the kernel that looks for auto-configured raid devices will still run. I would expect it to fail to create any actual raid instances, but the code should still execute. It's important that everything raidframe/raid related be disabled before the kernel boots, or my RAID will be hosed again and I don't need that level of stress. I was lucky to recover it the first time (have encountered a few damaged files since then). Given that you've had "issues" with raid's auto-configure before, I would be reluctant to try this with your current kernel. I would suggest that you build a new kernel with no raid config(1)ured. Also note that disabling a built-in module does not allow you to load a different instance of that module. modload(8) will find the built-in module, I think that means if I disable something via userconf, the on-disk loadable module won't be loaded. If the module is built-in, it will never be loaded from the *.kmod file. But as I pointed out above, disabling in userconf does NOT disable the module, and does not prevent the module's initialization code from executing. I suppose I could whip up a custom kernel without the raidframe/raid support in it, but it's crucial to keep the raidframe module from being loaded if any disk is found with RAID autoconf support. If you build a custom kernel without any raid support, then there will be no code to look for any auto-configured-raid-sets, and therefore no code to instantiate any raid devices, and therefore no reason to ever attempt to autoload the module. If you're really paranoid, you can also configure your custom kernel with MODULAR_DEFAULT_AUTOLOAD disabled (this is on by default). I suppose also I can turn off autoconfig on the RAID before booting the test kernel (the config file is renamed so it won't be found by the 'rc' scripts). I have another machine with a local raidframe raid that I can test the procedure with when current tasks are completed. Hope this helps! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: built-in vs loadable modules and userconf
On Sat, 19 Oct 2019, John D. Baker wrote: I'm curious to see if changes to ahci_sata code in -current fixes the problem in PR kern/54289. On the primary test machine I have it does not. The only other machine to exhibit the problem is my file server using RAIDframe. I nearly lost the RAID booting a netbsd-9 kernel when half of the disks failed to identify due the problem in the PR. If I boot a -current kernel in userconf mode (boot -c) and disable the built-in "raid" device, this should prevent the raid from trying to configure and failing if the problem is still present. I want to be sure that a disabled built-in module won't cause a loadable module to be loaded and defeat the disabling of the built-in "raid" device. Disabling the raid device in userconf doesn't disable the raidframe module. If the raidframe module is in your kernel, it can only be disabled after booting, using modunload(8). Also note that disabling a built-in module does not allow you to load a different instance of that module. modload(8) will find the built-in module, and if you specify the -f option for modload it will re-enable the built-in module. (Without -f, modload will report an error.) ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
firefox dumping core after NetBSD upgrade
I recently upgraded my system from 9.99.4 to 9.99.15, and I've noticed
that firefox is repeatedly dumping core. I haven't found the specific
trigger yet, but...
* The host system is a NetBSD amd64
* firefox 69.0.1 (and all of its dependencies) was build from pkgsrc,
while the host was still running 9.99.4
I don't have debug symbols available, but I was able to get a stack
back-trace using gdb; hopefully someone might recognize what the
problem is...
Core was generated by `firefox'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7af20d009a7b in _atomic_cas_ptr (new=, old=0x0,
ptr=0x7af20d3cb730)
at /build/netbsd-local/src_ro/lib/libpthread/arch/x86_64/pthread_md.h:77
77 __asm __volatile ("lock; cmpxchgq %2, %1"
[Current thread is 1 (process 1)]
(gdb)
(gdb) bt
#0 0x7af20d009a7b in _atomic_cas_ptr (new=, old=0x0,
ptr=0x7af20d3cb730)
at /build/netbsd-local/src_ro/lib/libpthread/arch/x86_64/pthread_md.h:77
#1 pthread_mutex_lock (ptm=ptm@entry=0x7af20d3cb720)
at /build/netbsd-local/src_ro/lib/libpthread/pthread_mutex.c:201
#2 0x7af1ec643f74 in mtx_lock (mtx=0x7af20d3cb720)
at
/build/netbsd-local/xsrc_ro/external/mit/MesaLib/dist/include/c11/threads_posix.h:223
#3 simple_mtx_lock (mtx=0x7af20d3cb720)
at
/build/netbsd-local/xsrc_ro/external/mit/MesaLib/dist/src/util/simple_mtx.h:125
#4 _mesa_error (ctx=ctx@entry=0x7af20d3b9868, error=error@entry=1282,
fmtString=fmtString@entry=0x7af1ee415f84 "Inside glBegin/glEnd")
at
/build/netbsd-local/xsrc_ro/external/mit/MesaLib/dist/src/mesa/main/errors.c:309
#5 0x7af1ec65e256 in _mesa_GetString (name=7938)
at
/build/netbsd-local/xsrc_ro/external/mit/MesaLib/dist/src/mesa/main/getstring.c:124
#6 0x7af1fbdd534d in ?? () from /usr/pkg/lib/firefox/libxul.so
#7 0x7af1fbdd5828 in ?? () from /usr/pkg/lib/firefox/libxul.so
#8 0x7af1fbdcb6a4 in ?? () from /usr/pkg/lib/firefox/libxul.so
#9 0x7af1fbdd2df8 in ?? () from /usr/pkg/lib/firefox/libxul.so
#10 0x7af1fbdd3649 in ?? () from /usr/pkg/lib/firefox/libxul.so
#11 0x00012e805f57 in _start ()
(gdb)
++------+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: heads up: follow correct upgrade procedures
On Mon, 30 Sep 2019, Jonathan A. Kollasch wrote: Due to some recent changes to some file system syscalls, it is necessary to follow correct upgrade procedures to avoid trouble. Be sure to install new kernel and matching modules and boot the new kernel before upgrading userland. Remember that once userland is upgraded you will not be able to run an older kernel. Remember that /rescue will not save you if it has been upgraded beyond the old kernel too. If not already done, this should probably be added to src/UPDATING ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build failed on fresh sources
On Sun, 29 Sep 2019, Christos Zoulas wrote:
Sure, but the question is why are you getting errors in the first place.
They should have been downgraded to warnings by -Wno-error-foo.
Something in /etc/mk.conf perhaps?
christos
On Sep 29, 2019, at 3:18 AM, Greywolf wrote:
On Sat, Sep 28, 2019 at 3:48 AM Christos Zoulas wrote:
We've chosen not to fix the fallthrough warnings in 3rd party code, but
we instead have changed the default setting to not produce errors. Have
you made any changes to the compilation environment that caused those to
become errors again?
christos
No, sir, I have not -- fresh sources, no environment variables set (I
only set them for full release builds).
Can this be overridden with a subsequent -Wno-{something}, or something similar?
--
--*greywolf;
!DSPAM:5d90be4e77492061013659!
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Build error
OK, I did another ``cvs up'' and the problem appears to have been fixed! Sorry for the noise. On Sun, 25 Aug 2019, Paul Goyette wrote: With sources updated to just a few minutes ago, I'm getting the following when building on a 9.99.4 amd64 host: dependall ===> tests/crypto/libcrypto/srp /build/netbsd-local/tools/x86_64/amd64/lib/gcc/x86_64--netbsd/7.4.0/../../../../x86_64--netbsd/bin/ld: /build/netbsd-local/dest/amd64/lib/libnpf.so: undefined reference to `nvlist_exists' /build/netbsd-local/tools/x86_64/amd64/lib/gcc/x86_64--netbsd/7.4.0/../../../../x86_64--netbsd/bin/ld: /build/netbsd-local/dest/amd64/lib/libnpf.so: undefined reference to `dnvlist_take_number' (several more undefined references follow) ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build error
With sources updated to just a few minutes ago, I'm getting the following when building on a 9.99.4 amd64 host: dependall ===> tests/crypto/libcrypto/srp /build/netbsd-local/tools/x86_64/amd64/lib/gcc/x86_64--netbsd/7.4.0/../../../../x86_64--netbsd/bin/ld: /build/netbsd-local/dest/amd64/lib/libnpf.so: undefined reference to `nvlist_exists' /build/netbsd-local/tools/x86_64/amd64/lib/gcc/x86_64--netbsd/7.4.0/../../../../x86_64--netbsd/bin/ld: /build/netbsd-local/dest/amd64/lib/libnpf.so: undefined reference to `dnvlist_take_number' (several more undefined references follow) ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
On Thu, 8 Aug 2019, Paul Goyette wrote: I am investigating... This should be fixed by sys/kern/kern_module.c rev 1.138 On Thu, 8 Aug 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: modules/t_builtin:busydisable The above test failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2019.08.07.00.38.01 pgoyette src/sys/dev/ccd.c,v 1.180 2019.08.07.00.38.02 pgoyette src/sys/dev/iscsi/iscsi_main.c,v 1.31 2019.08.07.00.38.02 pgoyette src/sys/dev/usb/usbnet.c,v 1.7 2019.08.07.00.38.02 pgoyette src/sys/kern/kern_module.c,v 1.137 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_ipc.c,v 1.40 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_msg.c,v 1.75 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_sem.c,v 1.98 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_shm.c,v 1.137 2019.08.07.00.38.02 pgoyette src/sys/miscfs/genfs/layer_vfsops.c,v 1.52 2019.08.07.00.38.02 pgoyette src/sys/sys/module.h,v 1.47 2019.08.07.00.38.02 pgoyette src/sys/sys/msg.h,v 1.28 2019.08.07.00.38.02 pgoyette src/sys/sys/sem.h,v 1.34 2019.08.07.00.38.02 pgoyette src/sys/sys/shm.h,v 1.53 2019.08.07.00.39.23 pgoyette src/sys/sys/param.h,v 1.603 2019.08.07.01.09.49 roy src/lib/libc/sys/read.2,v 1.37 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.08.html#2019.08.07.01.09.49 !DSPAM:5d4bb60467481808415646! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 test failure
I am investigating... On Thu, 8 Aug 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of a new failure of the NetBSD test suite. The newly failing test case is: modules/t_builtin:busydisable The above test failed in each of the last 3 test runs, and passed in at least 27 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2019.08.07.00.38.01 pgoyette src/sys/dev/ccd.c,v 1.180 2019.08.07.00.38.02 pgoyette src/sys/dev/iscsi/iscsi_main.c,v 1.31 2019.08.07.00.38.02 pgoyette src/sys/dev/usb/usbnet.c,v 1.7 2019.08.07.00.38.02 pgoyette src/sys/kern/kern_module.c,v 1.137 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_ipc.c,v 1.40 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_msg.c,v 1.75 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_sem.c,v 1.98 2019.08.07.00.38.02 pgoyette src/sys/kern/sysv_shm.c,v 1.137 2019.08.07.00.38.02 pgoyette src/sys/miscfs/genfs/layer_vfsops.c,v 1.52 2019.08.07.00.38.02 pgoyette src/sys/sys/module.h,v 1.47 2019.08.07.00.38.02 pgoyette src/sys/sys/msg.h,v 1.28 2019.08.07.00.38.02 pgoyette src/sys/sys/sem.h,v 1.34 2019.08.07.00.38.02 pgoyette src/sys/sys/shm.h,v 1.53 2019.08.07.00.39.23 pgoyette src/sys/sys/param.h,v 1.603 2019.08.07.01.09.49 roy src/lib/libc/sys/read.2,v 1.37 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.08.html#2019.08.07.01.09.49 !DSPAM:5d4bb60467481808415646! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: NetBSD 9.99.1 Quick Question
On Mon, 5 Aug 2019, Rhialto wrote: On Thu 01 Aug 2019 at 22:52:56 +, Thomas Mueller wrote: Is there any preference on which Xorg I should use on a new installation: modular or native? I personally prefer native, since I consider X to be part of the operating system (or at least not part of the extra software that is installed according to the taste of the user). Same here - I've always used the in-tree native X, and never even looked at the pkgsrc stuff. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: NetBSD 9.99.1 Quick Question
On Wed, 31 Jul 2019, Thomas Mueller wrote: How do users of 8.99.51 and earlier 8.99.x decide whether to go with 9.99.1 or 9.0_BETA? I am on NetBSD amelia2 8.99.51 NetBSD 8.99.51 (NetBSD-HEAD amd64.nb899-20190723) #1: Tue Jul 23 13:35:29 GMT 2019 root@amelia2:/usr/obj/usr/src/sys/arch/amd64/compile/SANDY7 amd64 as I type this; also built i386 from the same source tree. If you were previously on 8.99.x then you were tracking -current and not any particular release. IMHO you should now track the 9.99.x series, as that is the new -current! If you intend to deploy a stable 9.0 release (rather than tracking -current) I would recommend installing 9.0-BETA to help us make the release as "solid" as possible. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Error building kernel-only
With sources up-to-date, a ``build.sh release'' succeeds. HOWEVER, a ``build.sh kernel=XXX'' fails with the following errors (the entire log is attached...) In file included from /build/netbsd-local/src_ro/sys/compat/netbsd32/netbsd32.h:107:0, from /build/netbsd-local/src_ro/sys/arch/amd64/amd64/process_machdep.c:89: ./machine/netbsd32_machdep.h:108:2: error: unknown type name 'siginfo32_t' siginfo32_t sf_si; ^~~ ./machine/netbsd32_machdep.h:109:2: error: unknown type name 'ucontext32_t' ucontext32_t sf_uc; ^~~~ In file included from /build/netbsd-local/src_ro/sys/arch/amd64/amd64/process_machdep.c:89:0: /build/netbsd-local/src_ro/sys/compat/netbsd32/netbsd32.h:324:2: error: unknown type name 'siginfo32_t' siginfo32_t psi_siginfo; /* signal information structure */ ^~~ /build/netbsd-local/src_ro/sys/compat/netbsd32/netbsd32.h:1178:26: error: unknown type name 'siginfo32_t'; did you mean 'siginfo_t'? void netbsd32_si_to_si32(siginfo32_t *, const siginfo_t *); ^~~ siginfo_t /build/netbsd-local/src_ro/sys/compat/netbsd32/netbsd32.h:1179:45: error: unknown type name 'siginfo32_t' void netbsd32_si32_to_si(siginfo_t *, const siginfo32_t *); ^~~ /build/netbsd-local/src_ro/sys/compat/netbsd32/netbsd32.h:1181:63: error: 'struct __ksiginfo32' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] void netbsd32_ksi32_to_ksi(struct _ksiginfo *si, const struct __ksiginfo32 *si32); ^~~~ cc1: all warnings being treated as errors *** [process_machdep.o] Error code 1 ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+===> build.sh command:./build.sh -T /build/netbsd-local/tools/x86_64/amd64 -D /build/netbsd-local/dest/amd64 -O /build/netbsd-local/obj/amd64 -R /build/netbsd-local/release -V RELEASEMACHINEDIR=amd64 -V MKDEBUG=yes -V MKKDEBUG=yes -U -x -N0 -m amd64 -j1 kernel=SPEEDY releasekernel=SPEEDY ===> build.sh started:Thu Jun 27 00:34:12 UTC 2019 ===> NetBSD version: 8.99.48 ===> MACHINE: amd64 ===> MACHINE_ARCH:x86_64 ===> Build platform: NetBSD 8.99.45 amd64 ===> HOST_SH: /bin/sh ===> MAKECONF file: /etc/mk.conf ===> TOOLDIR path:/build/netbsd-local/tools/x86_64/amd64 ===> DESTDIR path:/build/netbsd-local/dest/amd64 ===> RELEASEDIR path: /build/netbsd-local/release ===> Updated makewrapper: /build/netbsd-local/tools/x86_64/amd64/bin/nbmake-amd64 ===> Building kernel without building new tools ===> Building kernel: SPEEDY ===> Build directory: /build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY Build directory is /build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY Don't forget to run "make depend" depending the kern library objects making sure the kern library is up to date... building standard kern library /build/netbsd-local/src_ro/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_bo.c: In function 'nouveau_ttm_io_mem_reserve': /build/netbsd-local/src_ro/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_bo.c:1469:57: warning: this statement may fall through [-Wimplicit-fallthrough=] if (drm->device.info.family < NV_DEVICE_INFO_V0_TESLA || !node->memtype) ~~^ /build/netbsd-local/src_ro/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_bo.c:1473:2: note: here case TTM_PL_VRAM: ^~~~ /build/netbsd-local/src_ro/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/dma/nouveau_nvkm_engine_dma_usernv04.c: In function 'nv04_dmaobj_new': /build/netbsd-local/src_ro/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/dma/nouveau_nvkm_engine_dma_usernv04.c:129:18: warning: this statement may fall through [-Wimplicit-fallthrough=] dmaobj->flags0 |= 0x8000; ~~~^ /build/netbsd-local/src_ro/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/dma/nouveau_nvkm_engine_dma_usernv04.c:130:2: note: here case NV_MEM_ACCESS_RW: ^~~~ /build/netbsd-local/src_ro/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/fifo/nouveau_nvkm_engine_fifo_nv04.c: In function 'nv04_fifo_swmthd': /build/netbsd-local/src_ro/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/fifo/nouveau_nvkm_engine_fifo_nv04.c:124:3: warning: this statement may fall
Re: Automated report: NetBSD-current/i386 build failure
Hmmm... With sources from 2019-06-17 at 17:43:48 UTC I have just completed a amd64 'build.sh release' successfully. Does i386 include the chfs file system, but not include flash(4) device? On Mon, 17 Jun 2019, Andreas Gustafsson wrote: The build is still failing as of source date 2019.06.17.16.34.02: -- kern-INSTALL --- /tmp/bracket/build/2019.06.17.16.34.02-i386/tools/bin/i486--netbsdelf-ld: chfs_vfsops.o: in function `chfs_mountfs': chfs_vfsops.c:(.text+0xaef): undefined reference to `flash_cdevsw' -- Andreas Gustafsson, g...@gson.org !DSPAM:5d07dfe481556811919384! ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Minor annoyance - keyboard LED not restored
This is on a amd64 8.99.37 system built from sources dated 2019-04-24 23:45:06 UTC, and with in-tree (native) Xorg... When switching from the X session on VT05 to any other VT, the state of the "NumLock" LED is retained. However, when switching to the X session the LED is always turned off, regardless of previous state. The internal keyboard state appears to be maintained correctly, as the numeric keypad still generates numbers (rather than cursor movement escape sequences), and pressing the NumLock key _twice_ turns the LED back on. I've noticed discrepancies with the NumLock LED before, but never bothered to look into it in any detail until just now. So I don't have the slightest clue as to when this might have started. ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: What to do with base X11 for netbsd-9 ?
Well, my problems are not with X but with in-kernel nouveau driver. I have noted my issues several times in the past: * GTX 1050-Ti not supported, so I have to use vga kernel driver. * Shutting down xdm(8) normally results in a totally black screen with no control, and no ability even for blind typing. * Therefore, a system shutdown or reboot requires manually using ``kill -9'' on xdm (from the console), followed by shutdown(9). * Once I've killed xdm, I cannot restart it - I _must_ reboot! * Attempts to use the vesa driver (rather than vga) have been unsuccessful. I have a (rather "sub-optimal") workaround for my situation, so it's not critical, and I would not use my issues as a reason for delaying the up-coming branch of NetBSD-9. I am curious why we need to apparently build all of the LLVM stuff for a release? If LLVM is needed as part of the build, it should be built as host tools; I don't understand why we _also_ need to build LLVM for the target machine. (And, if the answer to this is YES, we should probably find a way to build-and-install a minimal subset, not the whole thing!) On Wed, 29 May 2019, Martin Husemann wrote: Hey folks, I would like to get your feedback about the current state of the base X11, as there have been lots of threads about various issues and I have lost the overview of what works in -current and what does not. We *really* need to branch netbsd-9 very soon now, and it is unclear (at least to me) what should happen to the in-tree X11 version. - we have very obvious display bugs at first sight in xdm - self hosting builds on 4 GB amd64 machines are not really possible any more (due to LLVM runtime dependencies, which can not even be disabled at build time right now) - reports here (and on other lists) about display problems and success stories have no clear winner (but probably due to me losing track) So what is you story/opinion: is base X11 usable in -current? If not, what needs to be done or what hardware needs fixes? Martin !DSPAM:5cee313a49191121140670! ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: current long build time
On Sun, 28 Apr 2019, Riccardo Mottola wrote: Hi, after a long build time I see end of 37 extra files *** Failed target: checkflist I did build using "./build.sh -U -x distribution" so it was not an update build. What can I do? just delete the files? if there is a command to get this list I can try... The list of extra files should immediately preceed the above messages. (You did log your build command output in a file, right?) This usually indicated that there are files in the $DESTDIR left over from a previous build. Remove them, and then rerun the build.sh with -u (and save the output in a log file!) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 build failure
2 nbmake[6]: stopped in /tmp/bracket/build/2019.04.27.06.18.15-i386/src/sys/rump/net/lib --- dependall-libnetcan --- The following commits were made between the last successful build and the failed build: 2019.04.27.06.18.15 pgoyette src/sys/net/if_faith.c,v 1.60 2019.04.27.06.18.15 pgoyette src/sys/net/if_mpls.c,v 1.35 2019.04.27.06.18.15 pgoyette src/sys/net/if_srt.c,v 1.30 2019.04.27.06.18.15 pgoyette src/sys/netcan/if_canloop.c,v 1.6 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.04.html#2019.04.27.06.18.15 !DSPAM:5cc416b7207041263116732! ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: current long build time
On Thu, 25 Apr 2019, Riccardo Mottola wrote: Hi all, I am in the process updating (thus to test) my laptop (HP620 - dual core amd64) to current. My first attempt failed, in userland because I used "-u" flag and clearly something broke. Now I went the "Long" route 1) build tools, build kernel 2) reboot new kernel (works!) 3) rebuild tools to match kernel 4) build & install modules 5) build userland (-U -x) I notice that 5) is running since yesterday evening, almost 24hrs now - I was accustomed to it to finish in a couple of hours, usually I was able to update during business hours. Is this expected, like are we compiling lots of new stuff... or is something going wrong that considerably slows down the process. If you are building in-tree X then we are now building a bunch of LLVM stuff (needed for the new mesa). It takes a LONG time to build. ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Strange apropos(1) behavior?
On Fri, 19 Apr 2019, Paul Goyette wrote: Should it be possible to use both the -l (legacy mode) option and specify a specific section -[1-9] ? # apropos -l -8 specific apropos: no such table: mandb apropos: No relevant results obtained. Please make sure that you spelled all the terms correctly or try using different keywords. And another anomaly: # apropos -p specific apropos: Cannot allocate 140187716927593 bytes: Cannot allocate memory And while we're at it, the man page for apropos(1) says that the -p option _defaults_ to using more(1) as the pager, implying that it should be possible to use a different pager. Yet there is no option to tell apropos to which other pager the output should be piped! And finally, the -P option is documented in the apropos(1) man page as also "Turn on pager formatting". Is this correct? Or should one of these two options be a "Turn _off_ pager formatting" ? :) ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Strange apropos(1) behavior?
Should it be possible to use both the -l (legacy mode) option and specify a specific section -[1-9] ? # apropos -l -8 specific apropos: no such table: mandb apropos: No relevant results obtained. Please make sure that you spelled all the terms correctly or try using different keywords. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: date/strftime() returning wrong timezone name
On my 8.99/35 system from last month I get $ TZ=Australia/Melbourne date; TZ=NZ date Wed Apr 17 16:21:31 AEST 2019 Wed Apr 17 18:21:31 NZST 2019 $ On an 8.99.37 within qemu (built only a couple days ago), I get # TZ=Australia/Melbourne date; TZ=NZ date Wed Apr 17 16:24:10 LMT 2019 Wed Apr 17 18:24:10 LMT 2019 # I'd guess that a recent import of the latest tzcode has gone awry. On Wed, 17 Apr 2019, Geoff Wing wrote: Hi, running /sbin/dmesg and /bin/date I am seeing a timezone name of "LMT" instead of my normal "AEST" Copying "date" and my zoneinfo file from a working computer, I still see bad info. From -current (compiled myself and from nyftp snapshot): % TZ=Australia/Melbourne date; TZ=NZ date Wed Apr 17 16:04:16 LMT 2019 Wed Apr 17 16:04:16 LMT 2019 From a month ago: % TZ=Australia/Melbourne date; TZ=NZ date Wed Apr 17 16:03:54 AEST 2019 Wed Apr 17 16:03:54 NZST 2019 "LMT" was the correct timezone name 125-150 years ago for those zones. Is this reproducible for anyone else or something unique to me? I see there have been some recent changes to strftime() so perhaps those are the cause of my problem. Regards, Geoff !DSPAM:5cb6c3a8134038455320440! ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: no options COMPAT_43
On Mon, 15 Apr 2019, Paul Goyette wrote: There may be some other option you have enabled which requires COMPAT_43 Try to boot your new kernel and use modstat(8) to see what other modules might require the compat_43 module. A quick check on my recent amd64 build shows that compat_linux requires compat_43. On Mon, 15 Apr 2019, Masanobu SAITOH wrote: Hi. I tried to make a kernel without COMPAT_43 from conf/GENERIC. I added "no options COMPAT_43" at the end of conf/GENERIC or conf/GENERIC.local, but compile/GENERIC/opt_compat_43.h had: #define COMPAT_43 1 Is this behavior intended? When I added "no options COMPAT_43" twice, config(8) said: GENERIC:1219: warning: options `COMPAT_43' is not defined so my "no options COMPAT_43" lines are at after loading of sys/conf/compat_netbsd.config. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org) !DSPAM:5cb45ac1290301372017733! ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: no options COMPAT_43
There may be some other option you have enabled which requires COMPAT_43 Try to boot your new kernel and use modstat(8) to see what other modules might require the compat_43 module. On Mon, 15 Apr 2019, Masanobu SAITOH wrote: Hi. I tried to make a kernel without COMPAT_43 from conf/GENERIC. I added "no options COMPAT_43" at the end of conf/GENERIC or conf/GENERIC.local, but compile/GENERIC/opt_compat_43.h had: #define COMPAT_43 1 Is this behavior intended? When I added "no options COMPAT_43" twice, config(8) said: GENERIC:1219: warning: options `COMPAT_43' is not defined so my "no options COMPAT_43" lines are at after loading of sys/conf/compat_netbsd.config. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org) !DSPAM:5cb45ac1290301372017733! ++------+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Automated report: NetBSD-current/i386 build failure
On Sat, 6 Apr 2019, Paul Goyette wrote:
My amd64 build failed with
checkflist ===> distrib/sets
== 3 missing files in DESTDIR
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/tests/modules/t_ufetchstore
./usr/tests/modules/ufetchstore_tester
./usr/tests/modules/ufetchstore_tester/ufetchstore_tester.kmod
end of 3 missing files ==
Looks like there's a missing Makefile in that directory.
maya@ fetched the missing file and committed it. The amd64 build
is now working.
Back to i386 failures :) The current issue looks like another
fallout from ufetch/ustore ...
On Sat, 6 Apr 2019, Andreas Gustafsson wrote:
The i386 build is still failing, but now in a different place:
--- dependall-sys ---
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/compat/freebsd/freebsd_syscall.c:
In function 'freebsd_syscall':
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/compat/freebsd/freebsd_syscall.c:103:9:
error: passing argument 2 of 'ufetch_long' from incompatible pointer type
[-Werror=incompatible-pointer-types]
--- dependall-external ---
--- dependall ---
--- dependall-sys ---
&code);
^
In file included from
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/sys/timevar.h:66:0,
from
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/sys/time.h:307,
from
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/sys/param.h:145,
from
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/compat/freebsd/freebsd_syscall.c:35:
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/sys/systm.h:341:5:
note: expected 'long unsigned int *' but argument is of type 'register_t *
{aka int *}'
int ufetch_long(const unsigned long *uaddr, unsigned long *valp);
^~~
--
Andreas Gustafsson, g...@gson.org
!DSPAM:5ca8931b139052003219678!
+----+------+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
+----+------+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: Automated report: NetBSD-current/i386 build failure
My amd64 build failed with
checkflist ===> distrib/sets
== 3 missing files in DESTDIR
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/tests/modules/t_ufetchstore
./usr/tests/modules/ufetchstore_tester
./usr/tests/modules/ufetchstore_tester/ufetchstore_tester.kmod
end of 3 missing files ==
Looks like there's a missing Makefile in that directory.
On Sat, 6 Apr 2019, Andreas Gustafsson wrote:
The i386 build is still failing, but now in a different place:
--- dependall-sys ---
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/compat/freebsd/freebsd_syscall.c:
In function 'freebsd_syscall':
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/compat/freebsd/freebsd_syscall.c:103:9:
error: passing argument 2 of 'ufetch_long' from incompatible pointer type
[-Werror=incompatible-pointer-types]
--- dependall-external ---
--- dependall ---
--- dependall-sys ---
&code);
^
In file included from
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/sys/timevar.h:66:0,
from
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/sys/time.h:307,
from
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/sys/param.h:145,
from
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/compat/freebsd/freebsd_syscall.c:35:
/tmp/bracket/build/2019.04.06.09.33.07-i386/src/sys/sys/systm.h:341:5: note:
expected 'long unsigned int *' but argument is of type 'register_t * {aka int
*}'
int ufetch_long(const unsigned long *uaddr, unsigned long *valp);
^~~
--
Andreas Gustafsson, g...@gson.org
!DSPAM:5ca8931b139052003219678!
+----+------+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
/usr/tests/modules usage
It seemts to me that the original intent of this directory was for "things that [help] test the modules system". But recently we seem to have acquired at least a couple entries here which are "module- that-help-test-other-things". Shouldn't the latter class be in the directory appropriate to what is being tested? For example, threadpool and ufetchstore testers should perhaps belong in /usr/tests/kern ... (And, of course, the corresponding comments/changes related to related source code.) ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
npf configuration for blacklistd
With all the discussion going on (re removal of pf), I revisited my attempts to implement blacklistd. But I'm still having some issues getting npf configured. I have two external-facing interfaces, both of which should be handled identically by blacklistd. I tried using the npf examples, with an interface group containug both wm0 and tun0, but npf won't deal with it - it complains about having multiple members in the $ext_if group. (See PR kern/51818) So, I tried creating two groups, one for each interface, but both having the same blacklistd ruleset. Now npf complains "some table has a duplicate entry" and still doesn't start. So, any suggestions on how to make this work? (FWIW, I have no real opinion on the greater question(s) regarding the possible demise of pf and/or ipf.) ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
RE: swwdoq workqueue (was Re: panic in sysmon_envsys_unregister())
OK, I just committed this. On Wed, 27 Mar 2019, Paul Goyette wrote: On Tue, 26 Mar 2019, Michael van Elst wrote: And while looking for places that work queues get destroyed in dev/sysmon/ it seems that swwdog's workqueue is created twice when loaded as a module. Yep. The modularization is broken. Do either of you want to fix this? Or should I pick it up? (I don't mind, I just don't want to duplicate effort.) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ !DSPAM:5c9b38d0100841793941041! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
RE: swwdoq workqueue (was Re: panic in sysmon_envsys_unregister())
On Tue, 26 Mar 2019, Michael van Elst wrote: And while looking for places that work queues get destroyed in dev/sysmon/ it seems that swwdog's workqueue is created twice when loaded as a module. Yep. The modularization is broken. Do either of you want to fix this? Or should I pick it up? (I don't mind, I just don't want to duplicate effort.) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
atc(6) - display current score when game exits?
I've been a long-time fan of atc(6), but one thing has always bothered
me!
It seems that when you lose a game (and you always eventually will
lose!), the playing field is erased before the high-scores list is
printed. Since the playing field is the only place where your current
game's score is displayed, you end up with a screen that (most often)
says only "You didn't beat your previous score". Your _previous_ score
is displayed as part of the high-score list, but your current score is
NOT displayed. Thus you can't see how close you came to your previous
score.
The following simple patch seems to solve this:
Index: log.c
===
RCS file: /cvsroot/src/games/atc/log.c,v
retrieving revision 1.23
diff -u -p -r1.23 log.c
--- log.c 10 Jan 2017 20:40:53 - 1.23
+++ log.c 16 Mar 2019 22:52:52 -
@@ -161,6 +161,9 @@ log_score(int list_em)
struct utsname lname;
longoffset;
+ printf("You directed %d planes safely to their destination.\n\n",
+ thisscore.planes);
+
if (score_fp == NULL) {
warnx("no score file available");
return (-1);
Any objections?
++------+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Strange usb crash during shutdown
I was shutting down my 8.99.32 system (kernel & userland both from just a few days ago), and got a strange crash. It happened after all the "special" filesystems were dismounted (/proc, /kern, etc.) but before the "regular" dismounts for /var etc. Here's the back-trace (manually transcribed) mutex_oncpu + 1e mutex_vector_enter + d9 uhub_explore + 3bc uhub_explore + cc usb_discover.isra.2 + 68 usb_Event_thread + 77 It had started to write a crash dump but appeared to be doing a full non-sparse dump and it would have taken a very long time to dump my entire 128GB... +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: wifi SIOCS80211 error in 8.99.32 and iwn0
That should have been fixed already, but the build cluster might not have picked up the fix. If you can't build your own kernel, wait for the next build cycle. Other folks who had the same problem have confirmed the fix, so I'm pretty sure your problem will be fixed too. :) On Wed, 30 Jan 2019, David Brownlee wrote: I'm running a netbsd-8 userland with the latest nyftp current kernel on amd64 and just saw this on boot: iwn0: starting wpa_supplicant iwn0: failed to start wpa_supplicant iwn0: Sucessfully initialized wpa_supplicant ioctl[SIOCS80211, op=16, arg_len=0]: Inappropriate ioctl for device iwn0: Failed to initialize driver interface wifi appears to work fine... just an FYI in case its relevant to anyone... Thanks David !DSPAM:5c51735988201261034429! +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: SIOCS80211 ioctl and 8.99.32
This should be fixed now. An additional commit is pending to change the name of the hook, but no functional change is intended there! On Mon, 28 Jan 2019, Ryo ONODERA wrote: Hi, From: Patrick Welche , Date: Mon, 28 Jan 2019 10:58:54 + Just tried a 8.99.32 kernel and get Successfully initialized wpa_supplicant ioctl[SIOCS80211, op=16, arg_len=0]: Inappropriate ioctl for device iwn0: Failed to initialize driver interface when running wpa_supplicant. (8.99.30 userland from 22 Jan - works with 22 Jan kernel) I have the same problem with iwm(4). And wpa_supplicant's error message seems wrong. It should be ioctl[SIOCG80211, op=16, arg_len=0]: Inappropriate ioctl for device Cheers, Patrick -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3 !DSPAM:5c4ee142213832910019183! +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: SIOCS80211 ioctl and 8.99.32
On Mon, 28 Jan 2019, bch wrote: On Mon, Jan 28, 2019 at 1:51 PM Paul Goyette wrote: I notice that christos made some changes here overnight while I was (gasp) sleeping! Can you check to see if his changes fix your problem? It didn???t appear fixed w/i the last 0.5h or so, if that helps... OK, I think I figured it out. It's actually the same problem as the one I was chasing for msaitoh@ I've got a tentative fix, testing it now. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: SIOCS80211 ioctl and 8.99.32
On Mon, 28 Jan 2019, bch wrote: On Mon, Jan 28, 2019 at 1:51 PM Paul Goyette wrote: I notice that christos made some changes here overnight while I was (gasp) sleeping! Can you check to see if his changes fix your problem? It didn???t appear fixed w/i the last 0.5h or so, if that helps... OK, this is item #2 on my To-Do list. I'll try to get to it before leaving for my dentist appointment in a couple hours. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: SIOCS80211 ioctl and 8.99.32
I notice that christos made some changes here overnight while I was (gasp) sleeping! Can you check to see if his changes fix your problem? On Mon, 28 Jan 2019, Ryo ONODERA wrote: Hi, From: Patrick Welche , Date: Mon, 28 Jan 2019 10:58:54 + Just tried a 8.99.32 kernel and get Successfully initialized wpa_supplicant ioctl[SIOCS80211, op=16, arg_len=0]: Inappropriate ioctl for device iwn0: Failed to initialize driver interface when running wpa_supplicant. (8.99.30 userland from 22 Jan - works with 22 Jan kernel) I have the same problem with iwm(4). And wpa_supplicant's error message seems wrong. It should be ioctl[SIOCG80211, op=16, arg_len=0]: Inappropriate ioctl for device Cheers, Patrick -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3 !DSPAM:5c4ee142213832910019183! +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: SIOCS80211 ioctl and 8.99.32
I will investigate as soon as possible. But it may take some time. On Mon, 28 Jan 2019, Ryo ONODERA wrote: Hi, From: Patrick Welche , Date: Mon, 28 Jan 2019 10:58:54 + Just tried a 8.99.32 kernel and get Successfully initialized wpa_supplicant ioctl[SIOCS80211, op=16, arg_len=0]: Inappropriate ioctl for device iwn0: Failed to initialize driver interface when running wpa_supplicant. (8.99.30 userland from 22 Jan - works with 22 Jan kernel) I have the same problem with iwm(4). And wpa_supplicant's error message seems wrong. It should be ioctl[SIOCG80211, op=16, arg_len=0]: Inappropriate ioctl for device Cheers, Patrick -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3 !DSPAM:5c4ee142213832910019183! +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Automated report: NetBSD-current/i386 build failure
This is being worked on... On Mon, 28 Jan 2019, NetBSD Test Fixture wrote: This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2019.01.27.22.06.07. An extract from the build.sh output follows: /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:155: syntax error /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:167: option `COMPAT_LINUX32' dependency `COMPAT_LINUX' is an unknown option --- kern-GENERIC --- /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:154: syntax error /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:155: syntax error /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:167: option `COMPAT_LINUX32' dependency `COMPAT_LINUX' is an unknown option --- kern-LEGACY --- /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:154: syntax error /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:155: syntax error /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:167: option `COMPAT_LINUX32' dependency `COMPAT_LINUX' is an unknown option --- kern-INSTALL --- /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:154: syntax error /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:155: syntax error /tmp/bracket/build/2019.01.27.22.06.07-i386/src/sys/conf/files:167: option `COMPAT_LINUX32' dependency `COMPAT_LINUX' is an unknown option --- kern-XEN3PAE_DOMU --- *** Stop. --- distrib-dirs --- --- check_DESTDIR --- --- NetBSD.dist.tmp --- --- kern-XEN3PAE_DOMU --- *** [kern-XEN3PAE_DOMU] Error code 1 nbmake[1]: stopped in /tmp/bracket/build/2019.01.27.22.06.07-i386/src/etc The following commits were made between the last successful build and the failed build: 2019.01.27.22.00.14 pgoyette src/sys/conf/files,v 1.1223 2019.01.27.22.06.07 pgoyette src/sys/conf/files,v 1.1224 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2019.01.html#2019.01.27.22.06.07 !DSPAM:5c4e549f287651283720264! +--+------++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Automated report: NetBSD-current/i386 build failure
I think I just fixed this... On Sun, 27 Jan 2019, Andreas Gustafsson wrote: Th eNetBSD Test Fixture wrote: *** [kern_mod_80.d] Error code 1 To wit: --- dependall-compat_80 --- /tmp/bracket/build/2019.01.27.19.13.04-i386/src/sys/compat/common/kern_mod_80.c:52:31: fatal error: sys/compat/module.h: No such file or directory #include ^ -- Andreas Gustafsson, g...@gson.org !DSPAM:5c4e20cf220867463594025! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Merge (was "Collapse") of the pgoyette-compat branch (fwd)
Just a HEADS UP, I have completed the merge of [pgoyette-compat] into -current. I tried not to break anything, but this is a major change and I'm sure that something will break. Please let me know of any fallout from the merge (preferably via Email) and I will address as soon as $REALLIFE permits. On Wed, 16 Jan 2019, Paul Goyette wrote: FWIW, it's been pointed out to me that "collapse" of the branch might be mistakenly taken to indicate that the branch is beyond hope! :) Definitely not true - it's just an unfortunate holdover from a former $DAYJOB. Of course, the intended meaning was to "merge" the branch back into mainline. On Wed, 16 Jan 2019, Paul Goyette wrote: On Wed, 16 Jan 2019, Kamil Rytarowski wrote: On 16.01.2019 10:20, Paul Goyette wrote: Given the dearth of response to the notice posted on current-users I thought I'd widen the audience a bit, to make sure that all concerned have a chance to react! -- Forwarded message -- Date: Mon, 14 Jan 2019 08:21:18 +0800 (PST) From: Paul Goyette To: current-users@netbsd.org Subject: Collapse of the pgoyette-compat branch Folks, Having reached today a significant milestone (conversion of the rtsock_50 code to use function-pointers for callbacks), I'm ready to collapse/merge the pgoyette-compat branch into HEAD.?? Current status of the branch, including a list of open items, can be found at What are the benefits of the new branch? All compat code usable as modules? Well, I haven't reached 100% yet, but much closer than before. There's much more granularity than before, with a separate compat_xx module per NetBSD version, rather than a single monolithic compat module. Similarly for those architectures that support it, there are version-specific compat32_xx modules. As a result, you can load (or autoload) only as much compat code as you want - it's no longer an all-or-nothing operation. A lot of the #ifdef spaghetti that existed has been removed and replaced with function pointers that get loaded or initialized when optional code is built into the kernel. Just as an example, the vnd(4) driver is optional, but if it is present there are some compat functions that the mainline driver needs to call (for some compatability ioctl's). The compat module simply provides it own replacement function pointers, overriding the initial values (which point at no-op functions). There's also a mechanism for ensuring that a module doesn't get unloaded while some other code is following one of these function pointers. (A very very VERY big thanks goes out to riastradh@ for the basic design of this, using a combination of localcount(9) and pserialize(9) for interlocking.) One of the things that triggered my work here was the problem with the rtsock code. Most people know that I use modules whenever I can, and that includes the compat stuff. Yet when the rtsock code was modified, the compat functions could only be reached if they were built-in. They could not be part of any compat module. (Well, they could be included in the compat module, but there was no mechanism for the main rtsock code to call non-built-in compat routines.) There were also some module infrastructure changes made, mostly a removal of some limitations. There's no longer a maximum number of "required" prerequisite modules, and there's also no limit to the depth of recursion when loading "required" modules. Please also look at the file [pgoyette-compat]src/sys/doc/TODO.compat-branch for additional details. Hopefully all this makes some sort of sense. I really am not very good at explaining or justifying things. (Don't ever pick me as a member of your debate team - I can almost guarantee you would lose any competition in which I particpate!) [pgoyette-compat]src/doc/TODO.compat-module The only thing that's holding me back from committing is an inability to commmit to timely resolution of any fallout that might arise, due to $PERSONAL_LIFE issues.?? But, given that most people actually don't use modules anyway, any delays in fixing the fallout should likely have minimal impact.?? With luck, we'll actually get this into HEAD in time for netbsd-9 after all!?? (And christos@ has encouraged me to go ahead and commit sooner rather than later!) So, I'm planning to commit within the next two weeks (around the 27th or 28th of January).?? Until then, I'll respond to comments/reviews as best as I can. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:?? | | (Retired)?? | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+------+---
Re: Merge (was "Collapse") of the pgoyette-compat branch (fwd)
FWIW, it's been pointed out to me that "collapse" of the branch might be mistakenly taken to indicate that the branch is beyond hope! :) Definitely not true - it's just an unfortunate holdover from a former $DAYJOB. Of course, the intended meaning was to "merge" the branch back into mainline. On Wed, 16 Jan 2019, Paul Goyette wrote: On Wed, 16 Jan 2019, Kamil Rytarowski wrote: On 16.01.2019 10:20, Paul Goyette wrote: Given the dearth of response to the notice posted on current-users I thought I'd widen the audience a bit, to make sure that all concerned have a chance to react! -- Forwarded message -- Date: Mon, 14 Jan 2019 08:21:18 +0800 (PST) From: Paul Goyette To: current-users@netbsd.org Subject: Collapse of the pgoyette-compat branch Folks, Having reached today a significant milestone (conversion of the rtsock_50 code to use function-pointers for callbacks), I'm ready to collapse/merge the pgoyette-compat branch into HEAD.?? Current status of the branch, including a list of open items, can be found at What are the benefits of the new branch? All compat code usable as modules? Well, I haven't reached 100% yet, but much closer than before. There's much more granularity than before, with a separate compat_xx module per NetBSD version, rather than a single monolithic compat module. Similarly for those architectures that support it, there are version-specific compat32_xx modules. As a result, you can load (or autoload) only as much compat code as you want - it's no longer an all-or-nothing operation. A lot of the #ifdef spaghetti that existed has been removed and replaced with function pointers that get loaded or initialized when optional code is built into the kernel. Just as an example, the vnd(4) driver is optional, but if it is present there are some compat functions that the mainline driver needs to call (for some compatability ioctl's). The compat module simply provides it own replacement function pointers, overriding the initial values (which point at no-op functions). There's also a mechanism for ensuring that a module doesn't get unloaded while some other code is following one of these function pointers. (A very very VERY big thanks goes out to riastradh@ for the basic design of this, using a combination of localcount(9) and pserialize(9) for interlocking.) One of the things that triggered my work here was the problem with the rtsock code. Most people know that I use modules whenever I can, and that includes the compat stuff. Yet when the rtsock code was modified, the compat functions could only be reached if they were built-in. They could not be part of any compat module. (Well, they could be included in the compat module, but there was no mechanism for the main rtsock code to call non-built-in compat routines.) There were also some module infrastructure changes made, mostly a removal of some limitations. There's no longer a maximum number of "required" prerequisite modules, and there's also no limit to the depth of recursion when loading "required" modules. Please also look at the file [pgoyette-compat]src/sys/doc/TODO.compat-branch for additional details. Hopefully all this makes some sort of sense. I really am not very good at explaining or justifying things. (Don't ever pick me as a member of your debate team - I can almost guarantee you would lose any competition in which I particpate!) [pgoyette-compat]src/doc/TODO.compat-module The only thing that's holding me back from committing is an inability to commmit to timely resolution of any fallout that might arise, due to $PERSONAL_LIFE issues.?? But, given that most people actually don't use modules anyway, any delays in fixing the fallout should likely have minimal impact.?? With luck, we'll actually get this into HEAD in time for netbsd-9 after all!?? (And christos@ has encouraged me to go ahead and commit sooner rather than later!) So, I'm planning to commit within the next two weeks (around the 27th or 28th of January).?? Until then, I'll respond to comments/reviews as best as I can. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:?? | | (Retired)?? | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+------++ +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)|
Re: Collapse of the pgoyette-compat branch (fwd)
On Wed, 16 Jan 2019, Kamil Rytarowski wrote: On 16.01.2019 10:20, Paul Goyette wrote: Given the dearth of response to the notice posted on current-users I thought I'd widen the audience a bit, to make sure that all concerned have a chance to react! -- Forwarded message -- Date: Mon, 14 Jan 2019 08:21:18 +0800 (PST) From: Paul Goyette To: current-users@netbsd.org Subject: Collapse of the pgoyette-compat branch Folks, Having reached today a significant milestone (conversion of the rtsock_50 code to use function-pointers for callbacks), I'm ready to collapse/merge the pgoyette-compat branch into HEAD.?? Current status of the branch, including a list of open items, can be found at What are the benefits of the new branch? All compat code usable as modules? Well, I haven't reached 100% yet, but much closer than before. There's much more granularity than before, with a separate compat_xx module per NetBSD version, rather than a single monolithic compat module. Similarly for those architectures that support it, there are version-specific compat32_xx modules. As a result, you can load (or autoload) only as much compat code as you want - it's no longer an all-or-nothing operation. A lot of the #ifdef spaghetti that existed has been removed and replaced with function pointers that get loaded or initialized when optional code is built into the kernel. Just as an example, the vnd(4) driver is optional, but if it is present there are some compat functions that the mainline driver needs to call (for some compatability ioctl's). The compat module simply provides it own replacement function pointers, overriding the initial values (which point at no-op functions). There's also a mechanism for ensuring that a module doesn't get unloaded while some other code is following one of these function pointers. (A very very VERY big thanks goes out to riastradh@ for the basic design of this, using a combination of localcount(9) and pserialize(9) for interlocking.) One of the things that triggered my work here was the problem with the rtsock code. Most people know that I use modules whenever I can, and that includes the compat stuff. Yet when the rtsock code was modified, the compat functions could only be reached if they were built-in. They could not be part of any compat module. (Well, they could be included in the compat module, but there was no mechanism for the main rtsock code to call non-built-in compat routines.) There were also some module infrastructure changes made, mostly a removal of some limitations. There's no longer a maximum number of "required" prerequisite modules, and there's also no limit to the depth of recursion when loading "required" modules. Please also look at the file [pgoyette-compat]src/sys/doc/TODO.compat-branch for additional details. Hopefully all this makes some sort of sense. I really am not very good at explaining or justifying things. (Don't ever pick me as a member of your debate team - I can almost guarantee you would lose any competition in which I particpate!) [pgoyette-compat]src/doc/TODO.compat-module The only thing that's holding me back from committing is an inability to commmit to timely resolution of any fallout that might arise, due to $PERSONAL_LIFE issues.?? But, given that most people actually don't use modules anyway, any delays in fixing the fallout should likely have minimal impact.?? With luck, we'll actually get this into HEAD in time for netbsd-9 after all!?? (And christos@ has encouraged me to go ahead and commit sooner rather than later!) So, I'm planning to commit within the next two weeks (around the 27th or 28th of January).?? Until then, I'll respond to comments/reviews as best as I can. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:?? | | (Retired)?? | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--+----+ +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Collapse of the pgoyette-compat branch
Folks, Having reached today a significant milestone (conversion of the rtsock_50 code to use function-pointers for callbacks), I'm ready to collapse/merge the pgoyette-compat branch into HEAD. Current status of the branch, including a list of open items, can be found at [pgoyette-compat]src/doc/TODO.compat-module The only thing that's holding me back from committing is an inability to commmit to timely resolution of any fallout that might arise, due to $PERSONAL_LIFE issues. But, given that most people actually don't use modules anyway, any delays in fixing the fallout should likely have minimal impact. With luck, we'll actually get this into HEAD in time for netbsd-9 after all! (And christos@ has encouraged me to go ahead and commit sooner rather than later!) So, I'm planning to commit within the next two weeks (around the 27th or 28th of January). Until then, I'll respond to comments/reviews as best as I can. +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Panic on a -current from 13/12/2018
On Sat, 15 Dec 2018, Chavdar Ivanov wrote: Hi, On 8.99.27 AMD64 running under VirtualBox I got this morning the panic in http://ci4ic4.tx0.org/ci4ic4-panic-01.png I have the coredump, if it is of interest. I thought it might be useful, as it is apparently in the wm driver. Oh, dear. I just updated my one-and-only machine (real hardware, nothing virual) to yesterday's -current. And my one-and-only network interface is (of course) a wm0! I hope this panic is not frequently encountered. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Tue, 20 Nov 2018, David H. Gutteridge wrote: FWIW, I'm able to get suspend and resume to work reliably on a Lenovo T420 with NetBSD-8.0_STABLE. (With 8.99.x, it doesn't work as reliably because the SATA driver seems to have issues after resumption which don't occur with 8.0.) Jaromir Dolocek did a lot of work on ahcisata recently. You might try to coordninate with him to see if his changes have affected the suspend and resume stuff. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Strange build error on port evbarm64
I've done some additional experimentation This does not seem to be a result of using -O vs -M (ie, MAKEOBJDIR vs MAKEOBJDIRPREFIX). I get the same failure with each option. It also does not seem to be a problem on my branch, as I get the same failure on HEAD. /build/netbsd-compat/tools/x86_64/evbarm64/bin/aarch64--netbsd-install -c -r -m 444 bootaa64.efi /build/netbsd-compat/release/evbarm/installation/misc aarch64--netbsd-install: /build/netbsd-compat/release/evbarm/installation/misc.inst.8ySV7u: mkstemp: No such file or directory The error message would seem to indicate that the directory $RELEASEDIR/release/evbarm/installation does not exist, thus mkstemp cannot create the new temp file misc.inst.* within the directory. Looking closer, I find that the directory /installation DOES exist! And there is even a /installation/misc subdirectory. The install command seems to have some sort of typo - it is trying to create the temp file in /installation/misc.inst.xx vs /installation/misc/inst.xx ^ __| I don't understand why this does not cause a problem on the releng builds. Anyway, I'm not going to worry about it, as long as it's not a problem due to my pgoyette-compat branch! On Wed, 17 Oct 2018, Paul Goyette wrote: While trying to make sure I haven't broken anything, I've been building the same 67 builds as the releng cluster, on my pgoyette-compat branch. I get the same success/failure as the releng cluster, which tells me that my changes are unlikely to produce a build failure. With one exception - the evbarm-aarch64 build... I consistently get the following failure during the "release" target (this is with build.sh's noise level set to 3, so I can see the actual command that fails): /build/netbsd-compat/tools/x86_64/evbarm64/bin/aarch64--netbsd-install -c -r -m 444 bootaa64.efi /build/netbsd-compat/release/evbarm/installation/misc aarch64--netbsd-install: /build/netbsd-compat/release/evbarm/installation/misc.inst.8ySV7u: mkstemp: No such file or directory The error message would seem to indicate that the directory $RELEASEDIR/release/evbarm/installation does not exist, thus mkstemp cannot create the new temp file misc.inst.* within the directory. Of course, the exact file name varies from build to build, but the failure occurs in the same place, every time. And the failure occurs regardlesss of j=1 vs j=12, and it occurs whether or not I have -V MKDEBUG=yes defined. Yet the releng build succeeds. The only remaining (significant) difference I can see is my use of -O /obj/evbarm64 vs -M /evbarm-aarch64/201810160500Z-obj I do not specify the stuff for reproducible builds, but that should not matter (famous last words?). -P -B 201810160500Z -V NETBSD_OFFICIAL_RELEASE=no I can provide the entire log file (with noise-level=3) if it would be helpful. Here is the log header, along with a bit more context around the eventual failure: ===> build.sh command:./build.sh -T /build/netbsd-compat/tools/x86_64/evbarm64 -D /build/netbsd-compat/dest/evbarm64 -O /build/netbsd-compat/obj/evbarm64 -R /build/netbsd-compat/release -V RELEASEMACHINEDIR=evbarm64 -V MKDEBUG=yes -V MKKDEBUG=no -U -N3 -m evbarm64 -j1 release ===> build.sh started:Wed Oct 17 02:04:05 UTC 2018 ===> NetBSD version: 8.99.25 ===> MACHINE: evbarm ===> MACHINE_ARCH:aarch64 ===> Build platform: NetBSD 8.99.25 amd64 ===> HOST_SH: /bin/sh ===> MAKECONF file: /etc/mk.conf ===> TOOLDIR path:/build/netbsd-compat/tools/x86_64/evbarm64 ===> DESTDIR path:/build/netbsd-compat/dest/evbarm64 ===> RELEASEDIR path: /build/netbsd-compat/release ===> Updated makewrapper: /build/netbsd-compat/tools/x86_64/evbarm64/bin/nbmake-evbarm64 ... release ===> etc/evbarm/cdroms/installcd cd /build/netbsd-compat/src/sys/stand/efiboot/bootaa64 && /build/netbsd-compat/tools/x86_64/evbarm64/bin/nbmake release rm -f machine && ln -s /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/evbarm/include machine if [ -d /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/aarch64/include ]; then rm -f aarch64 && ln -s /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/aarch64/include aarch64; fi if [ -d /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/evbarm/include ]; then rm -f evbarm && ln -s /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/evbarm/include evbarm; fi if [ -d /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/arm/include ]; then rm -f arm && ln -s /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/arm/include arm; fi true /build/netbsd-compat/tools/x86_64/evbarm64/bin/aarch64--netbsd
Strange build error on port evbarm64
While trying to make sure I haven't broken anything, I've been building the same 67 builds as the releng cluster, on my pgoyette-compat branch. I get the same success/failure as the releng cluster, which tells me that my changes are unlikely to produce a build failure. With one exception - the evbarm-aarch64 build... I consistently get the following failure during the "release" target (this is with build.sh's noise level set to 3, so I can see the actual command that fails): /build/netbsd-compat/tools/x86_64/evbarm64/bin/aarch64--netbsd-install -c -r -m 444 bootaa64.efi /build/netbsd-compat/release/evbarm/installation/misc aarch64--netbsd-install: /build/netbsd-compat/release/evbarm/installation/misc.inst.8ySV7u: mkstemp: No such file or directory The error message would seem to indicate that the directory $RELEASEDIR/release/evbarm/installation does not exist, thus mkstemp cannot create the new temp file misc.inst.* within the directory. Of course, the exact file name varies from build to build, but the failure occurs in the same place, every time. And the failure occurs regardlesss of j=1 vs j=12, and it occurs whether or not I have -V MKDEBUG=yes defined. Yet the releng build succeeds. The only remaining (significant) difference I can see is my use of -O /obj/evbarm64 vs-M /evbarm-aarch64/201810160500Z-obj I do not specify the stuff for reproducible builds, but that should not matter (famous last words?). -P -B 201810160500Z -V NETBSD_OFFICIAL_RELEASE=no I can provide the entire log file (with noise-level=3) if it would be helpful. Here is the log header, along with a bit more context around the eventual failure: ===> build.sh command:./build.sh -T /build/netbsd-compat/tools/x86_64/evbarm64 -D /build/netbsd-compat/dest/evbarm64 -O /build/netbsd-compat/obj/evbarm64 -R /build/netbsd-compat/release -V RELEASEMACHINEDIR=evbarm64 -V MKDEBUG=yes -V MKKDEBUG=no -U -N3 -m evbarm64 -j1 release ===> build.sh started:Wed Oct 17 02:04:05 UTC 2018 ===> NetBSD version: 8.99.25 ===> MACHINE: evbarm ===> MACHINE_ARCH:aarch64 ===> Build platform: NetBSD 8.99.25 amd64 ===> HOST_SH: /bin/sh ===> MAKECONF file: /etc/mk.conf ===> TOOLDIR path:/build/netbsd-compat/tools/x86_64/evbarm64 ===> DESTDIR path:/build/netbsd-compat/dest/evbarm64 ===> RELEASEDIR path: /build/netbsd-compat/release ===> Updated makewrapper: /build/netbsd-compat/tools/x86_64/evbarm64/bin/nbmake-evbarm64 ... release ===> etc/evbarm/cdroms/installcd cd /build/netbsd-compat/src/sys/stand/efiboot/bootaa64 && /build/netbsd-compat/tools/x86_64/evbarm64/bin/nbmake release rm -f machine && ln -s /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/evbarm/include machine if [ -d /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/aarch64/include ]; then rm -f aarch64 && ln -s /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/aarch64/include aarch64; fi if [ -d /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/evbarm/include ]; then rm -f evbarm && ln -s /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/evbarm/include evbarm; fi if [ -d /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/arm/include ]; then rm -f arm && ln -s /build/netbsd-compat/src/sys/stand/efiboot/bootaa64/../../../arch/arm/include arm; fi true /build/netbsd-compat/tools/x86_64/evbarm64/bin/aarch64--netbsd-install -c -r -m 444 bootaa64.efi /build/netbsd-compat/release/evbarm/installation/misc aarch64--netbsd-install: /build/netbsd-compat/release/evbarm/installation/misc.inst.8ySV7u: mkstemp: No such file or directory *** [release] Error code 1 Any help you can provide on identifying why I cannot get a successful build.sh release would be appreciated! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: flist issue for current build
On Mon, 8 Oct 2018, Adam Ciarci?~Dski wrote: They come from: - src/crypto/external/bsd/openssl/lib/libcrypto/man/Makefile (upper-case man-pages) - src/crypto/external/bsd/openssl/lib/libdes/Makefile (lower-case man-pages) But why are you getting .3.gz files? If it were plain .3 files I could understand the issue, but .3.gz ? By using MKMANZ=yes :) I knew I had seen this option before! The option is, however, not documented in the src/BUILDING file. (It is mentioned in the src/share/mk/bsd.README file, along with a number of other MKxxx variables.) Would it be a good idea to add a cross-reference from BUILDING to the bsd.README file? Or consolidate the information in one place or the other? +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: flist issue for current build
Hmmm, since you are building on macos, it could be a case-sensitive file system issue. I have a hmac man page in section 3, but not HMAC. On Mon, 8 Oct 2018, Adam wrote: Greetings, This is what I get while trying to build amd64 or i386 (today sources). === 3 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/share/man/man3/DES_random_key.3.gz ./usr/share/man/man3/HMAC.3.gz ./usr/share/man/man3/MD5.3.gz = end of 3 extra files === Please, fix. :) Did you start with an empty destdir? Martin Yes. I usually point the destdir to a ram-disk, so it's always empty. Also, I cross-build on macOS, but that shouldn't matter, right? Kind regards, Adam !DSPAM:5bbb25ce195973638832627! +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Problem with /etc/security script?
On Sun, 7 Oct 2018, Robert Elz wrote: Date:Sun, 7 Oct 2018 07:39:42 +0800 (+08) From:Paul Goyette Message-ID: | I'm just using a normal simple postfix as far as I know. You could check its config, to see how it delivers mail (but it should be using mail.local to do that, and invoking it without the -l flag unless your /var/mail is accessed via NFS. No config changes in the last few days, and this just starting happening a few days ago. I _think_ there's something updated in pkgsrc which is doing this, but I have nearly 600 packages installed and no clue as to which ones were recently updated. (I rebuild and reinstall my entire package-set as a unit, not individually...) But it is more likely that the .lock files are coming from some user agent - something that is reading mail, and has been configured to use the wrong kind of locking when fetching mail from /var/mail Possible - see above. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Problem with /etc/security script?
On Sun, 7 Oct 2018, Robert Elz wrote:
Date:Sun, 7 Oct 2018 05:23:00 +0800 (+08)
From:Paul Goyette
Message-ID:
| Lately I've been noticing messages of the following form:
|
| Checking mailbox ownership.
| user paul.lock mailbox is owned by paul
| user paul.lock mailbox is --, group wheel
You might want to work out what is using .lock file style locking in /var/mail
The current convention is to to use O_EXLOCK normally, not that old
style locking.
I'm just using a normal simple postfix as far as I know.
| It seems like /etc/security tried to skip over the .lock files, but the
| test only checks for the filename having a leading '.' rather than
| matching ${user}.lock
I think it is intending to skip over dot files, rather than lock files. '.'
is a valid char in user names, even if not often used, so simply
omitting files containing dots would not be a good idea. If we wanted
to allow for old style user.lock files it would want to be skipping file
names that end in ".lock" not ones that happen to contain a '.'
(and then probably not skip, but validate that the xxx in xxx.lock is
owned by xxx)
Hmmm.
+--+------++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++
Problem with /etc/security script?
Lately I've been noticing messages of the following form:
Checking mailbox ownership.
user paul.lock mailbox is owned by paul
user paul.lock mailbox is --, group wheel
It seems like /etc/security tried to skip over the .lock files, but the
test only checks for the filename having a leading '.' rather than
matching ${user}.lock
if checkyesno check_varmail; then
ls -lA /var/mail | \
awk ' NR == 1 { next; }
$9 ~ /^\./ {next; }
$3 != $9 {
print "user " $9 " mailbox is owned by " $3
}
$1 != "-rw---" {
print "user " $9 " mailbox is " $1 ", group " $4
}' > $OUTPUT
if [ -s $OUTPUT ] ; then
printf "\nChecking mailbox ownership.\n"
cat $OUTPUT
fi
fi
Shouldn't the dot-check line be
$9 ~ /\./ {next; }
?
Problem building a release of aarch64
I've managed to get clean builds on my [pgoyette-compat] branch from 66 out of the 67 architectures that are currently being built by the releng build cluster. The only one that isn't working is aarch64. It seems to get all the way through building the world, but it fails at this point: ... release ===> etc/evbarm/instkernel/sshramdisk release ===> etc/evbarm/instkernel/instkernel test -z "" || /build/test/tools/x86_64/evbarm64/bin/aarch64--netbsd-install -r -p -c -m 444/build/test/release/evbarm64/installation/instkernel release ===> etc/evbarm/cdroms release ===> etc/evbarm/cdroms/installcd cd /build/test/src/sys/stand/efiboot/bootaa64 && /build/test/tools/x86_64/evbarm64/bin/nbmake release /build/test/tools/x86_64/evbarm64/bin/aarch64--netbsd-install -c -p -r -m 444 bootaa64.efi /build/test/release/evbarm/installation/misc aarch64--netbsd-install: /build/test/release/evbarm/installation/misc.inst.sJgZbU: mkstemp: No such file or directory *** [release] Error code 1 Thinking that I might have broken something, I checked out sources from MAIN, at the point of my most recent sync-with-head. (This corresponds to tag pgoyette-compat-0930, very close to 2018-09-30 at 00:00 UTC.) And sure enough, a build of the MAIN branch at that time-stamp fails in the same manner. I had seen similar failures earlier, for some of the evbearm's, and I traced those down to an accidental use of MKKDEBUG (which turns on -g for gcc compiles, which makes things a lot bigger). But I've checked my logs and confirmed that MKKDEBUG is no longer enabled, and the only kernel source being compiled with -g is debugsyms.o Does anyone have any additional clues as to what might be going wrong? FWIW, here's my build.sh command: cd /build/test/src ./build.sh \ -T /build/test/tools/x86_64/evbarm64 \ -D /build/test/dest/evbarm64 \ -O /build/test/obj/evbarm64 \ -R /build/test/release \ -V RELEASEMACHINEDIR=evbarm64 \ -V MKDEBUG=no \ -V MKKDEBUG=no -U -m evbarm64 \ -j1 release And the /build/test/src sources were checked out from anoncvs using cvs update -r pgoyette-compat-0930 +--+------++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
A -current kernel fails to boot - amd64
I was trying to boot a new kernel to test out recent USB changes (to see if they've fixed the problem I reported in kern/50319), but the kernel doesn't boot. Almost immediately after loading the kernel, and after only 3 or four lines of green console text being displayed, the screen goes totally black (without even a cursor). This is _very_ early in the boot process, and _long_ before the usual console-display-mode-switch from drmkms. After a brief interval, the machine reboots, so I suspect it is panic()ing; but there is no crash or panic info displayed on the blank screen. I run on a system with GTX 1050-Ti video card, and I know that this is currently unsupported by the nouveau(4) driver. But it runs just fine under a 8.99.22 kernel built from 2018-07-25 07:42:52 UTC sources (as seen by the attached dmesg). Since the screen goes totally black very quickly, and the small amount of text being displayed, and the lack of any other console mechanism, it is unfortunately not possible for me to provide any further debug info. I suspect that this might be caused by recent drmkms changes... +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++ dmesg.txt.gz Description: Binary data
Problem with -current - video-card related?
While attempting to verify kern/53019 I tried to boot a -current kernel from today's sources, unsuccessfully. It seems to load everything, then clears the display, prints out about two or three lines of text, and then the display goes completely black (not even a cursor). It obviously panics, because in a short while it reboots. FWIW I have a GTX 1050-Ti (nouveau) video card, running in "vga" mode (I don't enable vesa at the boot prompt). And it works just fine on a 8.99.22 kernel (as long as "fine" doesn't imply "video acceleration"). I have attached a copy of my dmesg output (gzipped to avoid any limits on message length!) in case it helps. +--+------++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++ dmesg.txt.gz Description: Binary data
Re: Error in vi (or in man page)
On Fri, 14 Sep 2018, Rin Okuyama wrote: On 2018/09/14 20:37, Christos Zoulas wrote: In article , Rin Okuyama wrote: ... It would be better to fix our vi in accordance with POSIX. Thoughts? I think it is better to keep the behavior (exit) and fix the man page. vim exits too. It is usually the case that the user does not want to edit the file with the same name! Well, I agree that the current behavior is safer for users. I fixed the manpage. Thank you! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Error in vi (or in man page)
On Fri, 14 Sep 2018, Christos Zoulas wrote: I think it is better to keep the behavior (exit) and fix the man page. vim exits too. It is usually the case that the user does not want to edit the file with the same name! In my case, it was a typo. I meant -R vs -r, so yes I really did intend to edit the file, just read-only. It doesn't really matter to me which one we fix; I'm mostly concerned about having the code match the docs. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Error in vi (or in man page)
Current vi(1) man page says -r Recover the specified files, or, if no files are specified, list the files that could be recovered. If no recoverable files by the specified name exist, the file is edited as if the -r option had not been specified. However, in actuality, if no recoverable files by the specified name exist, vi simply reports that fact, and does nothing; it does not edit the file "as if the -r option had not been specified." # ls kern_time_50.c kern_time_50.c # vi -r kern_time_50.c No files named kern_time_50.c, readable by you, to recover # +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Something got too big - build.sh install-image broke!
With sources updated on 2018-09-05 at 10:59:37 UTC (about 11 hours ago) I'm seeing ... Creating rootfs... chmod +r work/var/spool/ftp/hidden /build/netbsd-local/tools/x86_64/amd64/bin/nbmakefs -M 1488977920 -m 1488977920 -B 1234 -F work.spec -N work/etc -o bsize=16384,fsize=2048,density=8192 work.rootfs work nbmakefs: `work' size of 1496743936 is larger than the maxsize of 1488977920. *** Failed target: imgroot.fs Any clues on what to bump? +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Build failure due to DRM intel i915
I just did a build.sh release on sources updated as of 2018-08-29 at
07:46:17 UTC without any issue.
On Wed, 29 Aug 2018, Riccardo Mottola wrote:
Hi,
I upgraded CVS this morning (3 hours ago), built tools and kernel.
When building Kernl Modules, I get this failure:
# compile i915drmkms/intel_dsi.o
/usr/src/obj/tooldir.NetBSD-8.99.23-amd64/bin/x86_64--netbsd-gcc -O2
-march=core2 -g -std=gnu99 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers
-Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow
-Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare
-Werror -Wno-shadow -ffreestanding -fno-strict-aliasing -Wno-pointer-sign
-mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float -mcmodel=kernel
-fno-omit-frame-pointer -I/usr/src/common/include
--sysroot=/usr/src/obj/destdir.amd64 -I/usr/src/sys/external/bsd/drm2/include
-I/usr/src/sys/external/bsd/common/include
-I/usr/src/sys/external/bsd/drm2/dist/include
-I/usr/src/sys/external/bsd/drm2/dist/include/drm
-I/usr/src/sys/external/bsd/drm2/dist/uapi
-I/usr/src/sys/external/bsd/drm2/dist -D__KERNEL__
-DCONFIG_BACKLIGHT_CLASS_DEVICE=0 -DCONFIG_BACKLIGHT_CLASS_DEVICE_MODULE=0
-DCONFIG_DRM_FBDEV_EMULATION=0 -DCONFIG_FB=0 -DDIAGNOSTIC
-I/usr/src/sys/sys/modules/drmkms -I/usr/src/sys/external/bsd/drm2/i915drm
-I/usr/src/sys/external/bsd/drm2/dist/drm/i915 -DCONFIG_DRM_I915_FBDEV=1
-DCONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=0 -DNACPICA=1 -DNVGA=1
-I/usr/src/common/include -nostdinc -I. -I/usr/src/sys/modules/i915drmkms
-isystem /usr/src/sys -isystem /usr/src/sys/arch -isystem
/usr/src/sys/../common/include -D_KERNEL -D_LKM -D_MODULE
-DSYSCTL_INCLUDE_DESCR -c
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c
In file included from
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:42:0:
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.h:107:23: error: field
'base' has incomplete type
struct mipi_dsi_host base;
^~~~
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:97:25: error:
'struct mipi_dsi_msg' declared inside parameter list will not be visible
outside of this definition or declaration [-Werror]
const struct mipi_dsi_msg *msg)
^~~~
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c: In function
'intel_dsi_host_transfer':
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:103:25: error:
storage size of 'packet' isn't known
struct mipi_dsi_packet packet;
^~
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:108:8: error:
implicit declaration of function 'mipi_dsi_create_packet'
[-Werror=implicit-function-declaration]
ret = mipi_dsi_create_packet(&packet, msg);
^~
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:115:9: error:
dereferencing pointer to incomplete type 'const struct mipi_dsi_msg'
if (msg->flags & MIPI_DSI_MSG_USE_LPM) {
^~
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:115:19: error:
'MIPI_DSI_MSG_USE_LPM' undeclared (first use in this function)
if (msg->flags & MIPI_DSI_MSG_USE_LPM) {
^~~~
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:115:19: note: each
undeclared identifier is reported only once for each function it appears in
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:105:21: error:
variable 'data' set but not used [-Werror=unused-but-set-variable]
const u8 *header, *data;
^~~~
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:103:25: error:
unused variable 'packet' [-Werror=unused-variable]
struct mipi_dsi_packet packet;
^~
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c: At top level:
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:172:21: error:
variable 'intel_dsi_host_ops' has initializer but incomplete type
static const struct mipi_dsi_host_ops intel_dsi_host_ops = {
^
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:173:2: error:
unknown field 'attach' specified in initializer
.attach = intel_dsi_host_attach,
^
/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_dsi.c:173:12: error:
excess elements in struct initializer [-Werror]
.attach = intel_dsi_host_attach,
I suppose this is due to the recent import!
cheers,
Riccardo
!DSPAM:5b867a60142972046016392!
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++
Re: HEADS UP: drmkms update incoming
On Mon, 27 Aug 2018, Taylor R Campbell wrote: The drmkms update commit bomb is finished. I've compile-tested amd64, i386, macppc, sparc64, and evbarm/TEGRA, and they all build. I'll be around this evening US/Eastern to clean up fallout, of which I'm sure there will be some, but I need to get to $DAYJOB for a while now! I know that most everyone else already has the context. But for those few of us who don't, could you give a quick statement of what this actually accomplishes, besides importing the current state-of-linux as of version x.y.z? Do we get support for new(er) graphics cards (if so,which ones)? Do we get specific functionality that was not available in the previous code? Is this all (for now), or is there more coming? (I remember there being a comment on IRC about "doing it all over again" to come up to speed with the next go-round...) Oh, and I guess this info would also belong in src/doc/CHANGES if it hasn't already been added. :) Thanks so much for all the hard work, to you (and maya and everyone (else who collaborated on this. It was obviously a herculean task, and it's nice to know that someone(tm) was up to it! +--+------++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Build break - kasan issue in rump
FWIW, I suspect the following will fix the build break: --- kern_malloc.c 20 Aug 2018 15:04:52 - 1.148 +++ kern_malloc.c 21 Aug 2018 01:19:22 - @@ -72,7 +72,9 @@ #include __KERNEL_RCSID(0, "$NetBSD: kern_malloc.c,v 1.148 2018/08/20 15:04:52 maxv Exp $"); +#ifdef _KERNEL_OPT #include "opt_kasan.h" +#endif #include #include On Tue, 21 Aug 2018, Paul Goyette wrote: Always rump finds stuff! This is on amd64, with sources updated as of 2018-08-20 at 22:44:31 UTC #create librump/kern_malloc.d . . . /build/netbsd-local/src_ro/lib/librump/../../sys/rump/../kern/kern_malloc.c:75:23: fatal error: opt_kasan.h: No such file or directory #include "opt_kasan.h" ^ compilation terminated. +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++ +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Build break - kasan issue in rump
Always rump finds stuff! This is on amd64, with sources updated as of 2018-08-20 at 22:44:31 UTC #create librump/kern_malloc.d . . . /build/netbsd-local/src_ro/lib/librump/../../sys/rump/../kern/kern_malloc.c:75:23: fatal error: opt_kasan.h: No such file or directory #include "opt_kasan.h" ^ compilation terminated. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
tools build failure?
Anyone else seeing this? # link mandoc/mandoc cc -O -DOSNAME=\"NetBSD\ 8.99\" -DHAVE_CONFIG_H -I. -I/build/netbsd-local/tools/x86_64/amd64/include/compat -I/build/netbsd-local/src_ro/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -o mandoc eqn_html.lo eqn_term.lo html.lo main.lo man_html.lo man_term.lo mandoc_xr.lo manpath.lo mdoc_html.lo mdoc_markdown.lo mdoc_term.lo out.lo roff_html.lo roff_term.lo tbl_html.lo tbl_term.lo term.lo term_ascii.lo term_ps.lo term_tab.lo tree.lo att.lo chars.lo compat_ohash.lo eqn.lo lib.lo man.lo man_macro.lo man_validate.lo mandoc.lo mandoc_aux.lo mandoc_ohash.lo mdoc.lo mdoc_argv.lo mdoc_macro.lo mdoc_man.lo mdoc_state.lo mdoc_validate.lo msec.lo preconv.lo read.lo roff.lo roff_validate.lo st.lo tag.lo tbl.lo tbl_data.lo tbl_layout.lo tbl_opts.lo compat_strtonum.lo compat_reallocarray.lo -L/build/netbsd-local/tools/x86_64/amd64/lib -lnbcompat -lrt -lz mandoc_aux.lo: In function `mandoc_recallocarray': mandoc_aux.c:(.text+0x13c): undefined reference to `recallocarray' *** [mandoc] Error code 1 nbmake[3]: stopped in /build/netbsd-local/src_ro/tools/mandoc 1 error It's repeatable at least on my system, and a cvs update shows no new changes... +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Problem with shutting down the Xserver
On Fri, 27 Jul 2018, Martin Husemann wrote: For debugging: make sure you have the debug and xdebug sets installed. Make the system accessible via ssh. When the problem happens again: from another machine ssh in, pgrep for the X server, use gdb -p to attach to it and get a backtrace. "ssh in" won't work - the machine is non-responsive to network. :( Also, unfortunately, the only "other machine" I have is a Windoze laptop; I doubt that it would be a suitable place on which to run the "gdb -p" command. Oh, so the kernel driver actually locks up? Notebook or desktop? Next suggestion would be serial console and try to enter ddb ... The problem machine is a desktop. It has a serial port. Unfortunately the Windoze laptop does not, so nothing to which the other end of a serial cable could be attached. +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Problem with shutting down the Xserver
On Fri, 27 Jul 2018, Martin Husemann wrote: On Fri, Jul 27, 2018 at 08:26:12AM +0800, Paul Goyette wrote: Has anyone else seen anything similar? Any suggestions on how to debug this further? For debugging: make sure you have the debug and xdebug sets installed. Make the system accessible via ssh. When the problem happens again: from another machine ssh in, pgrep for the X server, use gdb -p to attach to it and get a backtrace. "ssh in" won't work - the machine is non-responsive to network. :( Also, unfortunately, the only "other machine" I have is a Windoze laptop; I doubt that it would be a suitable place on which to run the "gdb -p" command. +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Problem with shutting down the Xserver
Sometime not so long ago, my old video card died and I had to get a new one. Ever since then, when I "log out" the Xserver locks up my system. Details: 1. This has been happening at least since the end of May, running a -current 6.99.18 kernel. I've just completed an update to yesterday's 6.99.22 and the problem still existgs. 2. I'm using "native" X from xsrc, _not_ using pkgsrc. 3. I use xdm to manage my one display. 4. The problem occurs whether I'm using my personal account (which has fvwm window manager) or root (which uses the default twm). So it is unlikely to be related to the window manager. 5. When I terminate my X session, the screen resets and then goes completely black and a simple underline cursor appears at the top-left corner. A few seconds later the cursor disappears. As far as I can tell, the video card is still generating a valid signal, as the monitor does not display its "No signal" warning. 6. The video card being used is a nVidia GeForce GTX 1050 Ti: dmesg: vga0 at pci1 dev 0 function 0: vendor 10de product 1c82 (rev. 0xa1) wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation) lspci: +-03.0-[01]--+-00.0 NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] |\-00.1 NVIDIA Corporation GP107GL High Definition Audio Controller From the above you can see that I'm using the basic vga driver, since the nouveau driver doesn't handle such a modern card. 7. As far as I can tell, the X server is using the vesa display driver, with the vbe sub-module: ... [ 162.803] (II) LoadModule: "vesa" [ 162.804] (II) Loading /usr/X11R7/lib/modules/drivers/vesa_drv.so [ 162.815] (II) Module vesa: vendor="X.Org Foundation" [ 162.815]compiled for 1.18.4, module version = 2.4.0 [ 162.815]Module class: X.Org Video Driver [ 162.815]ABI class: X.Org Video Driver, version 20.0 ... [ 162.857] (II) VESA: driver for VESA chipsets: vesa [ 162.857] (--) Using wscons driver on /dev/ttyE4 in pcvt compatibility mode (version 3.32) [ 162.857] (--) using VT number 5 [ 162.886] (EE) [drm] Failed to open DRM device for pci:0001:01:00.0: -19 [ 162.890] (EE) [drm] Failed to open DRM device for pci:0001:01:00.0: -19 [ 162.890] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 162.890] (II) Loading sub module "vbe" [ 162.890] (II) LoadModule: "vbe" ... [ 163.001] (II) VESA(0): Creating default Display subsection in Screen section "Builtin Default vesa Screen 0" for depth/fbbpp 24/32 [ 163.001] (==) VESA(0): Depth 24, (--) framebuffer bpp 32 [ 163.001] (==) VESA(0): RGB weight 888 [ 163.001] (==) VESA(0): Default visual is TrueColor [ 163.001] (==) VESA(0): Using gamma correction (1.0, 1.0, 1.0) ... 8. The problem occurs whether or not I execute a ``vesa on'' command in the boot loader. 9. The system doesn't reboot, and does not respond to network pings. It also does not seem to have entered DDB(4) since it appears to have (tried to) reset the video card and switch to vt0. (I have ddb.onpanic set to "2" for some reason I cannot remember, and now I can't even find the docs on what "2" means!) If I ``kill -KILL ...'' all of the processes related to xdm (including the X server itself), then the system does not hang, and I can log in on the console and manually execute ``/etc/rc.d/xdm start'' and everything is back to normal. This would indicate to me that the X server is doing some sort of clean-up processing and that that is failing. Has anyone else seen anything similar? Any suggestions on how to debug this further? +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: panic when removing a file in current
On Thu, 19 Jul 2018, Paul Goyette wrote: Let me update my source tree, re-build, and check. What port are you using? i386? amd64? other? Hmmm. A -currrent from just a few minutes ago builds and runs correctly on amd64 (using QEMU). # dd if=/dev/zero of=test.test bs=8192 count=1k 1024+0 records in 1024+0 records # rm test.test # uname -a NetBSD 8.99.22 NetBSD 8.99.22 (GENERIC) #1: Thu Jul 19 03:30:19 UTC 2018 p...@speedy.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/GENERIC amd64 # On Thu, 19 Jul 2018, Johnny Billquist wrote: Anyone seen this, or know what it's about? On NetBSD/vax, with 8.99.22 from today. Removing any file that has disk blocks allocated to it: [ 653.3285523] ufs_inactive: unlinked ino 50313 on "/home" has non zero size 0 or blocks 1ac0 with allerror 0 [ 653.3484633] panic: ufs_inactive: dirty filesystem? [ 653.3788284] cpu0: Begin traceback... [ 653.3984724] panic: ufs_inactive: dirty filesystem? [ 653.4090004] Stack traceback : [ 653.4231115] Process is executing in user space. [ 653.4286045] cpu0: End traceback... Stopped in pid 39.1 (rm) at netbsd:vpanic+0xc5: pushl $0 If a file is small enough to have all the data in the inode itself, rm survives fine. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++ !DSPAM:5b50040990413217635383! +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: panic when removing a file in current
Let me update my source tree, re-build, and check. What port are you using? i386? amd64? other? On Thu, 19 Jul 2018, Johnny Billquist wrote: Anyone seen this, or know what it's about? On NetBSD/vax, with 8.99.22 from today. Removing any file that has disk blocks allocated to it: [ 653.3285523] ufs_inactive: unlinked ino 50313 on "/home" has non zero size 0 or blocks 1ac0 with allerror 0 [ 653.3484633] panic: ufs_inactive: dirty filesystem? [ 653.3788284] cpu0: Begin traceback... [ 653.3984724] panic: ufs_inactive: dirty filesystem? [ 653.4090004] Stack traceback : [ 653.4231115] Process is executing in user space. [ 653.4286045] cpu0: End traceback... Stopped in pid 39.1 (rm) at netbsd:vpanic+0xc5: pushl $0 If a file is small enough to have all the data in the inode itself, rm survives fine. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol !DSPAM:5b50017885611524031356! +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: incomplete obsolescence of "viadrm"
On Thu, 12 Jul 2018, m...@netbsd.org wrote: On Thu, Jul 12, 2018 at 09:32:47AM +0800, Paul Goyette wrote: While we're on the subject of viadrm, I noticed that it was removed from the amd64 GENERIC and ALL configs. Since one of the premises of removal was that viadrmums was a suitable replacement, shouldn't that have been added to the relevant configs? If you think it's good, we can enable it by default. On my machine it produces a corrupt display, although I think vesa failed harder. It should be included in ALL, whether or not it works 100%. I have no problem with adding it as a comment line in GENERIC. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: incomplete obsolescence of "viadrm"
While we're on the subject of viadrm, I noticed that it was removed from the amd64 GENERIC and ALL configs. Since one of the premises of removal was that viadrmums was a suitable replacement, shouldn't that have been added to the relevant configs? On Wed, 11 Jul 2018, John D. Baker wrote: Following the removal of "viadrm" from sources and i386 GENERIC and ALL configs, the module form is only being obsoleted and removed from: /stand/i386/8.99.21/modules/viadrm/viadrm.kmod and its immediate parent directory. There are two other instances which are not being accounted for: /stand/i386-xen/8.99.21/modules/viadrm/viadrm.kmod /stand/i386pae-xen/8.99.21/modules/viadrm/viadrm.kmod Following the latest 'postinstall ... fix obsolete', only the first instance was removed while the other two were left intact. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645 !DSPAM:5b46ae64281411907016811! +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Xen Domu kernel crash at start of boot
Stopped in pid 0.15 (system) at 80205968: fxsavel
I seem to recall some recent changes related to save/restore of fpu
state.
On Thu, 21 Jun 2018, Chuck Zmudzinski wrote:
I am getting a kernel crash almost immediately after booting the current
kernel. I am running NetBSD/xen amd64 on a Debian Linux 8.10 DOM0 which uses
Xen-4.4. Last week's kernel was good. I built a kernel from a cvs update a
couple of days ago and tried it. It crashed. I tried the most recent daily
snapshot available from NetBSD daily builds. It crashed too. Here is the
information from the console about the daily snapshot kernel that crashed (it
was built earlier today):
[ 1.000] NetBSD 8.99.19 (XEN3_DOMU) #0: Thu Jun 21 11:48:05 UTC 2018
[ 1.000]
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/xen/compile/XEN3_DOMU
Here is the information I got from the console about the crash:
[ 1.000] total memory = 3072 MB
[ 1.000] avail memory = 2963 MB
[ 1.000] cpu_rng: RDRAND
[ 1.000] running cgd selftest aes-xts-256 aes-xts-512 done
[ 1.000] mainbus0 (root)
[ 1.000] hypervisor0 at mainbus0: Xen version 4.4.1
[ 1.000] vcpu0 at hypervisor0
[ 1.000] vcpu0: Intel(R) Core(TM) i5-4590S CPU @ 3.00GHz, id 0x306c3
[ 1.000] vcpu0: package 0, core 3, smt 0
[ 1.000] vcpu1 at hypervisor0
[ 1.000] vcpu1: Intel(R) Core(TM) i5-4590S CPU @ 3.00GHz, id 0x306c3
[ 1.000] vcpu1: package 0, core 3, smt 0
[ 1.000] xenbus0 at hypervisor0: Xen Virtual Bus Interface
[ 1.000] xencons0 at hypervisor0: Xen Virtual Console Driver
[ 1.030] fatal protection fault in supervisor mode
[ 1.030] trap type 4 code 0 rip 0x80205968 cs 0x1e030
rflags 0x10046 cr2 0 ilevel 0 rsp 0xa000a570fbf0
[ 1.030] curlwp 0xa642d4a0 pid 0.15 lowest kstack
0xa000a570b2c0
kernel: protection fault trap, code=0
Stopped in pid 0.15 (system) at 80205968: fxsavel
ds 0
es 0
fs fd00
gs 0
rdi a000a570fbf8
rsi 1
rbp a000a570fe68
rbx 0
rdx 2
rcx 0
rax 0
r8 a668
r9 cccd
r10 64
r11 0
r12 a000a570fbf8
r13 1
r14 0
r15 0
rip 80205968
cs e030
rflags 10046
rsp a000a570fbf0
ss e02b
80205968: fxsavel
db{1}> bt
?() at 80205968
?() at 802313f0
?() at 8023155e
I could not get any useful info from addr2line. Any ideas why it crashes?
Thanks,
Chuck Zmudzinski
!DSPAM:5b2c48e0136191148838969!
+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++
Re: Radeon video card support
On Wed, 20 Jun 2018, Jonathan A. Kollasch wrote: An RX580 is going to be too new for our version of drmkms. I'm not quite sure where the cutoff is for Radeons. Good Linux support sometimes lags behind a cards marketplace debut. src/doc/3RDPARTY says we've got a drmkms that's circa Linux 3.15, which was released June 8, 2014. So, cards that did not yet exist at that point almost certainly will not work well. Some old chips/cards may have gotten rebadged with newer marketing names, but these are a bit of a support gray area. OK, that makes sense. So perhaps I should reword my inquiry a bit, and ask for suggestions on which video cards folks would recommend. I don't need "gaming", but it would be nice to have support for 2D and 3D acceleration. Also the card needs to support 1920x1080@60Hz with DL-DVI or HDMI output. Hopefully available via Amazon (since they don't have any problem with shipping to the Philippines)... :) Thanks in advance for any suggestions/recommendations. +--+--+--------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Radeon video card support
I'm unfortunately well aware that modern nVidia graphics cardds aren't working with the noveaudrmkms stuff. (I've got this nice spiffy new GTX-1050 running in vesa mode.) I've located a source for a reasonably current, reasonably-priced, radeon card with RX580. But before I rush out and purchase one, I figured it might be a good idea to find out how well it performs from other users. Anyone got any success stories? Or horror stories? :) +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: How to boot in UEFI mode: practically no documentation
I bookmarked this Email a while ago - it might help... https://mail-index.netbsd.org/current-users/2017/02/28/msg031220.html On Tue, 29 May 2018, Thomas Mueller wrote: Where do I find documentation on how to boot NetBSD amd64 or possibly i386 in UEFI mode? I couldn't find any man page and couldn't find anything useful in the online NetBSD wiki. I don't want to be limited to NetBSD, would also want to be able to boot FreeBSD and Linux in UEFI mode. I noticed /usr/mdec/bootx64.efi and bootia32.efi (on an amd64 installation) but don't really know where these would lead to. I also saw /usr/src/sys/arch/i386/stand/efiboot . Tom !DSPAM:5b0d0c85242761302317190! +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Recent spew into SRCDIR from build.sh
On Mon, 7 May 2018, Robert Elz wrote: I've considered putting a read only unionfs mount on top of srcdir, and then use that as the source directory, but I haven't tested that to see how well (if at all) that would work. I use a null mount for src_ro on top of src. Updates get done in the src directory, builds get done from src_ro. +--+--+----+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Recent spew into SRCDIR from build.sh
On Mon, 7 May 2018, Robert Elz wrote: I am seeing a bunch of generated files related to sys/rump and libbozohttp (or something ... see below) recently. These should be in the object directory. I have an up to date tree (the messages below are from cvs-update) - I delete all these files, build again, and they reappear One of the benefits of using a read-only $SRCDIR is prevention of this sort of thing. :) +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
