Re: Ports still broken by ino64?

2017-06-25 Thread Thomas Mueller 
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 the pkg-descr.

One less tool for getting debugging information when something crashes?

Tom

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2017-06-25 Thread Jeffrey Bouquet 
  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 ...' which would substitute for the 
buildworld 
cycle?  Also, one would be rebooted into a GENERIC kernel, ... and other 
details ?

  
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2017-06-25 Thread Benjamin Kaduk 
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
> handbook, though.

To be clear, that is: one of you please supply the correct commands
to execute this configuration manually (i.e., not via rc.conf), or the
rest of the documentation is unlikely to get updated.

Thanks,

Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Ports still broken by ino64?

2017-06-25 Thread Adrian Chadd 
Hi,

valgrind broke as part of the ino64 work :(


-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Skylake/Kabylake Intel Bug?

2017-06-25 Thread Pete Wright 



On 06/25/2017 14:53, A. Wilcox wrote:

On 25/06/17 12:56, Pete Wright wrote:

Came across this post today via HN regarding a issue with Hyperthreading
causing unpredictable behavior on these CPU's

https://lists.debian.org/debian-devel/2017/06/msg00308.html

I really wish there was more info on this in the email, for example
examples of programs being effected by this bug.  Anywho - was wondering
if any devs here had more info on this issue and could provide better
context?

Cheers,

-pete


The linked OCaml issue goes quite in-depth with the mechanisms behind
this bug and the risks behind not patching the microcode:

https://caml.inria.fr/mantis/view.php?id=7452


Basically, if a HyperThreaded core is running a tight loop accessing
%rax and %ah (or %rbx and %bh, etc) in quick succession, on both threads
of the same physical core, it can corrupt/poison L1d cache.

AIUI, OCaml manages to generate this code by manipulating tagged memory
addresses and the corresponding tag (the address is in %rax, and the tag
is at %ah).

I'd really love to see if this affects write-through-no-allocate cache
or only write-behind, but I haven't seen any program besides OCaml
actually manage to get GCC to generate the insn pattern that is needed,
and I don't have a Skylake or Kaby Lake CPU to test with anyway.


Fun little hardware bug.


Hope this helps you,
--arw


Thanks this is really helpful!  From the dire warning of the debian 
thread I was worried this was a very easy to run into runtime issue.  
Certainly sounds pretty darn serious, but having context at least gives 
me something to keep any eye out for as a syadmin - this def seems like 
a potentially interesting attack surface (as most CPU bugs tend to be) :)


i've got a couple effected CPUs that i use for dev purposes - might see 
if i can reproduce on my end just for shits and giggles.


-p

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ZFS ABD Panic

2017-06-25 Thread Shawn Webb 
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 = 1498436043
[141] KDB: stack backtrace:
[141] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe2fc8b0
[141] vpanic() at vpanic+0x19c/frame 0xfe2fc930
[141] kassert_panic() at kassert_panic+0x126/frame 0xfe2fc9a0
[141] sleepq_add() at sleepq_add+0x34f/frame 0xfe2fc9f0
[141] _sx_xlock_hard() at _sx_xlock_hard+0x2a4/frame 0xfe2fcaa0
[141] _sx_xlock() at _sx_xlock+0x98/frame 0xfe2fcae0
[141] refcount_remove_many() at refcount_remove_many+0x2a/frame 
0xfe2fcb20
[141] abd_return_buf() at abd_return_buf+0xe3/frame 0xfe2fcb50
[141] vdev_geom_io_intr() at vdev_geom_io_intr+0x114/frame 0xfe2fcb70
[141] g_io_schedule_up() at g_io_schedule_up+0x42/frame 0xfe2fcba0
[141] g_up_procbody() at g_up_procbody+0x6d/frame 0xfe2fcbb0
[141] fork_exit() at fork_exit+0x84/frame 0xfe2fcbf0
[141] fork_trampoline() at fork_trampoline+0xe/frame 0xfe2fcbf0

  pool: rpool
 state: ONLINE
  scan: none requested
config:

NAME STATE READ WRITE CKSUM
rpoolONLINE   0 0 0
  mirror-0   ONLINE   0 0 0
mfid0p3  ONLINE   0 0 0
mfid1p3  ONLINE   0 0 0
  mirror-1   ONLINE   0 0 0
mfid2ONLINE   0 0 0
mfid3ONLINE   0 0 0

errors: No known data errors

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: Skylake/Kabylake Intel Bug?

2017-06-25 Thread A. Wilcox 
On 25/06/17 12:56, Pete Wright wrote:
> Came across this post today via HN regarding a issue with Hyperthreading
> causing unpredictable behavior on these CPU's
> 
> https://lists.debian.org/debian-devel/2017/06/msg00308.html
> 
> I really wish there was more info on this in the email, for example
> examples of programs being effected by this bug.  Anywho - was wondering
> if any devs here had more info on this issue and could provide better
> context?
> 
> Cheers,
> 
> -pete
> 

The linked OCaml issue goes quite in-depth with the mechanisms behind
this bug and the risks behind not patching the microcode:

https://caml.inria.fr/mantis/view.php?id=7452


Basically, if a HyperThreaded core is running a tight loop accessing
%rax and %ah (or %rbx and %bh, etc) in quick succession, on both threads
of the same physical core, it can corrupt/poison L1d cache.

AIUI, OCaml manages to generate this code by manipulating tagged memory
addresses and the corresponding tag (the address is in %rax, and the tag
is at %ah).

I'd really love to see if this affects write-through-no-allocate cache
or only write-behind, but I haven't seen any program besides OCaml
actually manage to get GCC to generate the insn pattern that is needed,
and I don't have a Skylake or Kaby Lake CPU to test with anyway.


Fun little hardware bug.


Hope this helps you,
--arw

-- 
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/



signature.asc
Description: OpenPGP digital signature

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

2017-06-25 Thread Boris Samorodov 
25.06.2017 16:21, Konstantin Belousov пишет:
> On Sun, Jun 25, 2017 at 06:05:21AM -0700, David Wolfskill wrote:
>> On Sun, Jun 25, 2017 at 03:52:23PM +0300, Konstantin Belousov wrote:
>>> ...
> The layout of the struct vm_map_entry was changed, the faulted address
> is somewhat consistent with ABI mismatch.

 Kinky. :-}
