https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
Eitan Adler changed:
What|Removed |Added
Status|In Progress |Closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #93 from m...@sentex.net ---
All working great since this commit for this particular bug
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
Ed Maste changed:
What|Removed |Added
Status|New |In Progress
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #92 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kib
Date: Wed Feb 14 00:31:45 UTC 2018
New revision: 329254
URL: https://svnweb.freebsd.org/changeset/base/329254
Log:
Ensure memory consistency on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #91 from m...@sentex.net ---
I just confirmed this bug happens on a my Epyc system as well. The compile hung
on the first try. A reboot with the patch applied in
https://reviews.freebsd.org/D14347
fixed the issue.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #90 from m...@sentex.net ---
(In reply to Kurt Jaeger from comment #88)
The deadlock I was running into with net/samba47 builds would happen
with and without SMT enabled. With the patch at
https://reviews.freebsd.org/D14347
I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #89 from Ed Maste ---
(In reply to Kurt Jaeger from comment #88)
I'm running with SMT disabled in BIOS still. I configured it like this while
testing/debugging this issue.
I will make sure that I have the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #88 from Kurt Jaeger ---
Can all cores be used to build packages or does it require BIOS settings
to not start the hyperthreading cores ? Any significant performance impact ?
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #87 from Ed Maste ---
(In reply to mike from comment #86)
The freebsd-hackers patch is now also available in Phabricator at
https://reviews.freebsd.org/D14347
With the D14347 patch applied to the -CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #86 from m...@sentex.net ---
The patch in
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=417183+0+archive/2018/freebsd-hackers/20180211.freebsd-hackers
seems to have fixed this issue for me in prelim testing.
On a RELENG 11
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #85 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #84)
(gdb) thread 4
[Switching to thread 4 (LWP 101503 of process 43500)]
#0 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #84 from Konstantin Belousov ---
(In reply to mike from comment #83)
It is yet another (different) lock leakage. Please switch to the Thread 4 (LWP
101503) and from the frame 1 do "print *mtx".
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #83 from m...@sentex.net ---
Created attachment 190490
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190490=edit
process that is hung in usem state
with libc path and python linked to debug libs
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #82 from Konstantin Belousov ---
(In reply to mike from comment #81)
I can't say anything without debug info. Start with the backtraces, as usual.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #81 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #79)
> BTW, if using the patch from the comment 59, is the hang reproducible ?
I got it to hang on RELENG_11 just now. Perhaps its some combo of the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #80 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #79)
re: patch 59
I will apply it by itself and try again
patch -p1 < p.59
Hmm... Looks like a unified diff to me...
The text leading up to this was:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #79 from Konstantin Belousov ---
BTW, if using the patch from the comment 59, is the hang reproducible ?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #78 from Konstantin Belousov ---
(In reply to Ed Maste from comment #77)
Ok. It could be a consequence of the discovered issue occuring in other code
fragment, it can be something else.
So I can wait for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #77 from Ed Maste ---
(In reply to Ed Maste from comment #75)
I spoke too soon; I encountered a stuck build on my threadripper in the
configuration described in comment 75.
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #76 from m...@sentex.net ---
(In reply to Ed Maste from comment #75)
Stalled out again. It managed 15 builds. My RELENG_11 box did as well after
23 builds
root@amdtestr12:/usr/ports/sysutils/dmidecode # procstat -k 34990
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #75 from Ed Maste ---
(In reply to Konstantin Belousov from comment #69)
I'm testing net/samba47 builds on my threadripper with a libc including the
patch from comment #69 applied to my work tree and it has
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #74 from Konstantin Belousov ---
(In reply to mike from comment #72)
I admit that it is strange that it hangs. It is quite possible that mfence
trick dos not work, but then the 'else' part of the patch must
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #73 from m...@sentex.net ---
(In reply to mike from comment #72)
To be safe, I am going to do a complete buildworld/kernel and repeat the tests
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #72 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #71)
Unfortunately, its back to the original behaviour where it just hangs in the
usem state
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #71 from Konstantin Belousov ---
(In reply to mike from comment #70)
Yes, just that libc patch.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #70 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #69)
OK, just this patch right ? Remove the kernel patches ?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #69 from Konstantin Belousov ---
(In reply to mike from comment #68)
Please try this, it should work and then it would be the last thing I am asking
to test.
diff --git a/lib/libc/stdio/_flock_stub.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #68 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #67)
yes and yes
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #66 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #65)
OK, I am still rebuilding world. While it rebuilds, I tried applying this patch
to a stock RELENG_11 box, and it didnt seem to help. Should I try
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #65 from Konstantin Belousov ---
(In reply to mike from comment #64)
Yes, libc must be pristine, otherwise it already hides the bug.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #64 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #63)
Thanks! I am running with a new kernel. Should I run python linked to the
unmodified libs ?
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #63 from Konstantin Belousov ---
(In reply to Konstantin Belousov from comment #62)
Try this.
diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S
index 25e3a592171..ef70eefdf37 100644
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #62 from Konstantin Belousov ---
(In reply to mike from comment #61)
Do not consider it a fix. I do not have any explanation what is going on
there.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #61 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #59)
Its managed 22 builds now without issue. Prior, I could only do 10 at most. I
have a separate RELENG_11 box as well. I take it the same patch
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #60 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #59)
I have to confess, I might have borked the previous patch and left the while
loop commented out :( I have made sure its right this time. Five
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #59 from Konstantin Belousov ---
(In reply to mike from comment #58)
Lets try a slight variation.
diff --git a/lib/libc/stdio/_flock_stub.c b/lib/libc/stdio/_flock_stub.c
index 069ed64c4e9..935bf18b529 100644
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #58 from m...@sentex.net ---
Created attachment 190431
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190431=edit
with while loop patch
funlockfile 0x80146caa0 0x80c83b800 0x0
Bus error (core dumped)
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #57 from Konstantin Belousov ---
(In reply to mike from comment #56)
Yes, that was already handled. And, the hang there is the whole system hang.
Please apply this debugging patch and try reproduce the issue
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #56 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #55)
The DragonFly commit mentioned here
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20
But I FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #55 from Konstantin Belousov ---
(In reply to mike from comment #53)
The article you linked does not provide any useful information. Nobody knows
why this knob helped.
That said, I am both disappointed and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #54 from m...@sentex.net ---
Created attachment 190430
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190430=edit
latest backtrace post kernel patch
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #53 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #52)
No luck. It survived a lot of builds, but still dumped core
funlockfile 0x80146ce48 0x80bcd1500 0x0
Bus error (core dumped)
BTW, DragonFly and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #52 from Konstantin Belousov ---
Created attachment 190428
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190428=edit
Disable RDFSBASE on zens.
This is a pure guess based on the _impression_ I get
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #51 from Konstantin Belousov ---
(In reply to mike from comment #50)
It is not the abort line that was printed for the core analyzed. I expect that
the first address printed is 0x80146cd10.
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #50 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #48)
forgot to paste
funlockfile 0x80146caa0 0x80d75ff00 0x0
Bus error (core dumped)
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #49 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #48)
(gdb) thread 1
[Switching to thread 1 (LWP 101411)]
#0 thr_kill () at thr_kill.S:3
3 RSYSCALL(thr_kill)
(gdb) list
1 #include
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #48 from Konstantin Belousov ---
(In reply to mike from comment #46)
What was printed on crash ?
>From thread 1 frame 3 please do "p *fp", "p *(fp->_fl_mutex)".
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #47 from Ed Maste ---
Do you have the message it printed before the SIGBUS as well?
(If you run it in tmux I'll attach and take a look.)
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #46 from m...@sentex.net ---
Created attachment 190408
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190408=edit
thread apply all bt on the core dump file post debug patch sig 10
Path worked!
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #45 from Konstantin Belousov ---
(In reply to mike from comment #44)
Use this instead.
diff --git a/lib/libc/stdio/_flock_stub.c b/lib/libc/stdio/_flock_stub.c
index 069ed64c4e9..0180f8f285f 100644
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #44 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #43)
its unlimited, the defaults. I changed the core pattern and tested it with
another shell script.
sysctl -w sysctl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #43 from Konstantin Belousov ---
(In reply to mike from comment #42)
Check ulimit.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #42 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #41)
It doesnt seem to be dumping core for some reason ?
root@amdtestr12:/ # cd /
root@amdtestr12:/ # find . -mtime -2h -type f -name "*.core"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #41 from Konstantin Belousov ---
(In reply to mike from comment #40)
There should be a core file from the python process somewhere. Please load it
into gdb and gather the same information (at least backtrace
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #40 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #38)
python2.7(pid 71466 uid 0) aborted: funlockfile(0x80146caa0, 0x80a718600, 0)
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #39 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #38)
# patch -p1 < p
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #38 from Konstantin Belousov ---
(In reply to mike from comment #37)
Try to apply the following debugging patch:
diff --git a/lib/libc/stdio/_flock_stub.c b/lib/libc/stdio/_flock_stub.c
index
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #37 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #36)
(gdb) print local_close
$5 = (int (*)(FILE *)) 0x801237880
(gdb) list
452Otherwise this close() will crash when flushing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #36 from Konstantin Belousov ---
(In reply to mike from comment #35)
Thank you. And please, from the same frame 5, do "print local_close".
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #35 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #33)
frame 5 has that var ?
(gdb) thread 9
[Switching to thread 9 (LWP 101309 of process 48133)]
#5 0x000800a82fb7 in close_the_file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #34 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #33)
gdb attach 48133
GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #33 from Konstantin Belousov ---
(In reply to mike from comment #32)
Perhaps you did not switched to the thread 9 before select frame ?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #32 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #31)
Its not there ?
(gdb) frame 7
#7 0x000800b55b5b in call_function (pp_stack=0x7fffde3f3148, oparg=0) at
Python/ceval.c:4341
4341
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #31 from Konstantin Belousov ---
(In reply to mike from comment #30)
Not useful, indeed.
Please from the same thread 9, change to the frame 7 and do "print local_fp",
"print *local_fp".
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #30 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #29)
(gdb) thread 9
[Switching to thread 9 (LWP 101309 of process 48133)]
#0 _umtx_op () at _umtx_op.S:3
3 RSYSCALL(_umtx_op)
(gdb) frame 6
#6
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #29 from Konstantin Belousov ---
(In reply to mike from comment #28)
Now please switch to the thread 9, and from the frame 6, do "print *f" and
"print *(f->f_fp)".
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #28 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #27)
(gdb) thread 2
[Switching to thread 2 (LWP 101302 of process 48133)]
#0 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #27 from Konstantin Belousov ---
(In reply to mike from comment #26)
Please switch to the Thread 2 (LWP 101302) and do:
- on frame 2, "print *curthread" and "print *m"
- on frame 4, "print *mutex"
- on frame
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #26 from m...@sentex.net ---
Created attachment 190385
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190385=edit
thread apply all bt
info thread at the end
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #25 from Konstantin Belousov ---
It seems that gdb can do 'thread apply all bt'. At least my copy of gdb 8.1
can.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #24 from Mark Millard ---
(In reply to mike from comment #23)
Try:
(gdb) thread 11
[Switching to thread 11 (LWP 101275 of process 38415)]
#0 _umtx_op_err () at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #23 from m...@sentex.net ---
(In reply to Mark Millard from comment #22)
Hi,
I installed gdb from the ports as it doesnt seem to be installed by default in
HEAD anymore ?
bt thread 11 doesnt seem to work in 8.x
(gdb) bt thread
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #22 from Mark Millard ---
(In reply to mike from comment #21)
It looks like after:
(gdb) thread 11
[Switching to thread 11 (LWP 101275 of process 38415)]
#0 _umtx_op_err () at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #21 from m...@sentex.net ---
Created attachment 190376
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190376=edit
bt and listing of threads
Note, this box is attached off zoo if you want to log in and look around
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #20 from m...@sentex.net ---
(In reply to mike from comment #19)
It took a few more runs, but after 10 builds, the build hung as usual.
attaching the output
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #19 from m...@sentex.net ---
(In reply to Konstantin Belousov from comment #18)
Interesting. With -g -O0, I dont get the build hangs. So far in a loop, the
port has built 9 times. Normally, it hangs 100% of the time
Could be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #18 from Konstantin Belousov ---
(In reply to mike from comment #17)
Rebuild libthr with flags "-g -O0" and reinstall it.
I need: backtrace of all threads in the process. Plain "bt" for each thread is
enough,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #17 from m...@sentex.net ---
Created attachment 190365
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190365=edit
gdb output of stuck python process
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #16 from m...@sentex.net ---
(In reply to Eugene Grosbein from comment #15)
I built world with
/etc/make.conf
KERNCONF=DEBUG
DEBUG_FLAGS=-g
WITH_DEBUG=YES
and then rebuilt python. I am not sure what needs to be done in the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #15 from Eugene Grosbein ---
(In reply to Konstantin Belousov from comment #14)
Thanks. I personally do not have such problem nor AMD hardware to reproduce
that but hope Mike will benefit from this hint.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #14 from Konstantin Belousov ---
(In reply to Eugene Grosbein from comment #12)
Compile everything with debugging symbols, i.e. rtld/libc/libthr, and the
application (python interpreter).
Than take the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #13 from m...@sentex.net ---
(In reply to Eugene Grosbein from comment #11)
Re: timing issues, I did try it on a number of different Intel CPUs ( eg
Xeon(R) CPU E5-1650) of various core densities and speeds and was not able to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
Eugene Grosbein changed:
What|Removed |Added
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #11 from Eugene Grosbein ---
(In reply to mike from comment #9)
These threads locked in "umtxn" state remind me of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 that revealed
long-standing bugs in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #10 from Ed Maste ---
(In reply to mike from comment #9)
> Hi, apart from
> KDB_UNATTENDED
> these options are all part of a standard GENERIC kernel on HEAD, no ?
They are, yes. I suspect we're going to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #9 from m...@sentex.net ---
(In reply to Eugene Grosbein from comment #7)
Hi, apart from
KDB_UNATTENDED
these options are all part of a standard GENERIC kernel on HEAD, no ?
I added that as well as BREAK_TO_DEBUGGER. The kernel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #8 from Mark Millard ---
I got a different example:
Threadripper 1950X context, head -r327485 doing a adm64 -> aarch64
cross build of ports: hung up in uwait. The context is also:
Running under
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #7 from Eugene Grosbein ---
Could you please re-do your test using kernel with following options added? Be
ready for panic, though and prepare to collect crashdump:
options KDB
options
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #6 from Andriy Gapon ---
(In reply to Ed Maste from comment #3)
What's nice about this problem is it is debuggable. The build hangs, but the
system doesn't. So, it should be possible to examine the system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
Mark Millard changed:
What|Removed |Added
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #4 from m...@sentex.net ---
I tried pretty well every combo on my Ryzen board as well-- SMT on / off, No
HT, cores only, etc with no change.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #3 from Ed Maste ---
I have reproduced this on my Threadripper, both with and without SMT disabled
in BIOS.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #2 from m...@sentex.net ---
Tried with
# sysctl -a kern.sched.name
kern.sched.name: 4BSD
but not obvious difference.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
--- Comment #1 from m...@sentex.net ---
Tried also with kern.eventtimer.periodic=1 but it made no difference that I
could tell. Process hung as usual
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225584
Bug ID: 225584
Summary: Various compile process hang on Ryzen, but not on
Intel
Product: Base System
Version: CURRENT
Hardware: amd64
OS: Any
95 matches
Mail list logo