Re: Missing file after postisnstall?
On Tue, 13 Feb 2018, Paul Goyette wrote: On Tue, 13 Feb 2018, Valery Ushakov wrote: On Tue, Feb 13, 2018 at 05:40:22 +0800, Paul Goyette wrote: I recently updated from 8.99.7 to 8.99.12 and noticed that my daily security job reported a missing file: Checking special files and directories. ./etc/rc.d/dhcpd6 missing Shouldn't this have been found and fixed by postinstall? Why it should be "fixed" if it ain't broken? :) Your system still happily boots without DHCP6 server, isn't it? If you want to update your configuration files to the new etc.tgz you run etcupdate. postinstall only does minimal configuration tweaks that are necessary to keep the system working with the new userland, or at least that was its original design goal as I remember it. I also ran `etcupdate -al -s etc.gz -s xetc.gz` and it does not find the missing rc.d file, either. The missing file is listed in an mtree specification file that was installed as part of the upgrade, so the file should exist. But there doesn't seem to be any "sample" file anywhere in /usr/share so nothing that can be copied. Since the postinstall/etcupdate process has previously found other missing rc.d files, and successfully fixed/installed them, I still consider this to be a bug in -current. The mtree file says the file should exist, but it doesn't. +--+--+----+ | 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 | +--+--++
Missing file after postisnstall?
I recently updated from 8.99.7 to 8.99.12 and noticed that my daily security job reported a missing file: Checking special files and directories. ./etc/rc.d/dhcpd6 missing Shouldn't this have been found and fixed by postinstall? +--+--++ | 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: Status of 8.99.12
On Mon, 12 Feb 2018, Thor Lancelot Simon wrote: On Mon, Feb 12, 2018 at 08:48:32AM +0800, Paul Goyette wrote: 1. Starting the gnucash program (from pkgsrc finance/gnucash) now takes about 3 times as long as before. Even after successfully loading the image (to get libraries etc into the file system cache) it take more than three full minutes for the program to initialize. It previously took 1 full minute? Yes, at least on the initial load (before caching everything). On subsequent loads it would take at least 20-30 seconds to start. How does it look without LOCKDEBUG? I would have to build a new kernel and check. Do you thing it is truly relevant? Would there be a lot of locking/contention occurring during the program start-up phase? FWIW, someone also suggested that the "3-seconds needed to unmount a nullfs" problem could also be affected by LOCKDEBUG. Interestingly, this problem does not seem to persist. Some time after the system is booted, and some time after all the nullfs mounts are completed, the unmount process completes as expected; all 20+ umount complete within total of 3-4 seconds, rather than 3-6 seconds each. I'll try to characterize the "some time after" details later, after resolving the bigger outstanding issues. +--+--+----+ | 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: Missing file after postisnstall?
On Tue, 13 Feb 2018, Valery Ushakov wrote: On Tue, Feb 13, 2018 at 05:40:22 +0800, Paul Goyette wrote: I recently updated from 8.99.7 to 8.99.12 and noticed that my daily security job reported a missing file: Checking special files and directories. ./etc/rc.d/dhcpd6 missing Shouldn't this have been found and fixed by postinstall? Why it should be "fixed" if it ain't broken? :) Your system still happily boots without DHCP6 server, isn't it? If you want to update your configuration files to the new etc.tgz you run etcupdate. postinstall only does minimal configuration tweaks that are necessary to keep the system working with the new userland, or at least that was its original design goal as I remember it. I also ran `etcupdate -al -s etc.gz -s xetc.gz` and it does not find the missing rc.d file, either. +--+--+----+ | 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 | +--+--++
Status of 8.99.12
After an extended period of build breaks, I finally got a new release built from sources updated on 2018-02-10 at 04:02:43 UTC I'm seeing several problems with this release that were not seen with my previous installation (from last November). 1. Starting the gnucash program (from pkgsrc finance/gnucash) now takes about 3 times as long as before. Even after successfully loading the image (to get libraries etc into the file system cache) it take more than three full minutes for the program to initialize. 2. Whenever I try to shutdown the system, I get a networking-related panic. The following is manually transcribed: trap type 4 code 0 rip 0x802d3f75 cs 0x8 rflags 0x10282 cr2 0x77e0e931c020 ilevel 0x4 rsp 0x80090a7e3c80 curlwp 0xe4afbb6e8700 pid 926.1 lowest kstack 0x80090a7e0c20 kernel: protection fault trap, code = 0 stopped in 926.1 (avahi-daemon) at ip_setmoptions+0x237: movq 360(%rax),%rdi traceback: ip_setmoptions + 0x237 ip_rtloutput + 0x218 udp_ctloutput + 0x82 udp_ctloutput_wrapper + 0x2c sosetopt + 0x67 sys_setsockopt + 0x91 syscall + 0x1ed (syscall #105) 3. After getting the above, as soon as I type a single character as command input to ddb(4), I get a LOCKDEBUG panic. I didn't yet transcribe the 40+ lines of output, but the backtrace clearly includes a couple entries from the xhci (USB-3) driver. 4. While the system is running, I have noticed that un-mounting nullfs mounts is very slow. Using mksandbox (from pkgsrc), I create a sandbox with about 22 null mounts. Creating/mounting is no problem, and everything runs as expected. However, when unmounting these nullfs, each one takes between 3 and 6 wall-seconds, during which the umount process is running at 100% of one CPU. Additionally, some of these umounts seem to grab the CPU with interrupts disabled, resulting in total stall of the machine for the duration (and, in X, cursor movement stalls/gets "jerky"). All the unmounts eventually complete successflly. +--+--+----+ | 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: Status of 8.99.12
On Mon, 12 Feb 2018, Ryota Ozaki wrote:
2. Whenever I try to shutdown the system, I get a networking-related
panic. The following is manually transcribed:
trap type 4 code 0 rip 0x802d3f75 cs 0x8 rflags 0x10282
cr2 0x77e0e931c020 ilevel 0x4 rsp 0x80090a7e3c80
curlwp 0xe4afbb6e8700 pid 926.1 lowest kstack
0x80090a7e0c20
kernel: protection fault trap, code = 0
stopped in 926.1 (avahi-daemon) at ip_setmoptions+0x237: movq
360(%rax),%rdi
traceback:
ip_setmoptions + 0x237
ip_rtloutput + 0x218
udp_ctloutput + 0x82
udp_ctloutput_wrapper + 0x2c
sosetopt + 0x67
sys_setsockopt + 0x91
syscall + 0x1ed (syscall #105)
Is the panic fixed by the following patch?
diff --git a/sys/netinet/ip_output.c b/sys/netinet/ip_output.c
index 44d8032f387..2e5e346af91 100644
--- a/sys/netinet/ip_output.c
+++ b/sys/netinet/ip_output.c
@@ -1927,9 +1927,13 @@ ip_drop_membership(struct ip_moptions *imo,
const struct sockopt *sopt)
* Give up the multicast address record to which the
* membership points.
*/
- IFNET_LOCK(imo->imo_membership[i]->inm_ifp);
+{
+ struct ifnet *inm_ifp = imo->imo_membership[i]->inm_ifp;
+ IFNET_LOCK(inm_ifp);
in_delmulti(imo->imo_membership[i]);
- IFNET_UNLOCK(imo->imo_membership[i]->inm_ifp);
+ /* ifp should not leave thanks to solock */
+ IFNET_UNLOCK(inm_ifp);
+}
/*
* Remove the gap in the membership array.
Yes it appears to address the problem. Without this patch, the above
crash was 100% reproducible (5 out of 5). With this patch applied (and
no other changes) I have had 3 consecutive reboots without and problem!
Thanks for the quick turn-around.
+--+--+--------+
| 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: Status of 8.99.12
On Mon, 12 Feb 2018, Paul Goyette wrote: 2. Whenever I try to shutdown the system, I get a networking-related panic. The following is manually transcribed: trap type 4 code 0 rip 0x802d3f75 cs 0x8 rflags 0x10282 cr2 0x77e0e931c020 ilevel 0x4 rsp 0x80090a7e3c80 curlwp 0xe4afbb6e8700 pid 926.1 lowest kstack 0x80090a7e0c20 kernel: protection fault trap, code = 0 stopped in 926.1 (avahi-daemon) at ip_setmoptions+0x237: movq 360(%rax),%rdi traceback: ip_setmoptions + 0x237 ip_rtloutput + 0x218 udp_ctloutput + 0x82 udp_ctloutput_wrapper + 0x2c sosetopt + 0x67 sys_setsockopt + 0x91 syscall + 0x1ed (syscall #105) This appears to be fixed by a patch provided by ozakir@ 3. After getting the above, as soon as I type a single character as command input to ddb(4), I get a LOCKDEBUG panic. I didn't yet transcribe the 40+ lines of output, but the backtrace clearly includes a couple entries from the xhci (USB-3) driver. Here's the console output from the LOCKDEBUG panic - all transcribed by hand, but hopefully without too many typos! Mutex error: mutex_vector_enter,523: spin lock held lock address: 0xe410e9d1d9a0 type: spin initialized: 0x802bac06 shared holds: 0 exclusive: 1 shares wanted: 0 exclusive: 0 current CPU: 11 last held: 11 curlwp: 0xe41fc09ad2c0 last held: 0xe41fc09ad2c0 last locked*: 0x802b81de unlocked: 0x80291179 owner field: 0x00010600 wait/spin:0/1 panic: LOCKDEBUG: Mutex error: mutex_vector_enter,523: spin lock held And the backtrace is vpanic+0x140 snprintf lockdebug_more mutex_enter+0x69d xhci_device_intr_start+0x125 usbd_start_next+0x65 xhci_soft_intr+0x49b xhci_poll+0x37 ukbd_cngetc+0x19 cngetc+0x34 db_readline+0x65 db_read_line+0x15 db_command_loop+0x84 db_trap+0xe3 kbd_trap+0xe2 trap (number 4) followed by the original backtrace (see above, starting with ip_setmoptions). 4. While the system is running, I have noticed that un-mounting nullfs mounts is very slow. Using mksandbox (from pkgsrc), I create a sandbox with about 22 null mounts. Creating/mounting is no problem, and everything runs as expected. However, when unmounting these nullfs, each one takes between 3 and 6 wall-seconds, during which the umount process is running at 100% of one CPU. Additionally, some of these umounts seem to grab the CPU with interrupts disabled, resulting in total stall of the machine for the duration (and, in X, cursor movement stalls/gets "jerky"). All the unmounts eventually complete successflly. +--+--+----+ | 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 | +--+--++
Re: Automated report: NetBSD-current/i386 build failure
On Sat, 10 Feb 2018, Andreas Gustafsson wrote: Christos Zoulas wrote: | i486--netbsdelf-install: CA.pl: stat: No such file or directory | *** [/tmp/bracket/build/2018.02.09.17.14.26-i386/destdir/usr/share/examples/openssl/CA.pl] Error code 1 Looking into it. The build now gets past that point, but later fails at: --- kern-XEN3_DOM0 --- /tmp/bracket/build/2018.02.10.06.22.22-i386/src/sys/arch/i386/i386/db_interface.c:198:12: error: unused variable 'dbreg' [-Werror=unused-variable] db_regs_t dbreg; ^ This was already fixed - thanks to Christos@ +--+--++ | 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: 'drvctl -d' problem
What happens if you cd to /dev first? Or, specify drvctl -d /dev/iwn0 There could be a problem with lookup of the device node... It's happened before, although I thought it had been fixed. On Wed, 21 Feb 2018, Makoto Fujiwara wrote: I'm often use /sbin/drvctl, usually with -d device argument. (the situation is after waked up from sleep). Recently I'm getting syntax error and resulting help shown. The good version is at 8.99.4, and bad example is at 8.99.12. my 8.99.12 version is kept with the name drvctl-8.99.12. Following is the log for above symptom. cf-j10@makoto 11:16:56/180221(..sbin/drvctl)% sudo /sbin/drvctl-8.99.12 -d iwn0 Usage: drvctl-8.99.12 -r [-a attribute] busdevice [locator ...] drvctl-8.99.12 -d device drvctl-8.99.12 [-nt] -l [device] drvctl-8.99.12 [-n] -p device [property] drvctl-8.99.12 -Q device drvctl-8.99.12 -R device drvctl-8.99.12 -S device cf-j10@makoto 11:17:12/180221(..sbin/drvctl)% sudo /sbin/drvctl -d iwn0 cf-j10@makoto 11:17:29/180221(..sbin/drvctl)% sudo /sbin/drvctl -r pci3 cf-j10@makoto 11:17:36/180221(..sbin/drvctl)% cf-j10@makoto 11:17:51/180221(..sbin/drvctl)% ls -l /sbin/drvctl* -r-xr-xr-x 1 root wheel 19384 Oct 12 18:53 /sbin/drvctl -r-xr-xr-x 1 root wheel 19376 Jan 29 00:00 /sbin/drvctl-8.99.12 checked the commit log for drvctl.c, but I did not get the meaningfull diffs. Please help me to fix the problem, thank you. -- mak...@ki.nu m...@netbsd.org - Makoto Fujiwara, Chiba, Japan, Narita Airport and Disneyland prefecture. !DSPAM:5a8cdcdb185711760256429! +--+--++ | 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 | +--+--++
dig(1) broken - openssl fallout?
It doesn't seem to matter what host I try to lookup, I get the following error messages: # dig www.netbsd.org. 21-Feb-2018 08:01:50.585 ENGINE_by_id failed (crypto failure) 21-Feb-2018 08:01:50.585 error:25070067:DSO support routines:DSO_load:could not load the shared library:/build/netbsd-local/src_ro/crypto/external/bsd/openssl/dist/crypto/dso/dso_lib.c:161: 21-Feb-2018 08:01:50.585 error:260B6084:engine routines:dynamic_load:dso not found:/build/netbsd-local/src_ro/crypto/external/bsd/openssl/dist/crypto/engine/eng_dyn.c:414: 21-Feb-2018 08:01:50.585 error:2606A074:engine routines:ENGINE_by_id:no such engine:/build/netbsd-local/src_ro/crypto/external/bsd/openssl/dist/crypto/engine/eng_list.c:339:id=gost dig: dst_lib_init: crypto failure # +--+--++ | 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: i386 config w/tpm* at acpi? build fails.
Probably the same issue as what I ran into with dbcool(4) last week.
Look in files.acpi for a line that looks like
define acpi {}
and remove it (or comment it out).
On Wed, 21 Feb 2018, John D. Baker wrote:
Shortly after i386-current switched to GCC-6, my first (non-update) build
went fine. Since then, something changed and now configs which include:
tpm* at acpi?
fail with:
[...]
--- tpm_acpi.o ---
/x/current/src/sys/dev/acpi/tpm_acpi.c:88:27: error: 'tpm_acpi_ids' defined but
not used [-Werror=unused-const-variable=]
static const char * const tpm_acpi_ids[] = {
^~~~
[...]
--
|/"\ 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:5a8e1a0450141313947420!
+--+--+----+
| 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: i386 config w/tpm* at acpi? build fails.
Hmmm, that's not going to work!
First, the suggestion should have been to look for
define tpm {}
but I looked, and it's not there! Instead, this looks more like an
issue that mrg@ fixed with pmax's tc driver yesterday. It has to do
with the line that reads
attach tpm at acpinodebus with tpm_acpi
I'm not sure what the real, proper fix is for this one.
On Thu, 22 Feb 2018, Paul Goyette wrote:
Probably the same issue as what I ran into with dbcool(4) last week.
Look in files.acpi for a line that looks like
define acpi {}
and remove it (or comment it out).
On Wed, 21 Feb 2018, John D. Baker wrote:
Shortly after i386-current switched to GCC-6, my first (non-update) build
went fine. Since then, something changed and now configs which include:
tpm* at acpi?
fail with:
[...]
--- tpm_acpi.o ---
/x/current/src/sys/dev/acpi/tpm_acpi.c:88:27: error: 'tpm_acpi_ids' defined
but not used [-Werror=unused-const-variable=]
static const char * const tpm_acpi_ids[] = {
^~~~
[...]
--
|/"\ 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:5a8e1a0450141313947420!
+--+--+----+
| 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 |
+--+--++
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: 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 | +--+--++
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 | +--+--++
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 | +--+--++
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 | +--+--++
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 | +--+--++
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 | +--+--++
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(, 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: 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 | +--+--++
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: 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: 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: running out of file descriptors
On Wed, 18 Apr 2018, Thomas Klausner wrote: Hi! I've recently updated to a NetBSD built on April 3rd. In my latest bulk builds I noticed /netbsd: file: table is full - increase kern.maxfiles or MAXFILES It was around 3700, I've bumped it to 8000. I wonder why I needed to do that though. Did something start using more file descriptors, or is something leaking file descriptors? Did anyone else notice something similar? The other day I had an instance of the shell (tcsh) reporting "No more processes" for a brief period. The problem self-corrected so I didn't research any 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 | +--+--++
Bad man-page cross-refs?
fixmount(8) seems to refer to mtab(5) and rmtab(5), neither exist. +--+--++ | 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 | +--+--++
Two fatal errors with yesterday's -current
With sources built from 2018-04-20 23:11:20 UTC I encountered two fatal errors while booting: First, the system was unable to identify either of my hard drives: ... [ 6.4285988] ums0 at uhidev2: 3 buttons and Z dir [ 6.4285988] wsmouse0 at ums0 mux 0 [ 6.6787124] wd0: IDENTIFY failed [ 6.6787124] wd0: fixing 0 sector size [ 6.6787124] wd0: secperunit and ncylinders are zero [ 9.6800696] wd0(ahcisata0:0:0): using PIO mode 0 [ 9.6800696] wd1 at atabus1 drive 0 [ 9.7100829] ehci_sync_hc: timed out [ 10.7105355] ehci_sync_hc: timed out [ 12.6814270] wd1: IDENTIFY failed [ 12.6814270] wd1: fixing 0 sector size [ 12.6814270] wd1: secperunit and ncylinders are zero ... Second, I received a whole bunch of the "ehci_sync_hc: timed out" messages. The two occurrences above were the first, but there were several more later on in the boot. After all the messages, the boot process prompted me for a root device (since the real root device suffered from the IDENTIFY failed). And just as soon as I entered one character on the keyboard, BOOM it crashed and dropped into ddb. Unfortunately, I was unable to get a crash dump (no hard drive!) , and I also forgot to transcribe the backtrace. If necessary, I can repeat the experiment. For comparison purposes, I have attached the dmesg from my earlier (sources dated 2018-03-20 11:25:00 UTC) working kernel. +--+--+----+ | 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 | +--+--++Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 8.99.14 (SPEEDY 2018-03-20 11:25:00 UTC) #0: Wed Mar 21 10:38:29 UTC 2018 p...@speedy.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY total memory = 127 GB avail memory = 124 GB cpu_rng: RDSEED timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 ASUS All Series (System Version) mainbus0 (root) ACPI: RSDP 0x000F0540 24 (v02 ALASKA) ACPI: XSDT 0xCB235090 94 (v01 ALASKA A M I01072009 AMI 00010013) ACPI: FACP 0xCB26B9D0 00010C (v05 ALASKA A M I01072009 AMI 00010013) ACPI: DSDT 0xCB2351B8 036814 (v02 ALASKA A M I01072009 INTL 20091013) ACPI: FACS 0xCD48CF80 40 ACPI: APIC 0xCB26BAE0 000138 (v03 ALASKA A M I01072009 AMI 00010013) ACPI: FPDT 0xCB26BC18 44 (v01 ALASKA A M I01072009 AMI 00010013) ACPI: FIDT 0xCB26BC60 9C (v01 ALASKA A M I01072009 AMI 00010013) ACPI: MCFG 0xCB26BD00 3C (v01 ALASKA A M I01072009 MSFT 0097) ACPI: ASF! 0xCB2825A8 A0 (v32 INTEL HCG 0001 TFSM 000F4240) ACPI: SSDT 0xCB26BD98 00036D (v01 SataRe SataTabl 1000 INTL 20120913) ACPI: UEFI 0xCB26C108 42 (v01 ALASKA A M I01072009 ) ACPI: HPET 0xCB26C150 38 (v01 ALASKA A M I0001 INTL 20091013) ACPI: MSCT 0xCB26C188 90 (v01 ALASKA A M I0001 INTL 20091013) ACPI: SLIT 0xCB26C218 2D (v01 ALASKA A M I0001 INTL 20091013) ACPI: SRAT 0xCB26C248 001158 (v03 ALASKA A M I0001 INTL 20091013) ACPI: WDDT 0xCB26D3A0 40 (v01 ALASKA A M I INTL 20091013) ACPI: SSDT 0xCB26D3E0 0151C1 (v02 ALASKA PmMgt0001 INTL 20120913) ACPI: 3 ACPI AML tables successfully acquired and loaded ioapic0 at mainbus0 apid 1: pa 0xfec0, version 0x20, 24 pins ioapic1 at mainbus0 apid 2: pa 0xfec01000, version 0x20, 24 pins cpu0 at mainbus0 apid 0 cpu0: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz, id 0x406f1 cpu0: package 0, core 0, smt 0 cpu1 at mainbus0 apid 2 cpu1: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz, id 0x406f1 cpu1: package 0, core 1, smt 0 cpu2 at mainbus0 apid 4 cpu2: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz, id 0x406f1 cpu2: package 0, core 2, smt 0 cpu3 at mainbus0 apid 6 cpu3: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz, id 0x406f1 cpu3: package 0, core 3, smt 0 cpu4 at mainbus0 apid 8 cpu4: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz, id 0x406f1 cpu4: package 0, core 4, smt 0 cpu5 at mainbus0 apid 10 cpu5: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz, id 0x406f1 cpu5: package 0, core 5, smt 0 cpu6 at mainbus0 apid 12 cpu6: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz, id 0x406f1 cpu6: package 0, core 6, smt 0 cpu7 at mainbus0 apid 14 cpu7: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz, id 0x4
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: 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 | +--+--++
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: 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-install -c -r -m 444 bootaa64.ef
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 | +--+--++
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 | +--+--++
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 |
+--+--++
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 | +--+--++
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; }
?
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)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55D
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 | +--+--++
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: 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: 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: 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 | +--+--++
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: 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 | +--+--++
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 | +--+--++
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 | +--+--++
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: 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: 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: 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: 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 | ++--+---+
/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 | ++--+---+
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 ---
);
^
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 |
++--+---+
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 ---
);
^
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 |
++--+---+
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 | ++--+---+
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: 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
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
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: 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
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: 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: 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: 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 | ++--+---+
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: 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 | ++--+---+
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: 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: 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 | ++--+---+
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 through [-Wimplicit-fallthrough=] nvkm_wr32(device, 0x003280, (engine &= ~mask)); ^
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 | ++--+---+
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: 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 | ++--+---+
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 | ++--+---+
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: 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: 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: 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: 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 | ++--+---+
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
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: 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: 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: 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: 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: 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 | ++--+---+
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: 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 | ++--+---+
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 | ++--+---+
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 | ++--+---+