>>> Do you use any third-party modules ?
>>
>> On the laptop, I use x11/nvidia-driver-340; on the build machine, no.
>>
>> I think we should focus on the build machine -- it runs a GENERIC kernel
>> without ports (3rd-party) modules.
> Ok.
> 
>>
>> #cat /etc/src-env.conf 
>> WITH_META_MODE=yes
> 
> So can you _remove_ all kernel object files and rebuild anew with the
> clean build dir, please ?

I also use WITH_META_MODE=yes. And full rebuild helped here too.

Thank you.

-- 
WBR, bsam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Has gdb been disconnected from make installworld?

2017-06-25 Thread Benjamin Kaduk 
On Sun, Jun 25, 2017 at 09:03:58PM +0200, Trond Endrestøl wrote:
> On Sun, 25 Jun 2017 20:55+0200, Trond Endrestøl wrote:
> 
> > I was at bit surprised to see gdb missing from /usr/bin this evening. 
> > The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb.
> > 
> > This is on base/head r320329.
> > 
> > Do we need to add WITH_GDB=yes to our src.conf files?
> 
> Ah, they wound up in /usr/libexec. Still, that's an odd place for user 
> software.

---
r317416 | jhb | 2017-04-25 13:08:56 -0500 (Tue, 25 Apr 2017) | 16 lines

Add a new GDB_LIBEXEC option to install gdb and kgdb to /usr/libexec.

When this option is enabled, only gdb and kgdb are installed to
/usr/libexec for use by crashinfo(8). Other bits of GDB such as
gdbserver and gdbtui are not installed. For this option to be
effective, GDB must be enabled.

Rework r317094 to re-enable GDB on all platforms but enable
GDB_LIBEXEC on platforms for which the GDB in ports is a superset of
functionality.

Reviewed by:emaste, kib
Suggested by:   kib
Relnotes:   yes
Differential Revision:  https://reviews.freebsd.org/D10449
---


Note specifically that the GDB in ports is a substantial improvement in
functionality on amd64.

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2017-06-25 Thread Konstantin Belousov 
On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > https://people.freebsd.org/~kib/misc/vm2.2.patch
> 
> This patch made ruby23 happy on my end. Can't say the same for 
> emacs-nox11 or temacs while building the former.

What exactly do you mean ?  Explain the behaviour and show the ktrace log.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Has gdb been disconnected from make installworld?

2017-06-25 Thread Trond Endrestøl 
On Sun, 25 Jun 2017 20:55+0200, Trond Endrestøl wrote:

> I was at bit surprised to see gdb missing from /usr/bin this evening. 
> The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb.
> 
> This is on base/head r320329.
> 
> Do we need to add WITH_GDB=yes to our src.conf files?

Ah, they wound up in /usr/libexec. Still, that's an odd place for user 
software.

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Has gdb been disconnected from make installworld?

2017-06-25 Thread Trond Endrestøl 
I was at bit surprised to see gdb missing from /usr/bin this evening. 
The executables are still being built in /usr/obj/usr/src/gnu/usr.bin/gdb.

This is on base/head r320329.

Do we need to add WITH_GDB=yes to our src.conf files?

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2017-06-25 Thread Trond Endrestøl 
On Sun, 25 Jun 2017 19:41+0300, Konstantin Belousov wrote:

> On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
> > 
> > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov  
> > > wrote:
> > > 
> > > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote:
> > >> maybe message got reformatted in mail program (mac mail).
> > >> could you send me a tar file of the patch?
> > >> also not sure if ???patch -p1  > >> patch
> > >> 
> > >> you could cc r...@pozo.com  , that way i have copy 
> > >> on freebsd box and on mac.
> > > 
> > > https://people.freebsd.org/~kib/misc/vm2.1.patch 
> > > 
> > 
> > OK patched and built new kernel \
> > rebooted,
> > same ruby message. So it must be a ruby thing.
> > new kdump.txt at http://www.pozo.com/kernel/kdump.txt 
> > 
> > 
> > also i???ll put a copy of my kernel config in same directory:
> > 
> > http://www.pozo.com/kernel/pozo 
> > 
> > only one module is being loaded at boot:
> > (kernel)4908}kldstat
> > Id Refs AddressSize Name
> >  15 0x8020 10380a8  kernel
> >  21 0x8123a000 e13f50   nvidia.ko 
> > 
> > I can disable nvidia if it helps as I really only access this machine over 
> > the net or serial console.
> > 
> 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 stack
> split.
> 
> It seems that ruby requested very small stack for a new thread, only 5
> pages in size.  This size caused the stack gap to be correctly calculated
> as having zero size, because the whole stack is allocated by initial grow.
> But then there is no space for the guard page, which caused mapping failure
> for it, and overall stack mapping failure.
> 
> Try this.
> https://people.freebsd.org/~kib/misc/vm2.2.patch

This patch made ruby23 happy on my end. Can't say the same for 
emacs-nox11 or temacs while building the former.

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Skylake/Kabylake Intel Bug?

2017-06-25 Thread Pete Wright 
Came across this post today via HN regarding a issue with Hyperthreading 
causing unpredictable behavior on these CPU's


https://lists.debian.org/debian-devel/2017/06/msg00308.html

I really wish there was more info on this in the email, for example 
examples of programs being effected by this bug.  Anywho - was wondering 
if any devs here had more info on this issue and could provide better 
context?


Cheers,

-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2017-06-25 Thread Manfred Antar 

> On Jun 25, 2017, at 10:21 AM, Konstantin Belousov  wrote:
> 
> On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote:
>> 
>>> On Jun 25, 2017, at 9:41 AM, Konstantin Belousov  
>>> wrote:
>>> 
>>> On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
 
> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov  
> wrote:
> 
> On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote:
>> maybe message got reformatted in mail program (mac mail).
>> could you send me a tar file of the patch?
>> also not sure if ???patch -p1 > patch
>> 
>> you could cc r...@pozo.com  , that way i have copy 
>> on freebsd box and on mac.
> 
> https://people.freebsd.org/~kib/misc/vm2.1.patch 
> 
 
 OK patched and built new kernel \
 rebooted,
 same ruby message. So it must be a ruby thing.
 new kdump.txt at http://www.pozo.com/kernel/kdump.txt 
 
 
 also i???ll put a copy of my kernel config in same directory:
 
 http://www.pozo.com/kernel/pozo 
 
 only one module is being loaded at boot:
 (kernel)4908}kldstat
 Id Refs AddressSize Name
 15 0x8020 10380a8  kernel
 21 0x8123a000 e13f50   nvidia.ko 
 
 I can disable nvidia if it helps as I really only access this machine over 
 the net or serial console.
 
