On 2020-Dec-25, at 22:21, Mark Millard wrote:
>> On 2020-Dec-24, at 21:17, Mark Millard wrote:
>>
>> Hartmann, O. o.hartmann at walstatt.org wrote on
>> Thu Dec 24 21:34:56 UTC 2020 :
> . . .
Looks like I was over specific about where I did "git fetch"
from and so made some sequences
> On 2020-Dec-24, at 21:17, Mark Millard wrote:
>
> Hartmann, O. o.hartmann at walstatt.org wrote on
> Thu Dec 24 21:34:56 UTC 2020 :
. . .
I've done more exploring and so am more willing to be
explicit about commands now that I've tried some of this.
>> I can not find (easily) any hints
>>
Hartmann, O. o.hartmann at walstatt.org wrote on
Thu Dec 24 21:34:56 UTC 2020 :
> According to the status of the wiki refered to by
> https://wiki.freebsd.org/git,
> most of
> the transition from svn to git has been done.
> According to the recent logs reported at
>
> Author: delphij
> Date: Mon Aug 17 05:57:02 2020
> New Revision: 364292
> URL:
> https://svnweb.freebsd.org/changeset/base/364292
>
>
> Log:
> Don't explicitly specify c99 or gnu99 as the default is now gnu99.
>
> . . .
>
> Modified: head/lib/libc/tests/sys/Makefile
>
> Author: manu
> Date: Sat Aug 8 16:56:20 2020
> New Revision: 364053
> URL:
> https://svnweb.freebsd.org/changeset/base/364053
>
>
> Log:
> release: RPI3: Add the RPI2 DTB
>
> The RPI2 v1.2 is using the same SoC as the RPI3 so it can boot this image
> but needs the RPI2 dtb.
>
>
On 2020-Jul-25, at 13:59, Mark Millard wrote:
> On 2020-Jul-8, at 01:28, Stefan Eßer wrote:
>
>> Am 08.07.20 um 09:01 schrieb Mark Millard:
>>> The following is more informational than anything as far
>>> as I'm concerned. But there may be implications that I'm
>>> unaware of. (I sometimes
On 2020-Jul-8, at 01:28, Stefan Eßer wrote:
> Am 08.07.20 um 09:01 schrieb Mark Millard:
>> The following is more informational than anything as far
>> as I'm concerned. But there may be implications that I'm
>> unaware of. (I sometimes experiment with toolchain use
>> to see what the current
Michal Meloun mmel at FreeBSD.org wrote on
Sat Jul 25 06:32:24 UTC 2020 :
> Author: mmel
> Date: Sat Jul 25 06:32:23 2020
> New Revision: 363510
> URL:
> https://svnweb.freebsd.org/changeset/base/363510
>
>
> Log:
> Revert r363123.
> As Emanuel poited me the Linux processes these clock
On 2020-Jul-8, at 20:35, Yuri Pankov wrote:
> Mark Millard wrote:
>> This seems to have broken doing buildworld buildkernel and
>> other things using make:
>> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
>> comparison operator should be either == or !=
>> make[2]:
This seems to have broken doing buildworld buildkernel and
other things using make:
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator should be either == or !=
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator
On 2020-Jul-8, at 01:28, Stefan Eßer wrote:
> Am 08.07.20 um 09:01 schrieb Mark Millard:
>> The following is more informational than anything as far
>> as I'm concerned. But there may be implications that I'm
>> unaware of. (I sometimes experiment with toolchain use
>> to see what the current
The following is more informational than anything as far
as I'm concerned. But there may be implications that I'm
unaware of. (I sometimes experiment with toolchain use
to see what the current status is for such use.)
I attempted to build a system for 32-bit powerpc using clang
and binutils,
Beyond being a breaking change for existing /boot/blacklist.txt
files, there is the non-operation issue:
. . .
+ram_excludelist_type="ram_excludelist" # Required for the kernel to find
# the blacklist module
. . .
In other words, it is still using the term
Hans Petter Selasky hps at selasky.org wrote on
Sat Jun 20 13:27:13 UTC 2020 :
> On 2020-06-20 13:10, Rodney W. Grimes wrote:
> >> Author: imp
> >> Date: Sat Jun 20 04:19:17 2020
> >> New Revision: 362422
> >> URL:https://svnweb.freebsd.org/changeset/base/362422
> >>
> >> Log:
> >>Increase
[Yet another oddity.]
On 2020-Jun-11, at 21:05, Mark Millard wrote:
>
> There is another oddity in the code structure, in
> that if pt was ever NULL the code would misuse the
> NULL before the test for non-NULL is made:
>
>pt = moea_pvo_to_pte(pvo, -1);
> . . .
>
There is another oddity in the code structure, in
that if pt was ever NULL the code would misuse the
NULL before the test for non-NULL is made:
pt = moea_pvo_to_pte(pvo, -1);
. . .
old_pte = *pt;
/*
* If the PVO is in the page
[Just a better panic backtrace text copy.]
On 2020-Jun-11, at 20:29, Mark Millard wrote:
> On 2020-Jun-11, at 19:25, Justin Hibbits wrote:
>
>> On Thu, 11 Jun 2020 17:30:24 -0700
>> Mark Millard wrote:
>>
>>> On 2020-Jun-11, at 16:49, Mark Millard wrote:
>>>
On 2020-Jun-11, at 14:42,
On 2020-Jun-11, at 19:25, Justin Hibbits wrote:
> On Thu, 11 Jun 2020 17:30:24 -0700
> Mark Millard wrote:
>
>> On 2020-Jun-11, at 16:49, Mark Millard wrote:
>>
>>> On 2020-Jun-11, at 14:42, Justin Hibbits
>>> wrote:
>>>
>>> On Thu, 11 Jun 2020 14:36:37 -0700
>>> Mark Millard wrote:
On 2020-Jun-11, at 16:49, Mark Millard wrote:
> On 2020-Jun-11, at 14:42, Justin Hibbits wrote:
>
> On Thu, 11 Jun 2020 14:36:37 -0700
> Mark Millard wrote:
>
>> On 2020-Jun-11, at 13:55, Justin Hibbits
>> wrote:
>>
>>> On Wed, 10 Jun 2020 18:56:57 -0700
>>> Mark Millard wrote:
> . . .
>>
On 2020-Jun-11, at 14:42, Justin Hibbits wrote:
On Thu, 11 Jun 2020 14:36:37 -0700
Mark Millard wrote:
> On 2020-Jun-11, at 13:55, Justin Hibbits
> wrote:
>
>> On Wed, 10 Jun 2020 18:56:57 -0700
>> Mark Millard wrote:
. . .
>
>
>> That said, the attached patch effectively copies
>> what's
On 2020-Jun-11, at 14:41, Brandon Bergren wrote:
> An update from my end: I now have the ability to test dual processor G4 as
> well, now that mine is up and running.
Cool.
FYI:
Dual processors are not required for the
problem to happen: the stress based testing
showed the problem just as
On 2020-Jun-11, at 13:55, Justin Hibbits wrote:
> On Wed, 10 Jun 2020 18:56:57 -0700
> Mark Millard wrote:
>
>> On 2020-May-13, at 08:56, Justin Hibbits wrote:
>>
>>> Hi Mark,
>>
>> Hello Justin.
>
> Hi Mark,
Hello again, Justin.
>>
>>> On Wed, 13 May 2020 01:43:23 -0700
>>> Mark
On 2020-May-13, at 08:56, Justin Hibbits wrote:
> Hi Mark,
Hello Justin.
> On Wed, 13 May 2020 01:43:23 -0700
> Mark Millard wrote:
>
>> [I'm adding a reference to an old arm64/aarch64 bug that had
>> pages turning to zero, in case this 32-bit powerpc issue is
>> somewhat analogous.]
>>
Warner Losh imp at bsdimp.com wrote on
Thu Jun 4 02:47:14 UTC 2020 :
> On Wed, Jun 3, 2020, 6:28 PM Rodney W. Grimes
> wrote:
>
> > [ Charset UTF-8 unsupported, converting... ]
> > > Author: gonzo
> > > Date: Wed Jun 3 22:18:15 2020
> > > New Revision: 361775
> > > URL:
Justin Hibbits chmeeedalf at gmail.com wrote on
Thu May 28 02:41:06 UTC 2020 :
> On Thu, 28 May 2020 00:49:03 + (UTC)
> Brandon Bergren wrote:
>
> > Author: bdragon
> > Date: Thu May 28 00:49:02 2020
> > New Revision: 361568
> > URL: https://svnweb.freebsd.org/changeset/base/361568
> >
> >
[I'm adding a reference to an old arm64/aarch64 bug that had
pages turning to zero, in case this 32-bit powerpc issue is
somewhat analogous.]
On 2020-May-13, at 00:29, Mark Millard wrote:
> [stress alone is sufficient to have jemalloc asserts fail
> in stress, no need for a multi-socket G4
[stress alone is sufficient to have jemalloc asserts fail
in stress, no need for a multi-socket G4 either. No need
to involve nfsd, mountd, rpcbind or the like. This is not
a claim that I know all the problems to be the same, just
that a jemalloc reported failure in this simpler context
happens
[Yet another new kind of experiment. But this looks
like I can cause problems in fairly sort order on
demand now. Finally! And with that I've much better
evidence for kernel vs. user-space process for making
the zeroed memory appear in, for example, nfsd.]
I've managed to get:
:
[A new kind of experiment and partial results.]
Given the zero'ed memory page(s) that for some of
the example contexts include a page that should not
be changing after initialization in my context
(jemalloc global variables), I have attempted the
following for such examples:
A) Run gdb
B) Attach
[I caused nfsd to having things shifted in mmeory some to
see it it tracked content vs. page boundary for where the
zeros stop. Non-nfsd examples omitted.]
> . . .
>> nfsd hit an assert, failing ret == sz_size2index_compute(size)
>
> [Correction: That should have referenced
[More details for a sshd failure. The other
examples are omitted. The sshd failure also shows
a all-zeros-up-to-a-page-boundary issue, just for
a different address range.]
On 2020-May-7, at 12:06, Mark Millard wrote:
>
> [mountd failure example: also at sz_size2index_lookup assert
> for the
[mountd failure example: also at sz_size2index_lookup assert
for the same zero'd memory problem.]
> On 2020-May-7, at 00:46, Mark Millard wrote:
>
> [__je_sz_size2index_tab seems messed up in 2 of the
> asserting contexts: first 384 are zero in both. More
> before that is also messed up (all
[__je_sz_size2index_tab seems messed up in 2 of the
asserting contexts: first 384 are zero in both. More
before that is also messed up (all zero). I show the
details later below.]
On 2020-May-6, at 16:57, Mark Millard wrote:
> [This explores process crashes that happen during system
> shutdown,
[This explores process crashes that happen during system
shutdown, in a context not having MALLOC_PRODUCTION= .
So assert failures are reported as the stopping points.]
It looks like shutdown -p now, shutdown -r now, and the
like can lead some processes to assert during their exit
attempt,
[This report just shows an interesting rpcbind crash:
a pointer was filled with part of a string instead,
leading to a failed memory access attempt from the junk
address produced.]
Core was generated by `/usr/sbin/rpcbind'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0
[This report just shows some material for the
sendmail SIGSEGV's, based on truss output.]
I've returned to using the modern jemalloc because
it seems to show problems more, after having
caught the earlier reported dhclient example under
the older jemalloc context. (Again: jemalloc may
be exposing
This note just reports things from looking at 2
.core files (mountd and rpcbind) from the new
jemalloc context's failures. May be someone that
knows more can get something out of it. I've
not included any of the prior message history.
For mountd:
Core was generated by `/usr/sbin/mountd -r'.
[The bit argument ot bitmap_unset seems to be way
too large.]
On 2020-May-3, at 11:08, Mark Millard wrote:
> [At around 4AM local time dhcient got a signal 11,
> despite the jemalloc revert. The other exmaples
> have not happened.]
>
> On 2020-May-2, at 18:46, Mark Millard wrote:
>
>> [I'm
[At around 4AM local time dhcient got a signal 11,
despite the jemalloc revert. The other exmaples
have not happened.]
On 2020-May-2, at 18:46, Mark Millard wrote:
> [I'm only claiming the new jemalloc is involved and that
> reverting avoids the problem.]
>
> I've been reporting to some lists
On 2020-May-3, at 01:26, nonameless at ukr.net wrote:
> --- Original message ---
> From: "Mark Millard"
> Date: 3 May 2020, 04:47:14
>
>
>
>> [I'm only claiming the new jemalloc is involved and that
>> reverting avoids the problem.]
>>
>> I've been reporting to some lists problems with:
[I'm only claiming the new jemalloc is involved and that
reverting avoids the problem.]
I've been reporting to some lists problems with:
dhclient
sendmail
rpcbind
mountd
nfsd
getting SIGSEGV (signal 11) crashes and some core
dumps on the old 2-socket (1 core per socket) 32-bit
PowerMac G4
>From https://ci.freebsd.org/job/FreeBSD-head-powerpc-build/15810/console :
--- mmu_oea64.o ---
23:10:11 /usr/src/sys/powerpc/aim/mmu_oea64.c:933:7: error: format specifies
type 'uintmax_t' (aka 'unsigned long long') but the argument has type 'unsigned
int' [-Werror,-Wformat]
===
Mark Millard
> Author: cem
> Date: Sun Apr 12 18:04:20 2020
> New Revision: 359829
> URL:
> https://svnweb.freebsd.org/changeset/base/359829
>
>
> Log:
> Add queue(2) debug macros as build options
>
> Add QUEUE_MACRO_DEBUG_TRACE and QUEUE_MACRO_DEBUG_TRASH as proper kernel
> options. While here,
Gleb Smirnoff glebius at FreeBSD.org wrote on
Wed Mar 4 23:49:22 UTC 2020 :
> author: glebius
> Date: Wed Mar 4 23:49:20 2020
> New Revision: 358658
> URL:
> https://svnweb.freebsd.org/changeset/base/358658
>
>
> Log:
> Add a missing bktr header.
>
> Modified:
> head/ObsoleteFiles.inc
>
Konstantin Belousov kostikbel at gmail.com wrote on
Mon Mar 2 18:27:05 UTC 2020 ":
> On Mon, Mar 02, 2020 at 09:13:53AM -0800, Ryan Libby wrote:
> > On Mon, Mar 2, 2020 at 12:45 AM Alexander V. Chernikov > ipfw.ru> wrote:
> > >
> > > 28.02.2020, 18:32, "Ryan Libby" :
> > > > Author: rlibby
> > >
Warner Losh imp at FreeBSD.org wrote on
Sun Mar 1 20:37:45 UTC 2020 :
> +# 20200301: bktr removed
> +OLD_DIRS+=usr/include/dev/bktr
> +OLD_FILES+=usr/include/dev/bktr/ioctl_bktr.h
> +OLD_FILES+=usr/include/dev/bktr/ioctl_meteor.h
> +.if ${TARGET_ARCH} == "i386"
>
head -r358439 breaks unmodified ports that use, for example, clang70 and
clang++70:
https://lists.freebsd.org/pipermail/freebsd-emulation/2020-February/017672.html
https://lists.freebsd.org/pipermail/freebsd-emulation/2020-February/017675.html
show things like . . .
kBuild: Compiling
Pedro Giffuni pfg at FreeBSD.org wrote on
Sat Feb 29 15:42:34 UTC 2020 :
> On 29/02/2020 07:40, Ed Maste wrote:
> > Author: emaste
> > Date: Sat Feb 29 12:40:27 2020
> > New Revision: 358459
> > URL: https://svnweb.freebsd.org/changeset/base/358459
> >
> > Log:
> >Remove contrib/gcc and
> Author: emaste
> Date: Sat Feb 29 13:15:01 2020
> New Revision: 358462
> URL:
> https://svnweb.freebsd.org/changeset/base/358462
>
>
> Log:
> src.opts.mk: simplify Clang and lld bootstrap defaults
>
> With the retirement of GCC 4.2.1 we can assume the host compiler supports
> C++11,
In cleaning out my old gcc 4.2.1 related material I have patches in places
that have not been deleted:
M /usr/src/contrib/gcc/unwind-dw2.c
M /usr/src/contrib/gcc/unwind-dw2.h
Is /head/contrib/gcc deliberately being kept? (binutils
needing it for ld for 32-bit powerpc? System gdb
[Ignoring llvm-project and libstdc++, I only find
about 24 other instances of "static_assert".]
On 2020-Feb-27, at 19:03, Mark Millard wrote
> On 2020-Feb-27, at 16:37, John Baldwin wrote:
>
>> On 2/27/20 2:45 PM, Mark Millard wrote:
>>> John Baldwin jhb at FreeBSD.org wrote on
>>> Thu Feb 27
On 2020-Feb-27, at 16:37, John Baldwin wrote:
> On 2/27/20 2:45 PM, Mark Millard wrote:
>> John Baldwin jhb at FreeBSD.org wrote on
>> Thu Feb 27 16:55:01 UTC 2020:
>>
>>> On 2/27/20 7:30 AM, Warner Losh wrote:
Author: imp
Date: Thu Feb 27 15:30:13 2020
New Revision: 358392
John Baldwin jhb at FreeBSD.org wrote on
Thu Feb 27 16:55:01 UTC 2020:
> On 2/27/20 7:30 AM, Warner Losh wrote:
> > Author: imp
> > Date: Thu Feb 27 15:30:13 2020
> > New Revision: 358392
> > URL: https://svnweb.freebsd.org/changeset/base/358392
> >
> > Log:
> > _Static_assert is to be
[This is not an objection to the version upgrade.]
FYI: I happen to have updated to head -r358132 on multiple
environments, not having done anything to force rebuilds
of things tied to ncurses.
armv7 / 32-bit powerpc : poudriere options displays look normal.
aarch64 / powerpc64 / amd64: they
(Derived from O. Hartmann's report, despite his not
having the same source version, . . .)
In the code:
823 static struct filestat_list *
824 procstat_getfiles_sysctl(struct procstat *procstat, struct kinfo_proc
*kp,
825 int mmapped)
826 {
827 struct kinfo_file
Justin Hibbits chmeeedalf at gmail.com wrote on
Sun Jan 5 18:03:59 UTC 2020 :
> On Sun, 5 Jan 2020 12:21:53 -0500 Ed Maste wrote: >
> On Sun, 5 Jan 2020 at 11:59, Ed Maste wrote:
> > >
> > > Author: emaste
> > > Date: Sun Jan 5 16:59:24 2020
> > > New Revision: 356379
> > > URL:
> Author: jhb
> Date: Sat Jan 4 00:59:47 2020
> New Revision: 356344
> URL:
> https://svnweb.freebsd.org/changeset/base/356344
> . . .
> +MAKE_PARAMS_powerpc?=CROSS_TOOLCHAIN=powerpc64-gcc6
> . . .
> +TOOLCHAINS_powerpc= powerpc64-gcc6
> . . .
(I know that for now gcc9 is not in use
John Baldwin jhb at FreeBSD.org wrote on
Thu Jan 2 21:41:07 UTC 2020 :
> On 1/2/20 1:34 PM, John Baldwin wrote:
> > Author: jhb
> > Date: Thu Jan 2 21:34:44 2020
> > New Revision: 356289
> > URL: https://svnweb.freebsd.org/changeset/base/356289
> >
> > Log:
> > Look for cross toolchain
On 2019-Dec-24, at 21:26, Mark Millard wrote:
> In:
>
> +# Defines a variable for Binutils linker, to be used to workaround some
> +# issue with LLVM LLD (i.e. support for PowerPC32 bit on PowerPC64)
> +#
> +# This is an unavoidable cross coupling with Makefile.inc1 and
> +# normal builds
Ronald Klop ronald-lists at klop.ws wrote on
Fri Dec 27 09:39:22 UTC 2019 :
QUOTE
Do powerpc people need to do something special while updating?
Like a clean buildkernel/buildworld. Or is this just a note for historical
bookkeeping?
END QUOTE
See
In:
+# Defines a variable for Binutils linker, to be used to workaround some
+# issue with LLVM LLD (i.e. support for PowerPC32 bit on PowerPC64)
+#
+# This is an unavoidable cross coupling with Makefile.inc1 and
+# normal builds works when CROSS_BINUTILS_PREFIX and could be removed
+# when LLD
> Author: jeff
> Date: Mon Dec 16 20:15:04 2019
> New Revision: 355819
> URL:
> https://svnweb.freebsd.org/changeset/base/355819
>
>
> Log:
> Repeat the spinlock_enter/exit pattern from amd64 on other architectures to
> fix an assert violation introduced in r355784. Without this
Now it is clang builds that are broken, at least ones that use:
sys/compat/linuxkpi/common/include/linux/compiler.h
An example from:
https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/14953/console
is:
14:32:22 --- all_subdir_lindebugfs ---
14:32:22 In file included from
> Author: daichi
> Date: Fri Sep 20 17:37:23 2019
> New Revision: 352558
> URL:
> https://svnweb.freebsd.org/changeset/base/352558
>
>
> Log:
> top(1): support multibyte characters in command names (ARGV array)
> depending on locale.
>
>- add setlocale()
>- remove printable()
Warner Losh imp at bsdimp.com wrote on
Fri Aug 23 22:05:39 UTC 2019 :
> On Fri, Aug 23, 2019 at 12:26 PM Conrad Meyer wrote:
>
> > At expected peril of wading into a thread >4 emails deep,
> >
> > @Warner, modern GCC reports a similar warning; it just doesn't become
> > an error (at least in
> Author: dim
> Date: Tue Aug 20 17:39:32 2019
> New Revision: 351253
> URL:
> https://svnweb.freebsd.org/changeset/base/351253
>
>
> Log:
> Pull in r368867 from upstream libc++ trunk (by Marshall Clow):
>
> Rework recursive_timed_mutex so that it uses __thread_id instead of
>
[I did not deal with translating register usage correctly.]
> On 2019-Apr-27, at 01:50, Mark Millard wrote:
>
> Justin Hibbits jhibbits at FreeBSD.org wrote on
> Fri Apr 26 16:21:47 UTC 2019 :
>
>> This actually uses 'cmpb' which is only available on PowerISA 2.05+, so
>> I'll need to pull it
Justin Hibbits jhibbits at FreeBSD.org wrote on
Fri Apr 26 16:21:47 UTC 2019 :
> This actually uses 'cmpb' which is only available on PowerISA 2.05+, so
> I'll need to pull it out for now, and re-enable it once we have
> ifuncs. As it stands, this commit broke the G5 and POWER4/POWER5.
As I
Using if_igb.ko and if_em.ko as examples:
-r324406 (2017-Oct-7) used relative symbolic links (via a different technique)
[sbruno]
-r324500 (3 days later) used hard links (ian, with sbruno submitting)
-r346441 (2019-Apr-20) is back to relative symbolic links. (asomers)
Sbruno or Ian might want
Mateusz Guzik mjg at FreeBSD.org wrote on
Tue Nov 20 14:58:42 UTC 2018 :
> +#if defined(__mips__) || defined(__powerpc__)
> +#define UNR64_LOCKED
> +#endif
But on powerpc64 ( system clang from head -r339076 ):
# clang -dM -E -x c /dev/null | grep -i __power
#define __POWERPC__ 1
#define
Warner Losh imp at FreeBSD.org wrote on
Tue Nov 20 07:11:24 UTC 2018 :
> Instead, used fixed constants because there's no way to say ceil(X)
> for integer math. . . .
For a ratio of unsigned integers, with 0
// ceil_x_div_y(x,y), given 0https://lists.freebsd.org/mailman/listinfo/svn-src-head
To
[I note what I've failed to find a way to investigate.]
On 2018-Nov-7, at 11:53, Mark Millard wrote:
> [I trace code associated with bl <1322.plt_call.getenv>
> in the two contexts and extend the range over which things
> appear to match: up to some point after the branch
> b
John Baldwin jhb at FreeBSD.org wrote on
Wed Nov 7 21:36:02 UTC 2018 :
> On 11/7/18 1:01 PM, Ed Schouten wrote:
> > Op wo 7 nov. 2018 om 19:32 schreef John Baldwin :
> >> Modified: head/sys/kern/imgact_elf.c
> >> ==
> >>
[I trace code associated with bl <1322.plt_call.getenv>
in the two contexts and extend the range over which things
appear to match: up to some point after the branch
b <__glink_PLTresolve> .]
On 2018-Nov-6, at 19:12, Mark Millard wrote:
> [I've present a little information about the
[I've present a little information about the longer-existing
failure's odd backtrace for /libexec/ld-elf.so.1 /bin/ls
--but on powerpc64 FreeBSD instead of 32-bit powerpc FreeBSD.]
On 2018-Nov-2, at 11:50, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard
On 2018-Nov-3, at 12:51 PM, Konstantin Belousov wrote:
> On Sat, Nov 03, 2018 at 12:04:53PM -0700, Mark Millard wrote:
>> 80903 ld-elf.so.1 CALL
>> mmap(0x1,0xb000,0,0x6010,0x,0x1,0,0)
>> 80903 ld-elf.so.1 RET mmap -1 errno 12 Cannot allocate memory
>
> This is the
On 2018-Nov-3, at 12:04 PM, Mark Millard wrote:
> On 2018-Nov-3, at 8:49 AM, Konstantin Belousov wrote:
>
>> On Fri, Nov 02, 2018 at 05:51:25PM -0700, Mark Millard wrote:
>>> On 2018-Nov-2, at 11:50 AM, Konstantin Belousov
>>> wrote:
>>>
On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark
On 2018-Nov-3, at 8:49 AM, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 05:51:25PM -0700, Mark Millard wrote:
>> On 2018-Nov-2, at 11:50 AM, Konstantin Belousov
>> wrote:
>>
>>> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote:
. . .
>>>
>>> There seems to be an
On 2018-Nov-2, at 11:50 AM, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote:
>> . . .
>
> There seems to be an issue with the direct execution mode on ppc.
> Even otherwise working ld-elf.so.1 segfaults if I try to use it as
> standalone binary.
>
>
On 2018-Nov-2, at 8:52 AM, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 08:30:17AM -0700, Mark Millard wrote:
>> Breakpoint 4, reloc_non_plt (obj=0x41041000, obj_rtld=0x1801cc7, flags=4,
>> lockstate=0x0) at /usr/src/libexec/rtld-elf/powerpc/reloc.c:338
>> 338
On 2018-Nov-2, at 4:38 AM, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 12:16:23AM -0700, Mark Millard wrote:
>> It stops when the dcbst in __syncicache runs into an address in
>> the p_align 65536 caused hole between the two PT_LOAD's with PF_X.
>> /bin/ls itself has such a hole, as
[The backtrace confirms what I reported to Alexander Richardson
and Shawn Webb earlier.]
On 2018-Nov-1, at 6:40 PM, Mark Millard wrote:
> On 2018-Nov-1, at 5:41 PM, Konstantin Belousov wrote:
>
>> On Tue, Oct 30, 2018 at 12:45:13PM -0700, Mark Millard wrote:
>>> Konstantin Belousov kostikbel
On 2018-Nov-1, at 5:41 PM, Konstantin Belousov wrote:
> On Tue, Oct 30, 2018 at 12:45:13PM -0700, Mark Millard wrote:
>> Konstantin Belousov kostikbel at gmail.com wrote on
>> Tue Oct 30 18:04:04 UTC 2018 :
>>
>>> On Tue, Oct 30, 2018 at 03:32:40PM +, Alexander Richardson wrote:
On
On 2018-Oct-31, at 11:53 AM, Alexander Richardson
wrote:
> On Wed, 31 Oct 2018 at 18:38, Mark Millard
> wrote:
>>
>> On 2018-Oct-30, at 3:23 PM, Alexander Richardson > freebsd.org> wrote:
>>
>>> . . .
>>> Before this change obj->textsize was always set as the end of
>>> PT_LOAD[0]. Now it
On 2018-Oct-30, at 3:23 PM, Alexander Richardson
wrote:
> . . .
> Before this change obj->textsize was always set as the end of
> PT_LOAD[0]. Now it will contain everything up to the end of the last
> PT_LOAD with execute permissions. In the binary you dumped this is
> PT_LOAD[0] both before
On 2018-Oct-30, at 2:40 PM, Alexander Richardson
wrote:
> On Tue, 30 Oct 2018 at 21:32, Mark Millard
> wrote:
>>
>>
>>
>> On 2018-Oct-30, at 2:23 PM, Alexander Richardson > freebsd.org> wrote:
>>
>>> On Tue, 30 Oct 2018 at 18:19, Mark Millard
>>> wrote:
Alexander Richardson
On 2018-Oct-30, at 2:23 PM, Alexander Richardson
wrote:
> On Tue, 30 Oct 2018 at 18:19, Mark Millard
> wrote:
>>
>> Alexander Richardson arichardson at freebsd.org wrote on
>> Tue Oct 30 15:33:00 UTC 2018 :
>>
>>> On Tue, 30 Oct 2018 at 10:17, Michael Tuexen
>>> wrote:
> On
Konstantin Belousov kostikbel at gmail.com wrote on
Tue Oct 30 18:04:04 UTC 2018 :
> On Tue, Oct 30, 2018 at 03:32:40PM +, Alexander Richardson wrote:
> > On Tue, 30 Oct 2018 at 10:17, Michael Tuexen
> > wrote:
> > >
> > > > On 29. Oct 2018, at 22:08, Alex Richardson
> > > > wrote:
> > > >
Alexander Richardson arichardson at freebsd.org wrote on
Tue Oct 30 15:33:00 UTC 2018 :
> On Tue, 30 Oct 2018 at 10:17, Michael Tuexen
> wrote:
> >
> > > On 29. Oct 2018, at 22:08, Alex Richardson
> > > wrote:
> > >
> > > Author: arichardson
> > > Date: Mon Oct 29 21:08:02 2018
> > > New
[Similar to an old note about -r336099 .]
Both:
https://ci.freebsd.org/job/FreeBSD-head-amd64-build/10300/consoleText
https://ci.freebsd.org/job/FreeBSD-head-i386-build/9428/consoleText
show (from the amd64 example):
===> zlib (install)
install -N /usr/src/etc -T release -o root -g wheel -m
[I've got a historical WERROR= used in my amd64-gcc based builds.]
On 2018-Sep-20, at 6:05 PM, Mark Millard wrote:
> Li-Wen Hsu lwhsu at freebsd.org wrote on
> Thu Sep 20 22:10:19 UTC 2018 :
>
>> On Thu, Sep 20, 2018 at 10:06 PM Mark Johnston wrote:
>>>
>>> On Thu, Sep 20, 2018 at
Li-Wen Hsu lwhsu at freebsd.org wrote on
Thu Sep 20 22:10:19 UTC 2018 :
> On Thu, Sep 20, 2018 at 10:06 PM Mark Johnston wrote:
> >
> > On Thu, Sep 20, 2018 at 09:39:24AM -0700, John Baldwin wrote:
> > > On 9/20/18 8:54 AM, Mark Johnston wrote:
> > > > On Sun, Jul 15, 2018 at 12:23:11AM +,
John Baldwin jhb at FreeBSD.org wrote on
Thu Sep 20 16:39:27 UTC 2018 :
> On 9/20/18 8:54 AM, Mark Johnston wrote:
> > On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote:
> >> Author: mmacy
> >> Date: Sun Jul 15 00:23:10 2018
> >> New Revision: 336299
> >> URL:
Mark Johnston markj at freebsd.org wrote on
Thu Sep 20 15:54:08 UTC 2018 :
> On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote:
> > Author: mmacy
> > Date: Sun Jul 15 00:23:10 2018
> > New Revision: 336299
> > URL: https://svnweb.freebsd.org/changeset/base/336299
> >
> > Log:
> > msun:
[I was asked what the fix might be. So I suggest specifics.]
On 2018-Sep-16, at 10:06 AM, Mark Millard wrote:
> Looks like this head/ObsoleteFiles.inc update has a typo
> in each thing added to OLD_FILES . . .
>
> # ls -lTdt /usr/tests/usr.bin/indent/*
> -r--r--r-- 1 root wheel 121 Sep 13
Looks like this head/ObsoleteFiles.inc update has a typo
in each thing added to OLD_FILES . . .
# ls -lTdt /usr/tests/usr.bin/indent/*
-r--r--r-- 1 root wheel 121 Sep 13 22:53:30 2018
/usr/tests/usr.bin/indent/Kyuafile
. . .
-r--r--r-- 1 root wheel 295 Sep 13 22:53:29 2018
https://ci.freebsd.org/job/FreeBSD-head-riscv64-build/10428/consoleText
shows:
--- objcopy.full ---
cc -O2 -pipe -I/workspace/src/contrib/elftoolchain/libelftc
-I/workspace/src/contrib/elftoolchain/libpe
-I/workspace/src/contrib/elftoolchain/common -DWITH_PE=1 -I. -g -std=gnu99
I'm not sure if the following is intended or not.
I tried using
beastie_disable="YES"
loader_color="NO"
in boot/loader.conf on head -r338341 .
The default colors are still changed during:
(some characters are filtered out)
QUOTE
Setting currdev to disk2p2:
On 2018-Aug-31, at 9:40 AM, Glen Barber wrote:
> On Fri, Aug 31, 2018 at 09:34:00AM -0700, Mark Millard wrote:
>> On Fri, Aug 31, 2018 at 02:20:09PM +, Glen Barber wrote:
On Fri, Aug 31, 2018 at 08:51:29AM -0400, Ed Maste wrote:
> On 30 August 2018 at 22:46, Glen Barber wrote:
On Fri, Aug 31, 2018 at 02:20:09PM +, Glen Barber wrote:
> > On Fri, Aug 31, 2018 at 08:51:29AM -0400, Ed Maste wrote:
> > > On 30 August 2018 at 22:46, Glen Barber wrote:
> > > >
> > > > As I look closer at the log, I have a sneaking suspicion this may have
> > > > been a transient. I'm
1 - 100 of 166 matches
Mail list logo
