On 2021-May-23, at 01:27, Mark Millard wrote:
> On 2021-May-23, at 00:44, Mark Millard wrote:
>
>> On 2021-May-21, at 17:56, Rick Macklem wrote:
>>
>>> Mark Millard wrote:
>>> [stuff snipped]
>>>> Well, why is it that ls -R, find, and diff -
On 2021-May-23, at 00:44, Mark Millard wrote:
> On 2021-May-21, at 17:56, Rick Macklem wrote:
>
>> Mark Millard wrote:
>> [stuff snipped]
>>> Well, why is it that ls -R, find, and diff -r all get file
>>> name problems via genet0 but diff -r gets no problem
On 2021-May-21, at 17:56, Rick Macklem wrote:
> Mark Millard wrote:
> [stuff snipped]
>> Well, why is it that ls -R, find, and diff -r all get file
>> name problems via genet0 but diff -r gets no problems
>> comparing the content of files that it does match up (the
>
On 2021-May-21, at 09:00, Rick Macklem wrote:
> Mark Millard wrote:
>> On 2021-May-20, at 22:19, Rick Macklem wrote:
> [stuff snipped]
>>> ps: I do not think that r367492 could cause this, but it would be
>>>nice if you try a kernel with the r367492 patch re
[Looks like the RPi4B genet0 handling is involved.]
On 2021-May-20, at 22:56, Mark Millard wrote:
>
> On 2021-May-20, at 22:19, Rick Macklem wrote:
>
>> Ok, so it isn't related to "soft".
>> I am wondering if it is something specific to what
>> &qu
ve a preference
for main vs. stable/13 vs. release/13.0.0 based? Is it okay to
stick to the base version things are now based on --or do you
want me to update to more recent? (That last only applies if
main or stable/13 is to be put to use.)
> . . . old history deleted . . .
===
Mark Millard
mar
[Direct drive connection to machine: no problem.]
On 2021-May-20, at 21:40, Mark Millard wrote:
> [main test example and main/releng/13 mixed example]
>
> On 2021-May-20, at 20:36, Mark Millard wrote:
>
>> [stable/13 test: example ends up being odder. That might
>>
[main test example and main/releng/13 mixed example]
On 2021-May-20, at 20:36, Mark Millard wrote:
> [stable/13 test: example ends up being odder. That might
> allow eliminating some potential alternatives.]
>
> On 2021-May-20, at 19:38, Mark Millard wrote:
>>
>>
[stable/13 test: example ends up being odder. That might
allow eliminating some potential alternatives.]
On 2021-May-20, at 19:38, Mark Millard wrote:
>
> On 2021-May-20, at 18:09, Rick Macklem wrote:
>>
>> Oh, one additional thing that I'll dare to top post...
&
ebsd.org on
> behalf of Rick Macklem
> Sent: Thursday, May 20, 2021 8:55 PM
> To: FreeBSD-STABLE Mailing List; Mark Millard
> Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs
> (in a zfs file systems context)
>
> Mark Millard wrote:
>> [I wa
2.13G 113G 2.13G /usr/ports
I've no clue if ZFS is important to the odditity
or not.
The original mount command was on CA72_16Gp_ZFS:
# mount -onoatime,soft 192.168.1.170:/usr/ports/ /mnt/
The network is just a local EtherNet.
===
Mark Millard
marklmi at yahoo.co
ewsyslog.conf.d/[!.]*.conf
/usr/local/etc/newsyslog.conf.d/[!.]*.conf
Specifically, the 7 lines with "@" involved under "when" get the
complaints.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
__
On 2021-May-5, at 17:01, Yuri Pankov wrote:
> Mark Millard via freebsd-current wrote:
>> Context:
>>
>> # gpart show -pl da0
>> => 40 468862048da0 GPT (224G)
>> 40 532480 da0p1 efiboot0 (260M)
>> 532520 2
19:52:14 2021
config:
NAMESTATE READ WRITE CKSUM
zroot ONLINE 0 0 0
da0p3 ONLINE 0 0 0
errors: No known data errors
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in e
On 2021-May-5, at 05:28, Mark Millard wrote:
> On 2021-May-5, at 02:47, Andriy Gapon wrote:
>
>> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>>> I had a:
>>> # zfs list -tall
>>> NAME USED AVAIL
On 2021-May-4, at 20:26, Mark Millard wrote:
> On 2021-May-4, at 13:38, Mark Millard wrote:
>
>> [The first buidlworld is still in process. So while waiting . . .]
>>
>> On 2021-May-4, at 10:31, Mark Millard wrote:
>>
>>> I probably know why
On 2021-May-5, at 02:47, Andriy Gapon wrote:
> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>> I had a:
>> # zfs list -tall
>> NAME USED AVAIL REFER MOUNTPOINT
>> . . .
>> zroot/DESTDIRs/13_0R-CA72
On 2021-May-4, at 13:38, Mark Millard wrote:
> [The first buidlworld is still in process. So while waiting . . .]
>
> On 2021-May-4, at 10:31, Mark Millard wrote:
>
>> I probably know why the huge count of differences this time
>> unlike the original report . . .
&
For reference:
# uname -apKU
FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0
releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021
root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1300139 1300
[The first buidlworld is still in process. So while waiting . . .]
On 2021-May-4, at 10:31, Mark Millard wrote:
> I probably know why the huge count of differences this time
> unlike the original report . . .
>
> Previously I built based on a checked-in branch as part of
> m
line 293, in load
return loads(fp.read(),
File "/usr/local/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 18:
invalid start byte
Not exactly an obvious error me
.
===
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 unsubscribe, send any mail to "freebsd-stable-uns
[Just adding readelf -S info since it seems to show more.]
On 2021-May-4, at 10:01, Mark Millard wrote:
> On 2021-May-4, at 08:51, Mark Millard wrote:
>
>> On 2021-May-4, at 06:01, Ed Maste wrote:
>>
>>> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>>
On 2021-May-4, at 08:51, Mark Millard wrote:
> On 2021-May-4, at 06:01, Ed Maste wrote:
>
>> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>>>
>>> But I'll note that I've built and stalled py37-diffoscope
>>> (new to me). A ba
On 2021-May-4, at 06:01, Ed Maste wrote:
> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>>
>> But I'll note that I've built and stalled py37-diffoscope
>> (new to me). A basic quick test showed that it reports:
>>
>> W: diffoscope.main: Fuzzy-
On 2021-May-3, at 21:27, Mark Millard wrote:
> On 2021-May-3, at 19:26, Mark Millard wrote:
>
>> On 2021-May-3, at 10:51, Mark Millard wrote:
>>
>>> On 2021-May-3, at 07:47, Ed Maste wrote:
>>>
>>>> On Thu, 29 Apr 2021 at 02:
On 2021-May-3, at 19:26, Mark Millard wrote:
> On 2021-May-3, at 10:51, Mark Millard wrote:
>
>> On 2021-May-3, at 07:47, Ed Maste wrote:
>>
>>> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>>> wrote:
>>>>
>>>
On 2021-May-3, at 10:51, Mark Millard wrote:
> On 2021-May-3, at 07:47, Ed Maste wrote:
>
>> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>> wrote:
>>>
>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
>>> /usr
On 2021-May-3, at 07:47, Ed Maste wrote:
> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
> wrote:
>>
>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
>> Files /usr/obj/DESTDIRs/1
ht notice and care about such differences.
===
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 unsubscribe, send an
On 2021-Apr-25, at 08:14, Graham Perrin wrote:
> On 23/04/2021 08:39, Mark Millard via freebsd-current wrote:
>
>> [3]
>
>
> With regard to mounting ZFS file systems in single user mode
>
> What's currently footnote 3 will pr
j/DESTDIRs/13_0R-CA7-for-chroot/var/db/etcupdate/
I have not checked on if "etcupdate build" has a similar issue
vs. not.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing
on would be more independent of dates possibly
being touched on the file server and would make time ordered
finding of things (such as for build-less approximate bisecting)
far more reasonable.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_
Is stable/13 going to start getting snapshot builds?
(As stands, main , stable/12 , and stable/11 are getting them.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
https
ng / writable at this
stage either.)
===
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 unsubscribe, send an
-r--r-- 1 root wheel 26552108 Apr 9 07:39:21 2021 kernel.txz
# ls -Tla /usr/freebsd-dist/
ls: /usr/freebsd-dist/: No such file or directory
NOTE: creating /usr/freebsd-dist/ with a copy of the MANIFEST
file in it was enough to get past this issue: it is doing
Archive Extraction now.
===
Mark Mi
When I looked at https://www.freebsd.org/platforms/ I noticed
that "64-bit little-endian PowerPC" powerpc64le is not listed.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org ma
as I have 20G of RAM and am pretty close to no swap space
> activity, but, of course, paging does occur.
With 20 GiBytes of RAM, what is going on at the time that
leads to paging activity? I'm thinking of just untarring
the firefox file, not building firefox or such. Can you
test such an unta
On 2021-Mar-15, at 14:57, Kevin Oberman wrote:
> Responses in-line.
>
> On Sun, Mar 14, 2021 at 3:09 PM Mark Millard wrote:
>
>> On 2021-Mar-14, at 11:09, Kevin Oberman wrote:
>>
>> > . . .
>> >
>> > Seems to only occur on large r/w
t; switched to a different workspace from ctrl-alt-right and did a clean
> shutdown.
>
> Do I also have a graphics issue? Examining log files show no indication that
> anything was happening. SMART shows no errors and reasonable values for
> everything. No indication of a HW problem. Th
sed on more recent
stable/13. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253968
comment 4 has some more notes about the context. The "make extract"
for firefox likely is not as complicated as the portsnap extract
example's execution structure.
Might be something to keep an ey
On 2021-Mar-4, at 14:16, Mark Millard wrote:
> Christos Chatzaras chris at cretaforce.gr wrote on
> Thu Mar 4 21:41:01 UTC 2021 :
>
>
>> After finding slow filesystem operations with 13.0-BETA2 I did more tests.
>>
>> All tests done with same hardware (Se
ages received
> 0 signals received
> 385527 voluntary context switches
>369 involuntary context switches
>
> --
>
> Differences between 13.0 and 14-CURRENT maybe related to debugging features.
>
> But 13.0-BETA4 is slower than 12.2. Does someon
s are seeing?
I'll note that someone submitted:
https://lists.freebsd.org/pipermail/freebsd-bugs/2021-March/100124.html
against 13.0-BETA4 for the UFS journaled soft-updates
related performance issue(s). They compared something
to 12.1-RELEASE for illustration.
===
Mark Millard
mar
ion of an alternate net Michael Tuexen 5 days
1 -36/+49
* | sctp: clear a pointer to a net which will be removed
. . . (all the prior history) . . .
and an empty vs. non-empty status is easier to tell
apart.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Ma
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
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-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
//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-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
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
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
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
On 2020-Jun-29, at 14:12, Donald Wilde wrote:
> On 6/29/20, Mark Millard wrote:
>> [I'm now subscribed so my messages should go through to
>> the list.]
>>
>> On 2020-Jun-29, at 06:17, Donald Wilde wrote:
>>
>>> . . .
>>
>> You r
[I'm now subscribed so my messages should go through to
the list.]
On 2020-Jun-29, at 06:17, Donald Wilde wrote:
> [adding maintainers of synth and ccache]
>
> On 6/29/20, Mark Millard wrote:
>> Based on "small arm system" context experiments
>> mostly .
s like /boot/loader.conf having
something like:
vfs.root.mountfrom='ufs:/dev/gpt/MyRoot'
to control where things are booted from.
> If I have MBR, I could override "active" slice in boot0 MBR loader
> interactively.
>
> Is it analogous feature for GPT?
===
Ma
in the Tier-2 support package sets list as well.
Technically the reported lists are from: pkg0.isc.freebsd.org
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
https
[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
[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,
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:
>>>>
>>
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-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,
[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
>>
[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
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
[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
[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
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-stable@freebsd.org mailing list
https://lists.f
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
88810 would be unlikely
contributors.
===
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 unsubscribe, send any mail to &
ed if C11 was not enabled (e.g.
via -std=c99), so this also fixes compile failures if a modern version
of GCC was used with -std=c11 but with FreeBSD's instead
of GCC's and this change fixes that case as well.
Reported by: Mark Millard
Reviewed by: kib
D
ependent. You may have no issues with some
> software+hardware combination and long timeouts with same software
> but different hardware.
Dimitry's example is for changing the software for the same(?) hardware,
if I understand right. (FreeBSD vs. some Linux distribution.)
(?: He did say
essing some at the intended results for
default tuning --and that you probably are using default
tuning.) So the in-use swapspace is likely from one or
more existing processes that did page-outs earlier.
(Expect my descriptions to be over simplified, but hopefully
pointing in the right general di
into sleep state, before sleeping, check if
* thread was removed from umtx queue.
*/
static inline int
umtxq_sleep(struct umtx_q *uq, const char *wmesg, struct abs_timeout *abstime)
. . .
Note: I'm guessing that /usr/src/sys/dev/qlnx/qlnxe/ecore_dbg_fw_funcs.c
is not involved.
===
r the speed of its
internal interconnect-fabric's operation.
I'll note that, if one goes through the referenced Linux exchanges about
this, Ryzen Threadripper's examples are also reported to have the problem.
===
Mark Millard
marklmi at yahoo.com
(
On 2018-Jan-21, at 12:17 PM, Don Lewis wrote:
> On 20 Jan, Mark Millard wrote:
>> Don Lewis truckman at FreeBSD.org wrote on
>> Sat Jan 20 02:35:40 UTC 2018 :
>>
>>> The only real problem with the old CPUs is the random segfault problem
>>> and some othe
eebsd.org/bugzilla/show_bug.cgi?id=221029
comment #103 on 2017-Oct-09):
QUOTE
The ghc build failure seems to be gone after upgrading the a
more recent 12.0-CURRENT. I will try to bisect for the fix
when I have a chance.
END QUOTE
Did that not pan out? Did you conclude it was
hardware-context specific?
ing boards).
I've only tried the 1950X with a native FreeBSD boot once
(a fair time ago). It showed a lockup problem fairly
quickly (power switch/plug time). I've never seen such
(or anything analogous) under Hyper-V with extensive use.
It does not look like I'll be investigating n
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"
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
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-
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
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 ---
>
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"
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
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
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
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
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
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 .
>
>
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
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
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
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
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
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
>>
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 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
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
[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
1 - 100 of 170 matches
Mail list logo
