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
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
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 yo
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"
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 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_wrappe
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
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 w
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
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 t
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?
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?
--
+---+-
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 go
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
> 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,
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
> 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 reform
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 fil
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 -070
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
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
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
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
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
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. :-}
>
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-
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
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.
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
Both on laptop and build machine; fortunately for me, the latter has a
serial console, so:
__ _ _
| | | _ \ / | __ \
| |___ _ __ ___ ___ | |_) | (___ | | | |
| ___| '__/ _ \/ _ \| _ < \___ \| | | |
| | | | | __/ __/| |_) |__
(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 begi
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
_
32 matches
Mail list logo