Recent reports of needing to avoid META_MODE for head kernel builds for updates: a preliminary investigation

For an example of the recent reports: David Wolfskill david at catwhisker.org wrote on Mon Jun 26 12:44:20 UTC 2017 : > On Mon, Jun 26, 2017 at 03:29:59PM +0300, Konstantin Belousov wrote: > > ... > > > > Hmmm. > > > > As if computer tries to say you, do not use meta mode. > > > For

head -r320192 -> -r320387 kernel build and install to a DESTDIR: if_igb.ko vs. DESTDIR use for installkernel has symbolic link that seems inapproriate

installkernel DESTDIR=/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387 produced a if_igb.ko (this used: ls -lD %C ): lrwxr-xr-x 1 root wheel80 20 if_igb.ko -> /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if_em.ko This does not allow simple

Re: Ports still broken by ino64?

I'm sure stas can figure it out! -a On 25 June 2017 at 22:44, Thomas Mueller wrote: > from Adrian Chadd: > >> valgrind broke as part of the ino64 work :( > > Valgrind was not on my mind! Your post sent me to > > ls -d /usr/ports/*/val* > > to find valgrind, and then read

Re: Current amd64 new error or warning from today's current with ruby r320323

On Mon, Jun 26, 2017 at 01:34:35PM -0700, Benno Rice wrote: > > > On Jun 26, 2017, at 13:25, Konstantin Belousov wrote: > > > > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: > >> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov >

Re: Current amd64 new error or warning from today's current with ruby r320323

> On Jun 26, 2017, at 13:25, Konstantin Belousov wrote: > > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: >> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov >> wrote: >> >>> No need, I understood why MAP_STACK failed in this

Re: Current amd64 new error or warning from today's current with ruby r320323

On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: > On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov > wrote: > > > No need, I understood why MAP_STACK failed in this case, thanks to the > > ktrace log. This is indeed something ruby-specific, or rather,

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov wrote: > No need, I understood why MAP_STACK failed in this case, thanks to the > ktrace log. This is indeed something ruby-specific, or rather, triggered > by ruby special use of libthr. It is not related to the main

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

On Mon, 26 Jun 2017 12:22:50 +0100 Steven Hartland wrote: > Is this related to kib's additional fix over the weekend? > > https://svnweb.freebsd.org/changeset/base/320344 > > Regards > Steve > > On 26/06/2017 09:29, O. Hartmann wrote: > > Over the past week

Re: status of and/or url to check base packages repo somewhere?

On Sun, Jun 25, 2017 at 10:30:53PM -0700, Jeffrey Bouquet wrote: > As the Subject: is there a canonical url to check, and a procedure in place > yet, to, > for instance, if one cannot buildworld on 12.0-CURRENT, to access the package > .txz or > whatever and 'pkg fetch ... pkg add ...'

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

On Mon, 26 Jun 2017 14:48:58 +0200 Gary Jennejohn wrote: > On Mon, 26 Jun 2017 14:00:48 +0200 > "O. Hartmann" wrote: > > > On Mon, 26 Jun 2017 13:26:08 +0200 > > Gary Jennejohn wrote: > > > > > On Mon, 26 Jun 2017 10:29:47

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

On Mon, 26 Jun 2017 14:00:48 +0200 "O. Hartmann" wrote: > On Mon, 26 Jun 2017 13:26:08 +0200 > Gary Jennejohn wrote: > > > On Mon, 26 Jun 2017 10:29:47 +0200 > > "O. Hartmann" wrote: > > > > > Over the past week we did

Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"

On Mon, Jun 26, 2017 at 03:29:59PM +0300, Konstantin Belousov wrote: > ... > > Hmmm. > > As if computer tries to say you, do not use meta mode. For building the kernel, on head as of some commit after r320307 (but by r320324). Peace, david -- David H. Wolfskill

Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"

On Mon, Jun 26, 2017 at 05:28:24AM -0700, David Wolfskill wrote: > On Mon, Jun 26, 2017 at 03:05:58PM +0300, Konstantin Belousov wrote: > > On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote: > > > KLD geom_eli.ko: depends on kernel - not available or version mismatch > > >

Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"

