TILS_BOOTSTRAP=
WITH_ELFTOOLCHAIN_BOOTSTRAP=
#WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
WITH_LLD_IS_LD=
WITHOUT_BINUTILS=
WITH_LLVM_LIBUNWIND=
WITH_LLDB=
#PORTS_MODULES=emulators/virtualbox-ose-additions-nox11
#PORTS_MODULES=emulators/virtualbox
ed that my long-in-use amd64 virtual-box context that I run and
update FreeBSD in (under macOS) just automatically updated sufficiently via
installkernel and installworld after building. (This assumes that all the
changes are in the freebsd-ufs partition involved and that the freebsd-boot
partition i
On 2018-Aug-26, at 12:35 PM, Dag-Erling Smørgrav wrote:
> Mark Millard writes:
>> But when I look at [...] the installed build(7) for head -r338319 I do
>> not find any references to LOADER_DEFAULT_INTERP .
>
> It was added to build(7) in r338043:
Thanks for the notes.
] #8 0x80fc0e5e at
> amd64_syscall+0x29e
> Sep 3 13:13:13 hbsd-dev-laptop kernel: [619] #9 0x80f9dc9d at
> fast_syscall_common+0x101
See:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231116
for "Out of bounds memory access in bli
00:57:43 pine64 kernel: pid 44248 (exhaust_test), uid 0: exited on
signal 11 (core dumped)
I'm not sure that they all would be expected.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@
[Adding listing broken tests, but ignoring sys/cddl/zfs/ ones.
lib/libc/string/memcmp_test:diff is one of them.]
On 2018-Sep-11, at 2:44 AM, Mark Millard wrote:
> [No zfs use, just a UFS e.MMC filesystem on a microsd adapter.]
>
> I got 14 failures. I've not enabled any
[After the run top -CawSopid shows something interesting/odd:
lots of g_eli[?] and md?? processes are still around in
geli:w state for g_eli[?] and mdwait for md??. Also there
are 4 processes in aiordy state.]
On 2018-Sep-11, at 8:48 AM, Mark Millard wrote:
> [Adding listing broken tests,
4/sys/GENERIC-NODBG
arm64 aarch64 1200084 1200084
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
On 2018-Sep-16, at 2:25 AM, Piotr P. Stefaniak wrote:
> On 2018-09-11 02:44:49, Mark Millard wrote:
>> usr.bin/indent/functional_test:nsac -> failed: atf-check failed; see the
>> output of the test for details [0.151s]
>> usr.bin/indent/functional_test:sac ->
On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker wrote:
> On Tue, Sep 11, 2018 at 08:48:03AM -0700, Mark Millard wrote:
>> [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones.
>> lib/libc/string/memcmp_test:diff is one of them.]
>
>> ===> Brok
On 2018-Sep-16, at 1:50 PM, Jilles Tjoelker wrote:
> On Sun, Sep 16, 2018 at 01:21:33PM -0700, Mark Millard wrote:
>> On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker wrote:
>
>>> On another note, the comment just below that,
>
>>> /* But we need to z
libibverbs.so.1
OLD_LIBS+=usr/lib/libmlx5.so.1
OLD_LIBS+=usr/lib/libibverbs.so.1
END QUOTE
This was after having the nsac and sac kyua tests report
failures in my environment, long after they should have
not existed.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar
On 2018-Sep-19, at 9:14 AM, Sean Bruno wrote:
> On 9/18/18 8:48 PM, Mark Millard wrote:
>> A problem here is that the references should be to usr.bin instead
>> of usr/bin . See:
>>
>> https://lists.freebsd.org/pipermail/svn-src-head/2018-September/118426.html
&
NTXSEG + 1];
^
1 error generated.
*** [if_fxp.o] Error code 1
It does look odd to me.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.or
using what
is built?
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "
a53+crypto
ACFLAGS.aesv8-armx.S+= -mcpu=cortex-a53+crypto
ACFLAGS.ghashv8-armx.S+=-mcpu=cortex-a53+crypto
# more ~/src.configs/make.conf
CFLAGS.gcc+= -v
LDFLAGS.lld+= -Wl,--no-threads
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
LVAGE? [yn] y
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-c
.0-ALPHA8 #4 r339076M: Mon Oct 15
13:19:35 PDT 2018
markmi@FBSDG5L:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG
powerpc powerpc64 1200084 1200084
ports was at -r480180.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away i
[I got another data storage interrupt failure, again
during kyaua showing:
sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 ->
but the backtrace looks different. See below.]
On 2018-Oct-17, at 4:58 PM, Mark Millard wrote:
> On a powerpc64 with builworld buildkernel built via
> devel/
[Booting a debug kernel reported a lock order
reversal that might be relevant. The problem
repeated again: seems to always fail in my
context. The backtrace is like the prior
one, but for the debug kernel build being used
this time.]
On 2018-Oct-17, at 6:29 PM, Mark Millard wrote:
> [I
e in this odd context expected/reasonable?
Should I ignore it?
(I have no reason to normally run such a odd mix of vintages
of world vs. kernel materials. I'm just checking if the
crashing is somehow specific to my builds or not.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away
On 2018-Oct-18, at 12:12 PM, Mark Millard wrote:
> As part of helping to track down a powerpc64 system
> crash when "kyua test -k /usr/tests/Kyuafile" is run
> I substituted into a -r339076 context official kernel
> materials from:
>
> https://download.freeb
88810 would be unlikely
contributors.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any m
On 2018-Oct-20, at 1:39 AM, Mark Millard wrote:
> I attempted to jump from head -r334014 to -r339076
> on a threadripper 1950X board and the boot fails.
> This is both native booting and under Hyper-V,
> same machine and root file system in both cases.
I did my investigation u
e board is a GIGABYTE X399 AORUS Gaming 7 (rev 1.0).
It has 96 GiBytes of ECC RAM, just 6 DIMMs installed.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.f
[Adding some vintage information for a loader
that allowed a native boot.]
On 2018-Oct-20, at 4:00 AM, Mark Millard wrote:
> I attempted to jump from head -r334014 to -r339076
> on a threadripper 1950X board and the native
> FreeBSD boot failed very early. (Hyper-V use of
> the sa
[I found what change lead to the 1950X boot crashing
with BTX halted.]
On 2018-Oct-20, at 12:44 PM, Mark Millard wrote:
> [Adding some vintage information for a loader
> that allowed a native boot.]
>
> On 2018-Oct-20, at 4:00 AM, Mark Millard wrote:
>
>> I attemp
On 2018-Oct-20, at 10:32 PM, Warner Losh wrote:
> On Sat, Oct 20, 2018 at 11:04 PM Mark Millard wrote:
> [I found what change lead to the 1950X boot crashing
> with BTX halted.]
>
>> On 2018-Oct-20, at 12:44 PM, Mark Millard wrote:
>>
>> > [Adding some
[Building and installing based on WITHOUT_ZFS= allows the
resulting loader to work correctly on the 1950X.]
On 2018-Oct-21, at 12:05 AM, Mark Millard wrote:
> On 2018-Oct-20, at 10:32 PM, Warner Losh wrote:
>
>> On Sat, Oct 20, 2018 at 11:04 PM Mark Millard wrote:
>> [I
[I built based on WITHOUT_ZFS= for other reasons. But,
after installing the build, Hyper-V based boots are
working.]
On 2018-Oct-20, at 2:09 AM, Mark Millard wrote:
> On 2018-Oct-20, at 1:39 AM, Mark Millard wrote:
>
>> I attempted to jump from head -r334014 to -r339076
>>
On 2018-Oct-21, at 8:30 PM, Warner Losh wrote:
> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote:
>
> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable
> wrote:
>> [I built based on WITHOUT_ZFS= for other reasons. But,
>> after installing the build,
On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote:
>
>> On 22 Oct 2018, at 06:30, Warner Losh wrote:
>>
>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote:
>>
>>>
>>>
>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable
On 2018-Oct-22, at 4:07 AM, Toomas Soome wrote:
> On 22 Oct 2018, at 13:58, Mark Millard wrote:
>>
>> On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote:
>>>
>>>> On 22 Oct 2018, at 06:30, Warner Losh wrote:
>>>>
>>
[I will note the the loader problem has been shown to
not be involved in the kernel problem that this
"Subject:" was originally for.]
On 2018-Oct-22, at 9:26 AM, Warner Losh wrote:
> On Mon, Oct 22, 2018 at 6:39 AM Mark Millard wrote:
>> On 2018-Oct-22, at 4:07 AM,
[I' unable to reproduce the under-Hyper-V early kernel
crash for WITH_ZFS= (implicit) build that includes the
for-loaders patch I was given to try.]
On 2018-Oct-22, at 10:01 AM, Mark Millard wrote:
> [I will note the the loader problem has been shown to
> not be involved in the ker
nknown-freebsd13.0
.endif
.endif
LIB32CPUFLAGS+= -mabi=32
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To uns
user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To
[Fixing dumb, confusing subject typo. No change below.]
On 2018-Nov-17, at 12:54, Mark Millard wrote:
> For some reason there is no .dev.cpu.31 listed for the 1950X that
> I use. This is a native boot, not use under Hyper-V. For
> illustration I list:
>
> # sysctl dev.c
ed
amount" figure, different by very roughly a factor of 2 if I remember
right, neither near what the documentation suggests. Suggesting a
fixed ratio to RAM-size just seems to be wrong.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_
/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/usr/bin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/legacy/usr/sbin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/legacy/usr/bin:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/legacy/bin::/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/u
On 2018-Dec-11, at 17:27, Mark Millard wrote:
> [This was after amd64 updating to -r341836 successfully ( from -r341766 ).
> The below was a meta-mode cross build, also going from -r341766 to
> -r341836 .]
>
> #
> ~/sys_build_scripts.amd64-host/make_armv7_nodebug_cla
.0-CURRENT #5 r341836M: Tue Dec 11
16:37:42 PST 2018
markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG
amd64 amd64 135 135
# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repos
[Looks like a race or some such for devel/qt5-testlib: retry of poudreire-devel
did not hang. The other hang-up seems to be repeating and I give some details.]
On 2018-Dec-19, at 12:20, Mark Millard wrote:
> FYI: Based on FreeBSD head -r341836 (host and target) and ports -r484783 .
>
[I attached to the hung-up process with gdb and looked around a little.]
On 2018-Dec-19, at 13:58, Mark Millard wrote:
> [Looks like a race or some such for devel/qt5-testlib: retry of
> poudreire-devel
> did not hang. The other hang-up seems to be repeating and I give some
[A amd64->armv7 cross build shows interesting hang-up behavior as
well, apparently highly repeatable for my current context.]
On 2018-Dec-19, at 16:21, Mark Millard wrote:
> [I attached to the hung-up process with gdb and looked around a little.]
>
> On 2018-Dec-19, at 13:58,
-up at the same point.
Building anything that requires multimedia/gstreamer1-qt@qt5 seems to be
solidly blocked in my environment.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailin
lready, building just
multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same point.
Building anything that requires multimedia/gstreamer1-qt@qt5 seems to be
solidly blocked in my environment.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 20
[I found my E-mail records reporting successful builds using
qemu-user-static from ports head -r484783 under FreeBSD
head -r340287.]
On 2018-Dec-22, at 00:10, Mark Millard wrote:
> [I messed up the freebsd-emulation email address the first time I sent
> this. I also forgot to indicate th
[I built a FreeBSD head -r340288 context and tried ports head
-r484783 and the problem repeated.]
On 2018-Dec-22, at 12:55, Mark Millard wrote:
> [I found my E-mail records reporting successful builds using
> qemu-user-static from ports head -r484783 under FreeBSD
> head -r340287.]
>
hcp 1 20012M 484K select 1 0:00 0.00%
dhclient: awg0 (dhclient)
(Basically the Pine64+ 2GB [aarch64] above was idle after boot other than
some runs of top.)
I see this oddity across architectures, for example amd64, powerpc64,
aarch64, armv7.
===
Mark Millard
marklmi
[A native poudreire-devel based build of
multimedia/gstreamer1-qt@qt5 did not hang-up
and worked fine. Official package build history
also provides some evidence.]
On 2018-Dec-22, at 12:55, Mark Millard wrote:
> [I found my E-mail records reporting successful builds using
> qemu-user-
On 2018-Dec-24, at 13:49, Yuri Pankov wrote:
> Mark Millard wrote:
>> From my from=source head -r3418363 context, top with -opid does not
>> seem to sort in a coherent order, not time of process creation order
>> (either direction) and not in just-PID numeric order (eith
() from /lib/libc.so.7
(gdb) bt
#0 0xf4e5e0dc in _ppoll () from /lib/libc.so.7
#1 0x00033bf0 in SubprocessSet::DoWork (this=) at
src/subprocess-posix.cc:237
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in e
en when using
head. (The kernel does have symbols.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscrib
[Using ktrace/kdump shows an apperent oddity in the kevent use that
hang-up in cmake, not that I know it causes the hang-up.]
On 2018-Dec-28, at 00:16, Mark Millard wrote:
> [The historical notes are removed and replaced by partial trace
> information from example hang-ups, not tha
On 2018-Dec-28, at 12:12, Mark Millard wrote:
> On 2018-Dec-28, at 05:13, Michal Meloun wrote:
>
>> Mark,
>> this is known problem with qemu-user-static.
>> Emulation of every single interruptible syscall is broken by design (it
>> have signal related races).
On 2018-Dec-28, at 12:12, Mark Millard wrote:
> On 2018-Dec-28, at 05:13, Michal Meloun wrote:
>
>> Mark,
>> this is known problem with qemu-user-static.
>> Emulation of every single interruptible syscall is broken by design (it
>> have signal related races).
[Removing __packed did make the size and offsets match armv7
and the build worked based on the reconstructed qemu-arm-static.]
On 2018-Dec-30, at 16:38, Mark Millard wrote:
> On 2018-Dec-28, at 12:12, Mark Millard wrote:
>
>> On 2018-Dec-28, at 05:13, Michal Meloun wrote:
On 2018-Dec-30, at 21:01, Jonathan Chen wrote:
> On Mon, 31 Dec 2018 at 14:34, Mark Millard via freebsd-ports
> wrote:
>>
>> [Removing __packed did make the size and offsets match armv7
>> and the build worked based on the reconstructed qemu-arm-static.]
>
> Than
On 2018-Dec-31, at 10:16, Jonathan Chen wrote:
> On Mon, 31 Dec 2018 at 21:05, Mark Millard wrote:
> [...]
>> But if you have a form of hang-up that shows no sign of being tied
>> to kevent or hangs-up only sometimes, I'd be surprised if the __packed
>> change(s) w
[I listed my /usr/src svn veriosn information instead of /usr/ports .
Correcting. . .]
On 2018-Dec-31, at 12:05, Mark Millard wrote:
> On 2018-Dec-31, at 10:16, Jonathan Chen wrote:
>
>> On Mon, 31 Dec 2018 at 21:05, Mark Millard wrote:
>> [...]
>>> But if you
On 2019-Jan-3, at 22:56, Michal Meloun wrote:
> On 29.12.2018 18:47, Dennis Clarke wrote:
>> On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote:
>>>
>>> On 2018-Dec-28, at 12:12, Mark Millard wrote:
>>>
>>>> On 2018-Dec-28, at 05
349250) (based on LLVM
7.0.1)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
I'd not expect clang vintage to be the issue.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-cur
the default driver on the major Linux distributions.
. . .
but it seems to not have a 13-current entry. It does have
a 12.0-RELEASE entry.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd
On 2019-Feb-17, at 18:35, Rodney W. Grimes wrote:
>> On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote:
>>>
>>>
>>> On 2019-Feb-17, at 10:03, Steve Kargl
>>> wrote:
>>>
>>> Anyone have insight into what evdev is? The
Features=0x1783fbff
Features2=0xfed83203
AMD Features=0x2e500800
AMD Features2=0x4003f3
Structured Extended
Features=0x209c01a9
XSAVE Features=0xf
AMD Extended Feature Extensions ID EBX=0x2001004
Hypervisor: Origin = "Microsoft Hv"
. . .
===
Mark Millard
marklmi at yahoo.com
( d
/src/share/mk/bsd.confs.mk
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk /usr/src/share/
mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk
/usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk
/usr/src/share/mk/bsd.subdir.mk /usr/src/share/
On 2019-Jul-26, at 18:35, Mark Millard wrote:
> This was an attempted self-hosted update from -r350300 to
> -r350364 . The lib32 part of buildworld got:
That -r350300 should have been: -r350255 .
Apparently, this was a build-race that I've not seen
in some time: Simply starting a
5test-in. Stop
make[7]: stopped in /usr/src/lib/libc/tests/hash
*** Error code 2
The original context was -r350364 .
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing li
A textually small nit for r351100 is that %ju normally goes with a
(uintmax_t) cast, so more like:
debugf(sc->dev, "Bus clock is at %ju\n", (uintmax_t)clk);
%ju need not match up with uint64_t from:
uint64_t clk;
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
dir.mk
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/stand/i386/boot2'
1 error
FYI:
# uname -apKU
FreeBSD FBSDFHUGE 13.0-CURRENT FreeBSD 13.0-CURRENT #29 r351102M: Thu Aug 15
14:22:00 PDT 2019
markmi@FBSDFHUGE:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-N
--- realinstall_subdir_tests ---
. . .
--- realinstall_subdir_stand ---
sh: cc: not found
Repeating buildworld buildkernel and then trying installworld (without
the -j28 I had used originally) completed.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar
src/share/mk/bsd.clang-analyze.mk
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/stand/i386/gptboot /usr/src/stand/i386/boot2
/usr/src/stand/i386/common /usr/src/stand/libsa'
1 error
===
Mark Millard
marklmi at yahoo.c
ns to have been run
in a Windows 10 Pro HyperV session, instead
of in a native-boot of the same media. (A
native-boot would have had 32 CPUs.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebs
On 2019-Sep-11, at 07:31, Mark Johnston wrote:
> On Tue, Sep 10, 2019 at 10:58:05PM -0700, Mark Millard wrote:
>> In a context with:
>>
>> # cpuset -g
>> pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
>> 18, 19, 20, 21, 22, 23
On 2019-Sep-11, at 08:15, Mark Johnston wrote:
> On Wed, Sep 11, 2019 at 07:57:26AM -0700, Mark Millard wrote:
>>
>>
>> On 2019-Sep-11, at 07:31, Mark Johnston wrote:
>>
>>> On Tue, Sep 10, 2019 at 10:58:05PM -0700, Mark Millard wrote:
>>&g
On 2019-Sep-11, at 10:11, Mark Millard wrote:
> On 2019-Sep-11, at 08:15, Mark Johnston wrote:
>
>> On Wed, Sep 11, 2019 at 07:57:26AM -0700, Mark Millard wrote:
>>>
>>>
>>> On 2019-Sep-11, at 07:31, Mark Johnston wrote:
>>>
>>>
ard computer investigations
that lead to my learning about vm.pageout_oom_seq .)
If more or different configuration/tuning is required, I'm going to
eventually want to learn about it as well.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
messages?
(It used to be that the system simply leaves the dirty pages in
memory when a swap_pager_getswapspace failed message is produced.
Of itself, it did not cause a kill. I do not know about now.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
__
/sys/sys/mutex.h:258:2: note: expanded from macro '__mtx_lock_spin'
spinlock_enter(); \
^
. . .
(spinlock_enter was not the only example.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@free
On 2019-Sep-14, at 11:21, Ian Lepore wrote:
> On Sat, 2019-09-14 at 11:05 -0700, Mark Millard via freebsd-arm wrote:
>> After updating my amd64 context to head -r352274,
>> attempting an amd64->armv7 cross buildworld buildkernel
>> ended up failing with:
>&g
causing crappy down-stream effects. You can
use the I/O scheduler to limit the write rates at the low end. You might also
be able to schedule a lower write queue depth at the top end as well, but I've
not seen good ways to do that.
===
Mark Millard
marklmi at yahoo.com
( dsl-only
ormation for earlier offerings.
Snapshots are not vetted as far as I know --and sometimes do not boot
in contexts that I've tried. This applies both to artifact.ci.freebsd.org
materials and the announced snapshots put under
https://download.freebsd.org/ftp/snapshots/ .
===
Mark M
On 2019-Nov-20, at 14:28, Julian Elischer wrote:
> On 11/20/19 1:51 PM, Mark Millard wrote:
>> Bob P. wrote for an aarch64 context:
>>
>>> From time to time it would be handy to revert freebsd-current to
>>> an older, well-behaved revision.
>>>
ts) = {};
21:21:52
^~~~
21:21:52
*** [bitstring_test.o] Error code 1
But, as of when I looked, none of the FreeBSD-head-amd64-gcc build attempts have
completed since then.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freeb
only used in:
KASSERT(sc->dmamap_seg_count == 0,
("data pending interrupt pushed through SDHCI framework"));
and this was a non-debug build: so the KASSERT did not use sc either.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net w
/os-release
was established, possibly via the distrib-dirs distribution DB_FROM_SRC=1 use
involved in (re-)constructing
/usr/obj/DESTDIRs/clang-cortexA53-installworld-poud/ .
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
On 2019-Nov-24, at 15:11, Ben Woods wrote:
> On Sun, 24 Nov 2019 at 1:27 pm, Mark Millard wrote:
> My poudiere jail constructions with the likes of -a arm64.aarch64 -x are
> all getting:
>
> awk: can't open file /sys/param.h
> source line number 1
>
> Hi M
: /usr/ports/lang/gcc5
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5
Relative URL: ^/head/lang/gcc5
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule
Copyright 1992. But I've not
noticed any later ANSI/ISO material indicating the the above has changed status
in more recent vintages of the standard. I could be wrong since I've not tried
to be comprehensive about analyzing changes.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-22
include/c++/v1/. -std=gnu++11 -L/usr/lib/.
(The above and just below experiments with mostly(?) avoiding use of gcc 4.2.1,
even for CC/CXX/CPP contexts.)
> # ls -FPal /usr/bin/g[+c]*
> lrwxr-xr-x 1 root wheel 48 Mar 20 02:03 /usr/bin/g++@ ->
> /usr/local/bin/powerpc64-portbld-f
-freebsd11.0-gcc
> CXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++
> CPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp
> CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/
> X_COMPILER_TYPE=gcc
> CXXFLAGS+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=gnu++11
>
just below experiments with mostly(?) avoiding use of gcc 4.2.1,
even for CC/CXX/CPP contexts.)
> # ls -FPal /usr/bin/g[+c]*
> lrwxr-xr-x 1 root wheel 48 Mar 20 02:03 /usr/bin/g++@ ->
> /usr/local/bin/powerpc64-portbld-freebsd11.0-g++
> lrwxr-xr-x 1 root wheel 48 Mar 19 04:20
s since a dtls1.h was found.)
The reference is finding /usr/include/openssl/dtls1.h (old)
instead of /usr/obj/usr/src/tmp/usr/include/openssl/dtls1.h or
/usr/src/crypto/openssl/ssl/dtls1.h (new):
> # diff -w /usr/include/openssl/dtls1.h
> /usr/obj/usr/src/tmp/usr/include/openssl/dtls1
# more /etc/src.conf
> NO_WERROR=
> WITH_LIBCPLUSPLUS=
> CC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
> CXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++
> CPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp
> CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/
&
n requested address
> Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for
> [omitted] fails: Can't assign requested address
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-31, at 07:13 PM, Mark Millard wrote:
Basic context:
> $ dmesg | head
> ...
> Fr
On 2015-Apr-1, at 08:12 PM, Kevin Oberman wrote:
>
> On Wed, Apr 1, 2015 at 12:08 PM, Mark Millard wrote:
> I rebuilt and the boot-message line
>
> > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error
>
>
> is no longer is occurring. But I&#x
e set in this file are MAKEOBJDIRPREFIX,
> WITH_DIRDEPS_BUILD, and WITH_META_MODE as they are environment-only
> variables.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/ma
ps://svn0.us-west.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 402906
> Node Kind: directory
> Schedule: normal
> Last Changed Author: wen
> Last Changed Rev: 402906
> Last Changed Date: 2015-12-03 18:06:07 -0800 (Thu, 03 Dec 2015)
===
I'm adding a note about the missing "\" being just an E-mail editing error, not
an original command error. . .
On 2015-Dec-6, at 8:32 AM, Mark Millard wrote:
> Mostly just an FYI: This means that for my own purposes I'll tend to avoid
> WITH_CCACHE_BUILD= for now
1 - 100 of 1389 matches
Mail list logo
