daily CVS update output

Updating src tree: P src/distrib/sets/lists/xdebug/shl.mi P src/etc/rc.subr P src/external/mit/xorg/lib/gallium/Makefile P src/lib/libc/sys/sigaction.2 P src/lib/libpanel/above.c P src/lib/libpanel/below.c P src/lib/libpanel/panel_above.3 P src/sys/compat/netbsd32/netbsd32_time.c P

Re: go vs. NetBSD ELF

On Sun, Nov 01, 2015 at 04:41:44PM +0100, Martin Husemann wrote: > On Sun, Nov 01, 2015 at 03:27:01PM +, Michael van Elst wrote: > > > // The Go build ID is stored in a note described by an ELF PT_NOTE prog > > header. > > But why would the kernel see this? > > Just to make sure I parsed

Re: sendmmsg() on NetBSD vs Linux

In article <25322.1446399...@andromeda.noi.kre.to>, Robert Elz wrote: >Date:Sun, 1 Nov 2015 15:41:04 + (UTC) >From:mlel...@serpens.de (Michael van Elst) >Message-ID: > > | That is a bug in the NetBSD sendmmsg()

Re: go vs. NetBSD ELF

On Sun, Nov 01, 2015 at 10:17:14PM +0700, Robert Elz wrote: > I'd suggest ... (src/sys/kern/exec_elf.c) Well, I rather hoped that the go toolchain could get fixed to not create executables that have this issue :) Thomas

Re: sendmmsg() on NetBSD vs Linux

jan.vce...@nic.cz (=?UTF-8?B?SmFuIFbEjWVsw6Fr?=) writes: >I've found that the problem is in the newly added sendmmsg() interface. >It's behavior slightly differs from the implementation in Linux. The >sendmmsg() on NetBSD modifies the msg_hdr.msg_iov member of the supplied >struct mmsg_hdr, which

Re: go vs. NetBSD ELF

On Sun, Nov 01, 2015 at 03:27:01PM +, Michael van Elst wrote: > w...@netbsd.org (Thomas Klausner) writes: > > >/usr/pkg/go/pkg/tool/netbsd_amd64/vet: Unknown elf note type 4 (unknown > >tag): [namesz=4, descsz=40 name=Go ] > > >Ideas how to fix this? Change the message to only happen

Re: go vs. NetBSD ELF

Date:Sun, 1 Nov 2015 14:39:15 +0100 From:Thomas Klausner Message-ID: <20151101133915.ga19...@danbala.tuwien.ac.at> | Ideas how to fix this? I'd suggest ... (src/sys/kern/exec_elf.c) --- exec_elf.c.was 2015-08-09 01:37:37.0 +0700 +++

Re: go vs. NetBSD ELF

On Nov 1, 11:54pm, k...@munnari.oz.au (Robert Elz) wrote: -- Subject: Re: go vs. NetBSD ELF | Is it really rational to keep adding cases for every new note that | gets discovered (to ignore them), just so that the kernel can print a | message (and otherwise ignore) notes that it hasn't yet been

Re: go vs. NetBSD ELF

w...@netbsd.org (Thomas Klausner) writes: >/usr/pkg/go/pkg/tool/netbsd_amd64/vet: Unknown elf note type 4 (unknown tag): >[namesz=4, descsz=40 name=Go ] >Ideas how to fix this? // The Go build ID is stored in a note described by an ELF PT_NOTE prog header. But why would the kernel see this?

Re: go vs. NetBSD ELF

Date:Sun, 1 Nov 2015 15:38:28 + (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | Fixed in the kernel. Is it really rational to keep adding cases for every new note that gets discovered (to ignore them), just so that

sendmmsg() on NetBSD vs Linux

Hello list, we've been recently reported that Knot DNS segfaults on NetBSD 7. I've found that the problem is in the newly added sendmmsg() interface. It's behavior slightly differs from the implementation in Linux. The sendmmsg() on NetBSD modifies the msg_hdr.msg_iov member of the supplied

Re: go vs. NetBSD ELF

In article <20151101133915.ga19...@danbala.tuwien.ac.at>, Thomas Klausner wrote: >Hi! > >The go toolchain is writing errors in my kernel log again. > >/usr/pkg/go/pkg/tool/netbsd_amd64/compile: Unknown elf note type 4 >(unknown tag): [namesz=4, descsz=40 name=Go ]

daily CVS update output

Updating src tree: P src/distrib/sets/lists/xcomp/md.amd64 P src/distrib/sets/lists/xcomp/md.i386 P src/distrib/sets/lists/xdebug/md.amd64 P src/distrib/sets/lists/xdebug/md.evbarm P src/doc/CHANGES P src/lib/libc/time/strptime.3 P src/lib/libc/time/strptime.c P src/lib/libkvm/kvm_sparc.c P

Re: Three failure modes seen with -current amd64 modular kernels (somewhat lengthy)

On Tue, 27 Oct 2015, Paul Goyette wrote: With current kernels, I am seeing three distinct failure modes when loading/unloading modules. (FWIW, my base kernel contains as few built-in modules as possible; everything is loaded as needed.) At least issues 1 and 3 have been uncovered as a result

Re: go vs. NetBSD ELF

chris...@zoulas.com (Christos Zoulas) writes: > On Nov 1, 11:54pm, k...@munnari.oz.au (Robert Elz) wrote: > -- Subject: Re: go vs. NetBSD ELF > > | Is it really rational to keep adding cases for every new note that > | gets discovered (to ignore them), just so that the kernel can print a > |

Re: sendmmsg() on NetBSD vs Linux

Date:Sun, 1 Nov 2015 15:41:04 + (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | That is a bug in the NetBSD sendmmsg() implementation. I'm not sure that's necessarily true. On neither Linux nor NetBSD is the msg_hdr

Re: sendmmsg() on NetBSD vs Linux

chris...@astron.com (Christos Zoulas) writes: >Well, the recvmmsg code did not do it, and it was simple enough to make >both sides do the same :-)... I.e. not scribble to the userland struct >unnecessarily. The flags handling might also need a look. sendmsg just sets msg_flags to

Re: sendmmsg() on NetBSD vs Linux

On Mon, Nov 02, 2015 at 12:40:21AM +0700, Robert Elz wrote: > Date:Sun, 1 Nov 2015 15:41:04 + (UTC) > From:mlel...@serpens.de (Michael van Elst) > Message-ID: > > | That is a bug in the NetBSD sendmmsg() implementation. > > I'm not

pppoe "taking interface down"

Since upgrading to netbsd-7 branch kernel, I've had my pppoe interface taken down by the kernel on a few occasions, and up'ing the interface is required a few times to actually get it up and running again. It looks as though maybe the remote end queues a PADT, which I get as soon as I attempt to