>>> 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 stack
>>> split.
>>> 
>>> It seems that ruby requested very small stack for a new thread, only 5
>>> pages in size.  This size caused the stack gap to be correctly calculated
>>> as having zero size, because the whole stack is allocated by initial grow.
>>> But then there is no space for the guard page, which caused mapping failure
>>> for it, and overall stack mapping failure.
>>> 
>>> Try this.
>>> https://people.freebsd.org/~kib/misc/vm2.2.patch
>> 
>> Seems to have worked:
>> 
>> (~)4933}ruby -v
>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
>> (~)4934}
>> 
>> No more message. Do you want new ktrace ?
> 
> Thanks for testing.  You might post the trace.

New trace at :

http://www.pozo.com/kernel/kdump-working.txt 


Thanks
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2017-06-25 Thread Konstantin Belousov 
On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote:
> 
> > On Jun 25, 2017, at 9:41 AM, Konstantin Belousov  
> > wrote:
> > 
> > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
> >> 
> >>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov  
> >>> wrote:
> >>> 
> >>> On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote:
>  maybe message got reformatted in mail program (mac mail).
>  could you send me a tar file of the patch?
>  also not sure if ???patch -p1   patch
>  
>  you could cc r...@pozo.com  , that way i have copy 
>  on freebsd box and on mac.
> >>> 
> >>> https://people.freebsd.org/~kib/misc/vm2.1.patch 
> >>> 
> >> 
> >> OK patched and built new kernel \
> >> rebooted,
> >> same ruby message. So it must be a ruby thing.
> >> new kdump.txt at http://www.pozo.com/kernel/kdump.txt 
> >> 
> >> 
> >> also i???ll put a copy of my kernel config in same directory:
> >> 
> >> http://www.pozo.com/kernel/pozo 
> >> 
> >> only one module is being loaded at boot:
> >> (kernel)4908}kldstat
> >> Id Refs AddressSize Name
> >> 15 0x8020 10380a8  kernel
> >> 21 0x8123a000 e13f50   nvidia.ko 
> >> 
> >> I can disable nvidia if it helps as I really only access this machine over 
> >> the net or serial console.
> >> 
> > 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 stack
> > split.
> > 
> > It seems that ruby requested very small stack for a new thread, only 5
> > pages in size.  This size caused the stack gap to be correctly calculated
> > as having zero size, because the whole stack is allocated by initial grow.
> > But then there is no space for the guard page, which caused mapping failure
> > for it, and overall stack mapping failure.
> > 
> > Try this.
> > https://people.freebsd.org/~kib/misc/vm2.2.patch
> 
> Seems to have worked:
> 
> (~)4933}ruby -v
> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> (~)4934}
> 
> No more message. Do you want new ktrace ?

Thanks for testing.  You might post the trace.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2017-06-25 Thread Manfred Antar 

> On Jun 25, 2017, at 9:41 AM, Konstantin Belousov  wrote:
> 
> On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
>> 
>>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov  
>>> wrote:
>>> 
>>> On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote:
 maybe message got reformatted in mail program (mac mail).
 could you send me a tar file of the patch?
 also not sure if ???patch -p1  , that way i have copy 
 on freebsd box and on mac.
>>> 
>>> https://people.freebsd.org/~kib/misc/vm2.1.patch 
>>> 
>> 
>> OK patched and built new kernel \
>> rebooted,
>> same ruby message. So it must be a ruby thing.
>> new kdump.txt at http://www.pozo.com/kernel/kdump.txt 
>> 
>> 
>> also i???ll put a copy of my kernel config in same directory:
>> 
>> http://www.pozo.com/kernel/pozo 
>> 
>> only one module is being loaded at boot:
>> (kernel)4908}kldstat
>> Id Refs AddressSize Name
>> 15 0x8020 10380a8  kernel
>> 21 0x8123a000 e13f50   nvidia.ko 
>> 
>> I can disable nvidia if it helps as I really only access this machine over 
>> the net or serial console.
>> 
> 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 stack
> split.
> 
> It seems that ruby requested very small stack for a new thread, only 5
> pages in size.  This size caused the stack gap to be correctly calculated
> as having zero size, because the whole stack is allocated by initial grow.
> But then there is no space for the guard page, which caused mapping failure
> for it, and overall stack mapping failure.
> 
> Try this.
> https://people.freebsd.org/~kib/misc/vm2.2.patch

Seems to have worked:

(~)4933}ruby -v
ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
(~)4934}

No more message. Do you want new ktrace ?

Thanks
Manfred
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2017-06-25 Thread Konstantin Belousov 
On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
> 
> > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov  
> > wrote:
> > 
> > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote:
> >> maybe message got reformatted in mail program (mac mail).
> >> could you send me a tar file of the patch?
> >> also not sure if ???patch -p1  >> patch
> >> 
> >> you could cc r...@pozo.com  , that way i have copy 
> >> on freebsd box and on mac.
> > 
> > https://people.freebsd.org/~kib/misc/vm2.1.patch 
> > 
> 
> OK patched and built new kernel \
> rebooted,
> same ruby message. So it must be a ruby thing.
> new kdump.txt at http://www.pozo.com/kernel/kdump.txt 
> 
> 
> also i???ll put a copy of my kernel config in same directory:
> 
> http://www.pozo.com/kernel/pozo 
> 
> only one module is being loaded at boot:
> (kernel)4908}kldstat
> Id Refs AddressSize Name
>  15 0x8020 10380a8  kernel
>  21 0x8123a000 e13f50   nvidia.ko 
> 
> I can disable nvidia if it helps as I really only access this machine over 
> the net or serial console.
> 
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 stack
split.

It seems that ruby requested very small stack for a new thread, only 5
pages in size.  This size caused the stack gap to be correctly calculated
as having zero size, because the whole stack is allocated by initial grow.
But then there is no space for the guard page, which caused mapping failure
for it, and overall stack mapping failure.

Try this.
https://people.freebsd.org/~kib/misc/vm2.2.patch
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2017-06-25 Thread Trond Endrestøl 
On Sun, 25 Jun 2017 18:08+0200, Trond Endrestøl wrote:

