nce work that is going on where the caching was having
negative consequences when nullfs was also in use.)
kib's wording when I asked about the display-of-mode-status
issue was:
QUOTE
Mount uses getfsstat(2) which has no knowledge of nmount(2).
END QUOTE
===
Mark Millard
marklmi at yahoo.com
n
has been this way.
Is there a way for it to automatically use the likes of the
nfsd.ko from the same directory as the kernel in all cases,
where I pick the default kernel place via loader.conf ? Do
I need to do more manual steps in the loader, not just use
the menu selections to override the defaults for this
sufficiently to have the likes of the matching nfsd.ko load?
===
Mark Millard
marklmi at yahoo.com
e bulk
runs out of packages it can build, absent building boost-libs .
Side note:
As far as I can tell, how to identify a context that allows
identification of what commit vintage a PkgBase world is based on
is unspecified so far. For a PkgBase kernel uname -apKU may well
report the kernel-commit
via a USB3 adapter for U.2 . The UFS partition
was/is:
537405440 1337979528 da0p9 freebsd-ufs (638G)
===
Mark Millard
marklmi at yahoo.com
e
serial console. (But, thinking about it, I've not used that in some
time.)
===
Mark Millard
marklmi at yahoo.com
ne of the turbo settings, the
more modern RPI firmware is varying the speed of the clock in the early
boot time frame and FreeBSD is working in a way that requires more
uniformity for such. (May be delays based on just loop counting?)
===
Mark Millard
marklmi at yahoo.com
f08e41aa and was still broken at 75464941dc .
===
Mark Millard
marklmi at yahoo.com
On Apr 18, 2024, at 08:02, Mark Millard wrote:
> void wrote on
> Date: Thu, 18 Apr 2024 14:08:36 UTC :
>
>> Not sure where to post this..
>>
>> The last bulk build for arm64 appears to have happened around
>> mid-March on ampere2. Is it broken?
>
>
64/tmp/usr/lib/clang/17/lib/freebsd/libclang_rt.asan_static-aarch64.a
-r--r--r-- 1 root wheel - 998 Mar 2 19:39:47 2024
/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr/lib/clang/17/lib/freebsd/libclang_rt.fuzzer_interceptors-aarch64.a
===
Mark Millard
marklmi at yahoo.com
d from the same
build.)
Note, I noticed because of a message from an etcupdate run: I do not use the
file for anything.
===
Mark Millard
marklmi at yahoo.com
On Apr 19, 2024, at 07:16, Philip Paeps wrote:
> On 2024-04-18 23:02:30 (+0800), Mark Millard wrote:
>
>> void wrote on
>> Date: Thu, 18 Apr 2024 14:08:36 UTC :
>>
>>> Not sure where to post this..
>>>
>>> The last bulk build for arm64 appea
On Apr 26, 2024, at 18:55, Philip Paeps wrote:
> On 2024-04-18 23:02:30 (+0800), Mark Millard wrote:
>> void wrote on
>> Date: Thu, 18 Apr 2024 14:08:36 UTC :
>>
>>> Not sure where to post this..
>>>
>>> The last bulk build for arm64 appears
On Apr 28, 2024, at 18:06, Philip Paeps wrote:
> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote:
>> On Apr 18, 2024, at 08:02, Mark Millard wrote:
>>> void wrote on
>>> Date: Thu, 18 Apr 2024 14:08:36 UTC :
>>>
>>>> Not sure where to post
On Apr 29, 2024, at 19:54, Mark Millard wrote:
> On Apr 28, 2024, at 18:06, Philip Paeps wrote:
>
>> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote:
>>> On Apr 18, 2024, at 08:02, Mark Millard wrote:
>>>> void wrote on
>>>> Date: Thu, 18 Apr 2
On Apr 29, 2024, at 20:11, Mark Millard wrote:
> On Apr 29, 2024, at 19:54, Mark Millard wrote:
>
>> On Apr 28, 2024, at 18:06, Philip Paeps wrote:
>>
>>> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote:
>>>> On Apr 18, 2024, at 08:02, Ma
contexts.
I've no clue how to reduce this to a simple, repeatable context.
===
Mark Millard
marklmi at yahoo.com
On May 4, 2024, at 09:59, Mark Millard wrote:
> I recently did some of my rare "poudriere bulk -c -a" high-load-average
> style experiments, here on a 7950X3D (amd64) system and I ended up with
> a couple of stuck builders (one per bulk run of 2 runs). Contexts:
>
>
On Apr 29, 2024, at 20:16, Mark Millard wrote:
> On Apr 29, 2024, at 20:11, Mark Millard wrote:
>
>> On Apr 29, 2024, at 19:54, Mark Millard wrote:
>>
>>> On Apr 28, 2024, at 18:06, Philip Paeps wrote:
>>>
>>>> On 2024-04-18 23:14:22 (+0800
re that lead to 3481 ports not being built, including
graphics/graphviz . But the "bulk -a" completed and 24176 packages
built and were distributed.
graphics/graphviz having BROKEN_armv7 should generaelly build more
packages than that when graphics/giflib builds okay.
===
Mark Millard
marklmi at yahoo.com
12 urdlck IJ0 0:00.02 | | |
`-- /usr/local/bin/dot -c
0 91907 91496 5 68 0 15760 4492 nanslp S 0 1:05.17 | | |--
sh: poudriere[main-armv7-poud-default]: html_json_main (sh)
0 99134 91496 1 40 0 15760 4740 piperd I 0 0:03.22 | | `--
On Jul 16, 2024, at 10:42, Mark Millard wrote:
> No longer is the problem only observed on ampere2! But this was with
> a non-debug, personally built kernel that has some of my now patches.
> I'll see if I can replicate the issue with an official pkgbase debug
> kernel.
It re
5.0-CURRENT
main-n271137-d68d12481778 GENERIC arm64 aarch64 1500019 1500019
That is from: .snap20240711212638
The armv7 jail directory tree is from: .snap20240711211723
===
Mark Millard
marklmi at yahoo.com
On Jul 16, 2024, at 11:37, Mark Millard wrote:
> On Jul 16, 2024, at 10:42, Mark Millard wrote:
>
>> No longer is the problem only observed on ampere2! But this was with
>> a non-debug, personally built kernel that has some of my now patches.
>> I'll see if I ca
On Jul 16, 2024, at 18:41, Mark Millard wrote:
> On Jul 16, 2024, at 11:37, Mark Millard wrote:
>
>> On Jul 16, 2024, at 10:42, Mark Millard wrote:
>>
>>> No longer is the problem only observed on ampere2! But this was with
>>> a non-debug, personally
On Jul 16, 2024, at 23:45, Mark Millard wrote:
> On Jul 16, 2024, at 18:41, Mark Millard wrote:
>
>> On Jul 16, 2024, at 11:37, Mark Millard wrote:
>>
>>> On Jul 16, 2024, at 10:42, Mark Millard wrote:
>>>
>>>> No longer is the problem only o
On Jul 18, 2024, at 01:14, Mark Millard wrote:
> On Jul 16, 2024, at 23:45, Mark Millard wrote:
>
>> On Jul 16, 2024, at 18:41, Mark Millard wrote:
>>
>>> On Jul 16, 2024, at 11:37, Mark Millard wrote:
>>>
>>>> On Jul 16, 2024, at 10:42, M
On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
> [Everything and everybody in Cc: are stripped for good].
>
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>>
>> (g
On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
> [Everything and everybody in Cc: are stripped for good].
>
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>>
>> (g
On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
> [Everything and everybody in Cc: are stripped for good].
>
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>>
>> (g
On Jul 20, 2024, at 16:42, Mark Millard wrote:
> On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
>
>> [Everything and everybody in Cc: are stripped for good].
>>
>> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>>> 0x201375c0 - 0x201
[Correction to a rather misleading wording in
my description of the failure sequencing.]
On Jul 21, 2024, at 03:36, Mark Millard wrote:
> On Jul 20, 2024, at 16:42, Mark Millard wrote:
>
>> On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
>>
>>> [Everythi
.symtab entry problems.
Nor have I figured out why the installed materials are
different for Symbol table '.symtab' . So this is not
yet root-cause information.
===
Mark Millard
marklmi at yahoo.com
On Jul 21, 2024, at 20:58, Mark Millard wrote:
> I found a significant difference in my failing vs. working
> armv7 contexts as installed: Presence vs. Lack of a .symtab
> entry for the symbol _rtld_get_stack_prot in
> /libexec/ld-elf.so.1 .
>
> gdb inspection of operation
On Jul 21, 2024, at 21:08, Mark Millard wrote:
> On Jul 21, 2024, at 20:58, Mark Millard wrote:
>
>> I found a significant difference in my failing vs. working
>> armv7 contexts as installed: Presence vs. Lack of a .symtab
>> entry for the symbol _rtld_get_stack_prot in
s that
DEBUG_FLAGS was defined. That in turn likely means that strip is not
being used. In such a case, I expect that the .symtab entry for
_rtld_get_stack_prot (and more) exists for such a context.
===
Mark Millard
marklmi at yahoo.com
On Jul 22, 2024, at 06:40, Michal Meloun wrote:
> On 22.07.2024 13:46, Mark Millard wrote:
>> On Jul 21, 2024, at 22:59, Michal Meloun wrote:
>>> I don't want to hijack the original thread, so I'm replying in a new one.
>>>
>>> My tegra track cur
done on amd64 as well. ("Tegra" models and examples of
ARMv7-A and of ARMv8-A.)
For John Carr, I do not know if amd64 based builds of
the world were systematically in use, never in use,
or some mix in his tests.
===
Mark Millard
marklmi at yahoo.com
On Jul 22, 2024, at 09:41, meloun.mic...@gmail.com wrote:
> On 22.07.2024 18:26, Mark Millard wrote:
>> On Jul 22, 2024, at 06:40, Michal Meloun wrote:
>>> On 22.07.2024 13:46, Mark Millard wrote:
>>>> On Jul 21, 2024, at 22:59, Michal Meloun wrote:
>>>
On Jul 22, 2024, at 12:36, Michal Meloun wrote:
> On 22. 7. 2024 19:27, Mark Millard wrote:
>> On Jul 22, 2024, at 09:41, meloun.mic...@gmail.com wrote:
>>
>>
>>> On 22.07.2024 18:26, Mark Millard wrote:
>>>
>>>> On Jul 22, 2024, at 06:40, Mi
architecture-specific EABI symbols and
use it on arm for selected EABI functions. These functions can be called
with rtld bind lock write-locked, so they should be resolved in forward.
Reported by: Mark Millard , John F Carr
Reviewed by: kib, imp
MFC after: 1 week
Differential Revision: https
On Jul 25, 2024, at 09:48, Mark Millard wrote:
> Michal Meloun has committed a fix in main:
>
> See:
> https://lists.freebsd.org/archives/dev-commits-src-main/2024-July/025399.html
>
> that starts with:
>
> From: Michal Meloun
> Date: Thu, 25 Jul 2024 16:25:09
On Jul 26, 2024, at 07:56, Philip Paeps wrote:
> On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
>> So, it looks like updating the kernel and world on ampere2 and
>> enabling builds of main-armv7-default should no longer have
>> main-armv7-default hang-up during grap
On Jul 26, 2024, at 16:44, Warner Losh wrote:
> On Fri, Jul 26, 2024, 5:37 PM Mark Millard wrote:
>> On Jul 26, 2024, at 07:56, Philip Paeps wrote:
>>
>> > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
>> >> So, it looks like updating the kernel and
| grep -v "^l" | sed -E
's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort -ru
FreeBSD-.snap20240726112037
After exiting the chroot, the aarch64 environment did the unmount /mnt just
fine.
===
Mark Millard
marklmi at yahoo.com
On Jul 26, 2024, at 21:20, Mark Millard wrote:
> The original mount was:
>
> mount -onoatime 192.168.1.140:/ /mnt
>
> For reference:
> 192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
> (nfs, noatime)
>
> gdb reports:
>
>
On Jul 26, 2024, at 21:58, Mark Millard wrote:
> On Jul 26, 2024, at 21:20, Mark Millard wrote:
>
>> The original mount was:
>>
>> mount -onoatime 192.168.1.140:/ /mnt
>>
>> For reference:
>> 192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-c
-poud/usr/lib/include/machine/fiq.h
/usr/obj/DESTDIRs/main-CA7-poud/usr/share/man/man4/CAM.4.gz
===
Mark Millard
marklmi at yahoo.com
On Jul 27, 2024, at 16:07, Mark Millard wrote:
> The following old files were in the historically incrementally
> updated directory tree but not in the installation to an empty
> directory tree (checked via diff -rq):
>
> /usr/obj/DESTDIRs/main-CA7-poud/rescue/gbde
> /usr/obj
e done such on amd64
historically, not aarch64, other than possibly one prior
time. On amd64 the drive was internal PCI hardware and
no production of a VHDX file was required. On aarch64
with the USB based drive, direct use of the drive is
blocked, thus the use of a VHDX file produced from th
itx_metaslab_slog_alloc)!
pid 58 (zpool) is attempting to use unsafe AIO requests - not logging anymore
• [2:13 PM]Flox:
FreeBSD fbsd15.localdomain 15.0-CURRENT FreeBSD 15.0-CURRENT #0
main-aea9dba46b: Sat Aug 10 16:48:02 EDT 2024
mike@fbsd15.localdomain:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
===
Mark Millard
marklmi at yahoo.com
s a duplicate of 16431 and 16431's fix
has been committed to the openzfs master branch:
https://github.com/openzfs/zfs/commit/244ea5c4881f92a9d7c1fb341a49b127fda7539d
===
Mark Millard
marklmi at yahoo.com
/boot/efi/efi/BOOT/bootx64.efi
-rwxr-xr-x 1 root wheel 643K Aug 24 05:32 /boot/efi/efi/FREEBSD/loader.efi
If one is old, then it is probably the one actually being used.
(The name bootx64.efi is amd64 specific: other platforms use
other names.)
In such a case, you might need something like:
# cp -a /boot/loader.efi /boot/efi/efi/BOOT/bootx64.efi
===
Mark Millard
marklmi at yahoo.com
void wrote on
Date: Sat, 07 Sep 2024 13:19:24 UTC :
> hello again,
>
> On Fri, Sep 06, 2024 at 03:13:59PM -0700, Mark Millard wrote:
> >
> >What shows if you do the likes of (showing an amd64 context example):
> >
> ># ls -lah /boot/efi/efi/*/*
> >-r-xr-xr
void wrote on
Date: Sat, 07 Sep 2024 17:27:00 UTC :
> On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote:
>
> >I'm more interested in what is there than just what is not
> >there. May be show something analogous to:
> >
> ># gpart list | grep -E
FI is in use, then the ESP-ish partition is not from the guest
context but from some place else --unless the man pages are wildly
wrong about what is supported for the gpt*boot 's.
===
Mark Millard
marklmi at yahoo.com
xport XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# From based on clang (via system). . .
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.export CC
.export CXX
.export CPP
.endif
===
Mark Millard
mar...@dsl-only.net
_
On 2017-Oct-6, at 7:15 AM, Justin Hibbits wrote:
> Hi Mark,
>
> On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote:
>> Warner Losh imp at bsdimp.com wrote on
>> Thu Oct 5 21:01:26 UTC 2017 :
>>
>>> Starting in FreeBSD 11, arm and powerpc are supported b
ing lib32.
(This may well be better than clang's status overall.)
B) For targeting powerpc (32-bit): what toolchain?
===
Mark Millard
markmi at dsl-only.net
___
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"
28334599 Jul 2 23:44 ranlib
-r-xr-xr-x 2 root wheel 28334592 Jul 2 23:44 ar
-r-xr-xr-x 2 root wheel 49540244 Jul 2 23:44 objdump
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mail
[I'm adding examples with output from clang -v since it explicitly shows
the path used for ld and such.]
On 2017-Oct-7, at 12:58 AM, Mark Millard wrote:
> On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote:
>
>> Just to clarify my not agreeing with Mark regarding EH on ppc64.
&
ion I reached back then anyway. I give evidence
in the below.]
On 2017-Oct-7, at 1:10 AM, Mark Millard wrote:
> [I'm adding examples with output from clang -v since it explicitly shows
> the path used for ld and such.]
>
> On 2017-Oct-7, at 12:58 AM, Mark Millard wrote:
>
>
g ago. Correcting it
again. . .]
On 2017-Oct-7, at 2:18 AM, Mark Millard wrote:
> [I'm separately listing backtrace information and related
> information from one of core dumps and going back through
> the details to see if they seem to be as they were back
> then. Read only if you
with this long ago. Correcting it
again. . .]
On 2017-Oct-7, at 2:18 AM, Mark Millard wrote:
> [I'm separately listing backtrace information and related
> information from one of core dumps and going back through
> the details to see if they seem to be as they were back
> then. Rea
On 2017-Oct-7, at 3:21 AM, Roman Divacky wrote:
> Answers inline.
>
> On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote:
>> Just a short top-post as this does not fit well with the
>> other material:
>>
>> I believe Roman only built his example pro
() at
/usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104
Current language: auto; currently minimal
===
Mark Millard
markmi at dsl-only.net
___
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"
is not.
Is libgcc_s ready to deal with those extras that are
in the 90s? Is this an ABI difference between clang
(as configured) and powerpc64-gcc (as configured)?
Is there a problem based on powerpc64-gcc not generating
examples of those 90s "extras"? Is this lack of support
for some part of some ABI?
===
Mark Millard
markmi at dsl-only.net
___
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"
[I should have checked for 3 digit numerals in r notation.]
On 2017-Oct-7, at 11:36 PM, Mark Millard wrote:
> With a fresh day after sleep and some pondering
> I finally am thinking straight for where things
> are in files for C++ scratch register usage and
> such:
>
> It is
++/eh_personality.cc:PERSONALITY_FUNCTION
(int version,
. . .
So it looks like the implementation of __gxx_personality_v0
is supposed to be in one of:
libcxxrt.so.* for clang and modern gcc based buildworld's
libsuppc++.so.* for gcc 4.2.1 based buildworld's
===
Mark Millard
markmi at ds
eom fix to the earlier -r325227: -r325227 was
causing various folks problems.
-r325272 or later may avoid your problem.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listi
7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a
/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a
===
Mark Millard
markmi at dsl-only.net
___
freebsd-curre
_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/librtld_db/rtld_db.pico
. . .
And so on.
===
Mark Millard
markmi at dsl-only.net
On 2017-Nov-2, at 5:30 PM, Bryan Drewery wrote:
On 11/2/17 3:44 PM, Mark Millard wrote:
>> Author: bdrewery
>> Date: Thu No
On 2017-Nov-2, at 8:08 PM, Bryan Drewery wrote:
> On 11/2/2017 7:47 PM, Mark Millard wrote:
>> [Top post as it does not flow with the prior material.]
>>
>> Back-to-back repeats of the same buildworld buildkernel
>> command are rebuilding lots of obj-lib32 *.o file
[The rebuilding is not your problem. . . Its a
file system time problem.]
On 2017-Nov-2, at 8:16 PM, Mark Millard wrote:
> On 2017-Nov-2, at 8:08 PM, Bryan Drewery wrote:
>
>> On 11/2/2017 7:47 PM, Mark Millard wrote:
>>> [Top post as it does not flow with the prior mat
ions of
the attempts? Could running such a test be automatic
(part of something that is run systematically) and
fast enough to not want to skip it? (Just being
illustrative. The details involved are well outside
my background knowledge. There may be nothing
easy or reasonable.)
===
Mark Mill
NG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITHOUT_LLD_IS_LD=
WITH_LLVM_LIBUNWIND=
WITH_LLDB=
#PORTS_MODULES=emulators/virtualbox-ose-additions
#
WITH_BOOT=
WITH_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_RE
On 2017-Nov-3, at 11:31 AM, Bryan Drewery wrote:
> On 11/3/17 1:52 AM, Mark Millard wrote:
>> I did get another problem after buildworld, buildkernel, installkernel
>> without future source code dates: the installworld got a "cc not found"
>> for the amd64 native
/src/lib/libc/posix1e
/usr/src/lib/libc/regex /usr/src/lib/libc/resolv /usr/src/lib/libc/stdio
/usr/src/lib/libc/stdlib /usr/src/lib/libc/stdlib/jemalloc
/usr/src/lib/libc/stdtime /usr/src/contrib/tzcode/stdtime
/usr/src/lib/libc/aarch64/string /usr/src/lib/libc/string /usr/src/sys/libkern
[Forcing use of /usr/local/aarch64-freebsd/bin/ld
and other aarch64-binutils-2.28,1 material for the
aarch64 links: that fails too, but with messages
that are more informative (but might be
independent): "R_AARCH64_ABS64 used with TLS
symbol".]
> On 2017-Nov-3, at 9:24 PM, Mark M
h the build --all
the way to completion.
For ld.lld, use of WITHOUT_DEBUG_FILES=
still failed the same way as the original
use of WITH_DEBUG_FILES= .
Prior notes:
> On 2017-Nov-3, at 10:36 PM, Mark Millard wrote:
>
> [Forcing use of /usr/local/aarch64-freebsd/bin/ld
> and other aarch6
uot;cannot open output file " + Config->OutputFile + ": " + E.message());
And the error call is then made once
tryCreateFile returns.
===
Mark Millard
markmi at dsl-only.net
___
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"
laris/uts/common/fs/zfs
[breaks lld on zfs: lld uses fallocate]
See, for example,
https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-November/003413.html
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
On 2017-Nov-4, at 5:04 AM, Andriy Gapon wrote:
> On 04/11/2017 13:41, Andriy Gapon wrote:
>> On 04/11/2017 12:32, Mark Millard wrote:
>>> if (int Err = ::posix_fallocate(FD, 0, Size)) {
>>>if (Err != EOPNOTSUPP)
>>> return std::e
On 2017-Nov-4, at 4:58 AM, Ed Maste wrote:
> On 4 November 2017 at 07:41, Andriy Gapon wrote:
>> On 04/11/2017 12:32, Mark Millard wrote:
>>> if (int Err = ::posix_fallocate(FD, 0, Size)) {
>>>if (Err != EOPNOTSUPP)
>>> return std::e
On 2017-Nov-4, at 10:02 AM, Mark Millard wrote:
> On 2017-Nov-4, at 4:58 AM, Ed Maste wrote:
>
>> On 4 November 2017 at 07:41, Andriy Gapon wrote:
>>> On 04/11/2017 12:32, Mark Millard wrote:
>>>> if (int Err = ::posix_fallocate(FD, 0, Size)) {
>>>
[The patch allowed the amd64 -> aarch64 cross-buildworld
to complete instead of failing in lld.]
On 2017-Nov-4, at 10:13 AM, Mark Millard wrote:
> On 2017-Nov-4, at 10:02 AM, Mark Millard wrote:
>
>
>> On 2017-Nov-4, at 4:58 AM, Ed Maste wrote:
>>
>>> On
On 2017-Nov-4, at 4:58 AM, Ed Maste wrote:
> On 4 November 2017 at 07:41, Andriy Gapon wrote:
>> On 04/11/2017 12:32, Mark Millard wrote:
>>> if (int Err = ::posix_fallocate(FD, 0, Size)) {
>>>if (Err != EOPNOTSUPP)
>>> return std::e
rns EINVAL to
> indicate that the operation is not supported. (I think this is a strange
> choice of errno on the part of POSIX.)
>
> PR: 223383, 223440
> Reported by: Mark Millard
> Sponsored by: The FreeBSD Foundation
>
> Changes:
> _U stable/11/
>
efix used
if specified in the env list before mergemaster.)
===
Mark Millard
markmi at dsl-only.net
___
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 2017-Nov-10, at 5:16 PM, Bryan Drewery wrote:
> On 11/10/2017 8:30 AM, Bryan Drewery wrote:
>> On 11/10/17 7:52 AM, Bryan Drewery wrote:
>>> On 11/10/2017 12:46 AM, Mark Millard wrote:
>>>> When I use the command:
>>>>
>>>> ~/sys_bu
===
Mark Millard
mar...@dsl-only.net
On 2017-Nov-11, at 12:51 AM, Mark Millard wrote:
> On 2017-Nov-10, at 5:16 PM, Bryan Drewery wrote:
>
>> On 11/10/2017 8:30 AM, Bryan Drewery wrote:
>>> On 11/10/17 7:52 AM, Bryan Drewery wrote:
>>>> On 11/10/2017 12:46 A
On 2017-Nov-11, at 8:47 AM, Bryan Drewery wrote:
>> On Nov 11, 2017, at 00:51, Mark Millard wrote:
>>
>>> On 2017-Nov-10, at 5:16 PM, Bryan Drewery wrote:
>>>
>>>> On 11/10/2017 8:30 AM, Bryan Drewery wrote:
>>>> . . .
>>>&g
===
Mark Millard
mar...@dsl-only.net
On 2017-Nov-16, at 9:13 AM, Bryan Drewery wrote:
>> . . .
>
> Can you test this patch please in context of this problem please?
> It resolves read-only objdirs and should avoid more of the objdir
> creations at mergemaster/installworld
sd.org/base/head/include/
and in (see: line 25 ):
https://svnweb.freebsd.org/base/head/include/Makefile?revision=320844&view=markup
My guess is something is odd with your environment.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-curre
On 2017-Nov-17, at 10:37 PM, Yuri wrote:
> On 11/16/17 22:29, Mark Millard wrote:
>> My guess is something is odd with your environment.
>
>
> It's not my environment, I keep getting these failure notifications from the
> central build. -)
>
>
> Id
buildworld buildkernel had completed fine.
Until yesterday, I'd been running -r325700 or before and had not
seen such an issue ever before. I'd been using the virtualbox
version for a while before this as well.
===
Mark Millard
markmi at dsl-only.net
__
[I got another of these. By the way: amd64 context.
Again: buildworld was running.]
On 2017-Nov-19, at 5:52 PM, Mark Millard wrote:
> Attempting a dump failed. I'm afraid all for
> information is the below. The kernel was a
> non-debug kernel (with debug information).
>
> T
[Adding some analysis of where the 2 failures were in
source code terms.]
On 2017-Nov-19, at 9:07 PM, Mark Millard wrote:
> [I got another of these. By the way: amd64 context.
> Again: buildworld was running.]
>
> On 2017-Nov-19, at 5:52 PM, Mark Millard wrote:
>
>> Att
/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/powerpc.powerpc'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sy
T r325997M amd64 amd64
1200054 1200054
# more /etc/make.conf
WANT_QT_VERBOSE_CONFIGURE=1
#
DEFAULT_VERSIONS+=perl5=5.24 gcc=7
WRKDIRPREFIX?=/wrkdirs
#
# From a local /usr/ports/Mk/bsd.port.mk extension:
ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=
#
.if ${.CURDIR:M*/devel/llvm*}
#WITH_DEBUG=
.elif ${.CU
s not now updating?
===
Mark Millard
markmi at dsl-only.net
___
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"
701 - 800 of 1389 matches
Mail list logo
