daily CVS update output
Updating src tree: P src/distrib/sets/lists/dtb/ad.aarch64 P src/distrib/sets/lists/dtb/ad.aarch64eb P src/distrib/sets/lists/dtb/ad.earmv6 P src/distrib/sets/lists/dtb/ad.earmv6eb P src/distrib/sets/lists/dtb/ad.earmv6hf P src/distrib/sets/lists/dtb/ad.earmv6hfeb P src/distrib/sets/lists/dtb/ad.earmv7 P src/distrib/sets/lists/dtb/ad.earmv7hf P src/distrib/sets/lists/dtb/ad.earmv7hfeb P src/lib/libpthread/pthread.c P src/lib/libpthread/pthread_cond.c P src/lib/libpthread/pthread_int.h P src/lib/libpthread/pthread_mutex.c P src/lib/libpthread/pthread_types.h P src/share/misc/acronyms P src/sys/arch/aarch64/aarch64/pmap.c P src/sys/arch/arm/fdt/cpu_fdt.c P src/sys/arch/arm/imx/fdt/files.imx6 P src/sys/arch/arm/imx/fdt/imx6_clk.c U src/sys/arch/arm/imx/fdt/imx7d_ccm.c U src/sys/arch/arm/imx/fdt/imx7d_ccm.h P src/sys/arch/arm/imx/fdt/imx_ccm.c P src/sys/arch/arm/imx/fdt/imx_ccm.h P src/sys/arch/arm/imx/fdt/imx_ccm_composite.c U src/sys/arch/arm/imx/fdt/imx_ccm_div.c P src/sys/arch/arm/imx/fdt/imx_ccm_gate.c U src/sys/arch/arm/imx/fdt/imx_ccm_mux.c U src/sys/arch/arm/imx/fdt/imx_ccm_pll.c P src/sys/arch/evbarm/conf/GENERIC P src/sys/arch/evbmips/cavium/autoconf.c P src/sys/arch/mips/cavium/dev/if_cnmac.c P src/sys/arch/x86/include/specialreg.h P src/sys/dev/acpi/acpi_i2c.c P src/sys/dev/bluetooth/bthidev.c P src/sys/dev/bluetooth/bthub.c P src/sys/dev/bluetooth/btmagic.c P src/sys/dev/bluetooth/btsco.c P src/sys/dev/fdt/fdtbus.c P src/sys/dev/hdaudio/hdafg.c P src/sys/dev/hdaudio/hdaudio.c P src/sys/dev/i2c/i2c.c P src/sys/dev/ofw/ofw_subr.c P src/sys/dev/pci/if_ixl.c P src/sys/dev/pci/if_tl.c P src/sys/dev/pci/if_wm.c P src/sys/dev/spi/spi.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/dev/usb/usb_subr.c P src/sys/dev/wscons/wsdisplay_util.c P src/sys/dev/wsfb/genfb.c P src/sys/dtb/arm/Makefile P src/sys/kern/kern_drvctl.c P src/sys/kern/kern_pmf.c P src/sys/kern/kern_veriexec.c P src/sys/kern/makesyscalls.sh P src/sys/kern/subr_disk.c P src/sys/rump/librump/rumpkern/rump.c P src/tests/lib/libpthread/t_cond.c P src/usr.sbin/sysinst/arch/cobalt/md.c P src/usr.sbin/sysinst/arch/cobalt/md.h Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 38885049 Jun 11 03:08 ls-lRA.gz
Re: cmake hanging
On Mon, Jun 08, 2020 at 03:38:44PM +0100, 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 just made some more changes to libpthread today that may help. I'll try building KDE soon. Cheers, Andrew
Re: cmake hanging
On Wed, Jun 10, 2020 at 01:30:22AM +0200, Joerg Sonnenberger wrote: > On Tue, Jun 09, 2020 at 11:22:27PM +, Andrew Doran wrote: > > On Sat, Jun 06, 2020 at 09:25:55PM +0200, 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. > > > > Hmm. From what I've seen I'm starting to suspect that it's a signal handler > > screwing up a waiting thread underneath it, by playing with threads stuff. I have made pthread_mutex and pthread_cond hopefully insensitive to that. If something is badly behaved and calls pthread_cond_broadcast() from a signal handler for example it shouldn't cause any damage. > I've been wondering if we actually want to have SA_RESTART behavior for > _lwp_park. It relies on EINTR being returned at the moment. Consider for example if a signal is taken, and during signal processing a wakeup is eaten by _lwp_park() called by the dynamic linker for its locks. On the way back out the parked thread needs to restart and check if it has actually been awoken, because it might never see a wakeup. Andrew
Re: bad dir ino panic
On Sun, Jun 07, 2020 at 08:10:08PM +0100, Patrick Welche wrote: > On Mon, Jun 08, 2020 at 12:20:15AM +0700, Robert Elz wrote: > > Date:Sun, 7 Jun 2020 15:20:17 +0100 > > From:Patrick Welche > > Message-ID: <20200607142017.GB3061@quark> > > > > | It was HEAD from June 6 13:54 UTC. > > > > Hmm ... very new, so new that issues might not have been found yet. > > I should specify: that was the one that saw the panic, the one that did > the writing would have been 2nd or 3rd June code. I reproduced this more carefully in kern/55362 Cheers, Patrick
Re: sysinst extended partitioning won't set/do the "newfs" flag!
On Wed, 10 Jun 2020 at 05:32, Martin Husemann wrote: > > On Mon, Jun 08, 2020 at 04:42:42PM -0700, Greg A. Woods wrote: > > What magic am I missing, or is this a bug? > > A bug, probably related to not using MBR on xen devices (but most other x86 > code expecting disklabel inside MBR). It worked (last I tested) in the > default partition editor, not sure what goes wrong here. > > I'll try to reproduce it locally. > > Martin I've done several installations lately under XCP-NG, but I always switch to uEFI and GPT scheme, this has worked just fine for me. (Only native X stopped recently to work with some ancient message about the Cirrus Logic driver having a kernel module, which cannot be unloaded; wsfb starts, though the mouse is erratic). Chavdar --
