daily CVS update output
Updating src tree: P src/common/lib/libprop/prop_data.c P src/distrib/sets/lists/comp/mi P src/distrib/sets/lists/debug/shl.mi P src/sbin/gpt/backup.c P src/share/man/man2/siginfo.2 P src/share/man/man3/bits.3 P src/share/man/man3/types.3 P src/share/man/man4/aibs.4 P src/sys/arch/arm/imx/imx6_ccm.c P src/sys/arch/evbarm/conf/GENERIC P src/sys/dev/acpi/acpi_i2c.c P src/sys/dev/bluetooth/bthub.c P src/sys/dev/sysmon/swsensor.c P src/sys/dev/sysmon/sysmon_envsys.c P src/sys/dev/sysmon/sysmon_envsys_util.c P src/sys/dev/sysmon/sysmon_power.c P src/sys/kern/kern_module.c P src/sys/kern/kern_veriexec.c P src/sys/sys/Makefile P src/tests/lib/libc/sys/t_ptrace_fork_wait.h P src/tests/lib/libprop/t_proplib.c P src/tests/usr.bin/make/t_make.sh P src/usr.bin/make/unit-tests/modorder.exp P src/usr.bin/make/unit-tests/modorder.mk Updating xsrc tree: P xsrc/local/programs/ttf2wsfont/main.c Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 38850381 Jun 9 03:07 ls-lRA.gz
Re: regression: xen domU no longer supports "type=cdrom" vbd disk
At Tue, 9 Jun 2020 00:00:17 +0200, Manuel Bouyer wrote: Subject: Re: regression: xen domU no longer supports "type=cdrom" vbd disk > > On Mon, Jun 08, 2020 at 02:26:39PM -0700, Greg A. Woods wrote: > > I use xl.cfg "disk" entries like the following to mount a virtual CDROM > > in a Xen domU: > > > > 'format=raw, vdev=0x5, access=ro, devtype=cdrom, > > target=/images/NetBSD-9.0-amd64.iso' > > > > However since upgrading my -current source tree I've been seeing: > > > > xenbus0: ignoring device/vbd/4 type cdrom > > > > As shown in this patch I had to comment out the core of the mentioned > > change to be able to use an ISO image again as a virtual CDROM again: > > Actually this change matches what other OSes do with 'devtype=cdrom', > we were an outsider here. > > For PV or PVH domUs you can omit the devtype keyword, it's only > needed for HVM guests (if you want to boot from the cdrom image). Ah OK, I think I understand, thanks! Perhaps this could be mentioned quite explicitly in in the CHANGES file (though that's not the first place I though to look, unfortunately) Maybe the xen/howto on the wiki could be more explicit about mapping a "image.iso" file to a disk vdev (perhaps instead of the currently less helpful suggestions about mapping an existing actual /dev/cd0a device). (Of course the xen/howto could use a lot of help.) (Not to mention but also some upstream Xen docs seem to need updating too, e.g. the xl-disk-configuration(5) manual page (that we unfortunately do not seem to install in the xentools package). Lots of guides mention using "devtype=cdrom" any time an "image.iso" is used.) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpa_VTJPzkrr.pgp Description: OpenPGP Digital Signature
Re: Automated report: NetBSD-current/i386 test failure
> On Jun 8, 2020, at 10:33 AM, Jason Thorpe wrote: > > >> On Jun 8, 2020, at 10:02 AM, NetBSD Test Fixture wrote: >> >> This is an automatically generated notice of new failures of the >> NetBSD test suite. >> >> The newly failing test cases are: >> >> net/if/t_ifconfig:ifconfig_description >> sbin/gpt/t_gpt:backup_2part > > I think this is just a matter of these test-cases needing to be updated to > reflect a change from base-16 to base-10 (or vice-versa) in the serialized > output. In any case, I'll investigate and fix it up. These are now both fixed. -- thorpej
Re: regression: xen domU no longer supports "type=cdrom" vbd disk
On Mon, Jun 08, 2020 at 02:26:39PM -0700, Greg A. Woods wrote: > I use xl.cfg "disk" entries like the following to mount a virtual CDROM > in a Xen domU: > > 'format=raw, vdev=0x5, access=ro, devtype=cdrom, > target=/images/NetBSD-9.0-amd64.iso' > > However since upgrading my -current source tree I've been seeing: > > xenbus0: ignoring device/vbd/4 type cdrom > > As shown in this patch I had to comment out the core of the mentioned > change to be able to use an ISO image again as a virtual CDROM again: Actually this change matches what other OSes do with 'devtype=cdrom', we were an outsider here. For PV or PVH domUs you can omit the devtype keyword, it's only needed for HVM guests (if you want to boot from the cdrom image). -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: regression: xen domU no longer supports "type=cdrom" vbd disk
On Mon, 8 Jun 2020 at 22:26, Greg A. Woods wrote:
>
> I use xl.cfg "disk" entries like the following to mount a virtual CDROM
> in a Xen domU:
>
> 'format=raw, vdev=0x5, access=ro, devtype=cdrom,
> target=/images/NetBSD-9.0-amd64.iso'
>
> However since upgrading my -current source tree I've been seeing:
>
> xenbus0: ignoring device/vbd/4 type cdrom
>
> As shown in this patch I had to comment out the core of the mentioned
> change to be able to use an ISO image again as a virtual CDROM again:
>
>
> --- xenbus_probe.c.~1.55.~ 2020-05-30 17:32:39.672816814 -0700
> +++ xenbus_probe.c 2020-06-08 14:13:45.025527521 -0700
> @@ -443,6 +443,14 @@
> kmem_free(xbusd, xbusd->xbusd_sz);
> break;
> }
> +//revision 1.51
> +//date: 2020-04-28 06:21:01 -0700; author: bouyer; state: Exp; lines: +30
> -9; commitid: 5XOy6F9zbgN8C96C;
> +//Skip block device with device-type "cdrom", as their emulation can't be
> +//disabled; and the backend driver doesn't handle them either.
> +//Fix hang when booting with 'ioemu:hdc:cdrom' type disks.
> +//While there convert some printf to aprint_error()
> +//
> +#if 0 /* XXX breaks use of ISO files! */
> if (strcmp(xa.xa_type, "vbd") == 0) {
> char dtype[10];
> if (xenbus_read(NULL, xbusd->xbusd_path,
> @@ -461,6 +469,7 @@
> continue;
> }
> }
> +#endif
> err = read_backend_details(xbusd);
> if (err != 0) {
> aprint_error_dev(xenbus_dev,
>
>
> Now it works again:
>
> xbd4 at xenbus0 id 4: Xen Virtual Block Device Interface
> xbd4: using event channel 12
> ...
> boot device: xbd4
> root on xbd4a dumps on xbd4b
> root file system type: cd9660
I believe this was necessary at least under XCP-NG in PVHVM mode with
platform:viridian set to false - before the change the CD-ROM had to
be unconfigured as the system was hanging. After the change this was
no longer necessary and the CD-ROM was available.
>
> --
> Greg A. Woods
>
> Kelowna, BC +1 250 762-7675 RoboHack
> Planix, Inc. Avoncote Farms
--
regression: xen domU no longer supports "type=cdrom" vbd disk
I use xl.cfg "disk" entries like the following to mount a virtual CDROM
in a Xen domU:
'format=raw, vdev=0x5, access=ro, devtype=cdrom,
target=/images/NetBSD-9.0-amd64.iso'
However since upgrading my -current source tree I've been seeing:
xenbus0: ignoring device/vbd/4 type cdrom
As shown in this patch I had to comment out the core of the mentioned
change to be able to use an ISO image again as a virtual CDROM again:
--- xenbus_probe.c.~1.55.~ 2020-05-30 17:32:39.672816814 -0700
+++ xenbus_probe.c 2020-06-08 14:13:45.025527521 -0700
@@ -443,6 +443,14 @@
kmem_free(xbusd, xbusd->xbusd_sz);
break;
}
+//revision 1.51
+//date: 2020-04-28 06:21:01 -0700; author: bouyer; state: Exp; lines: +30
-9; commitid: 5XOy6F9zbgN8C96C;
+//Skip block device with device-type "cdrom", as their emulation can't be
+//disabled; and the backend driver doesn't handle them either.
+//Fix hang when booting with 'ioemu:hdc:cdrom' type disks.
+//While there convert some printf to aprint_error()
+//
+#if 0 /* XXX breaks use of ISO files! */
if (strcmp(xa.xa_type, "vbd") == 0) {
char dtype[10];
if (xenbus_read(NULL, xbusd->xbusd_path,
@@ -461,6 +469,7 @@
continue;
}
}
+#endif
err = read_backend_details(xbusd);
if (err != 0) {
aprint_error_dev(xenbus_dev,
Now it works again:
xbd4 at xenbus0 id 4: Xen Virtual Block Device Interface
xbd4: using event channel 12
...
boot device: xbd4
root on xbd4a dumps on xbd4b
root file system type: cd9660
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpyhCAjH0HNg.pgp
Description: OpenPGP Digital Signature
Re: cmake hanging
On Mon, 8 Jun 2020 at 15:38, Chavdar Ivanov wrote: > > On Sun, 7 Jun 2020 at 10:25, Chavdar Ivanov wrote: > > > > Hi, > > > > I just had another one, rebuilding gimp, running gegl. Again gdb -p > > ... ; quit sorted it out. > > > > On Sat, 6 Jun 2020 at 20:36, Chavdar Ivanov wrote: > > > > > > On Sat, 6 Jun 2020 at 20:26, Joerg Sonnenberger wrote: > > > > > > > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote: > > > > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I got another cmake hang during pkg_rolling-replace today, while > > > > > > building misc/kdepimlibs4, trace as follows: > > > > > > > > > > Just to mention that after I quit gdb and detached from the process it > > > > > continued and completed the build . . . > > > > > > > > Right, that's the bug in the mutex wakeup handling. > > > > > > The second hung sample - with git - also completed OK after I quit gdb... > > I had another three cmake hangs just like this today, while rebuilding > bits of kf5. > > Just to confirm - the moment one answers 'y' to the question whether > to leave gdb the process continues and the build succeeds. > > This is somewhat annoying; although it does not stop the rebuild > process, it makes it impossible to complete unattended. I've had probably about 30 of these today, it renders bits of pkgsrc unusable on -current. I had to go through another kf5 update today and I've got a split tmux window, left side going through the build, right - just waiting for a hang so that I can attach to the cmake process with gdb and quit; the build then carries on. Is there any workaround for this hang? Here is another typical trace: [Switching to LWP 5461 of process 15944] 0x7d33fb4a87aa in ___lwp_park60 () from /usr/lib/libc.so.12 (gdb) thread apply all bt Thread 2 (LWP 15944 of process 15944): #0 0x7d33fb44551a in _lwp_wait () from /usr/lib/libc.so.12 #1 0x7d33fbc0c8e4 in pthread_join () from /usr/lib/libpthread.so.1 #2 0x7d33fc89e57b in std::thread::join() () from /usr/lib/libstdc++.so.9 #3 0x004a87eb in cmWorkerPoolWorker::~cmWorkerPoolWorker() () #4 0x004a8e2e in cmWorkerPoolInternal::UVSlotEnd(uv_async_s*) () #5 0x7d33fd20f69f in uv__async_io (loop=0x7d33fe8bb000, w=, events=) at src/unix/async.c:163 #6 0x7d33fd21d2aa in uv__io_poll (loop=loop@entry=0x7d33fe8bb000, timeout=) at src/unix/kqueue.c:343 #7 0x7d33fd20fc87 in uv_run (loop=0x7d33fe8bb000, mode=UV_RUN_DEFAULT) at src/unix/core.c:381 #8 0x004a948a in cmWorkerPoolInternal::Process() () #9 0x004a94d4 in cmWorkerPool::Process(void*) () #10 0x004731d4 in (anonymous namespace)::cmQtAutoMocUicT::Process() () #11 0x0067009c in cmQtAutoGenerator::Run(cm::string_view, cm::string_view) () #12 0x00462e22 in cmQtAutoMocUic(cm::string_view, cm::string_view) () #13 0x004186d5 in cmcmd::ExecuteCMakeCommand(std::vector, std::allocator >, std::allocator, std::allocator > > > const&) () #14 0x007652ea in main () Thread 1 (LWP 5461 of process 15944): #0 0x7d33fb4a87aa in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x7d33fbc096fd in ?? () from /usr/lib/libpthread.so.1 #2 0x004a7d35 in cmWorkerPoolInternal::Work(unsigned int) () #3 0x7d33fc89e53a in ?? () from /usr/lib/libstdc++.so.9 #4 0x7d33fbc0c6dc in ?? () from /usr/lib/libpthread.so.1 #5 0x7d33fb492370 in ?? () from /usr/lib/libc.so.12 #6 0x in ?? () Chavdar > > > > > > > > > > > > Joerg > > > > > > > > > > > > -- > > > > > > > > > > > -- > > > > > > -- > --
Re: Index of pub/NetBSD-daily/HEAD/index.html
On Mon, Jun 08, 2020 at 02:35:55PM -0500, Clay Daniels wrote: > I've been looking at: > > https://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/ > > I see, in the few days I've been looking, that the latest/ directory stays > at 03 Jun, despite a new daily snapshot. Is there some special significance > to the 03 Jun snapshot? Will it be replaced on Wed 10 Jun by a new > "latest/"? > > Clay Daniels Hi Clay, the latest/ directory gets updated when all the architectures build. It looks like it hasn't happened in some time. You can see the status of builds in http://releng.netbsd.org/cgi-bin/builds.cgi
Re: Automated report: NetBSD-current/i386 test failure
> On Jun 8, 2020, at 10:02 AM, NetBSD Test Fixture wrote: > > This is an automatically generated notice of new failures of the > NetBSD test suite. > > The newly failing test cases are: > >net/if/t_ifconfig:ifconfig_description >sbin/gpt/t_gpt:backup_2part I think this is just a matter of these test-cases needing to be updated to reflect a change from base-16 to base-10 (or vice-versa) in the serialized output. In any case, I'll investigate and fix it up. -- thorpej
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: net/if/t_ifconfig:ifconfig_description sbin/gpt/t_gpt:backup_2part The above tests failed in each of the last 4 test runs, and passed in at least 26 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.06.07.05.42.25 thorpej src/sbin/gpt/backup.c,v 1.19 2020.06.07.05.42.25 thorpej src/sbin/gpt/restore.c,v 1.20 2020.06.07.05.49.05 thorpej src/sbin/modload/main.c,v 1.18 2020.06.07.05.54.00 thorpej src/usr.sbin/powerd/powerd.c,v 1.19 2020.06.07.05.57.17 thorpej src/lib/libdm/libdm_ioctl.c,v 1.5 2020.06.07.06.02.58 thorpej src/sbin/ifconfig/af_atalk.c,v 1.21 2020.06.07.06.02.58 thorpej src/sbin/ifconfig/af_inetany.c,v 1.19 2020.06.07.06.02.58 thorpej src/sbin/ifconfig/carp.c,v 1.14 2020.06.07.06.02.58 thorpej src/sbin/ifconfig/env.c,v 1.13 2020.06.07.06.02.58 thorpej src/sbin/ifconfig/ether.c,v 1.9 2020.06.07.06.02.58 thorpej src/sbin/ifconfig/ifconfig.c,v 1.242 2020.06.07.06.02.58 thorpej src/sbin/ifconfig/media.c,v 1.9 2020.06.07.06.02.58 thorpej src/sbin/ifconfig/parse.c,v 1.20 2020.06.07.06.02.58 thorpej src/sbin/ifconfig/pfsync.c,v 1.3 2020.06.07.06.02.58 thorpej src/sbin/ifconfig/tunnel.c,v 1.22 2020.06.07.06.08.20 thorpej src/sys/sys/param.h,v 1.668 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.06.html#2020.06.07.06.08.20
Re: cmake hanging
On Sun, 7 Jun 2020 at 10:25, Chavdar Ivanov wrote: > > Hi, > > I just had another one, rebuilding gimp, running gegl. Again gdb -p > ... ; quit sorted it out. > > On Sat, 6 Jun 2020 at 20:36, Chavdar Ivanov wrote: > > > > On Sat, 6 Jun 2020 at 20:26, Joerg Sonnenberger wrote: > > > > > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote: > > > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov wrote: > > > > > > > > > > Hi, > > > > > > > > > > I got another cmake hang during pkg_rolling-replace today, while > > > > > building misc/kdepimlibs4, trace as follows: > > > > > > > > Just to mention that after I quit gdb and detached from the process it > > > > continued and completed the build . . . > > > > > > Right, that's the bug in the mutex wakeup handling. > > > > The second hung sample - with git - also completed OK after I quit gdb... I had another three cmake hangs just like this today, while rebuilding bits of kf5. Just to confirm - the moment one answers 'y' to the question whether to leave gdb the process continues and the build succeeds. This is somewhat annoying; although it does not stop the rebuild process, it makes it impossible to complete unattended. > > > > > > > > Joerg > > > > > > > > -- > > > > > > -- > --