> On Sun, 25 Jun 2017 17:56+0200, Trond Endrestøl wrote:
> 
> > On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote:
> > 
> > > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:
> > > 
> > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> > > > > 
> > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov 
> > > > > >  wrote:
> > > > > > 
> > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> > > > > >> 
> > > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov 
> > > > > >>>  wrote:
> > > > > >>> 
> > > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> > > > >  New world and kernel  r320323
> > > > >  I get a new error or message when using ruby:
> > > > >  
> > > > >  
> > > > >  /usr/local/sbin/portupgrade -av
> > > > >  : warning: pthread_create failed for timer: Resource 
> > > > >  temporarily unavailable, scheduling broken
> > > > >  
> > > > >  everything works just this message when using ruby. I recompiled 
> > > > >  ruby , still same message
> > > > >  
> > > > >  /usr/local/bin/ruby -v
> > > > >  : warning: pthread_create failed for timer: Resource 
> > > > >  temporarily unavailable, scheduling broken
> > > > >  ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > > > >  
> > > > >  Not sure what???s changed, I noticed some commits to vm stuff, 
> > > > >  maybe thats it.
> > > > > >>> 
> > > > > >>> ktrace your failing ruby invocation, then post output of kdump -H 
> > > > > >>> somewhere.
> > > > > >>> 
> > > > > >> 
> > > > > >> Ok not sure  if this is right , but this is what i did:
> > > > > >> 
> > > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v
> > > > > >> : warning: pthread_create failed for timer: Resource 
> > > > > >> temporarily unavailable, scheduling broken
> > > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > > > > >> 
> > > > > >> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> > > > > >> 
> > > > > >> you can get kdump.txt at:
> > > > > >> 
> > > > > >> http://www.pozo.com/kernel/kdump 
> > > > > >> .txt
> > > > > >> 
> > > > > >> It???s not failing, I don???t think , I can do portupgrade and it 
> > > > > >> works fine.
> > > > > >> I just get this new message
> > > > > > 
> > > > > > I see what is going on, but it is somewhat strange that it happens.
> > > > > > 
> > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ?
> > > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set 
> > > > > > in
> > > > > > your environment ?
> > > > > > 
> > > > > > Anyway, the rework of the stack grow indeed have incompatibility 
> > > > > > with the
> > > > > > old (pre-11) libthr, which tries to split main thread stack into 
> > > > > > smaller
> > > > > > stacks for the new threads.  New stack grow code was specifically 
> > > > > > designed
> > > > > > to prevent this.  Some hack would be needed there, to allow reuse of
> > > > > > the main stack gap.
> > > > > > 
> > > > > 
> > > > > Not running any jails
> > > > > all libraries are current as of today
> > > > > locate libthr. |xargs ls -l
> > > > > -r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
> > > > > -r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
> > > > > lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
> > > > > ../../lib/libthr.so.3
> > > > > 
> > > > > ldd /usr/local/bin/ruby
> > > > > -rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 
> > > > > /usr/local/lib/libruby23.so.2
> > > > > -rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 
> > > > > /usr/local/lib/libunwind.so.8.0.1
> > > > > 
> > > > > /usr/local/bin/ruby:
> > > > >   libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
> > > > >   libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
> > > > >   libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
> > > > >   libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
> > > > >   libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
> > > > >   libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
> > > > >   libm.so.5 => /lib/libm.so.5 (0x8018f9000)
> > > > >   libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
> > > > >   libc.so.7 => /lib/libc.so.7 (0x801d4e000)
> > > > >   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
> > > > >   liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
> > > > >   libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
> > > > >   libutil.so.9 => /lib/libutil.so.9 (0x802982000)
> > > > > 
> > > > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere
> > > > > 
> > > > > This is a fresh buildworld - installworld from noon today California 
> > > > > time.
> > > > > 
> > > > > here are env in make.conf:
> > > > > DEFAULT_VERSIONS=

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

2017-06-25 Thread Trond Endrestøl 
On Sun, 25 Jun 2017 17:56+0200, Trond Endrestøl wrote:

> On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote:
> 
> > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:
> > 
> > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> > > > 
> > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov 
> > > > >  wrote:
> > > > > 
> > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> > > > >> 
> > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov 
> > > > >>>  wrote:
> > > > >>> 
> > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> > > >  New world and kernel  r320323
> > > >  I get a new error or message when using ruby:
> > > >  
> > > >  
> > > >  /usr/local/sbin/portupgrade -av
> > > >  : warning: pthread_create failed for timer: Resource 
> > > >  temporarily unavailable, scheduling broken
> > > >  
> > > >  everything works just this message when using ruby. I recompiled 
> > > >  ruby , still same message
> > > >  
> > > >  /usr/local/bin/ruby -v
> > > >  : warning: pthread_create failed for timer: Resource 
> > > >  temporarily unavailable, scheduling broken
> > > >  ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > > >  
> > > >  Not sure what???s changed, I noticed some commits to vm stuff, 
> > > >  maybe thats it.
> > > > >>> 
> > > > >>> ktrace your failing ruby invocation, then post output of kdump -H 
> > > > >>> somewhere.
> > > > >>> 
> > > > >> 
> > > > >> Ok not sure  if this is right , but this is what i did:
> > > > >> 
> > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v
> > > > >> : warning: pthread_create failed for timer: Resource 
> > > > >> temporarily unavailable, scheduling broken
> > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > > > >> 
> > > > >> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> > > > >> 
> > > > >> you can get kdump.txt at:
> > > > >> 
> > > > >> http://www.pozo.com/kernel/kdump 
> > > > >> .txt
> > > > >> 
> > > > >> It???s not failing, I don???t think , I can do portupgrade and it 
> > > > >> works fine.
> > > > >> I just get this new message
> > > > > 
> > > > > I see what is going on, but it is somewhat strange that it happens.
> > > > > 
> > > > > Do you run ruby in a jail with old (say, stable/10) libthr ?
> > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in
> > > > > your environment ?
> > > > > 
> > > > > Anyway, the rework of the stack grow indeed have incompatibility with 
> > > > > the
> > > > > old (pre-11) libthr, which tries to split main thread stack into 
> > > > > smaller
> > > > > stacks for the new threads.  New stack grow code was specifically 
> > > > > designed
> > > > > to prevent this.  Some hack would be needed there, to allow reuse of
> > > > > the main stack gap.
> > > > > 
> > > > 
> > > > Not running any jails
> > > > all libraries are current as of today
> > > > locate libthr. |xargs ls -l
> > > > -r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
> > > > -r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
> > > > lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
> > > > ../../lib/libthr.so.3
> > > > 
> > > > ldd /usr/local/bin/ruby
> > > > -rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 
> > > > /usr/local/lib/libruby23.so.2
> > > > -rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 
> > > > /usr/local/lib/libunwind.so.8.0.1
> > > > 
> > > > /usr/local/bin/ruby:
> > > > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
> > > > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
> > > > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
> > > > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
> > > > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
> > > > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
> > > > libm.so.5 => /lib/libm.so.5 (0x8018f9000)
> > > > libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
> > > > libc.so.7 => /lib/libc.so.7 (0x801d4e000)
> > > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
> > > > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
> > > > libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
> > > > libutil.so.9 => /lib/libutil.so.9 (0x802982000)
> > > > 
> > > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere
> > > > 
> > > > This is a fresh buildworld - installworld from noon today California 
> > > > time.
> > > > 
> > > > here are env in make.conf:
> > > > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 
> > > > perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base
> > > > MALLOC_PRODUCTION=yes
> > > > WITH_BDB_VERSION=5
> > > > 
> > > > env in src.conf:
> > > > WITHOUT_DYNAMICROOT=yes 
> > > >

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

