https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #197 from Nils Beyer ---
As a last act of desperation, I've OCed my system:
- CPU freq: 3000MHz -> 3700MHz
- VCORE AUTO: -> 1.3625V
- DDR4 freq: 2133MHz-> 2400MHz
and disabled "OPCache Control" in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #196 from Nils Beyer ---
(In reply to commit-hook from comment #195)
thanks for the commit; I can confirm that there are no system
freezes/spontaneous reboots (without kernel panics) any more. Normal kernel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #195 from commit-h...@freebsd.org ---
A commit references this bug:
Author: truckman
Date: Wed Aug 2 01:43:36 UTC 2017
New revision: 321899
URL: https://svnweb.freebsd.org/changeset/base/321899
Log:
Lower the amd64 shared
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #194 from Nils Beyer ---
(In reply to Nils Beyer from comment #186)
> Now I've reset my CMOS to BIOS defaults and try a poudriere run with stock
> settings again - just as a cross-check...
and it kernel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #193 from Don Lewis ---
(In reply to rozhuk.im from comment #190)
I don't see that change in the March 2017 AMD64 Architecture Programmer’s
Manual Volume 2: System Programming (revision 3.28), which I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #192 from rozhuk...@gmail.com ---
(In reply to Nils Beyer from comment #191)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221132
You can play with it.
I will finish it later.
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #191 from Nils Beyer ---
(In reply to rozhuk.im from comment #190)
very interesting finding; AMD updated its dev docs March 2017, right after the
Ryzen launch - sounds like that the OS has to perform some
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #189 from Mark Millard ---
(In reply to Nils Beyer from comment #187)
I can not even tell if it is some form of
deadlock vs. livelock or what all else is
holding the lock over time (or even at the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #188 from Nils Beyer ---
(In reply to Don Lewis from comment #185)
thanks - will try after my cross-test is finished...
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #187 from Nils Beyer ---
(In reply to Mark Millard from comment #184)
is it caused by a software bug or hardware misbehaviour?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #185 from Don Lewis ---
(In reply to Nils Beyer from comment #177)
The patch is currently being reviewed here:
https://reviews.freebsd.org/D11780
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #184 from Mark Millard ---
(In reply to Nils Beyer from comment #183)
For:
#3 0x80a6b9e3 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:690
#4 0x80a4cf71 in _mtx_lock_spin_cookie
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #183 from Nils Beyer ---
And it paniced again - same reason as before:
---
root@asbach:/var/crash/#kgdb -c vmcore.1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
Nils Beyer changed:
What|Removed |Added
Version|11.0-STABLE |11.1-RELEASE
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #182 from Nils Beyer ---
In order to track these compilation errors, I did what AMD support requested:
cleared CMOS by removing all cables and the battery and set VCORE staticially
to 1.36250V
Then I started a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #181 from Don Lewis ---
(In reply to Nils Beyer from comment #177)
See comment #92
The final patch will be a bit more involved.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #180 from Nils Beyer ---
(In reply to Mark Millard from comment #179)
sure, I try:
--
1) fresh FreeBSD 11.1-RELEASE install on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #179 from Mark Millard ---
(In reply to Nils Beyer from comment #177)
Not that I'll be able to experiment with such a
build any time soon but . . .
Could you post material about how to set up
and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #178 from Nils Beyer ---
Ahh yes, got an MCA as well:
---
Jul 27 10:08:38 asbach kernel: pid 64716 (conftest), uid 0: exited on signal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #177 from Nils Beyer ---
finally, finally, finally a complete poudriere run without any system freezes
or unexpected reboots. :-)
Take a look for yourself:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #176 from Mark Millard ---
(In reply to Mark Millard from comment #172 and #173)
Looks like my comments #172 and #173 have
a different interpretation:
Just because the dmidecode reports something
does not
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #175 from rozhuk...@gmail.com ---
(In reply to Nils Beyer from comment #170)
I open new bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221038
(In reply to Don Lewis from comment #174)
No docs! :(
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #174 from Don Lewis ---
(In reply to Nils Beyer from comment #170)
Hmn, same here. Something to check is the AMD Family 17H docs to see if this
module needs any changes.
Something else to try is the very
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #173 from Mark Millard ---
(In reply to Mark Millard from comment #172)
I should have also noted that Nils Beyer
has earlier reported for that "not
supported" board (with 16 GB):
Physical Memory Array
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #172 from Mark Millard ---
(In reply to Don Lewis from comment #166)
Looks like you could try:
https://reviews.freebsd.org/D9824?id=25815
that rozhuk...@gmail.com reported (thanks!).
Nils Beyer reports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #171 from Mark Millard ---
(In reply to rozhuk.im from comment #167)
Machine Check Exceptions (MCEs) report various
errors that are detected in various ways.
For RAM: check or error correction bits (extra
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #170 from Nils Beyer ---
(In reply to rozhuk.im from comment #169)
cool, that module is already included in in 11.1-RELEASE (didn't know that).
But "dmesg" says after kldloading on my second system (with 16GB
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #169 from rozhuk...@gmail.com ---
(In reply to Don Lewis from comment #162)
Gigabyte have only 3 mobo for AM4 socket with good VRM (I mean VRM can provide
power for 95W CPU on long load cycles without additional cooling).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #168 from Mark Millard ---
(In reply to Don Lewis from comment #163)
Table 73 ("Memory Device (Type 17) structure") of:
http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.1.1.pdf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #167 from rozhuk...@gmail.com ---
(In reply to Mark Millard from comment #154)
MCE != ECC
MCE work even without ECC.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #166 from Don Lewis ---
(In reply to Mark Millard from comment #165)
... and I don't have any non-ECC RAM that I could try.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #165 from Mark Millard ---
(In reply to Don Lewis from comment #163)
Note: I can not claim to know for
In:
Physical Memory Array
. . .
Error Correction Type: Multi-bit ECC
I wonder if it says
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #164 from Mark Millard ---
(In reply to Don Lewis from comment #160)
Merely seeing detected (and corrected)
single(?)-bit errors on a fairly regular basis
(instead of very rare even on a very busy PC)
is
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #163 from Don Lewis ---
(In reply to Mark Millard from comment #159)
This is what dmidecode reports on my machine:
Handle 0x0027, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #162 from Don Lewis ---
(In reply to Mark Millard from comment #154)
Unfortunately that is true. That is one of the reasons why I switched from my
previous Gigabyte AB350 board to the AX370-GAMING 5 after
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #161 from Don Lewis ---
(In reply to Nils Beyer from comment #153)
I suspect that there is a pattern sensitivity issue in the icache since I've
seen quite a few reports of this. Nothing that we do in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #160 from Don Lewis ---
(In reply to Mark Millard from comment #151)
That's a correctable level 1 instruction cache error. The hardware should
automagically correct it and it should not affect proper
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #159 from Mark Millard ---
(In reply to Nils Beyer from comment #156)
Since the Ryzen itself supports ECC memory
I do not know if that would automatically
cause a report that indicates ECC support
overall
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #158 from Mark Millard ---
(In reply to Nils Beyer from comment #150)
For the problem:
": jemalloc_arena.c:821: Failed assertion:
nstime_compare(>epoch, ) <= 0"
what buzilla should be used? Should it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #157 from Nils Beyer ---
(In reply to Mark Millard from comment #155)
understood, as soon as I'm certain that my system doesn't freeze/reboot
anymore, I'll tell AMD support exactly as you suggest.
BTW:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #156 from Nils Beyer ---
(In reply to Mark Millard from comment #154)
wouldn't tell "dmidecode" tell the truth (from my 16GB non-poudriere system):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #155 from Mark Millard ---
(In reply to Nils Beyer from comment #153)
The MCA reports probably should be mentioned
in interactions with AMD, including that the
change that avoids panics does not eliminate
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #154 from Mark Millard ---
(In reply to Don Lewis from comment #149)
It is my understanding that many Ryzen 7
boards allow ECC memory but do not use the ECC
functionality: either the board is not wired
or
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #153 from Nils Beyer ---
(In reply to Nils Beyer from comment #152)
they still happen - even with Don's patch...
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #152 from Nils Beyer ---
(In reply to Mark Millard from comment #151)
yes, sorry; completely forgot these MCA messages. These occur during
compilation orgies. Infrequent, but they happen. So I've put some
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #151 from Mark Millard ---
(In reply to Nils Beyer from comment #150)
Which bugzilla report does the:
---
MCA: Bank 1, Status
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #150 from Nils Beyer ---
(In reply to Don Lewis from comment #149)
> Yes, opening a new ticket would make sense.
done:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
my response to your
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #149 from Don Lewis ---
(In reply to Nils Beyer from comment #147)
Yes, opening a new ticket would make sense.
So far I have not been able to reproduce the rename failure with a synthetic
test.
To try to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #148 from Nils Beyer ---
(In reply to Nils Beyer from comment #136)
just for the record, that's the response I've sent to AMD support:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #147 from Nils Beyer ---
(In reply to Nils Beyer from comment #146)
still running for 14 hours now - no freezes/reboots. Built: 8015 - Failed: 9
Apart from the known SIGBUS Java error, I got a strange signal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #146 from Nils Beyer ---
(In reply to Nils Beyer from comment #133)
poudriere is running for 8 hours now - , 4341 built, 4 failed builds, 2 of them
due to "unable to rename temporary":
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #145 from Don Lewis ---
(In reply to rozhuk.im from comment #135)
It's sort of unknown here about how "fine" the machine check code works, but I
have seen reports of errors getting logged. It is sometimes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #144 from Don Lewis ---
(In reply to Nils Beyer from comment #136)
They left out the most important part ... shaking a rubber chicken over it.
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #143 from Don Lewis ---
(In reply to Nils Beyer from comment #138)
I seriously doubt it.
You could try writing a script that writes to and then renames files and run
multiple instances in parallel to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #142 from rozhuk...@gmail.com ---
IMHO it can fix soft fails, but not reboots.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #141 from Nils Beyer ---
(In reply to rozhuk.im from comment #137)
I wonder if these support guys ever read the URLs people tell them - probably
not.
No matter, I'm not doing as support requested; I'd like to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #140 from Nils Beyer ---
Created attachment 184714
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=184714=edit
Don's Ryzen patch - stripped to the SHAREDPAGE define only...
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #139 from Nils Beyer ---
(In reply to rozhuk.im from comment #135)
okay, the Taichi is one of the top-notch AM4 mainboards; 12+4 CPU phases -
should be plenty.
> Does FreeBSD MCE implementation works fine?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #138 from Nils Beyer ---
(In reply to Don Lewis from comment #134)
thanks for the explanations. So, that specific Ryzen bug is not responsible for
the strange compilation failures (segfaults/bus errors/unable
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #135 from rozhuk...@gmail.com ---
(In reply to Nils Beyer from comment #110)
No.
I build all my systems without jail and I do not use poudriere at all.
I never see that build fail and rebuilds magically ok.
My mobo is asrock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #134 from Don Lewis ---
(In reply to Don Lewis from comment #124)
The AMD documentation that I've found is pretty much silent about
cross-modifying code. My interpretation of the pseudo-code that I found
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #133 from Nils Beyer ---
(In reply to Nils Beyer from comment #132)
you know what? Forget that. Because 11.1-RELEASE is out, I'll start a complete
new build of all ports. And I'll reboot my system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #132 from Nils Beyer ---
poudriere finished with 56 failed builds. No system freezes or reboots so far.
*thumbsup*
I've started poudriere again to try the failed builds again; for example:
"gcc5-devel" now
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #131 from Don Lewis ---
(In reply to Don Lewis from comment #126)
A total of three ports failed this time around, gstreamer1, thunderbird, and
openoffice-devel. All were the rename failure. The total
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
Nils Beyer changed:
What|Removed |Added
Severity|Affects Only Me |Affects Some People
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #130 from Nils Beyer ---
At least, there's more activity in the AMD forum's thread. One guy has openend
a bug report in the Linux kernel bugtracker:
https://bugzilla.kernel.org/show_bug.cgi?id=196481
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #127 from Nils Beyer ---
poudriere is still building after 27 hours - but it has done that before; so
I'm not confident, yet.
50 ports failed; some because of C/C++ errors; some - especially the GO
language
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #126 from Don Lewis ---
(In reply to Nils Beyer from comment #109)
Hey, I just got this during my latest ports build run, this time during the
build of gstreamer1:
error: unable to rename temporary
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #125 from SF ---
Dude, thats ridiculous. You have no clue what you are doing, if you really want
to find out whats going on then you need some debugging on asm-level and the
specifications of this cpu.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #124 from Don Lewis ---
(In reply to Nils Beyer from comment #121)
I let it run overnight here and got 16000+ passes w/o error.
I also see the same variation:
16680: Tue Jul 25 08:04:36 PDT 2017: OK
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #123 from SF ---
And thats why i think that it is no software-problem because it is too random,
i did never reproduce it the same way like before. It's always been different.
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #122 from Don Lewis ---
(In reply to Konstantin Belousov from comment #120)
I haven't seen this particular problem since I relocated the shared page. Not
to say that the problem is gone, but it has
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #121 from Nils Beyer ---
(In reply to Don Lewis from comment #119)
> This gives mfence() some memory loads to wait for, which allows the data to
> be migrated from the core A cache. With this change, I no
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
Konstantin Belousov changed:
What|Removed |Added
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #119 from Don Lewis ---
(In reply to Nils Beyer from comment #115)
I have some suspicions about what might be going wrong with ryzen_segv_test,
but I really don't understand the memory fence /
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #118 from SF ---
Noone of us can measure the temperature of the voltage-regulation of the cpu, i
talked about this before and i did read about people who managed to add some
additional cooling to it to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #117 from Don Lewis ---
(In reply to Nils Beyer from comment #109)
When I first switched to my current motherboard, I wanted to do some before and
after comparisons of the stack guard changes. I don't
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #116 from Nils Beyer ---
(In reply to Don Lewis from comment #114)
damn, sorry, out of ideas here - Gigabyte must be using some fancy sensor chip
there...
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #115 from Nils Beyer ---
(In reply to Don Lewis from comment #113)
done:
---
- atomic_store(, 1);
+ atomic_store(, 0);
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #114 from Don Lewis ---
(In reply to Nils Beyer from comment #111)
# mbmon
No Hardware Monitor found!!
InitMBInfo: No error: 0
# superiotool -de
superiotool r4.0-2827-g1a00cf0
No Super I/O found
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #113 from Don Lewis ---
(In reply to Nils Beyer from comment #112)
Hmn ... what I though of a bug may not have been a bug after all ...
I missed the fact that that main initially set the lock, so the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #112 from Nils Beyer ---
(In reply to Don Lewis from comment #108)
patch applied - load on all cores (incl. SMT ones) is 100%. But it seems that
the loops never finish - they seem to be stuck:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #111 from Nils Beyer ---
(In reply to Don Lewis from comment #107)
are you able to read temperatures using "mbmon" or my LUA script using
"superiotool"?
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #110 from Nils Beyer ---
(In reply to rozhuk.im from comment #106)
I've often read that increasing SoC voltage helps with things. Then I ask the
mainboard vendors: if that voltage increasing is so freaking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #109 from Nils Beyer ---
A little update:
1) after 13 passes my buildkernel/buildworld system threw two of the dreaded
errors right after another - despite being patched with the maxi-version of
Don's patch:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #108 from Don Lewis ---
(In reply to Nils Beyer from comment #91)
I'm pretty sure that ryzen_segv_test is actually broken. The first iteration
of the loop in the t2 threadx() is unlocked and there is no
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #107 from Don Lewis ---
(In reply to SF from comment #104)
The temperature in my un-airconditioned office varies quite a bit and I've
never been able to correlate the observed instability with temperature.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #106 from rozhuk...@gmail.com ---
Increase V SOC to 1,1V, this fix some strange issues with videocard for me.
I have no problems with build error: world+kernel, llvm, firefox, libre office
- ok.
But I have strange reboots after
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #105 from SF ---
I tested myself various things and none of the benchmarks or heating causes the
machine to have any errors but some processes do cause this errors and they are
only processes which also
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #104 from SF ---
Yeah, but enviromental circumstances like temperatures or minor processes
running do affect this.
Noone hade sucess solving this by deactivating features like smt and so on and
such
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #103 from Don Lewis ---
(In reply to SF from comment #102)
I'm pretty sure that my machine doesn't have RAM problems. I can build ports
in an i386 jail with no problems. Without the patch, building ports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #102 from SF ---
Are you sure you arent just masking the symptoms with this? I still think it is
caused by ram.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #101 from Don Lewis ---
(In reply to Nils Beyer from comment #75)
Nothing wrong with that backtrace. Each thread gets its own stack, which is
created by thread_start().
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #100 from Nils Beyer ---
(In reply to Don Lewis from comment #97)
and I got the "unable to rename temporary" direct in the first pass on my
buildkernel/buildworld system.
So, it seems that only this single
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #99 from Nils Beyer ---
(In reply to Don Lewis from comment #97)
okay, rebuilt the kernels of my two machines with the SHAREDPAGE modification
only. And restarted the stress tests...
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #98 from Nils Beyer ---
(In reply to Don Lewis from comment #96)
unfortunately, "cpuset" doesn't help:
---
#cpuset -l 2-15 ./run.sh 16
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #97 from Don Lewis ---
(In reply to Nils Beyer from comment #95)
I've seen the "unable to rename temporary..." errors, but only on an older
version of 12.0-CURRENT. I've never seen it with r320570, which
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #96 from Don Lewis ---
(In reply to Nils Beyer from comment #91)
Since the IRET instruction seems to play a factor in this problem, and it is
supposedly microcoded, I'm hoping that a microcode fix is
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #95 from Nils Beyer ---
(In reply to Don Lewis from comment #94)
I have your complete patch running on two Ryzen machines. One is currently
poudriering packages - still running. That is the machine that always
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #94 from Don Lewis ---
My machine is still stable if I only shift the shared page location and leave
the size unchanged.
Instead of decoding the CPU type to decide on whether to do this, I'm thinking
of
101 - 200 of 288 matches
Mail list logo