On 06/29/17 13:16, Hans Petter Selasky wrote:
On 06/26/17 15:03, O. Hartmann wrote:
On Mon, 26 Jun 2017 14:48:58 +0200
Gary Jennejohn <gljennj...@gmail.com> wrote:

On Mon, 26 Jun 2017 14:00:48 +0200
"O. Hartmann" <ohartm...@walstatt.org> wrote:

On Mon, 26 Jun 2017 13:26:08 +0200
Gary Jennejohn <gljennj...@gmail.com> wrote:
On Mon, 26 Jun 2017 10:29:47 +0200
"O. Hartmann" <o.hartm...@walstatt.org> 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 fowllowing the thread, I did as advised:
removing /usr/obj completely (we use filemon/WITH_META_MODE=YES all
over the place) and recompiling world and kernel.

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 mergemaster and tried to do "make installworld" - but
the box instantanously bails out:

Fatal error 'Cannot allocate red zone for initial thread' at line 392 in
file /usr/src/lib/libthread/thr_init.c
pid 60 (cc) uid0: exited on signal 6 ...


That way, I obviously can not install a world :-(

What is wrong here? Is the problem resovable?

How recent was your last update?  Some changes were made just a few
hours ago to fix a stack growth problem in threads.

Well, what do you mean by "...  source is not up to date ..."?
Performing an svn update of /usr/src should suffice, shouldn't
it?  If not, then ...  please correct me.  I think the sources
are up to date as of the moment the bug occured.

I consider the sources up to date, it is on the latest updated
box r320355.

You did not explicitly state in the orignal post at which SVN
revison your code was.  Seems to me that my question was

Now it's clear that your source should have been up to date.

Just for the record, I just booted a kernel from SVN r320357 which
immediately resulted in a kernel panic.  I had to delete everything
under /usr/obj/usr/src/sys to get a working kernel.

That has been made clear earlier in the thread, telling us that NO_CLEAN
and/or META_MODE leaves the object tree in a somehow unusable state. Id did so
twice this morning.

I have to build a kernel with KTRACE capabilities as requested herein, but can
perform this not before tomorrow morning.

Some people seem to report positive updates, but starting from a later svn
revision. So the problem seems to be transitional ...


This happens on systems with identical 12-current kernel and different user-space, like jails.

Fatal error 'Cannot allocate red zone for initial thread' at line 399 in
file /usr/src/lib/libthr/thread/thr_init.c (errno = 12)

In the one case I have a more recent 12-current user-space. On the other one which is failing I have 10-stable with 12-current kernel.

Here is the kdump leading up to the error:

  1465 xxx RET   __sysctl 0
1465 xxx CALL __sysctl(0x7fffffffdb90,0x3,0x80127632c,0x7fffffffdc38,0,0)
  1465 xxx SCTL  "kern.smp.cpus"
  1465 xxx RET   __sysctl 0
1465 xxx CALL mmap(0,0x400000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0)
  1465 xxx RET   mmap 34389098496/0x801c00000
  1465 xxx CALL  thr_self(0x801c06400)
  1465 xxx RET   thr_self 0
1465 xxx CALL mmap(0x7fffffbfe000,0x1000,0<PROT_NONE>,0x1000<MAP_ANON>,0xffffffff,0)
  1465 xxx RET   mmap -1 errno 12 Cannot allocate memory
  1465 xxx CALL  write(0x2,0x7fffffffdbc7,0x1)
  1465 xxx GIO   fd 2 wrote 1 byte

Does this give any hints about a solution? Is this related to sign-extension of the -1U parameter in the end of mmap() ?

Updating to the very latest version of FreeBSD-12-current kernel seems to fix this issue.


freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to