2017-06-25 Thread Trond Endrestøl 
On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote:

> On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:
> 
> > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> > > 
> > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov  
> > > > wrote:
> > > > 
> > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> > > >> 
> > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov 
> > > >>>  wrote:
> > > >>> 
> > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> > >  New world and kernel  r320323
> > >  I get a new error or message when using ruby:
> > >  
> > >  
> > >  /usr/local/sbin/portupgrade -av
> > >  : warning: pthread_create failed for timer: Resource 
> > >  temporarily unavailable, scheduling broken
> > >  
> > >  everything works just this message when using ruby. I recompiled 
> > >  ruby , still same message
> > >  
> > >  /usr/local/bin/ruby -v
> > >  : warning: pthread_create failed for timer: Resource 
> > >  temporarily unavailable, scheduling broken
> > >  ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > >  
> > >  Not sure what???s changed, I noticed some commits to vm stuff, maybe 
> > >  thats it.
> > > >>> 
> > > >>> ktrace your failing ruby invocation, then post output of kdump -H 
> > > >>> somewhere.
> > > >>> 
> > > >> 
> > > >> Ok not sure  if this is right , but this is what i did:
> > > >> 
> > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v
> > > >> : warning: pthread_create failed for timer: Resource temporarily 
> > > >> unavailable, scheduling broken
> > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > > >> 
> > > >> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> > > >> 
> > > >> you can get kdump.txt at:
> > > >> 
> > > >> http://www.pozo.com/kernel/kdump .txt
> > > >> 
> > > >> It???s not failing, I don???t think , I can do portupgrade and it 
> > > >> works fine.
> > > >> I just get this new message
> > > > 
> > > > I see what is going on, but it is somewhat strange that it happens.
> > > > 
> > > > Do you run ruby in a jail with old (say, stable/10) libthr ?
> > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in
> > > > your environment ?
> > > > 
> > > > Anyway, the rework of the stack grow indeed have incompatibility with 
> > > > the
> > > > old (pre-11) libthr, which tries to split main thread stack into smaller
> > > > stacks for the new threads.  New stack grow code was specifically 
> > > > designed
> > > > to prevent this.  Some hack would be needed there, to allow reuse of
> > > > the main stack gap.
> > > > 
> > > 
> > > Not running any jails
> > > all libraries are current as of today
> > > locate libthr. |xargs ls -l
> > > -r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
> > > -r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
> > > lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
> > > ../../lib/libthr.so.3
> > > 
> > > ldd /usr/local/bin/ruby
> > > -rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 
> > > /usr/local/lib/libruby23.so.2
> > > -rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 
> > > /usr/local/lib/libunwind.so.8.0.1
> > > 
> > > /usr/local/bin/ruby:
> > >   libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
> > >   libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
> > >   libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
> > >   libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
> > >   libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
> > >   libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
> > >   libm.so.5 => /lib/libm.so.5 (0x8018f9000)
> > >   libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
> > >   libc.so.7 => /lib/libc.so.7 (0x801d4e000)
> > >   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
> > >   liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
> > >   libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
> > >   libutil.so.9 => /lib/libutil.so.9 (0x802982000)
> > > 
> > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere
> > > 
> > > This is a fresh buildworld - installworld from noon today California time.
> > > 
> > > here are env in make.conf:
> > > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 
> > > perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base
> > > MALLOC_PRODUCTION=yes
> > > WITH_BDB_VERSION=5
> > > 
> > > env in src.conf:
> > > WITHOUT_DYNAMICROOT=yes 
> > > WITHOUT_UNBOUND=yes
> > > WITHOUT_CASPER=yes
> > > WITHOUT_CAPSICUM=yes
> > > WITHOUT_DMAGENT=yes
> > > WITHOUT_PROFILE=yes
> > > WITHOUT_TESTS=yes
> > > WITHOUT_KERNEL_SYMBOLS=yes
> > > WITHOUT_DEBUG_FILES=1
> > > WITHOUT_LIB32=yes
> > > INSTALL_NODEBUG=yes
> > > 
> > > # Don't die on warnings
> > > NO_WERROR=
> > > WERROR=
> > > KERNCONF=pozo
> > > WITH_CCACHE_BUILD=yes
> > 
> > Weird, I do not

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

2017-06-25 Thread Trond Endrestøl 
On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:

