https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
Mark Linimon changed:
What|Removed |Added
Status|New |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #105 from Mark Millard ---
(In reply to Mark Millard from comment #104)
FYI: So far what failed initially but
built in a later retry of a bulk -a
(no -C ) is:
tome4-1.5.5
sv-gimp-help-html-2.8.2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #104 from Mark Millard ---
(In reply to Don Lewis from comment #103)
I'm experimenting with a Ryzen Threadripper
1950X on head -r326192 an /usr/ports/
-r454407 and its first go build got:
. . .
bytes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #103 from Don Lewis ---
For my next experiment, I built my usual set of packages using the same set of
jails that I use on my other build box:
10.4 i386
lang/go build failure (malloc corruption)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #102 from Don Lewis ---
I finally got around to contacting AMD a couple weeks ago about a warranty
replacement for my CPU. My original CPU had a date code of 1708SUT and the new
one has a date code of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #101 from Nils Beyer ---
Back from my vacation and got the RMA CPU dated "UA 1730SUS" (end of July) -
will try a poudriere run now...
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #100 from Don Lewis ---
(In reply to Mark Millard from comment #95)
I wonder if the virtual CPUs in Hyper-V are not pinned to physical CPUs, but
are allowed to float around. That could cause threads in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #99 from Mark Millard ---
(In reply to Mark Millard from comment #98)
The retry is way past the earlier SIGSEGV point
(but is still building).
So even under qemu-arm-static emulation of
arm instructions
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #98 from Mark Millard ---
I tried an experiment of an amd64 -> armv6 cross build
of lang/gcc7 via poudriere and it appears that I got
a SIGSEGV in:
/wrkdirs/usr/ports/lang/gcc7/work/.build/./gcc/xgcc
that
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #97 from Don Lewis ---
Since this behavior seems to be sensitive to the scheduler, I tried SCHED_4BSD.
Things started out promising, though ghc died with it's usual SIGBUS. The
chromium build failed due
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #96 from Don Lewis ---
I undid my hack to restrict steal_idle to the current CCX, but left the
thresh=2 override in place.I saw the usual lang/ghc SIGBUS, and lang/go died
with its common malloc state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #95 from Mark Millard ---
I've now tried Hyper-V instead of VirtualBox
for building lang/ghc (the most systematic
usually-quick-failure test that I've found).
In this context:
sysctl kern.sched.balance=1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #91 from Mark Millard ---
My first ever compelted attempt at anything
like:
pousriere bulk -w -a
finished. (It started from a prior interrupted
attempt from a prior boot so some things had
already built
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #90 from Don Lewis ---
When stealing a thread from the other SMT thread on the same core, another
tuning knob comes into play, kern.sched.steal_thresh. A thread will only be
stolen if the that value,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #89 from Don Lewis ---
In my latest experiment, I hacked the sched_ule steal_idle code to only allow
threads to be stolen from the other SMT thread on the same core and set
steal_idle=1. CPU idle time was
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #88 from Don Lewis ---
(In reply to Mark Millard from comment #85)
With steal_idle=0 and balance=0 I was able to sucessfully build both
www/sogo2-activesync and devel/linux_libusb.
The there is
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #87 from Don Lewis ---
I set affinity back to its default value of 1 and got another clean 1700 port
poudriere run. It's curious that the only issues I've had when steal_idle=0
and balance=0 happened when
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #86 from Mark Millard ---
AMD wants to RMA the CPU for the Ryzen7 1800X PC that
I (sometimes) have access to.
So once the logistics are worked out and arrangements
made I will be out of the Ryzen testing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #85 from Mark Millard ---
(In reply to Mark Millard from comment #84)
Looks like I may have issues for linux related
builds and its /compat/linux/usr/bin/gcc use.
I've now gotten a 2nd example:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #84 from Mark Millard ---
(In reply to Don Lewis from comment #83)
Good to know for:
audio/linux-skype_oss_wrapper
lang/ghc
lang/go
Thanks. (It does not look like the lang/go
build has started yet in my
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #83 from Don Lewis ---
I reran poudriere again with the same settings (steal_idle=0, balance=0,
affinity=10) and got no failures this time. Both ghc and go builds were
successful.
The ghc build failed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #82 from Mark Millard ---
(In reply to Mark Millard from comment #79)
My kern.sched.steal_idle=0 based "poudriere bulk -a"
test has now had one SIGSEGV based build failure:
===> Building for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #81 from Mark Millard ---
(In reply to Don Lewis from comment #80)
FYI for my tests:
So far with kern.sched.steal_idle=0 I've never had
lang/ghc fail to build.
So far with kern.sched.steal_idle=1 I've
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #80 from Don Lewis ---
The events controlled by kern.sched.balance are timer based and are probably
much less frequent than occurences of a CPU running out of work to do and
triggering a steal_idle event
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #79 from Mark Millard ---
(In reply to Mark Millard from comment #77)
I have started a poudriere bulk -a based on:
sysctl kern.sched.balance=1
sysctl kern.sched.steal_idle=0
with:
#PARALLEL_JOBS=1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #78 from Don Lewis ---
I had x11/linux-c6-xorg-libs fail in patch depends when make got a SIGBUS with
sysctl kern.sched.affinity=100
sysctl kern.sched.balance=1
sysctl kern.sched.steal_idle=1
Also, ghc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #77 from Mark Millard ---
(In reply to Mark Millard from comment #76)
sysctl kern.sched.balance=0
sysctl kern.sched.steal_idle=0
with:
#PARALLEL_JOBS=1
ALLOW_MAKE_JOBS=yes
and ALLOW_MAKE_JOBS_PACKAGES
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #76 from Mark Millard ---
(In reply to Mark Millard from comment #75)
sysctl kern.sched.balance=1
sysctl kern.sched.steal_idle=0
also completed the lang/ghc build.
I'm now testing:
sysctl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #75 from Mark Millard ---
(In reply to Mark Millard from comment #74)
I got a lang/ghc build that completed on
the Ryzen:
# pkg search ghc
ghc-8.0.2_1Compiler for the functional
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #74 from Mark Millard ---
(In reply to Don Lewis from comment #73)
I'm trying:
sysctl kern.sched.balance=0
sysctl kern.sched.steal_idle=0
For my test with:
PARALLEL_JOBS=1
ALLOW_MAKE_JOBS=no
and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #73 from Don Lewis ---
When I've examined a ghc core file, gdb thought that rip was pointing at code
and allowed me to disassemble it. I didn't see anything that looked like it
could cause SIGBUS.
I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #72 from Mark Millard ---
(In reply to Mark Millard from comment #71)
I've done a few runs recovering the ghc.*.core
files and took a quick comparison/contrast:
info reg shows a few registers that seem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #71 from Mark Millard ---
Has anyone tried doing a bunch of lang/ghc builds
on Ryzen to see the failure rate but for the type
of context indicated below (specifying via a
poudriere context's techniques):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
Mark Millard changed:
What|Removed |Added
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #69 from Nils Beyer ---
(In reply to Conrad Meyer from comment #68)
- the poudriere segfault/unable to rename/kernel panic Ryzen is a 1700 stock,
manufacturing date: UA 1707PGT
- the unable to rename/never
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #68 from Conrad Meyer ---
Just curious -- what model Ryzens are you seeing the faults on?
I'm curious to what extent better binning affects the symptoms. Are R3s and
R5s mostly the affected? Or do R7s see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #67 from Nils Beyer ---
(In reply to Nils Beyer from comment #66)
well, it seems that we have to RMA our CPUs after all:
https://community.amd.com/message/2816858#comment-2816858
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #66 from Nils Beyer ---
(In reply to Don Lewis from comment #65)
> I am not convinced that the rename problem isn't a FreeBSD problem. It's
> rare enough that it is difficult to track down.
I wasn't able to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #65 from Don Lewis ---
I am not convinced that the rename problem isn't a FreeBSD problem. It's rare
enough that it is difficult to track down.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #64 from Nils Beyer ---
(In reply to Don Lewis from comment #63)
hmm - doesn't sound so good; if you say that there's nothing that FreeBSD can
do to workaround/circumvent/mitigate the issue and that there's
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #63 from Don Lewis ---
(In reply to Nils Beyer from comment #61)
Hard to say ...
If it is something triggered by context switches and is well understood, it
might be possible to add some synchronization
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #62 from Conrad Meyer ---
Interesting, thanks for sharing Nils.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #61 from Nils Beyer ---
well:
https://www.phoronix.com/scan.php?page=news_item=Ryzen-Segv-Response
"Performance Marginality Problem" - stupid phrase, really. Marketing drivel.
That here could be more of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #59 from Don Lewis ---
(In reply to Nils Beyer from comment #58)
Actually, I'm not so sure now. If I disassemble
llvm::FoldingSetBase::GrowBucketCount(), I see this computed call:
0x02c33cea
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #58 from Nils Beyer ---
(In reply to Don Lewis from comment #57)
Hmm, "speculative execution" aka "slipped RIP" perhaps?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #57 from Don Lewis ---
(In reply to Don Lewis from comment #55)
> #3 0x00a4cf46 in
> clang::FunctionProtoType::Profile(llvm::FoldingSetNodeID&, clang::ASTContext
> const&) ()
> #4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #56 from Don Lewis ---
The stack check failure in c++ for the node and the earlier cmake build
failures were also in clang::FunctionProtoType::Profile().
The stack doesn't look too damaged, since the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #55 from Don Lewis ---
It's not really repeatable at all. I've seen a couple different clang aborts,
but they are pretty rare, and happen when building different ports each time.
I did manage to get the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #54 from Nils Beyer ---
(In reply to Don Lewis from comment #53)
> Interestingly both node and libreoffice core files indicate that c++ died at
> the same place.
that sounds strange - the main feature of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #53 from Don Lewis ---
I change the CPU clock speed from 3.0 GHz to the default 3.4 GHz and things
were not quite as rosey. These were the failures:
* ghc SIGBUS as usual
* www/node - clang died with
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #52 from Don Lewis ---
Testing poudriere with SMT on, I got some more fallout:
* The usual ghc SIGBUS failure
* clang aborted while building cmake. Unfortunately the build output
isn't very
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #51 from Don Lewis ---
(In reply to Conrad Meyer from comment #46)
r321919 looks very promising. I upgraded to r322026 and the only "unexpected"
failure during my poudriere run was the lang/ghc sigbus
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #50 from Don Lewis ---
(In reply to Conrad Meyer from comment #48)
Interesting link. I've been hearing rumors about this, but this is the first
detailed info that I've seen.
Speculative execution is one
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #49 from Don Lewis ---
(In reply to Conrad Meyer from comment #46)
I have not tried r321919 yet. That'll be my next experiment. I'm currently
running r321732.
I just got the results from my last
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #48 from Conrad Meyer ---
That link is interesting. It looks like perhaps speculative execution is
triggering real faults.
https://en.wikipedia.org/wiki/Speculative_execution
(Obviously, it shouldn't cause
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #47 from Nils Beyer ---
Is that here:
http://fujii.github.io/2017/06/23/how-to-reproduce-the-segmentation-faluts-on-ryzen/
somewhat relevant, helpful, enlightening? How can the RIP CPU register slip?
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #46 from Conrad Meyer ---
(In reply to Don Lewis from comment #45)
Speaking of user faults, have you tried testing after r321919?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #45 from Don Lewis ---
I've never seen a successful amd64 ghc build. i386, no problem.
I don't recall seeing that assert before, but it could have been hiding in the
weeds. It is strangely consistent,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #44 from Nils Beyer ---
(In reply to Don Lewis from comment #43)
> Nope, my BIOS doesn't have a knob to disable the OPCache.
doesn't matter - my successful "ghc" build was just luck because I tried
another
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #43 from Don Lewis ---
Nope, my BIOS doesn't have a knob to disable the OPCache. Interesting about
ghc.
I just got another buildworld failure a little while ago after 26 successful
iterations. The same
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #42 from Nils Beyer ---
(In reply to Don Lewis from comment #41)
Don, do you have to possibility to disable "OPCache Control" or anything that
sounds like that in your BIOS?
I was able to build "ghc" for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
Nils Beyer changed:
What|Removed |Added
See Also|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
Nils Beyer changed:
What|Removed |Added
Depends on||219399
Referenced
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #41 from Don Lewis ---
Just got another when I restarted the test:
--- asn1_HDB_Ext_PKINIT_hash.o ---
Assertion failed: (Idx < getNumArgs() && "Argument index out of range!"),
functi
on getArgKind, file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #40 from Don Lewis ---
After 26 successful buildworld/buildkernel iterations, I got a failed build
cause by a clang assertion failure:
Assertion failed: (Idx < getNumArgs() && "Argument index out of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #39 from Don Lewis ---
My machine seems to be really stable doing buildworld/buildkernel these days,
even using tmpfs for OBJDIR. No errors when I was running it last night. I'm
running it again today
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #37 from Don Lewis ---
Results of another poudriere run, this time using tmpfs. Fix failed ports:
* guile2 - guild segfault
* wkhtmltopdf - c++ abort
* libreoffice - c++ abort
* go -
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #38 from Don Lewis ---
s/Fix/Five/
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #36 from Don Lewis ---
I finally had a chance to do another poudriere run. I saw three failures:
* gnucash - guild segmentation fault
* go - entersyscall inconsistent 0xc4207acea8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #35 from Don Lewis ---
Last night I upgraded to 12.0-CURRENT r321674 to pick up the build framework
change, the timehands change, and the libarchive change. Since then, my
machine has successfully
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #34 from Don Lewis ---
I'm pretty sure that the "Cannot open `.'" error is not Ryzen-specific. It's
coming from:
if (node->tn_links < 1)
return (ENOENT);
in tmpfs_open().
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #33 from Don Lewis ---
I haven't gotten another "Cannot open `.'" error, but I did get the rename
error overnight. Nothing was logged. Post-mortem checking of the obj tree
shows that the temp file was
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
Nils Beyer changed:
What|Removed |Added
Version|11.0-STABLE |11.1-RELEASE
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #32 from Nils Beyer ---
(In reply to Nils Beyer from comment #30)
well, after staticially setting my VCORE voltage to 1.36250V, my system paniced
(that's something new for sure).
But because of the panic,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #31 from Don Lewis ---
(In reply to Don Lewis from comment #27)
It even falis with:
# sysctl debug.vfscache=0
debug.vfscache: 1 -> 0
Time to add some more debug ...
I'm not seeing any MCA messages.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #30 from Nils Beyer ---
Time for the action which AMD tech support requested; I've just answered them:
-
Hi ...,
1) regarding system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #29 from Nils Beyer ---
(In reply to Mateusz Guzik from comment #19)
I applied your debug patch on my buildkernel/buildworld system and started the
stress test. It failed five times out of 28 passes:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #28 from Nils Beyer ---
(In reply to Nils Beyer from comment #16)
as excpected, several ports now built successfully (whereas they didn't in the
previous run):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #27 from Don Lewis ---
(In reply to Mateusz Guzik from comment #19)
--- test_04.cleandir ---
(cd /usr/src/lib/libxo/tests && DEPENDFILE=.depend.test_04 NO_SUBDIR=1 make
-f
Makefile _RECURSING_PROGS=t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #26 from Nils Beyer ---
(In reply to Don Lewis from comment #25)
http://netdna.webdesignerdepot.com/uploads/2013/05/11.jpg
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #25 from Don Lewis ---
Nothing real magical. Just very stripped down and it bails out if a build
fails so the the state of the obj tree can be examined. You have to the top of
the src tree yourself, and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #24 from Nils Beyer ---
(In reply to Don Lewis from comment #23)
> [...] I'm running a variation of the stress test.
now, that sounds daring - want to share?
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #23 from Don Lewis ---
(In reply to Nils Beyer from comment #18)
I'm running a variation of the stress test. I just got another, similar,
failure.
--- cleandir_subdir_usr.bin/su ---
===> usr.bin/su
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #21 from Nils Beyer ---
(In reply to Mateusz Guzik from comment #20)
> [...] can't reproduce myself.
do you have a Ryzen system?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #20 from Mateusz Guzik ---
to be clear, there are 2 parts:
1. possible problem where an already present negative entry causes dropping the
new positive entry on the floor, which gives ENOENT on lookup
2. dot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
Mateusz Guzik changed:
What|Removed |Added
CC||m...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #18 from Nils Beyer ---
(In reply to Don Lewis from comment #17)
did that happen by accident or did you try my "ryzen_stress_test.sh" script?
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #16 from Nils Beyer ---
Finally, my poudriere run went completely through - without any system freezes
or unexpected reboots:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #15 from Nils Beyer ---
(In reply to Nils Beyer from comment #14)
> So, no definite answer whether your evil patch bypasses the UTR-problem
> (Unable-To-Rename) or not...
and here I give me the definite
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #14 from Nils Beyer ---
(In reply to Don Lewis from comment #12)
> Earlier you mentioned not seeing this on the machine using the original
> version.
Ah, okay, sorry; you surely meant this comment here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #13 from Nils Beyer ---
(In reply to Don Lewis from comment #12)
> I'm pretty sure I saw one while doing a buildworld on ZFS as well. I think
> these errors occur less frequently on ZFS. I just did two
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #12 from Don Lewis ---
(In reply to Nils Beyer from comment #9)
I'm pretty sure I saw one while doing a buildworld on ZFS as well. I think
these errors occur less frequently on ZFS. I just did two
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #11 from Don Lewis ---
(In reply to Nils Beyer from comment #7)
I've gotten one of these:
Jul 22 17:17:17 speedy kernel: MCA: Bank 1, Status 0x902b0151
Jul 22 17:17:17 speedy kernel: MCA: Global
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #10 from Don Lewis ---
(In reply to Nils Beyer from comment #6)
Only on the Ryzen, maybe a week ago, before moving the shared page. I've never
seen it on my AMD FX-8320E.
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #9 from Nils Beyer ---
(In reply to Nils Beyer from comment #2)
believe it or not, I also get these
error: unable to rename
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #8 from Nils Beyer ---
Here are the MCA messages from my other Ryzen system (the one with ECC RAM):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #7 from Nils Beyer ---
FWIW, I also get MCA messages from the kernel, like this one:
-
MCA: Bank 1, Status 0xd02b0151
MCA:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #6 from Nils Beyer ---
(In reply to Don Lewis from comment #4)
do you mean with "seen before" before you've got your Ryzen CPU or after?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #5 from Nils Beyer ---
Before I forget, here's my "poudriere.conf":
-
ZPOOL=asbach
FREEBSD_HOST=ftp://ftp2.de.freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
Don Lewis changed:
What|Removed |Added
CC|
1 - 100 of 106 matches
Mail list logo