daily CVS update output
Updating src tree: P src/distrib/sets/lists/man/mi P src/external/gpl3/gcc/dist/libsanitizer/asan/asan_mapping.h P src/lib/libnvmm/libnvmm.3 P src/share/man/man4/Makefile P src/share/man/man4/isa.4 U src/share/man/man4/nct.4 P src/sys/arch/amd64/conf/GENERIC P src/sys/arch/i386/conf/GENERIC P src/sys/arch/powerpc/oea/cpu_subr.c P src/sys/dev/DEVNAMES P src/sys/dev/filemon/filemon_wrapper.c P src/sys/dev/isa/files.isa U src/sys/dev/isa/nct.c P src/sys/dev/onewire/onewire.c P src/sys/dev/onewire/onewirereg.h P src/sys/dev/onewire/owtemp.c P src/usr.sbin/sysinst/bsddisklabel.c P src/usr.sbin/sysinst/disks.c P src/usr.sbin/sysinst/part_edit.c P src/usr.sbin/sysinst/partitions.c P src/usr.sbin/sysinst/partitions.h Updating xsrc tree: Killing core files: Updating tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected: src/gnu done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc: collecting... replacing... done Updating release-7 src tree (netbsd-7): Updating release-7 xsrc tree (netbsd-7): Updating release-7 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src/x11: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc/xfree: collecting... replacing... done xsrc: collecting... replacing... done Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.2 P sys/arch/arm/ep93xx/epe.c P sys/arch/mac68k/nubus/if_netdock_nubus.c P sys/dev/hpc/hpcapm.c P sys/dev/ic/i82586.c P sys/dev/mii/ciphy.c P sys/dev/mii/miidevs P sys/dev/mii/miidevs.h P sys/dev/mii/miidevs_data.h P sys/dev/mii/rgephy.c P sys/dev/mii/rgephyreg.h P sys/dev/pci/if_bce.c P sys/dev/pci/if_bcereg.h P sys/dev/pcmcia/if_cnw.c P sys/dev/pcmcia/if_ray.c P sys/dev/qbus/if_il.c P sys/dev/qbus/if_qt.c P sys/net/if_vlan.c Updating release-8 xsrc tree (netbsd-8): Updating release-8 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected:
Re: xfwm4 crashes on NetBSD 9.99.17 (was "Re: firefox dumping core after NetBSD upgrade")
Can someone who has this issue explain it shortly? - Which GPU? - What part of updating (kernel, userland) did it? - Does a clean build of everything fix it? the i915 driver has broken userland compatibility. mrg/riastradh fixed it, but I won't be surprised if there's more we haven't spotted with the high bar of "does startx work". https://github.com/NetBSD/src/commit/52ef9d9e2c837c205a00799c3d54c3ef4d65d68d
Re: current kernel crashes while building userland
Riccardo Mottola wrote: >On 24/10/2019 22:06, Robert Swindells wrote: >> You maybe need some changes to the ata disk driver that went in on the >> 23rd. > >bad luck. I upgraded kernel and modules, installed and it crashes during >userland build, so no progress at all. > >Still a crash in compat_90_sys_fstatvfs1() at compat_90_sys_fstatvfs1 > >Could it be that it is actually a compatibility issue, where userland >calls somethingin the kernel that crashes? I wonder that it is compat_90 The recommended build process is to do the userland first then use the new toolchain to build the kernel. This is a clean build isn't it ? The amd64 port switched to gcc 8.3 on the 22nd.
xfwm4 crashes on NetBSD 9.99.17 (was "Re: firefox dumping core after NetBSD upgrade")
On Wed, 2019-10-16 at 12:10 +0100, Chavdar Ivanov wrote: > On Wed, 16 Oct 2019 at 11:03, David H. Gutteridge > wrote: > > > FWIW, aside from Firefox (where I also see this issue), I've found > > since the recent Mesa upgrade, Xfce4's window manager consistently > > crashes during startup. These's a correlation with Firefox in the > > backtrace: > > > > Core was generated by `xfwm4'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > (gdb) bt full > > #0 debug_namespace_get (severity=MESA_DEBUG_SEVERITY_HIGH, id=1, > > ns=0x79f288af02ef) at > > /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/debug_output.c:393 > > elem = 0x0 > > node = 0x0 > > state = 0 > > node = > > state = > > elem = > > #1 _mesa_debug_is_message_enabled (debug=0x79f288af77a0, > > source=source@entry=MESA_DEBUG_SOURCE_API, type=type@entry=MESA_DEBU > > G_TYPE_ERROR, id=1, > > severity=severity@entry=MESA_DEBUG_SEVERITY_HIGH) at > > /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/debug_output.c:623 > > gstack = 0 > > grp = 0x79f288af02ef > > nspace = 0x79f288af02ef > > #2 0x79f26fa440b0 in _mesa_error (ctx=ctx@entry=0x79f288ae5898, > > error=error@entry=1282, fmtString=fmtString@entry=0 > > x79f271815ee4 "Inside glBegin/glEnd") > > at > > /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/errors.c:311 > > do_output = > > do_log = > > error_msg_id = 1 > > #3 0x79f26fa5e256 in _mesa_GetString (name=7937) at > > /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/getstring.c:124 > > ctx = 0x79f288ae5898 > > vendor = 0x79f271833414 "Brian Paul" > > renderer = 0x79f2718214ab "Mesa" > > #4 0x0041b1b5 in ?? () > > No symbol table info available. > > #5 0x00442bb8 in ?? () > > No symbol table info available. > > [...] > > > > (I haven't had any time to look into this further, so I haven't > > enabled > > debugging symbols for xfwm4 itself.) > > > > Regards, > > > > Dave > > I also have xfwm4 crash, but only if there is .config/xfce4 directory. > So far if I remove it, xfce4 works fine. Otherwise the trace appeared > similar to the above. I found that the file .config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml specifically relates to this problem. If I remove it alone, xfwm4 starts. What's curious is that after each startup, that file gets automatically regenerated, but the regenerated version of the file causes xfwm4 to crash on the next startup cycle. I also tried various vblank setting options in that config file, but none have made a difference. Obviously there's more to this, but I haven't narrowed it down. Dave
Re: built-in vs loadable modules and userconf
On Sat, 19 Oct 2019, John D. Baker wrote: > So, it seems the plan of action is to reboot the installed system > (8.1_STABLE) in single-user mode, turn off autoconfig on the RAID > and reboot the test kernel in single-user mode. Then I can observe > the ahcisata behavior with respect to the RAID component disks without > having it try to configure and fail if any disks are not detected. This has worked and I was able to test a -current kernel without interfering with the RAID. Alas, the disks on the siisata card are not detected and I've made an addendum to PR kern/54289. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: current kernel crashes while building userland
Hi, On 24/10/2019 22:06, Robert Swindells wrote: You maybe need some changes to the ata disk driver that went in on the 23rd. bad luck. I upgraded kernel and modules, installed and it crashes during userland build, so no progress at all. Still a crash in compat_90_sys_fstatvfs1() at compat_90_sys_fstatvfs1 Could it be that it is actually a compatibility issue, where userland calls somethingin the kernel that crashes? I wonder that it is compat_90 Riccardo.
Re: heads-up: planned changes in nvmm
I've rebuilt my -current system a few hours ago, followed by a build of wip/qemu-nvmm, I see now at 4.1. So far everything seems to be working as expected. BTW I have been getting - on all my qemu-nvmm builds from wip - a PLIST error - share/locale/bg/LC_MESSAGES/qemu.mo share/locale/de_DE/LC_MESSAGES/qemu.mo share/locale/fr_FR/LC_MESSAGES/qemu.mo share/locale/hu/LC_MESSAGES/qemu.mo share/locale/it/LC_MESSAGES/qemu.mo share/locale/tr/LC_MESSAGES/qemu.mo share/locale/zh_CN/LC_MESSAGES/qemu.mo present in the destination folder but missing in PLIST. On Tue, 22 Oct 2019 at 21:34, Maxime Villard wrote: > > [I am not subscribed to this list, so if you want to answer, make sure to > CC me.] > > I will soon commit a set of changes in NVMM, which will require a full > rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API, > the libnvmm ATF tests, and the qemu-nvmm package if you're using it. > > You can cherry-pick each change, but it will be easier to just do a full > distribution rebuild and reinstall. > > Overall it is no different than what I've been doing over the last six > months. This time, however, the changes will also be pulled up to 9beta > afterwards. > > I will push my changes in -current and update the qemu-nvmm package in > several rounds probably over several days, and then will pull up to 9beta. > > In the meantime, do not upgrade your qemu-nvmm package if you're on 9beta. --
Re: File sharing over virtio-9p
> [W]hich of the following is more readable to the user: > $ ls foo > ls: foo: No such file or directory > or > $ ls foo > ls: stat(foo): No such file or directory It depends entirely on the user. As I recently wrote on a non-NetBSD mailing list, there is no such thing as a good or bad user interface; there is only a good or bad user interfaces for a particular user (or class of sufficiently-similar users). I've lost track of the number of times I've had to resort to a sledgehammer such as ktrace to find out what's really going wrong because an error message doesn't report enough information. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Tar extract behaviour changed
On Thu, Oct 24, 2019 at 10:17:17PM +0300, Valery Ushakov wrote:
> On Thu, Oct 24, 2019 at 05:26:41 +0200, Martin Husemann wrote:
>
> > Deal with this properly in sysinst would mean:
> >
> > 1) run a script like:
> > rm -f /tmp/list
> > for s in *.${suffix}
> > do
> >for dir in $( tar tvf "$s" | egrep '^d' | awk '{ print $9}' )
> >do
> > readlink "$dir" && echo "$dir" >> /tmp/list
> >done
> > done
>
> Isn't that info already available from mtree files? IIRC, set.base
> has all of the directories, including those that are populated by
> other sets. So you should be able to extract that and run mtree to
> check it.
I'm not really sure that would be a lot better. My prefered solution is to
just add -P to the extract args unconditionally (as this restores as close
to what we had as previous behaviour). If there would be an explicit
symlinks option I'd use that (unconditionally), but for our sets it does
not buy us much.
Martin
Re: File sharing over virtio-9p
On Fri, Oct 25, 2019 at 3:04 PM Michael van Elst wrote: > > ozaki.ry...@gmail.com (Ryota Ozaki) writes: > > >> @@ -72,7 +74,7 @@ serverconnect(const char *addr, unsigned short port) > >> + err(1, "setsockopt(SO_NOSIGPIPE)"); > >> +err(1, "open(%s)", path); > > >I prefer more informative messages. Why do you want to trim them? > > > Usually the error gives enough context, e.g. SO_NOSIGPIPE is a socket option > and telling that it's setsockopt failing is redundant and printing > an input file name is enough when the error identifies the operation > or the specific operation doesn't matter. > > But there is no rule for this, in particular when embedding filenames > where multiple operations are possible. Many people seem to prefer even > more verbose phrases like "Cannot open `%s'". Our code base has lots > of variants. I think I'm affected by ping6 or something (it's just one of variants though). > > I personally would prefer error messages without special characters > so that you can grep them easily. :) Indeed. A type of annoying messages is that a phrase is separated into two (or more) lines to avoid the 80 character limit. That's quite anti-grep :-/ ozaki-r
Re: File sharing over virtio-9p
On Fri, Oct 25, 2019 at 2:38 PM Valery Ushakov wrote: > > On Fri, Oct 25, 2019 at 12:56:43 +0900, Ryota Ozaki wrote: > > > > @@ -72,7 +74,7 @@ serverconnect(const char *addr, unsigned short port) > > > [...] > > > + err(1, "setsockopt(SO_NOSIGPIPE)"); > > > > > > I'd just trim it down to "SO_NOSIGPIPE". > > > > > > +err(1, "open(%s)", path); > > > > > > Ditto. Just make it "%s". > > > > I prefer more informative messages. Why do you want to trim them? > > Consider that from the user perspective. As a developer it's tempting > to dump the implementation details, but which of the following is more > readable to the user: > > $ ls foo > ls: foo: No such file or directory > > or > > $ ls foo > ls: stat(foo): No such file or directory Hm, the example makes sense to me (so I'll fix open's one), but doesn't for setsockopt: mount_9p: SO_NOSIGPIPE: Cannot allocate memory or mount_9p: setsockopt(SO_NOSIGPIPE): Cannot allocate memory I think the latter looks readable/understandable to users. ozaki-r
Re: File sharing over virtio-9p
ozaki.ry...@gmail.com (Ryota Ozaki) writes: >> @@ -72,7 +74,7 @@ serverconnect(const char *addr, unsigned short port) >> + err(1, "setsockopt(SO_NOSIGPIPE)"); >> +err(1, "open(%s)", path); >I prefer more informative messages. Why do you want to trim them? Usually the error gives enough context, e.g. SO_NOSIGPIPE is a socket option and telling that it's setsockopt failing is redundant and printing an input file name is enough when the error identifies the operation or the specific operation doesn't matter. But there is no rule for this, in particular when embedding filenames where multiple operations are possible. Many people seem to prefer even more verbose phrases like "Cannot open `%s'". Our code base has lots of variants. I personally would prefer error messages without special characters so that you can grep them easily. :) -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