> On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> > 
> > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov  
> > > wrote:
> > > 
> > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> > >> 
> > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov  
> > >>> wrote:
> > >>> 
> > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> >  New world and kernel  r320323
> >  I get a new error or message when using ruby:
> >  
> >  
> >  /usr/local/sbin/portupgrade -av
> >  : warning: pthread_create failed for timer: Resource temporarily 
> >  unavailable, scheduling broken
> >  
> >  everything works just this message when using ruby. I recompiled ruby 
> >  , still same message
> >  
> >  /usr/local/bin/ruby -v
> >  : warning: pthread_create failed for timer: Resource temporarily 
> >  unavailable, scheduling broken
> >  ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> >  
> >  Not sure what???s changed, I noticed some commits to vm stuff, maybe 
> >  thats it.
> > >>> 
> > >>> ktrace your failing ruby invocation, then post output of kdump -H 
> > >>> somewhere.
> > >>> 
> > >> 
> > >> Ok not sure  if this is right , but this is what i did:
> > >> 
> > >> (tmp)4637}ktrace /usr/local/bin/ruby -v
> > >> : warning: pthread_create failed for timer: Resource temporarily 
> > >> unavailable, scheduling broken
> > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > >> 
> > >> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> > >> 
> > >> you can get kdump.txt at:
> > >> 
> > >> http://www.pozo.com/kernel/kdump .txt
> > >> 
> > >> It???s not failing, I don???t think , I can do portupgrade and it works 
> > >> fine.
> > >> I just get this new message
> > > 
> > > I see what is going on, but it is somewhat strange that it happens.
> > > 
> > > Do you run ruby in a jail with old (say, stable/10) libthr ?
> > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in
> > > your environment ?
> > > 
> > > Anyway, the rework of the stack grow indeed have incompatibility with the
> > > old (pre-11) libthr, which tries to split main thread stack into smaller
> > > stacks for the new threads.  New stack grow code was specifically designed
> > > to prevent this.  Some hack would be needed there, to allow reuse of
> > > the main stack gap.
> > > 
> > 
> > Not running any jails
> > all libraries are current as of today
> > locate libthr. |xargs ls -l
> > -r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
> > -r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
> > lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
> > ../../lib/libthr.so.3
> > 
> > ldd /usr/local/bin/ruby
> > -rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 
> > /usr/local/lib/libruby23.so.2
> > -rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 
> > /usr/local/lib/libunwind.so.8.0.1
> > 
> > /usr/local/bin/ruby:
> > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
> > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
> > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
> > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
> > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
> > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
> > libm.so.5 => /lib/libm.so.5 (0x8018f9000)
> > libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
> > libc.so.7 => /lib/libc.so.7 (0x801d4e000)
> > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
> > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
> > libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
> > libutil.so.9 => /lib/libutil.so.9 (0x802982000)
> > 
> > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere
> > 
> > This is a fresh buildworld - installworld from noon today California time.
> > 
> > here are env in make.conf:
> > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 
> > perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base
> > MALLOC_PRODUCTION=yes
> > WITH_BDB_VERSION=5
> > 
> > env in src.conf:
> > WITHOUT_DYNAMICROOT=yes 
> > WITHOUT_UNBOUND=yes
> > WITHOUT_CASPER=yes
> > WITHOUT_CAPSICUM=yes
> > WITHOUT_DMAGENT=yes
> > WITHOUT_PROFILE=yes
> > WITHOUT_TESTS=yes
> > WITHOUT_KERNEL_SYMBOLS=yes
> > WITHOUT_DEBUG_FILES=1
> > WITHOUT_LIB32=yes
> > INSTALL_NODEBUG=yes
> > 
> > # Don't die on warnings
> > NO_WERROR=
> > WERROR=
> > KERNCONF=pozo
> > WITH_CCACHE_BUILD=yes
> 
> Weird, I do not see where such behaviour could come from.  I mean,
> the behaviour of the libthr, assuming that the failing call is from
> libthr and not from the ruby.
> 
> Anyway, please try the following.  Note that this might be not the final
> fix, but I am interesting in seeing whether it fixed the issue

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

2017-06-25 Thread David Wolfskill 
On Sun, Jun 25, 2017 at 04:21:16PM +0300, Konstantin Belousov wrote:
> ...
> > #cat /etc/src-env.conf 
> > WITH_META_MODE=yes
> 
> So can you _remove_ all kernel object files and rebuild anew with the
> clean build dir, please ?

OK; that seems to have resulted in a kernel that boots to multi-user
mode without incident:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT 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

To remove any possible ambiguity, here is what I did.  (Note that
head is on slice 4; recent stable/11 is on slice 1; when booted
from slice 1, slice 4's / is mounted on /S4.)
* Rebooted from slice 1 (stable/11).
* cd /S4/usr/obj
* cp -p usr/src/sys/GENERIC/version /tmp
* rm -fr usr/src/sys/GENERIC
* mkdir !$
* mv /tmp/version !$/
* cd /S4/boot
* cp -pr kernel.old kernel.save
* mv kernel{,.panic}
* mv kernel{.old,}
* Rebooted from slice 4 (head@r320307)
* setenv TMPDIR /tmp &&\
  id &&\
  mount &&\
  cd /usr/src &&\
  uname -a &&\
  date &&\
  make -j16 buildkernel &&\
  date &&\
  rm -fr /boot/modules.old &&\
  cp -pr /boot/modules{,.old} &&\
  make installkernel &&\
  date
* shutdown -r now
* Sent this message. :-)

Thanks!

Peace,
david

-- 
David H. Wolfskill  da...@catwhisker.org
Trump (et al.): Hiding information doesn't prove its falsity.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

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

2017-06-25 Thread Konstantin Belousov 
On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> 
> > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov  
> > wrote:
> > 
> > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> >> 
> >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov  
> >>> wrote:
> >>> 
> >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
>  New world and kernel  r320323
>  I get a new error or message when using ruby:
>  
>  
>  /usr/local/sbin/portupgrade -av
>  : warning: pthread_create failed for timer: Resource temporarily 
>  unavailable, scheduling broken
>  
>  everything works just this message when using ruby. I recompiled ruby , 
>  still same message
>  
>  /usr/local/bin/ruby -v
>  : warning: pthread_create failed for timer: Resource temporarily 
>  unavailable, scheduling broken
>  ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
>  
>  Not sure what???s changed, I noticed some commits to vm stuff, maybe 
>  thats it.
> >>> 
> >>> ktrace your failing ruby invocation, then post output of kdump -H 
> >>> somewhere.
> >>> 
> >> 
> >> Ok not sure  if this is right , but this is what i did:
> >> 
> >> (tmp)4637}ktrace /usr/local/bin/ruby -v
> >> : warning: pthread_create failed for timer: Resource temporarily 
> >> unavailable, scheduling broken
> >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> >> 
> >> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> >> 
> >> you can get kdump.txt at:
> >> 
> >> http://www.pozo.com/kernel/kdump .txt
> >> 
> >> It???s not failing, I don???t think , I can do portupgrade and it works 
> >> fine.
> >> I just get this new message
> > 
> > I see what is going on, but it is somewhat strange that it happens.
> > 
> > Do you run ruby in a jail with old (say, stable/10) libthr ?
> > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in
> > your environment ?
> > 
> > Anyway, the rework of the stack grow indeed have incompatibility with the
> > old (pre-11) libthr, which tries to split main thread stack into smaller
> > stacks for the new threads.  New stack grow code was specifically designed
> > to prevent this.  Some hack would be needed there, to allow reuse of
> > the main stack gap.
> > 
> 
> Not running any jails
> all libraries are current as of today
> locate libthr. |xargs ls -l
> -r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
> -r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
> lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
> ../../lib/libthr.so.3
> 
> ldd /usr/local/bin/ruby
> -rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 /usr/local/lib/libruby23.so.2
> -rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 
> /usr/local/lib/libunwind.so.8.0.1
> 
> /usr/local/bin/ruby:
>   libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
>   libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
>   libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
>   libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
>   libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
>   libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
>   libm.so.5 => /lib/libm.so.5 (0x8018f9000)
>   libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
>   libc.so.7 => /lib/libc.so.7 (0x801d4e000)
>   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
>   liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
>   libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
>   libutil.so.9 => /lib/libutil.so.9 (0x802982000)
> 
> no LIBPTHREAD_SPLITSTACK_MAIN set anywhere
> 
> This is a fresh buildworld - installworld from noon today California time.
> 
> here are env in make.conf:
> DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 
> perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base
> MALLOC_PRODUCTION=yes
> WITH_BDB_VERSION=5
> 
> env in src.conf:
> WITHOUT_DYNAMICROOT=yes 
> WITHOUT_UNBOUND=yes
> WITHOUT_CASPER=yes
> WITHOUT_CAPSICUM=yes
> WITHOUT_DMAGENT=yes
> WITHOUT_PROFILE=yes
> WITHOUT_TESTS=yes
> WITHOUT_KERNEL_SYMBOLS=yes
> WITHOUT_DEBUG_FILES=1
> WITHOUT_LIB32=yes
> INSTALL_NODEBUG=yes
> 
> # Don't die on warnings
> NO_WERROR=
> WERROR=
> KERNCONF=pozo
> WITH_CCACHE_BUILD=yes

