1 and libc++" list in that last paragraph
given the "upgrade easily" context intended.
(If there is an easy powerpc64 upgrade then I'd like to see notes about it:
Other contexts might be able to use similar techniques. I started my
explorations with 10.)
===
Mark Millard
m
tation fault.
I'm still not sure that the stable/9 to stable/10 update would be reliably
clean for powerpc64, despite -mlongcall not being used at that stage.
===
Mark Millard
markmi at dsl-only.net
On 2015-Oct-11, at 8:05 PM, Mark Millard wrote:
> On 2014-Oct-11 Dimitry Andric wrote:
gt; and proceeded usual rebuilding procedure.
>
> Fortunately, there was only 3 commits between r298836 and r298920,
> and I got right one in first attempt.
>
> But unfortunately, fixing portupgrade[-devel] or file/libmagic beyonds
> my hand. :-<
I have taken Tomoaki'
; WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLDB=
> #
> WITH_BOOT=
> WITHOUT_LIB32=
> WITHOUT_LIBSOFT=
> #
> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> #WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_DEBUG_FILES=
> #
> XCFLAGS+= -march=armv7-a -mcpu=cortex-a7
> XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
make.conf was empty.
The earlier -r302331 cross build had WITH_LIBSOFT= in use. -r302412 is my first
testing of WITHOUT_LIBSOFT= after rebuilding all ports to avoid libsoft.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
of a different issue when
WITH_META_MODE was attempted.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
= "arm" does not appear to achieve the original test's intent
and will mishandle things list armv6 as far as I can tell. (It certainly does
avoid the malformed conditional problem that stops the build.)
===
Mark Millard
markmi at dsl-only.net
___
27;:
> /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:288:22: error: unknown
> conversion type character 'b' in format [-Werror=format=]
>device_printf(dev, "quirks=0x%b\n", ctlr->quirks,
> ^
> /usr/src/sys/modules/ahci/../../dev/ahci/ahci.
[Top post of probable "already fixed" status.]
It looks like -r320441 on stable/11 reverted a kern.mk change controlling what
formats are (un)available for some compilers.
I'm rebuilding things based on -r302457 instead of -r302412 and will close the
defect if things work.
=
On 2016-Jul-9, at 8:53 PM, Ngie Cooper wrote:
>> On Jul 9, 2016, at 18:52, bugzilla-nore...@freebsd.org wrote:
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210953
>>
>> Mark Millard changed:
>
> I accidentally committed this regression to ker
On 2016-Jul-8, at 12:23 AM, Mark Millard wrote --but with
a few []'d notes added:
> [Before the below cross build/update attempt I updated my amd64 from -r302331
> -> -r302412.]
>
> Summary: It appears that WITHOUT_META_MODE= still needs to be forced for
> cross comp
ile SRCS
being ppc64_elf_freebsd.c).
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
est
> build with the -CFLAGS+= -Wa,-mppc64bridge line removed?
> -Nathan
>
> On 07/11/16 03:55, Mark Millard wrote:
>> Is the following something that should be updated something like is
>> indicated below for 11.0-BETA1? Is kboot powerpc64 specific?
>>
>> #
On 2016-Jul-11, at 11:04 AM, Mark Millard wrote:
> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn wrote:
>>
>> It is not 64-bit only; like the normal loader, it can load both 32-bit and
>> 64-bit kernels. Those two flags are probably obsolete at this point and were
>
On 2016-Jul-11, at 11:30 AM, Mark Millard wrote:
> On 2016-Jul-11, at 11:04 AM, Mark Millard wrote:
>
>> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn wrote:
>>>
>>> It is not 64-bit only; like the normal loader, it can load both 32-bit and
>>> 64-bi
kboot in.
I'll enter a report showing the sys/boot/powerpc/kboot/Makefile change that I
tried.
===
Mark Millard
markmi at dsl-only.net
On 2016-Jul-11, at 11:43 AM, Mark Millard wrote:
> On 2016-Jul-11, at 11:30 AM, Mark Millard wrote:
>
>> On 2016-Jul-11, at 11:04 AM, Ma
On 2016-Jul-11, at 1:51 PM, Mark Millard wrote:
> Quick top-post just to indicate that I just did gcc 4.2.1 based cross-builds
> for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 and they completed. They
> had analogous warnings to what clang (powerpc) and powerpc64-gcc (powerpc64)
&
ck with Bruce Evans. He has good coverage of the various
standards to be covered (that may not all agree and how/what FreeBSD then
picks).
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[The below does note that TARGET=powerpc has a mix of signed wchar_t and
unsigned char types and most architectures have both being signed types.]
On 2016-Jul-11, at 8:57 PM, Andrey Chernov wrote:
> On 12.07.2016 5:44, Mark Millard wrote:
>> My understanding of the criteria for __WCHA
On 2016-Jul-13, at 6:00 PM, Andrey Chernov wrote:
> On 13.07.2016 11:53, Mark Millard wrote:
>> [The below does note that TARGET=powerpc has a mix of signed wchar_t and
>> unsigned char types and most architectures have both being signed types.]
>
> POSIX says nothing a
ariants (32-bit vs. 64-bit), causing
lots of false-positive compiler notices. gcc had followed the ABI involved
(long int) until the correction.
===
Mark Millard
markmi at dsl-only.net
On 2016-Jul-13, at 11:46 PM, Mark Millard wrote:
> On 2016-Jul-13, at 6:00 PM, Andrey Chernov wrote:
>
&
ebus.c
> >head/sys/dev/gpio/ofw_gpiobus.c
> >head/sys/dev/iicbus/ofw_iicbus.c
> >head/sys/dev/ofw/ofw_bus_subr.c
> >head/sys/dev/ofw/ofw_bus_subr.h
> >head/sys/dev/ofw/ofwbus.c
> >head/sys/dev/pci/pci_host_generic.c
> > head/sys/dev/vn
dling. There are
other problems as well, such as exception handling. To actually use the
buildworld result I'd use a kernel modified to have a so-called "red-zone" for
signal delivery. clang can not yet build the kernel so that part would be gcc
4.2.1 based. This does not deal wit
(autoselect)
> status: no carrier
> nd6 options=29
> add host 127.0.0.1: gateway lo0 fib 0: route already in table
> add host ::1: gateway lo0 fib 0: route already in table
> add net fe80::: gateway ::1
> add net ff02::: gateway ::1
> add net :::0.0.0.0:
WWW: http://wiki.qemu.org/Main_Page
> Comment: QEMU CPU Emulator - development version
> Options:
> CDROM_DMA : on
> CURL : on
> DOCS : on
> GNS3 : on
> GNUTLS : on
> GTK2 : on
> JPEG : on
> OPENGL : on
> PCAP : on
> PNG: on
> SAMBA : off
> SASL : on
> STATIC_LINK: off
> USBREDIR : off
> X11: on
> X86_TARGETS: off
. . .
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
TRINGS
.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
# more ~/src.configs/make.conf
CFLAGS.gcc+= -v
===
Mark Millard
markmi at dsl-only.net
___
[i:]"
Revision: 304029
Last Changed Rev: 304029
# uname -apKU
FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #4 r304029M: Sat Aug 13
01:10:34 PDT 2016
markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm armv6
1100500 1100500
# svnlite info /usr/ports | grep &
-PRERELEASE #4 r304029M: Sat Aug 13
> 01:10:34 PDT 2016
> markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-N
> ODBG arm armv6 1100500 1100500
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
make.conf
> WANT_QT_VERBOSE_CONFIGURE=1
> #
> DEFAULT_VERSIONS+=perl5=5.22
> WRKDIRPREFIX=/usr/obj/portswork
> WITH_DEBUG=
> WITH_DEBUG_FILES=
> MALLOC_PRODUCTION=
If I remember right the above are accurate for the rpi2 as well.
I'll note that arm-none-eabi-binutils
Quick top post: retrying "portmaster -DKa" after rebooting did not repeat the
panic.
OPTIONS_FILE_SET+=RELRO likely has nothing to do with the unusual panic.
===
Mark Millard
markmi at dsl-only.net
On 2016-Aug-27, at 3:35 AM, Mark Millard wrote:
[I've no solid evidence of wh
uilding
> on one system and installing on another will fail due
> to not finding cc in the OBJDIR.
>
> An actual fix will be made on head separately.
>
> PR: 212877
> Relnotes: yes
> Sponsored by: Dell EMC
note that, while there are no official builds for the Pine64 family
(A64 based) that are under the Allwinner arm activity, the SOC's involved are
Cortex-A53 64-bit arm based. They likely do not fit in the "standard
conventions" or arm64/aarch64 would be where they would hav
andard
conventions" or arm64/aarch64 would be where they would have been supported.
Some rewording might be appropriate for the above quote as well.]
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebs
e SOC's involved are
Cortex-A53 64-bit arm based. They likely do not fit in the "standard
conventions" or arm64/aarch64 would be where they would have been supported.
Some rewording might be appropriate for the above quote as well.]
===
Mark Millard
markmi at dsl-only.net
On 2016-Sep-24, at 2:11 PM, Warner Losh wrote:
> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard wrote:
>> [A resend since I forget to list free-arm in the To: the first time.]
>>
>> From https://www.freebsd.org/platforms/arm.html :
>>
>>> 32-bit ARM is offi
64. I've not put much effort into figuring such out given
the more basic problems above. (The environment the attempt was done from is
dhcp based.)
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
more /etc/make.conf
> WANT_QT_VERBOSE_CONFIGURE=1
> #
> DEFAULT_VERSIONS+=perl5=5.22
> WRKDIRPREFIX=/usr/obj/portswork
> WITH_DEBUG=
> WITH_DEBUG_FILES=
> MALLOC_PRODUCTION=
> # svnlite status /usr/src
> M /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/Selection
Quick top post on avoiding the problem:
Reverting devel/powerpc64-gcc from -r421598 to -r413189 appears to have avoided
this problem.
While buildworld is still building: the build is well past the failure point
reported below.
===
Mark Millard
markmi at dsl-only.net
On 2016-Sep-26, at 4:48
my cross builds. I've no head (CURRENT)
activities going on at this point.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
PU
> dev.cpu.1.%parent: cpulist0
> dev.cpu.1.%location:
> dev.cpu.1.%driver: cpu
> dev.cpu.1.%desc: Open Firmware CPU
> dev.cpu.0.%parent: cpulist0
> dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a7
> dev.cpu.0.%location:
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%desc: Open Firmware CPU
> dev.cpu.0.%parent: cpulist0
> dev.cpulist.0.%parent: ofwbus0
> dev.cpulist.0.%pnpinfo: name=cpus
> dev.cpulist.0.%location:
> dev.cpulist.0.%driver: cpulist
> dev.cpulist.0.%desc: Open Firmware CPU Group
> dev.cpulist.%parent:
> dev.aw_cpusclk.0.%parent: aw_ccu0
> dev.aw_cpusclk.0.%pnpinfo: name=clk@01f0140inner,sun8i-a83t-cpus-clk
> dev.aw_cpusclk.0.%location:
> dev.aw_cpusclk.0.%driver: aw_cpusclk
> dev.aw_cpusclk.0.%desc: Allwinner CPUS Clock
> dev.aw_cpusclk.%parent:
> security.jail.param.cpuset.id: 0
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
dling power and heat issues).
> On Mon, 24 Oct 2016 15:42:40 -0700
> Mark Millard wrote:
>
>> On 2016-Oct-24, at 2:00 PM, Emmanuel Vadot wrote:
>>
>>
>>> Hello Mark,
>>>
>>> The A83T is BIG/Little IIRC and we don't support that. That's
f more detail that might well be
able to say "but it is not NUMA like for these details . . .". By no mean have
I analyzed all the consequences of all the details.
But I find no evidence of BIG/Little use of different classes of cores at
necessarily different cock rates and the like.
BSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24
00:41:16 PDT 2016
markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
arm armv6 1100505 1100505
===
Mark Millard
markmi at dsl-only.net
__
BSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24
00:41:16 PDT 2016
markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
arm armv6 1100505 1100505
===
Mark Millard
markmi at dsl-only.net
__
1 root wheel 0 Oct 25 16:57 libgcc2.s
-rw-r--r-- 1 root wheel108880 Oct 25 16:57 libgcc2.i
-rw-r--r-- 1 root wheel 7636 Oct 25 16:57 _muldi3.dep
-rw-r--r-- 1 root wheel 560 Oct 25 10:16 _ucmpdi2.o
-rw-r--r-- 1 root wheel 560 Oct 25 10:16 _cmpdi2.o
-rw-r--r-- 1
0
34699 as CALL close(0)
34699 as RET close 0
-25840 in 2's complement is: 0xF...F9B10
Here doing the gdb truss instead reports:
(gdb) print t->cs.number
$1 = 580819728
and 580819728 = 0x229E9B10
and the 229E part matches several PFLT's in the area, including just bef
On 2016-Oct-28, at 7:29 AM, John Baldwin wrote:
> On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote:
>> [The following has been reported in:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
>>
>> In trying to build lang/gcc6 xgcc's
On 2016-Oct-28, at 4:02 PM, Mark Millard wrote:
> On 2016-Oct-28, at 7:29 AM, John Baldwin wrote:
>
>> On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote:
>>> [The following has been reported in:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=2
[I re-established the crotchet-build based failure context finally.
Unfortunately truss just dies in a new place.]
On 2016-Oct-28, at 7:29 AM, John Baldwin wrote:
> On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote:
>> [The following has been reported in:
>> https://b
t;/usr/obj/rpi2_clang" \
make $*
# more ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host
TO_TYPE=armv6
#
KERNCONF=RPI2-NODBG
TARGET=arm
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
#CPUTYPE=soft
g make buildkernel
completed the rest of the build just fine, creating the previously-missing file
before trying to use it.
===
Mark Millard
markmi at dsl-only.net
On 2016-Nov-2, at 3:13 AM, Mark Millard wrote:
> Lack of dependency? Race? (I've not isolated why this happened y
y checks of internal
structures, required by INVARIANTS
nooptions WITNESS # Enable checks to detect deadlocks and
cycles
nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for
speed
nooptions DIAGNOSTIC
nooptions MALLOC_DEBUG_MAXZONES #
able/11 context to head (12-CURRENT).
If this is intentional then I think the man src.conf references and such should
be explicit about the /etc/make.conf vs. /etc/src.conf distinction for
__MAKE_CONF= vs. SRC_ENV_CONF= .
===
Mark Millard
markmi at dsl-only.net
___
[The original of this message was not delivered to two of the places it was
sent to. This retries sending to just those places.]
On 2016-Nov-4, at 9:40 AM, Bryan Drewery wrote:
> On 11/3/2016 5:28 PM, Mark Millard wrote:
>> I just had a case of "odd" command text in a buildw
et/work/obj/arm64.aarch64/usr/src/sys/GENERIC-NODBG
> arm64 aarch64 1200014 1200014
> # svnlite info /usr/ports | grep "Re[lv]"
> Relative URL: ^/head
> Revision: 424540
> Last Changed Rev: 424540
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On 2016-Nov-7, at 1:16 PM, Brad Davis wrote:
> On Mon, Nov 07, 2016 at 12:19:24PM -0800, Mark Millard wrote:
>> It looks like http://pkg.freebsd.org is still back as of head being
>> 11-CURRENT: http://pkg.freebsd.org shows only
>
> Correct. I wrote up some details
h: 2979 byte(s)
> Diff to previous 305419
> Add generic device-tree cpufreq driver.
Such things might determine if I stick with stable/11 vs. switch to head for
a BPi-M3.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.or
h: 2979 byte(s)
> Diff to previous 305419
> Add generic device-tree cpufreq driver.
Such things might determine if I stick with stable/11 vs. switch to head for
a BPi-M3.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.or
On 2016-Nov-2, at 12:16 PM, Mark Millard wrote:
> Quick top post reporting that a build-order-race for -j use seems likely: the
> clean-then-build sequence
>
>> Command: env __MAKE_CONF=/root/src.configs/make.conf
>> SRC_ENV_CONF=/root/src.configs/src.conf.rpi2-clang
; be shipped without it. There is no intention of merge of the removal.
> The stable@ mailing list added for wider audience.
Can we presume no invalidation of the TARGET_ARCH=powerpc ABI?
It is SVR4 based as I remember (unlike TARGET_ARCH=powerpc64 ).
===
Mark Millard
markmi
nested examples before I
existed the one that only had the su --at which point it detected
the Failed assertion: "tsd_booted" as well (su and sh, su first).
In other experiments I found that it was when buildworld activity
caused swapping out of the failing processes that there were t
On 2017-Feb-27, at 7:21 PM, Mark Millard wrote:
> [I've added a variant of this material to bugzilla 217138.]
>
> I've reduced the testing context to the following
> type of example (no longer involving buildworld
> buildkernel):
>
> # sh
> # sh
> # sh
>
swap_testing.c
0x20488 <+320>: adrp x8, 51
0x2048c <+324>: addx8, x8, #0x808; =0x808
0x20490 <+328>: ldrb w9, [x8]
0x20494 <+332>: tbzw9, #0x0, 0x204a4 ; <+348> at swap_testing.c
0x20498 <+336>: orrw0, wzr, #0x6
0x2049c <+340>: bl 0x205c0 ; symbol stub for: raise
0x204a0 <+344>: strw0, [sp, #0x4]
0x204a4 <+348>: adrp x8, 51
0x204a8 <+352>: addx8, x8, #0x818; =0x818
0x204ac <+356>: ldrb w9, [x8]
0x204b0 <+360>: tbzw9, #0x0, 0x204c0 ; <+376> at
swap_testing.c:105
0x204b4 <+364>: orrw0, wzr, #0x6
0x204b8 <+368>: bl 0x205c0 ; symbol stub for: raise
-> 0x204bc <+372>: strw0, [sp]
0x204c0 <+376>: ldpx29, x30, [sp, #0x10]
0x204c4 <+380>: addsp, sp, #0x20 ; =0x20
0x204c8 <+384>: ret
# uname -apKU
FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r314638M arm64 aarch64
1200023 1200023
buildworld buildlkernel did not have MALLOC_PRODUCTION= defined. The kernel is a
non-debug kernel. (Previous to these experiments my other corruption examples
were not caught by a debug kernel. I'm not hopeful that this simpler context
would either.)
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On 2017-Mar-13, at 11:52 PM, Mark Millard wrote:
> I'm still at a loss about how to figure out what stages are messed
> up. (Memory coherency? Some memory not swapped out? Bad data swapped
> out? Wrong data swapped in?)
>
> But at least I've found a much smaller/simpl
[Another correction I'm afraid --about alternative program variations
this time.]
On 2017-Mar-13, at 11:52 PM, Mark Millard wrote:
> I'm still at a loss about how to figure out what stages are messed
> up. (Memory coherency? Some memory not swapped out? Bad data swapped
&
[This is just a correction to the subject-line text to say arm64
instead of amd64.]
On 2017-Mar-14, at 12:58 AM, Mark Millard wrote:
[Another correction I'm afraid --about alternative program variations
this time.]
On 2017-Mar-13, at 11:52 PM, Mark Millard wrote:
> I'm still at
[test_check() between the fork and the wait/sleep prevents the
failure from occurring. Even a small access to the memory at
that stage prevents the failure. Details follow.]
On 2017-Mar-14, at 11:07 AM, Mark Millard wrote:
> [This is just a correction to the subject-line text to say ar
On 2017-Mar-14, at 4:44 PM, Bernd Walter wrote:
> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
>> [test_check() between the fork and the wait/sleep prevents the
>> failure from occurring. Even a small access to the memory at
>> that stage prevents the fa
A single Byte access to a 4K Byte aligned region between
the fork and wait/sleep/swap-out prevents that specific
4K Byte region from having the (bad) zeros.
Sounds like a page sized unit of behavior to me.
Details follow.
On 2017-Mar-14, at 3:28 PM, Mark Millard wrote:
> [test_check() betw
[Something strange happened to the automatic CC: fill-in for my original
reply. Also I should have mentioned that for my test program if a
variant is made that does not fork the swapping works fine.]
On 2017-Mar-15, at 9:37 AM, Mark Millard wrote:
> On 2017-Mar-15, at 6:15 AM, Scott Benn
On 2017-Mar-15, at 11:07 PM, Scott Bennett wrote:
> Mark Millard wrote:
>
>> [Something strange happened to the automatic CC: fill-in for my original
>> reply. Also I should have mentioned that for my test program if a
>> variant is made that does not fork the swappin
[Summary: I've now tested on a rpi3 in addition to a
pine64+ 2GB. Both contexts show the problem.]
On 2017-Mar-16, at 2:07 AM, Mark Millard wrote:
> On 2017-Mar-15, at 11:07 PM, Scott Bennett wrote:
>
>> Mark Millard wrote:
>>
>>> [Something strange happened
y: the small allocation size also matters.
Be warned that I can not eliminate the possibility that
the trashing changed what region of memory it trashed
for larger allocations or when tcache is disabled.
===
Mark Millard
markmi at dsl-only.net
___
f
On 2017-Mar-18, at 5:53 PM, Mark Millard wrote:
> A new, significant discovery follows. . .
>
> While checking out use of procstat -v I ran
> into the following common property for the 3
> programs that I looked at:
>
> A) My small test program that fails for
> a dyn
those ssh sessions (from a
macOS environment).
I discovered that if I typed ^C it would output a new prompt and
start taking/displaying input normally.
I've not had such an issue in a while.
I never managed to isolate what contributed to it happening.
===
Mark Millard
markmi at dsl-only.net
On 2017-Mar-18, at 9:10 PM, Mark Millard wrote:
>
> On 2017-Mar-18, at 5:53 PM, Mark Millard wrote:
>
>> A new, significant discovery follows. . .
>>
>> While checking out use of procstat -v I ran
>> into the following common property for the 3
>>
On 2017-Mar-21, at 7:21 PM, Mark Millard wrote:
> On 2017-Mar-18, at 9:10 PM, Mark Millard wrote:
>
>>
>> On 2017-Mar-18, at 5:53 PM, Mark Millard wrote:
>>
>>> A new, significant discovery follows. . .
>>>
>>> While checking out use
are known
to already be gcc compliant).
This still leaves the limits.h and gsystemlimits.h and
syslimits.h code in place but does block most of the
activity.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://li
area: 10.x continues to get separate
lang/gcc* package builds from 11.x and later.
No problem for this context as far as I know.
Note: To simplify I choose to not be explicit
about what authors wrote what original text.
If that becomes an issue, it is correctable.
Blame me for
ng which specific handling needs to be made.
But the vm_ooffset_t and vm_pindex_t changes did not even
make the UPDATING notes. Right now things look to have
the worst combination for lang/gcc* when release/11.1.0/
becomes official: lang/gcc* 's break without notification
or suggestion of a workaro
l need whatever
technique is used. Some, such as lang/gcc6-aux, need
more done because of binary bootstrap materials being
downloaded and used and so the build of lang/gcc6-aux
gets the problem and fails before staging happens: the
binary-bootstrap materials need to avoid the adjusted
headers th
On 2017-Jun-29, at 3:10 AM, Gerald Pfeifer wrote:
> Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard dsl-only.net>:
>> A primary test is building lang/gcc5-devel under release/11.0.1
>> and then using it under stable/11 or some draft of release/11.1.0 .
>
>
rst public description of the problem's details.)
I agree that you did not get an answer for the other
part:
> I simply asked if it's safe to assume the sysctl to be an integer in
> 11.1
I've not gone through any draft 11.1-release code
17h45m28s
[00:00:05] Loading MOVED
make: "/usr/ports/Mk/bsd.port.mk" line 1177: UNAME_r () and OSVERSION (1101501)
do not agree on major version number.
[00:00:06] Error: Error looking up pre-build ports vars
[00:00:06] Cleaning up
[00:00:09] Unmounting file systems
And at this point we are
the C11 _Static_assert, with or
> without the include, going well outside the C++ language definition.
>
> . . .
>
> Fixed in r297299 .
(The context was a C++ file head/contrib/libcxxrt/guard.cc so C++'s
static_assert was used instead and -std=c++11 was added for the
libra
On 2017-Aug-25, at 12:14 AM, David Chisnall wrote:
> On 25 Aug 2017, at 07:32, Mark Millard wrote:
>>
>> As I remember _Static_assert is from C11, not
>> the older C99.
>
> In pre-C11 dialects of C, _Static_assert is an identifier reserved for the
> implement
On 2017-Aug-27, at 11:54 PM, Ed Schouten wrote:
> 2017-08-25 14:53 GMT+02:00 Ed Schouten :
>> 2017-08-25 9:46 GMT+02:00 Mark Millard :
>>> It appears that at least 11.1-STABLE -r322807 does not handle
>>> -std=c++98 styles of use of _Static_assert for g++7 in tha
Last Changed Rev: 323012
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Nevermind, stupid mistake on my part: armv6 was not actually
updated yet.
> On 2017-Aug-29, at 8:42 PM, Mark Millard wrote:
>
> installworld for -r323012 is getting things like (at least with the likes of
> -j14):
>
> --- pwd_test.install ---
> --- _proginstall ---
>
achine's
16 hardware threads to FreeBSD and doing buildworld buildkernel
and poudriere based port builds. (Windows 10 Pro not being
otherwise busy.)
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.fre
5 for some reason.
Note: Using /rescue/zstd avoids this issue.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-
ant for some
system --and they were not reporting such
hangups, nor did they indicate running under
any hypervisors. So, something more
local-context-special seems to be involved.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing
tions
#
WITH_BOOT=
WITH_LIB32=
#
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_REPRODUCIBLE_BUILD=
WITH_DEBUG_FILES=
Ryzen Threadripper 1950X HW but FreeBSD -r327142 running
under a Windows 10 Pro Hyper-V virtual machine. 110592
MB of RAM assigned. 29 virtual processors assigned.
Physical hard disk used, not a virtual one.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
D QUOTE
Matching up stable revisions with releng/12.3/ or release/12.3.0/ in
the future would be easier starting from svn material in the first
place and would provide identification for git as well.
But I've no clue if such would be important to what you might need
to do with 12.
===
Mark M
ore 13 and so likely
will be able to avoid the issue myself.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsub
e/12.2.0 tag.)
Of course, for 12 there still is:
https://svnweb.freebsd.org/base/release/12.2.0/
https://svnweb.freebsd.org/base/releng/12.2/
as a svn side view of things that has the modern
cross references to git included.
===
Mark Millard
marklmi at yahoo.c
On 2021-Feb-12, at 23:03, Mark Millard wrote:
> Dewayne Geraghty dewayne at heuristicsystems.com.au wrote on
> Sat Feb 13 06:04:52 UTC 2021 :
>
>> The main list we used was:
>>
>> https://lists.freebsd.org/pipermail/svn-src-stable-12/
>>
>> b
//cgit.freebsd.org/src/log/?h=releng/12.0
shows the most recent releng/12.0 in git is from 2021-Jan-28:
Commit message (Expand) Author Age Files Lines
Add UPDATING entries and bump version.releng/12.0 Gordon Tetlow
2020-01-28 2 -1/+17
Are you confusing stable/12 and rele
On 2021-Feb-18, at 05:33, Mark Millard wrote:
> mike tancsa mike at sentex.net wrote on
> Thu Feb 18 10:33:14 UTC 2021 :
>
>> On 2/17/2021 12:10 PM, Warner Losh wrote:
>>> On Feb 17, 2021, at 6:05 AM, mike tancsa wrote:
>>>>I noticed on a box that
table/12/ material between releng/12.1@r354233
and releng/12.2@r366954 .)
Since you did not provide the output from the
likes of "uname -apKU" (or some rough equivalent)
I've no direct clue which version you were trying.
But you should be able to compare to the above to
see which r
On 2021-Feb-23, at 18:08, Chris wrote:
> On 2021-02-23 17:42, Mark Millard wrote:
>> (Warner is only CC'd here.)
>> Warner Losh imp at bsdimp.com wrote on
>> Wed Feb 24 01:04:13 UTC 2021 :
>>> On Tue, Feb 23, 2021, 4:51 PM Chris wrote:
>>> > G
1 - 100 of 170 matches
Mail list logo