On Mon, Jun 26, 2017 at 03:05:58PM +0300, Konstantin Belousov wrote: > On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote: > > KLD geom_eli.ko: depends on kernel - not available or version mismatch > > linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type > > swapon:

Re: Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"

On Mon, Jun 26, 2017 at 04:54:36AM -0700, David Wolfskill wrote: > KLD geom_eli.ko: depends on kernel - not available or version mismatch > linker_load_file: /boot/kernel/geom_eli.ko - unsupported file type > swapon: /dev/ada0s4b.eli: Invalid parameters Again remove all kernel build files and try

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

On Mon, 26 Jun 2017 13:26:08 +0200 Gary Jennejohn wrote: > On Mon, 26 Jun 2017 10:29:47 +0200 > "O. Hartmann" wrote: > > > Over the past week we did not update several 12-CURRENT running development > > hosts, so today is the first day of

Unable to load kernel modules after r320324 -> r320353: "depends on kernel - not available or version mismatch"

This is amd64: FreeBSD 12.0-CURRENT #386 r320324M/320326:1200035: Sun Jun 25 06:36:19 PDT 2017 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 After a src update to r320353, the last several lines on the serial console from the initial (verbose) reboot are: ...

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

On Mon, Jun 26, 2017 at 10:29:47AM +0200, O. Hartmann wrote: > Over the past week we did not update several 12-CURRENT running development > hosts, so today is the first day of performing this task. > > First I hit the very same problem David Wolfskill reported earlier, a fatal > trap 12, but

Re: [RESOLVED] Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11

On 26/06/17 00:59, Benjamin Kaduk wrote: > On Fri, Jun 23, 2017 at 11:22:46PM -0500, Benjamin Kaduk wrote: >> I fixed the rc.conf snippet in the handbook in r50399. >> I lost track of the rest of the thread as to what needs to be >> changed in the actual command examples in lagg.4 and/or the >>

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

On Mon, Jun 26, 2017 at 10:29:47AM +0200, O. Hartmann wrote: > ... > Since tag 20170617 in /usr/src/UPDATING referred to the INO64 update and the > INO64 update hasn't performed so far starting from r319971, I installed the > kernel, rebooted the box in single user mode (this time smoothly), did a

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

On Mon, 26 Jun 2017 12:22+0100, Steven Hartland wrote: > Is this related to kib's additional fix over the weekend? > > https://svnweb.freebsd.org/changeset/base/320344 Attempting to run r320348 with no patches applied proved unfruitful earlier today. I had partial success the weekend building

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

On Mon, 26 Jun 2017 10:29:47 +0200 "O. Hartmann" wrote: > Over the past week we did not update several 12-CURRENT running development > hosts, so today is the first day of performing this task. > > First I hit the very same problem David Wolfskill reported earlier, a

Re: r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

Is this related to kib's additional fix over the weekend? https://svnweb.freebsd.org/changeset/base/320344 Regards Steve On 26/06/2017 09:29, O. Hartmann wrote: Over the past week we did not update several 12-CURRENT running development hosts, so today is the first day of performing

r319971 -> r320351: Fatal error 'Cannot allocate red zone for initial thread'

Over the past week we did not update several 12-CURRENT running development hosts, so today is the first day of performing this task. First I hit the very same problem David Wolfskill reported earlier, a fatal trap 12, but fowllowing the thread, I did as advised: removing /usr/obj completely (we

Re: ZFS ABD Panic

On Monday, June 26, 2017, Shawn Webb wrote: > This is on the latest HardenedBSD 12-CURRENT on one of my servers: > > [141] panic: sleepq_add: td 0xf80008d20560 to sleep on wchan > 0xf803b7d4e810 with sleeping prohibited > [141] cpuid = 5 > [141] time =

Re: Has gdb been disconnected from make installworld?

On Sun, 25 Jun 2017 14:07-0500, Benjamin Kaduk wrote: > On Sun, Jun 25, 2017 at 09:03:58PM +0200, Trond Endrestøl wrote: > > > Ah, they wound up in /usr/libexec. Still, that's an odd place for user > > software. > > --- >