Weird, I do not see where such behaviour could come from.  I mean,
the behaviour of the libthr, assuming that the failing call is from
libthr and not from the ruby.

Anyway, please try the following.  Note that this might be not the final
fix, but I am interesting in seeing whether it fixed the issue for you.
I want to see the kdump output from ktrace _without_ -di, same as in 
your first trace.

diff --git a/lib/libc/sys/mprotect.2 b/lib/libc/sys/mprotect.2
index 3be81c6582a..ca4d6307c44 100644
--- a/lib/libc/sys/mprotect.2
+++ b/lib/libc/sys/mprotect.2
@@ -28,7 +28,7 @@
 .\"

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

2017-06-25 Thread Konstantin Belousov 
On Sun, Jun 25, 2017 at 06:05:21AM -0700, David Wolfskill wrote:
> On Sun, Jun 25, 2017 at 03:52:23PM +0300, Konstantin Belousov wrote:
> > ...
> > > > The layout of the struct vm_map_entry was changed, the faulted address
> > > > is somewhat consistent with ABI mismatch.
> > > 
> > > Kinky. :-}
> > Do you use any third-party modules ?
> 
> On the laptop, I use x11/nvidia-driver-340; on the build machine, no.
> 
> I think we should focus on the build machine -- it runs a GENERIC kernel
> without ports (3rd-party) modules.
Ok.

> 
> #cat /etc/src-env.conf 
> WITH_META_MODE=yes

So can you _remove_ all kernel object files and rebuild anew with the
clean build dir, please ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

2017-06-25 Thread David Wolfskill 
On Sun, Jun 25, 2017 at 03:52:23PM +0300, Konstantin Belousov wrote:
> ...
> > > The layout of the struct vm_map_entry was changed, the faulted address
> > > is somewhat consistent with ABI mismatch.
> > 
> > Kinky. :-}
> Do you use any third-party modules ?

On the laptop, I use x11/nvidia-driver-340; on the build machine, no.

I think we should focus on the build machine -- it runs a GENERIC kernel
without ports (3rd-party) modules.

Here are a few relevant files:
# cat /etc/src.conf
WITHOUT_DEBUG_FILES=1
WITH_ELFCOPY_AS_OBJCOPY=1
#
#cat /etc/src-env.conf 
WITH_META_MODE=yes
#
#cat /etc/make.conf
SENDMAIL_MC=/etc/mail/client.mc
# added by use.perl 2009-11-07 21:19:31
PERL_VERSION=5.12.1
WITH_PKGNG= YES
#
#cat /boot/loader.conf 
console="comconsole,vidconsole" # A comma separated list of console(s)
comconsole_pcidev="4:0:0"
comconsole_speed="9600"
filemon_load="YES"
# 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump (et al.): Hiding information doesn't prove its falsity.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

2017-06-25 Thread Konstantin Belousov 
On Sun, Jun 25, 2017 at 05:47:48AM -0700, David Wolfskill wrote:
> On Sun, Jun 25, 2017 at 03:32:26PM +0300, Konstantin Belousov wrote:
> > On Sun, Jun 25, 2017 at 05:07:31AM -0700, David Wolfskill wrote:
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 0; apic id = 00
> > > fault virtual address   = 0x120
> > This is clearly an impossible address.
> > 
> > Did you built the kernel with NO_CLEAN ?  If yes, try the full build,
> > perhaps even after removing all previous kernel objects.
> 
> No; I stopped using NO_CLEAN by 12 March 2016, in favor of filemon and
> WITH_FAST_DEPEND.  I have been doing daily builds & smoke-tests of
> head/amd64 since then.  (Well, I was also doing them before then,
> as well)
> 
> > The layout of the struct vm_map_entry was changed, the faulted address
> > is somewhat consistent with ABI mismatch.
> 
> Kinky. :-}
Do you use any third-party modules ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

2017-06-25 Thread David Wolfskill 
On Sun, Jun 25, 2017 at 03:32:26PM +0300, Konstantin Belousov wrote:
> On Sun, Jun 25, 2017 at 05:07:31AM -0700, David Wolfskill wrote:
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address   = 0x120
> This is clearly an impossible address.
> 
> Did you built the kernel with NO_CLEAN ?  If yes, try the full build,
> perhaps even after removing all previous kernel objects.

No; I stopped using NO_CLEAN by 12 March 2016, in favor of filemon and
WITH_FAST_DEPEND.  I have been doing daily builds & smoke-tests of
head/amd64 since then.  (Well, I was also doing them before then,
as well)

> The layout of the struct vm_map_entry was changed, the faulted address
> is somewhat consistent with ABI mismatch.

Kinky. :-}

> 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump (et al.): Hiding information doesn't prove its falsity.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

2017-06-25 Thread Konstantin Belousov 
On Sun, Jun 25, 2017 at 05:07:31AM -0700, David Wolfskill wrote:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x120
This is clearly an impossible address.

Did you built the kernel with NO_CLEAN ?  If yes, try the full build,
perhaps even after removing all previous kernel objects.

The layout of the struct vm_map_entry was changed, the faulted address
is somewhat consistent with ABI mismatch.

> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80d585a4
> stack pointer   = 0x28:0x82290a30
> frame pointer   = 0x28:0x82290a60
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= resume, IOPL = 0
> current process = 0 ()
> [ thread pid 0 tid 0 ]
> Stopped at  vm_map_lookup_entry+0x24:   cmpq%r15,0x20(%rbx)
> db> bt
> Tracing pid 0 tid 0 td 0x81e9e860
> vm_map_lookup_entry() at vm_map_lookup_entry+0x24/frame 0x82290a60
> vm_map_insert() at vm_map_insert+0x10b/frame 0x82290b00
> kmem_init() at kmem_init+0x72/frame 0x82290b30
> vm_mem_init() at vm_mem_init+0x46/frame 0x82290b50
> mi_startup() at mi_startup+0x9c/frame 0x82290b70
> btext() at btext+0x2c
> db> 
> 
> 
> (The laptop seems to have repeated the:
> 
> loading required module 'kernel'
> module 'kernel' exists but with wrong version
> 
> sequence a few times, based on the video I got of it.)
> 
> 
> The "saving grace" is that the panic happens before the file systems
> are mounted :-}
> 
> Unloading the (r320324) kernel and loading the r320307 kernel
> succeeds (at least enough to mount file systems).
> 
> Peace,
> david
> -- 
> David H. Wolfskillda...@catwhisker.org
> Trump (et al.): Hiding information doesn't prove its falsity.
> 
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

2017-06-25 Thread David Wolfskill 
Both on laptop and build machine; fortunately for me, the latter has a
serial console, so:

  __      _ _  
 |  | |  _ \ / |  __ \ 
 | |___ _ __ ___  ___ | |_) | (___ | |  | |
 |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
 | |   | | |  __/  __/| |_) |) | |__| |
 | |   | | |||| |  |  |
 |_|   |_|  \___|\___||/|_/|_/````
 s` `.---...--.```   -/
 +Welcome to FreeBSD===+ +o   .--` /y:`  +.
 | |  yo`:.:o  `+-
 |  1. Boot Multi User [Enter] |   y/   -/`   -o/
 |  2. Boot [S]ingle User  |  .-  ::/sy+:.
 |  3. [Esc]ape to loader prompt   |  / `--  /
 |  4. Reboot  | `:  :`
 | | `:  :`
 |  Options:   |  /  /
 |  5. [K]ernel: kernel (1 of 2)   |  .--.
 |  6. Configure Boot [O]ptions... |   --  -.
 | |`:`  `:`
 | |  .-- `--.
 | | .---.. 
 +=+
  

/boot/kernel/kernel text=0x14dea68 data=0x146b38+0x567b68 
syms=[0x8+0x16cae8+0x8+0x186331]
/boot/entropy size=0x1000
/boot/kernel/filemon.ko size 0xa128 at 0x2282000
loading required module 'kernel'
module 'kernel' exists but with wrong version
Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Table 'FACP' at 0xde3c1b98
Table 'APIC' at 0xde3c1ca8
APIC: Found table at 0xde3c1ca8
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 3: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 4: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 5: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 6: enabled
SMP: Added CPU 3 (AP)
MADT: Found CPU APIC ID 5 ACPI ID 7: enabled
SMP: Added CPU 5 (AP)
MADT: Found CPU APIC ID 7 ACPI ID 8: enabled
SMP: Added CPU 7 (AP)
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #385  r320324M/320326:1200035: Sun Jun 25 04:51:08 PDT 2017
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 
4.0.0)
WARNING: WITNESS option enabled, expect reduced performance.
Table 'FACP' at 0xde3c1b98
Table 'APIC' at 0xde3c1ca8
Table 'FPDT' at 0xde3c1d40
Table 'ASF!' at 0xde3c1d88
Table 'SLIC' at 0xde3c1e30
Table 'SSDT' at 0xde3c1fa8
Table 'SSDT' at 0xde3c24e8
Table 'MCFG' at 0xde3c2fc0
Table 'HPET' at 0xde3c3000
Table 'SSDT' at 0xde3c3038
Table 'SSDT' at 0xde3c33a8
Table 'MSDM' at 0xde3c6688
Table 'DMAR' at 0xde3c66e0
ACPI: No SRAT table found
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x120
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80d585a4
stack pointer   = 0x28:0x82290a30
frame pointer   = 0x28:0x82290a60
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 0 ()
[ thread pid 0 tid 0 ]
Stopped at  vm_map_lookup_entry+0x24:   cmpq%r15,0x20(%rbx)
db> bt
Tracing pid 0 tid 0 td 0x81e9e860
vm_map_lookup_entry() at vm_map_lookup_entry+0x24/frame 0x82290a60
vm_map_insert() at vm_map_insert+0x10b/frame 0x82290b00
kmem_init() at kmem_init+0x72/frame 0x82290b30
vm_mem_init() at vm_mem_init+0x46/frame 0x82290b50
mi_startup() at mi_startup+0x9c/frame 0x82290b70
btext() at btext+0x2c
db> 


(The laptop seems to have repeated the:

loading required module 'kernel'
module 'kernel' exists but with wrong version

sequence a few times, based on the video I got of it.)


The "saving grace" is that the panic happens before the file systems
are mounted :-}

Unloading the (r320324) kernel and loading the r320307 kernel
succeeds (at least enough to mount file systems).

Peace,
david
-- 
David H. Wolfskill

Re: r320307 -> r320324: kernel does not load

2017-06-25 Thread Boris Samorodov 
(cc: kib@)

Hi Kostik,

FYI: I've looked though last source changes and it looks like
your commit(s) may be related.

25.06.2017 13:54, Boris Samorodov пишет:
> Hi All,
> 
> I use self-built base packages for system updates. The jump from
> r320307 to r320324 leads to fatal trap 12 at the very beginning:
> https://goo.gl/Pgujga (sorry for the poor photo quality)
> 
> Revert to r320307, and the system boots fine.

-- 
WBR, bsam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r320307 -> r320324: kernel does not load

2017-06-25 Thread Boris Samorodov 
Hi All,

I use self-built base packages for system updates. The jump from
r320307 to r320324 leads to fatal trap 12 at the very beginning:
https://goo.gl/Pgujga (sorry for the poor photo quality)

Revert to r320307, and the system boots fine.

-- 
WBR, bsam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"